CVE-2026-68147

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 filesystems 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 its invoked for inode eviction under direct reclaim.

• fscrypt_destroy_inline_crypt_key() doesnt 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, lets 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 wont scale up to large number of block devices. For that wed 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 wont be needed.)

Affected Software

References

• https://git.kernel.org/stable/c/4462ac3d90e897dda52ce4b6af2d526ddae835a8
• https://git.kernel.org/stable/c/6fe4e4b8259e1330945b5f3c9476e08473b8e0e8
• https://git.kernel.org/stable/c/81ea8e8221853950c47dac7164f27c63a96f8f86
• https://git.kernel.org/stable/c/97a688563be71ec6fefc071aff69a66c69dbe244
• https://git.kernel.org/stable/c/bc2d630296e0e049210ec05ff08459a6893ae749