fscrypt: Avoid dynamic allocation in fscrypt_get_devices()
Summary
| CVE | CVE-2026-68147 |
| State | PUBLISHED |
| Assigner | Linux |
| Source Priority | CVE Program / NVD first with legacy fallback |
| Published | 2026-08-10 13:20:00 UTC |
| Updated | 2026-08-10 13:20:00 UTC |
| Description | 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.) |
Vendor Declared Affected Products
| Source | Vendor | Product | Version | Platforms |
|---|
| CNA |
Linux |
Linux |
affected 22e9947a4b2ba255888541bd0111cf00b9b16586 4462ac3d90e897dda52ce4b6af2d526ddae835a8 git |
Not specified |
| CNA |
Linux |
Linux |
affected 22e9947a4b2ba255888541bd0111cf00b9b16586 97a688563be71ec6fefc071aff69a66c69dbe244 git |
Not specified |
| CNA |
Linux |
Linux |
affected 22e9947a4b2ba255888541bd0111cf00b9b16586 81ea8e8221853950c47dac7164f27c63a96f8f86 git |
Not specified |
| CNA |
Linux |
Linux |
affected 22e9947a4b2ba255888541bd0111cf00b9b16586 bc2d630296e0e049210ec05ff08459a6893ae749 git |
Not specified |
| CNA |
Linux |
Linux |
affected 22e9947a4b2ba255888541bd0111cf00b9b16586 6fe4e4b8259e1330945b5f3c9476e08473b8e0e8 git |
Not specified |
| CNA |
Linux |
Linux |
affected 6.1 |
Not specified |
| CNA |
Linux |
Linux |
unaffected 6.1 semver |
Not specified |
| CNA |
Linux |
Linux |
unaffected 6.6.148 6.6.* semver |
Not specified |
| CNA |
Linux |
Linux |
unaffected 6.12.101 6.12.* semver |
Not specified |
| CNA |
Linux |
Linux |
unaffected 6.18.42 6.18.* semver |
Not specified |
| CNA |
Linux |
Linux |
unaffected 7.1.6 7.1.* semver |
Not specified |
| CNA |
Linux |
Linux |
unaffected 7.2-rc5 * original_commit_for_fix |
Not specified |
References
| Reference | Source | Link | Tags |
|---|
| git.kernel.org/stable/c/4462ac3d90e897dda52ce4b6af2d526ddae835a8 |
416baaa9-dc9f-4396-8d5f-8c081fb06d67 |
git.kernel.org |
|
| git.kernel.org/stable/c/81ea8e8221853950c47dac7164f27c63a96f8f86 |
416baaa9-dc9f-4396-8d5f-8c081fb06d67 |
git.kernel.org |
|
| git.kernel.org/stable/c/6fe4e4b8259e1330945b5f3c9476e08473b8e0e8 |
416baaa9-dc9f-4396-8d5f-8c081fb06d67 |
git.kernel.org |
|
| git.kernel.org/stable/c/97a688563be71ec6fefc071aff69a66c69dbe244 |
416baaa9-dc9f-4396-8d5f-8c081fb06d67 |
git.kernel.org |
|
| git.kernel.org/stable/c/bc2d630296e0e049210ec05ff08459a6893ae749 |
416baaa9-dc9f-4396-8d5f-8c081fb06d67 |
git.kernel.org |
|
| CVE Program record |
CVE.ORG |
www.cve.org |
canonical |
| NVD vulnerability detail |
NVD |
nvd.nist.gov |
canonical, analysis |
No vendor comments have been submitted for this CVE.
There are currently no legacy QID mappings associated with this CVE.