CVE-2026-68148: Linux kernel · fscrypt: Add missing superblock check in find_or_insert_direct_key()
Affects Linux kernelSource CVE Database V5
Not known to be exploited · CVSS 7.8 High · fixed in deff41898a5ae3a47db5fa1896a494aa95efda5d : patch Linux kernel soon.
Data as of 26 Oct 2026, 14:05 UTC
- EPSS
- 0.09% chance of exploitation in 30 days – higher than 0% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
- CISA SSVC
- Exploitation
- No evidence of active exploitation and no public proof of concept
- Automatable
- Attackers cannot reliably automate steps 1–4 of the kill chain
- Technical impact
- Total control over the software or total information disclosure
CISA SSVC assessment, 2026-10-16.
- Patch
- Available – fixed in deff41898a5ae3a47db5fa1896a494aa95efda5d, b5fa40226e71c17847b9ff2816c6ca4133d0d994, 330249609b70778094a7a36f5b6bcfa6362121d4 +3
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HExploitation evidence
Disclosed: evidence found.
CVE published 10 Aug 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.
What to do
Upgrade to a fixed release listed under Affected software.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
Description
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.
References
- git.kernel.org/stable/c/965b5bc8cf5031225e057979ce660fec2bd5fbfc (opens in a new tab)
- git.kernel.org/stable/c/330249609b70778094a7a36f5b6bcfa6362121d4 (opens in a new tab)
- git.kernel.org/stable/c/deff41898a5ae3a47db5fa1896a494aa95efda5d (opens in a new tab)
- git.kernel.org/stable/c/95376fe9c145be35566991df99c53134943d992f (opens in a new tab)
- git.kernel.org/stable/c/466f187b501a5ac8e1ea2ccf3ccd5c46108d8830 (opens in a new tab)
- git.kernel.org/stable/c/b5fa40226e71c17847b9ff2816c6ca4133d0d994 (opens in a new tab)