CVE-2026-68147 (GCVE-0-2026-68147)
Vulnerability from cvelistv5
Published
2026-08-10 11:59
Modified
2026-08-19 16:30
Severity ?
VLAI Severity ?
EPSS score ?
Summary
In the Linux kernel, the following vulnerability has been resolved:
fscrypt: Avoid dynamic allocation in fscrypt_get_devices()
When a blk_crypto_key starts being used or is evicted, fs/crypto/ calls
fscrypt_get_devices() to get the filesystem's list of block devices,
then iterates over them and calls blk_crypto_config_supported(),
blk_crypto_start_using_key(), or blk_crypto_evict_key() on each one.
Currently, the block device pointers are placed in a dynamically
allocated array. This dynamic allocation is problematic because:
- It can fail, especially at the fscrypt_destroy_inline_crypt_key() call
site when it's invoked for inode eviction under direct reclaim.
- fscrypt_destroy_inline_crypt_key() doesn't handle the failure. It
just zeroizes and frees the blk_crypto_key without calling
blk_crypto_evict_key(). That causes a use-after-free.
For now, let's fix this in the straightforward and easily-backportable
way by switching to an on-stack array. Currently the fscrypt
multi-device functionality is used only by f2fs, which has a hardcoded
limit of 8 block devices. An on-stack array works fine for that.
(Of course, this solution won't scale up to large number of block
devices. For that we'd need a different solution, like moving the block
device iteration into the filesystem. Or in the case of btrfs, which
will only support blk-crypto-fallback, we should make it just call
blk-crypto-fallback directly, so the block devices won't be needed.)
References
Impacted products
| Vendor | Product | Version | ||
|---|---|---|---|---|
| Linux | Linux |
Version: 22e9947a4b2ba255888541bd0111cf00b9b16586 Version: 22e9947a4b2ba255888541bd0111cf00b9b16586 Version: 22e9947a4b2ba255888541bd0111cf00b9b16586 Version: 22e9947a4b2ba255888541bd0111cf00b9b16586 Version: 22e9947a4b2ba255888541bd0111cf00b9b16586 Version: 22e9947a4b2ba255888541bd0111cf00b9b16586 |
||
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"fs/crypto/inline_crypt.c",
"fs/f2fs/super.c",
"include/linux/fscrypt.h"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "bab016bb80d74a9d1f7d4121a7fc1cb529b470e0",
"status": "affected",
"version": "22e9947a4b2ba255888541bd0111cf00b9b16586",
"versionType": "git"
},
{
"lessThan": "4462ac3d90e897dda52ce4b6af2d526ddae835a8",
"status": "affected",
"version": "22e9947a4b2ba255888541bd0111cf00b9b16586",
"versionType": "git"
},
{
"lessThan": "97a688563be71ec6fefc071aff69a66c69dbe244",
"status": "affected",
"version": "22e9947a4b2ba255888541bd0111cf00b9b16586",
"versionType": "git"
},
{
"lessThan": "81ea8e8221853950c47dac7164f27c63a96f8f86",
"status": "affected",
"version": "22e9947a4b2ba255888541bd0111cf00b9b16586",
"versionType": "git"
},
{
"lessThan": "bc2d630296e0e049210ec05ff08459a6893ae749",
"status": "affected",
"version": "22e9947a4b2ba255888541bd0111cf00b9b16586",
"versionType": "git"
},
{
"lessThan": "6fe4e4b8259e1330945b5f3c9476e08473b8e0e8",
"status": "affected",
"version": "22e9947a4b2ba255888541bd0111cf00b9b16586",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"fs/crypto/inline_crypt.c",
"fs/f2fs/super.c",
"include/linux/fscrypt.h"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "6.1"
},
{
"lessThan": "6.1",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.183",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.148",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.101",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.18.*",
"status": "unaffected",
"version": "6.18.42",
"versionType": "semver"
},
{
"lessThanOrEqual": "7.1.*",
"status": "unaffected",
"version": "7.1.6",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "7.2",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.1.183",
"versionStartIncluding": "6.1",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6.148",
"versionStartIncluding": "6.1",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.12.101",
"versionStartIncluding": "6.1",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.18.42",
"versionStartIncluding": "6.1",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "7.1.6",
"versionStartIncluding": "6.1",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "7.2",
"versionStartIncluding": "6.1",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nfscrypt: Avoid dynamic allocation in fscrypt_get_devices()\n\nWhen a blk_crypto_key starts being used or is evicted, fs/crypto/ calls\nfscrypt_get_devices() to get the filesystem\u0027s list of block devices,\nthen iterates over them and calls blk_crypto_config_supported(),\nblk_crypto_start_using_key(), or blk_crypto_evict_key() on each one.\n\nCurrently, the block device pointers are placed in a dynamically\nallocated array. This dynamic allocation is problematic because:\n\n- It can fail, especially at the fscrypt_destroy_inline_crypt_key() call\n site when it\u0027s invoked for inode eviction under direct reclaim.\n\n- fscrypt_destroy_inline_crypt_key() doesn\u0027t handle the failure. It\n just zeroizes and frees the blk_crypto_key without calling\n blk_crypto_evict_key(). That causes a use-after-free.\n\nFor now, let\u0027s fix this in the straightforward and easily-backportable\nway by switching to an on-stack array. Currently the fscrypt\nmulti-device functionality is used only by f2fs, which has a hardcoded\nlimit of 8 block devices. An on-stack array works fine for that.\n\n(Of course, this solution won\u0027t scale up to large number of block\ndevices. For that we\u0027d need a different solution, like moving the block\ndevice iteration into the filesystem. Or in the case of btrfs, which\nwill only support blk-crypto-fallback, we should make it just call\nblk-crypto-fallback directly, so the block devices won\u0027t be needed.)"
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 7.8,
"baseSeverity": "HIGH",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"scenarios": [
{
"lang": "en",
"value": "AV:L - The bug is reached only via local fscrypt/inline-crypto teardown (fscrypt_destroy_inline_crypt_key) during inode eviction or key removal on ext4/f2fs, triggered by local syscalls/ioctls and file operations, not by any network-facing kernel service.\nAC:L - An attacker can reliably induce the kmalloc failure by creating memory pressure while closing encrypted inodes or removing v2 fscrypt keys, especially under direct reclaim where the commit notes this path fails; both sides of the race are attacker-controlled.\nPR:L - Exploitation requires only a local unprivileged user on an inlinecrypt-mounted filesystem: v2 FS_IOC_ADD/REMOVE_ENCRYPTION_KEY are unprivileged, and the attacker can create/close their own encrypted files to drive fscrypt_put_encryption_info into the buggy destroy path.\nUI:N - No victim interaction is required; the attacker triggers memory pressure and encrypted inode/key teardown themselves through normal local file and fscrypt ioctl operations on systems already mounted with inline encryption.\nS:U - Impact is confined to kernel memory corruption and privilege escalation within the same kernel security domain; this is not a VM escape, IOMMU bypass, or other cross-authority boundary violation.\nC:H - Skipping blk_crypto_evict_key before kfree_sensitive leaves dangling slot-\u003ekey/bio_crypt_ctx pointers to a freed blk_crypto_key (containing raw key bytes), a classic use-after-free that enables arbitrary kernel memory disclosure and heap grooming.\nI:H - The use-after-free of blk_crypto_key structures still registered in blk-crypto keyslot hash tables can be leveraged for heap corruption and control-flow hijacking, yielding arbitrary kernel write or local privilege escalation primitives.\nA:H - Dereferencing the prematurely freed blk_crypto_key during subsequent block I/O or keyslot lookups can cause kernel oops/panic; use-after-free in the block crypto path also inherently threatens system availability even before full exploitation."
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-08-19T16:30:11.166Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/bab016bb80d74a9d1f7d4121a7fc1cb529b470e0"
},
{
"url": "https://git.kernel.org/stable/c/4462ac3d90e897dda52ce4b6af2d526ddae835a8"
},
{
"url": "https://git.kernel.org/stable/c/97a688563be71ec6fefc071aff69a66c69dbe244"
},
{
"url": "https://git.kernel.org/stable/c/81ea8e8221853950c47dac7164f27c63a96f8f86"
},
{
"url": "https://git.kernel.org/stable/c/bc2d630296e0e049210ec05ff08459a6893ae749"
},
{
"url": "https://git.kernel.org/stable/c/6fe4e4b8259e1330945b5f3c9476e08473b8e0e8"
}
],
"title": "fscrypt: Avoid dynamic allocation in fscrypt_get_devices()",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2026-68147",
"datePublished": "2026-08-10T11:59:12.308Z",
"dateReserved": "2026-07-30T09:28:09.371Z",
"dateUpdated": "2026-08-19T16:30:11.166Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
Loading…
Loading…
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.
Loading…
Loading…