Answer in brief
CVE-2026-68148 records a Unknown severity vulnerability in fscrypt: Add missing superblock check in find_or_insert_direct_key(). The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=22e9947a4b2ba255888541bd0111cf00b9b16586 <330249609b70778094a7a36f5b6bcfa6362121d4 || >=22e9947a4b2ba255888541bd0111cf00b9b16586 <deff41898a5ae3a47db5fa1896a494aa95efda5d || >=22e9947a4b2ba255888541bd0111cf00b9b16586 <95376fe9c145be35566991df99c53134943d992f || >=22e9947a4b2ba255888541bd0111cf00b9b16586 <466f187b501a5ac8e1ea2ccf3ccd5c46108d8830 || >=22e9947a4b2ba255888541bd0111cf00b9b16586 <b5fa40226e71c17847b9ff2816c6ca4133d0d994 | 330249609b70778094a7a36f5b6bcfa6362121d4, deff41898a5ae3a47db5fa1896a494aa95efda5d, 95376fe9c145be35566991df99c53134943d992f, 466f187b501a5ac8e1ea2ccf3ccd5c46108d8830, b5fa40226e71c17847b9ff2816c6ca4133d0d994 |
| Linux/Linuxgeneric | 6.1 | Not reported |
Published upstream
Aug 10, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 10, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 10, 2026
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.
Quoted source text, attributed separately from HOL analysis.
Answer in brief
CVE-2026-68148 records a Unknown severity vulnerability in fscrypt: Add missing superblock check in find_or_insert_direct_key(). The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=22e9947a4b2ba255888541bd0111cf00b9b16586 <330249609b70778094a7a36f5b6bcfa6362121d4 || >=22e9947a4b2ba255888541bd0111cf00b9b16586 <deff41898a5ae3a47db5fa1896a494aa95efda5d || >=22e9947a4b2ba255888541bd0111cf00b9b16586 <95376fe9c145be35566991df99c53134943d992f || >=22e9947a4b2ba255888541bd0111cf00b9b16586 <466f187b501a5ac8e1ea2ccf3ccd5c46108d8830 || >=22e9947a4b2ba255888541bd0111cf00b9b16586 <b5fa40226e71c17847b9ff2816c6ca4133d0d994 | 330249609b70778094a7a36f5b6bcfa6362121d4, deff41898a5ae3a47db5fa1896a494aa95efda5d, 95376fe9c145be35566991df99c53134943d992f, 466f187b501a5ac8e1ea2ccf3ccd5c46108d8830, b5fa40226e71c17847b9ff2816c6ca4133d0d994 |
| Linux/Linuxgeneric | 6.1 | Not reported |
Published upstream
Aug 10, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 10, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 10, 2026
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.
Quoted source text, attributed separately from HOL analysis.