On Sat, Jul 18, 2026 at 08:31:20PM -0700, Eric Biggers wrote:
> The legacy 'fscrypt_direct_keys' table caches master keys that are used
> by v1 encryption policies that have FSCRYPT_POLICY_FLAG_DIRECT_KEY.
> It's just a global table for all filesystems (since the keys can be
> provided by the legacy process-subscribed keyrings mechanism, which
> makes it difficult to reuse super_block::s_master_keys).
> 
> The entries in it ('struct fscrypt_direct_key') do contain a super_block
> pointer, though, for passing to fscrypt_destroy_inline_crypt_key() when
> the last inode that references the key is evicted.
> 
> However, when finding the fscrypt_direct_key for an inode, we weren't
> actually comparing the super_block pointer.  As a result, inodes with
> different super_blocks could point to the same fscrypt_direct_key.  That
> could extend the lifetime of a fscrypt_direct_key beyond the
> super_block it points to, causing a use-after-free later.
> 
> Fix this by creating distinct fscrypt_direct_key structs for distinct
> super_block structs.
> 
> Note that this problem doesn't exist in the v2 policy equivalent
> ("per-mode keys"), since the data structures there are per super_block.
> 
> 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

Reply via email to