Back to CVE records
High 7.8Published Aug 10, 2026

CVE-2026-68147fscrypt: Avoid dynamic allocation in fscrypt_get_devices()

Updated under an hour ago ()

Does this affect you?

It affects Linux. Add what you run to find out whether that includes you.

No exploitation reported and no EPSS estimate yet.

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.)

CVSS
7.8 HIGH (v3.1, CNA)CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Weakness (CWE)
Not given
Known exploited
Not in CISA's KEV catalog
EPSS (exploitation in the next 30 days)
Not loaded for this CVE
Assigned by
Linux
NVD analysis
Received
Record last updated
Aug 19, 2026
First seen by InfoSec Signals
Oct 9, 2026

Affected products

Affected products
Linux Linux
linux:linux (from the name)
from 22e9947a4b2ba255888541bd0111cf00b9b16586 before bab016bb80d74a9d1f7d4121a7fc1cb529b470e0; from 22e9947a4b2ba255888541bd0111cf00b9b16586 before 4462ac3d90e897dda52ce4b6af2d526ddae835a8; from 22e9947a4b2ba255888541bd0111cf00b9b16586 before 97a688563be71ec6fefc071aff69a66c69dbe244; from 22e9947a4b2ba255888541bd0111cf00b9b16586 before 81ea8e8221853950c47dac7164f27c63a96f8f86; from 22e9947a4b2ba255888541bd0111cf00b9b16586 before bc2d630296e0e049210ec05ff08459a6893ae749; 22e9947a4b2ba255888541bd0111cf00b9b16586 builds before 6fe4e4b8259e1330945b5f3c9476e08473b8e0e8
CNA record

References

The CVE record is authoritative. Products marked “from the name” were identified from the CNA's free-text names, not a CPE, and are matched less certainly. This product uses the NVD API but is not endorsed or certified by the NVD.

Your cookie choices
We use essential cookies to run this site, and, only with your consent, an advertising cookie from Google to measure whether our ads lead to sign-ups and subscriptions. See our for details.