Files
linux/include/linux
Eric Biggers 6fe4e4b825 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.)

Fixes: 22e9947a4b ("fscrypt: stop holding extra request_queue references")
Cc: stable@vger.kernel.org
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://sashiko.dev/#/patchset/20260713023708.9245-1-ebiggers%40kernel.org
Reviewed-by: Christoph Hellwig <hch@lst.de>
Link: https://patch.msgid.link/20260719055602.78828-1-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2026-07-20 10:39:24 -07:00
..
2026-02-11 13:44:47 +01:00
2026-04-02 15:52:49 +02:00
2026-03-18 15:11:40 +05:30
2026-05-21 13:04:42 +02:00
2026-03-19 23:55:27 +01:00
2026-06-17 11:32:14 +01:00
2026-05-28 21:24:54 -07:00
2026-01-20 19:44:19 -08:00
2026-06-16 08:53:53 -07:00
2026-04-03 16:53:50 -04:00
2026-06-07 10:03:01 -07:00
2026-03-02 17:08:05 -05:00
2026-05-28 17:45:46 -07:00
2026-06-05 00:34:55 -04:00
2026-05-18 11:16:29 +02:00
2026-05-19 17:26:07 +02:00
2026-05-28 11:36:59 -04:00
2026-04-07 17:38:07 +02:00
2026-02-27 16:40:16 +01:00
2026-06-05 17:46:17 -07:00
2026-01-12 16:52:09 +01:00
2026-05-28 21:24:43 -07:00
2026-02-06 07:29:14 -07:00
2026-07-01 15:26:47 +02:00
2026-06-10 10:42:55 -04:00
2026-04-05 13:53:28 -07:00
2026-01-11 06:09:11 -10:00
2026-04-01 10:19:41 +02:00
2026-04-03 16:53:50 -04:00
2026-04-03 16:53:50 -04:00
2026-03-18 09:59:57 +00:00
2026-04-05 13:53:00 -07:00
2026-01-26 20:02:27 -08:00
2026-03-08 11:06:53 +01:00
2026-06-26 22:18:34 -04:00
2026-03-27 07:35:05 -07:00
2026-01-30 11:34:34 +00:00
2026-04-05 13:53:10 -07:00
2026-02-10 11:39:31 +01:00
2026-01-11 06:09:11 -10:00
2026-04-20 11:35:17 -07:00
2026-05-26 11:02:01 +02:00
2026-02-27 16:40:16 +01:00
2026-01-11 06:09:11 -10:00
2026-03-08 11:06:53 +01:00
2026-03-31 07:04:00 -06:00
2026-03-25 20:11:29 +01:00
2026-03-13 08:22:54 +01:00
2026-05-11 16:59:43 +02:00
2026-03-12 15:05:34 +01:00
2026-03-30 16:43:24 -06:00
2026-01-30 18:26:59 -08:00
2026-06-06 15:22:44 +02:00