CVE-2023-53536: blk-crypto: make blk_crypto_evict_key() more robust
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.
Security readout for executives and security teams
Plain-English summary
A Linux block-encryption key cleanup error can leave a freed key referenced internally. If an unusual key-eviction failure occurs, later kernel activity may access that freed memory, potentially enabling system compromise or a crash. The triggering errors are described as conditions that should not normally occur.
Executive priority
Treat as a high-priority kernel maintenance issue, especially on multi-user or shared-workload Linux systems using block encryption. Schedule vendor-approved updates through normal emergency patching controls. Immediate crisis action is not supported by the evidence because exploitation is unconfirmed and the vulnerable state depends on exceptional failures.
Technical view
blk_crypto_evict_key() could return after detecting an in-use key or keyslot eviction failure without unlinking the key from keyslot-management structures. Its caller could then free the blk_crypto_key. A later blk_crypto_reprogram_all_keys() operation could access the dangling reference, causing a kernel use-after-free. Stable fixes unlink the key even when eviction fails.
Likely exposure
Exposure applies to affected Linux kernel versions where the blk-crypto key-management path is used and the exceptional eviction error occurs. The bundle identifies affected releases beginning with 5.8 and lists several branch boundaries, but distribution kernels may contain backports. Confirm using vendor advisories and fix-commit ancestry.
Exploitation context
The CVSS vector describes a local, low-privilege attack requiring no user interaction, with potentially high confidentiality, integrity, and availability impact. The prerequisite error conditions reportedly should not occur normally. The CVE is not in KEV, and the supplied evidence does not establish active or public exploitation.
Researcher notes
The flaw is conditional memory unsafety caused by mismatched failure assumptions between eviction and cleanup callers. Assess reachability of both the initial eviction failure and later key reprogramming. The source bundle supplies multiple stable-tree commits but no demonstrated trigger, proof of exploitation, CWE assignment, or distribution-specific package mapping.
Mitigation direction
Update to a vendor-supported kernel containing the applicable stable fix.
Check distribution advisories because kernel fixes may be backported without changing upstream-style version numbers.
Prioritize systems permitting untrusted local users or workloads if they use affected blk-crypto functionality.
Follow vendor guidance when an updated kernel is not immediately available.
Validation and detection
Inventory kernel versions and distribution package revisions across Linux systems.
Compare kernel source or vendor backports with the applicable stable fix commits.
Determine whether affected systems exercise blk-crypto key management paths.
Confirm the updated kernel is running after installation and reboot.
Monitor vendor advisories for revised affected-version or exploitation information.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2023-53536 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
1CVSS vectors
3Timeline events
0ADP providers
7Source links
CVSS vector scores
1 official score
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.