The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applicationsThere is no fixed version for RHEL:9
kernel-rt-64k-devel
.
Note: Versions mentioned in the description apply only to the upstream kernel-rt-64k-devel
package and not the kernel-rt-64k-devel
package as distributed by RHEL
.
See How to fix?
for RHEL:9
relevant fixed versions and status.
In the Linux kernel, the following vulnerability has been resolved:
blk-crypto: make blk_crypto_evict_key() more robust
If blk_crypto_evict_key() sees that the key is still in-use (due to a bug) or that ->keyslot_evict failed, it currently just returns while leaving the key linked into the keyslot management structures.
However, blk_crypto_evict_key() is only called in contexts such as inode eviction where failure is not an option. So actually the caller proceeds with freeing the blk_crypto_key regardless of the return value of blk_crypto_evict_key().
These two assumptions don't match, and the result is that there can be a use-after-free in blk_crypto_reprogram_all_keys() after one of these errors occurs. (Note, these errors shouldn't happen; we're just talking about what happens if they do anyway.)
Fix this by making blk_crypto_evict_key() unlink the key from the keyslot management structures even on failure.
Also improve some comments.