CVE-2026-68147
HighCVSS 7.8Exploitation Probability (EPSS)
Low risk3th percentile - higher than 3% of all known CVEs
Summary
In the Linux kernel's fscrypt module, fscrypt_get_devices() uses dynamic allocation for an array of block device pointers, which can fail, especially during key eviction under direct reclaim. The unhandled failure leads to a use-after-free.
Risk Assessment
The risk includes the possibility of system crashes or privilege escalation due to a use-after-free error, particularly in systems with multiple block devices (e.g., f2fs).
Recommendation
It is recommended to apply the kernel patch that replaces dynamic allocation with an on-stack array (limited to 8 devices), and to update systems.
Original NVD description (English source)
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.)