Re: [PATCH] fscrypt: Avoid dynamic allocation in fscrypt_get_devices()

[Eric Biggers <ebiggers@kernel.org>]

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: stable@vger.kernel.org
> Signed-off-by: Eric Biggers <ebiggers@kernel.org>
> ---

Applied to https://git.kernel.org/pub/scm/fs/fscrypt/linux.git/log/?h=for-current

- Eric