CVE-2026-68148
HighCVSS 7.8Exploitation Probability (EPSS)
Low risk1th percentile - higher than 1% of all known CVEs
Summary
In the Linux kernel's fscrypt module, in find_or_insert_direct_key(), there is a missing comparison of the super_block pointer, causing entries in the global fscrypt_direct_keys table to be shared between different super_blocks. This can lead to a use-after-free when a key is evicted after the super_block's lifetime ends.
Risk Assessment
The risk includes the possibility of a use-after-free error, which could lead to system crashes, privilege escalation, or data leakage.
Recommendation
It is recommended to apply the kernel patch that creates separate fscrypt_direct_key structures for different super_blocks, and to update systems.
Original NVD description (English source)
In the Linux kernel, the following vulnerability has been resolved: fscrypt: Add missing superblock check in find_or_insert_direct_key() The legacy 'fscrypt_direct_keys' table caches master keys that are used by v1 encryption policies that have FSCRYPT_POLICY_FLAG_DIRECT_KEY. It's just a global table for all filesystems (since the keys can be provided by the legacy process-subscribed keyrings mechanism, which makes it difficult to reuse super_block::s_master_keys). The entries in it ('struct fscrypt_direct_key') do contain a super_block pointer, though, for passing to fscrypt_destroy_inline_crypt_key() when the last inode that references the key is evicted. However, when finding the fscrypt_direct_key for an inode, we weren't actually comparing the super_block pointer. As a result, inodes with different super_blocks could point to the same fscrypt_direct_key. That could extend the lifetime of a fscrypt_direct_key beyond the super_block it points to, causing a use-after-free later. Fix this by creating distinct fscrypt_direct_key structs for distinct super_block structs. Note that this problem doesn't exist in the v2 policy equivalent ("per-mode keys"), since the data structures there are per super_block.