CVE-2026-68147

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fscrypt: Avoid dynamic allocation in fscrypt_get_devices()<br /> <br /> When a blk_crypto_key starts being used or is evicted, fs/crypto/ calls<br /> fscrypt_get_devices() to get the filesystem&amp;#39;s list of block devices,<br /> then iterates over them and calls blk_crypto_config_supported(),<br /> blk_crypto_start_using_key(), or blk_crypto_evict_key() on each one.<br /> <br /> Currently, the block device pointers are placed in a dynamically<br /> allocated array. This dynamic allocation is problematic because:<br /> <br /> - It can fail, especially at the fscrypt_destroy_inline_crypt_key() call<br /> site when it&amp;#39;s invoked for inode eviction under direct reclaim.<br /> <br /> - fscrypt_destroy_inline_crypt_key() doesn&amp;#39;t handle the failure. It<br /> just zeroizes and frees the blk_crypto_key without calling<br /> blk_crypto_evict_key(). That causes a use-after-free.<br /> <br /> For now, let&amp;#39;s fix this in the straightforward and easily-backportable<br /> way by switching to an on-stack array. Currently the fscrypt<br /> multi-device functionality is used only by f2fs, which has a hardcoded<br /> limit of 8 block devices. An on-stack array works fine for that.<br /> <br /> (Of course, this solution won&amp;#39;t scale up to large number of block<br /> devices. For that we&amp;#39;d need a different solution, like moving the block<br /> device iteration into the filesystem. Or in the case of btrfs, which<br /> will only support blk-crypto-fallback, we should make it just call<br /> blk-crypto-fallback directly, so the block devices won&amp;#39;t be needed.)