On Sat, Jul 18, 2026 at 10:56:02PM -0700, Eric Biggers wrote:
> 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.)
>
> Fixes: 22e9947a4b2b ("fscrypt: stop holding extra request_queue references")
> Cc: [email protected]
> Signed-off-by: Eric Biggers <[email protected]>
> ---
Applied to
https://git.kernel.org/pub/scm/fs/fscrypt/linux.git/log/?h=for-current
- Eric
