GHSA-R7WR-XW9J-768V
Vulnerability from github – Published: 2026-08-10 15:33 – Updated: 2026-08-19 18:32In 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.
{
"affected": [],
"aliases": [
"CVE-2026-68148"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-10T13:20:00Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nfscrypt: Add missing superblock check in find_or_insert_direct_key()\n\nThe legacy \u0027fscrypt_direct_keys\u0027 table caches master keys that are used\nby v1 encryption policies that have FSCRYPT_POLICY_FLAG_DIRECT_KEY.\nIt\u0027s just a global table for all filesystems (since the keys can be\nprovided by the legacy process-subscribed keyrings mechanism, which\nmakes it difficult to reuse super_block::s_master_keys).\n\nThe entries in it (\u0027struct fscrypt_direct_key\u0027) do contain a super_block\npointer, though, for passing to fscrypt_destroy_inline_crypt_key() when\nthe last inode that references the key is evicted.\n\nHowever, when finding the fscrypt_direct_key for an inode, we weren\u0027t\nactually comparing the super_block pointer. As a result, inodes with\ndifferent super_blocks could point to the same fscrypt_direct_key. That\ncould extend the lifetime of a fscrypt_direct_key beyond the\nsuper_block it points to, causing a use-after-free later.\n\nFix this by creating distinct fscrypt_direct_key structs for distinct\nsuper_block structs.\n\nNote that this problem doesn\u0027t exist in the v2 policy equivalent\n(\"per-mode keys\"), since the data structures there are per super_block.",
"id": "GHSA-r7wr-xw9j-768v",
"modified": "2026-08-19T18:32:07Z",
"published": "2026-08-10T15:33:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-68148"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/330249609b70778094a7a36f5b6bcfa6362121d4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/466f187b501a5ac8e1ea2ccf3ccd5c46108d8830"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/95376fe9c145be35566991df99c53134943d992f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/965b5bc8cf5031225e057979ce660fec2bd5fbfc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b5fa40226e71c17847b9ff2816c6ca4133d0d994"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/deff41898a5ae3a47db5fa1896a494aa95efda5d"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.