kernel/git/stable/linux-stable.git/fs/crypto/inline_crypt.c, branch master

fscrypt: Merge bio.c and inline_crypt.c into block.c

2026-07-20T17:39:26+00:00

Now that fscrypt always uses blk-crypto on block-based filesystems, there's no meaningful difference between bio.c and inline_crypt.c. Therefore merge the two files into one named block.c. Note: I didn't carry over bio.c's "Copyright (C) 2015, Motorola Mobility", as none of the code that applied to remained. Reviewed-by: Christoph Hellwig Link: https://patch.msgid.link/20260713023708.9245-17-ebiggers@kernel.org Signed-off-by: Eric Biggers

fscrypt: Remove fscrypt_dio_supported()

2026-07-20T17:39:26+00:00

On block-based filesystems, fscrypt file contents encryption is now always implemented using blk-crypto. This implementation supports direct I/O. Therefore, fscrypt_dio_supported() now always returns true, except in the edge case where statx(STATX_DIOALIGN) is called on an encrypted regular file that hasn't had its key set up. But that was really a workaround rather than the desired behavior, so we can disregard it. Thus, fscrypt_dio_supported() is no longer needed. Remove it. Reviewed-by: Christoph Hellwig Link: https://patch.msgid.link/20260713023708.9245-14-ebiggers@kernel.org Signed-off-by: Eric Biggers

fscrypt: Replace calls to fscrypt_inode_uses_inline_crypto()

2026-07-20T17:39:25+00:00

Now that fscrypt's file contents en/decryption is always implemented using blk-crypto when the filesystem is block-based, the calls to fscrypt_inode_uses_inline_crypto() in fs/crypto/inline_crypt.c (which contains functions that are called only from block-based filesystems) are equivalent to checking whether the file is an encrypted regular file, i.e. fscrypt_needs_contents_encryption(). Use that instead. Reviewed-by: Christoph Hellwig Link: https://patch.msgid.link/20260713023708.9245-13-ebiggers@kernel.org Signed-off-by: Eric Biggers

fscrypt: Always use blk-crypto for contents on block-based filesystems

2026-07-20T17:39:25+00:00

For encrypting and decrypting file contents on block-based filesystems (i.e., ext4 and f2fs, but not ceph and ubifs), always use blk-crypto instead of fs-layer crypto (direct use of crypto_skcipher). Since the blk-crypto API provides a fallback to CPU-based encryption, it's all that's needed on block-based filesystems. The support for two alternative block-based file contents encryption implementations, fs-layer and blk-crypto, existed mainly for historical reasons, as the fs-layer path came first. Some of it is also still needed for the non-block-based filesystems, but a lot of it isn't. Removing the duplicate fs-layer code paths greatly simplifies the code, most of which is done in later commits. Specific implementation details: - SB_INLINECRYPT now controls whether blk_crypto_config::allow_hw is set to true, instead of whether blk-crypto is used at all. The effect is that the semantics are preserved: the inlinecrypt mount option selects the use of inline encryption hardware instead of the CPU. - Set up a blk_crypto_key iff the file is a regular file on a block-based filesystem. To determine whether the filesystem is block-based, add a bit fscrypt_operations::is_block_based. - Remove fscrypt_select_encryption_impl(). Move the logging logic that was previously there into fscrypt_prepare_inline_crypt_key(). Note that blk_crypto_config_supported() is no longer needed. Reviewed-by: Christoph Hellwig Link: https://patch.msgid.link/20260713023708.9245-6-ebiggers@kernel.org Signed-off-by: Eric Biggers

fscrypt: Fully disallow IV_INO_LBLK_32 with s_blocksize != PAGE_SIZE

2026-07-20T17:39:25+00:00

FSCRYPT_POLICY_FLAG_IV_INO_LBLK_32 with s_blocksize != PAGE_SIZE works only with the fs-layer implementation of file contents encryption, not blk-crypto. This is a problem for standardizing on blk-crypto. Fortunately, no one should be using this combination anyway. It doesn't make sense because the entire point of IV_INO_LBLK_32 is to support inline encryption hardware that is limited to 32-bit DUNs. Thus, fully disallow IV_INO_LBLK_32 with s_blocksize != PAGE_SIZE. Reviewed-by: Christoph Hellwig Link: https://patch.msgid.link/20260713023708.9245-5-ebiggers@kernel.org Signed-off-by: Eric Biggers

blk-crypto: Allow control over whether hardware is used

2026-07-20T17:39:25+00:00

fscrypt uses inline encryption hardware only when the "inlinecrypt" mount option is given. I'd like to keep that behavior even after standardizing on the blk-crypto API for file contents encryption. That is, the default should continue to be the well-tested CPU-based encryption code, and the use of inline encryption hardware should continue to be an opt-in feature for systems where it's beneficial and has been fully validated (including verifying ciphertext correctness). To support this use case, extend blk_crypto_config with a new flag BLK_CRYPTO_CFG_ALLOW_HW. For now it's always set. Later commits will change that. Reviewed-by: Christoph Hellwig Link: https://patch.msgid.link/20260713023708.9245-4-ebiggers@kernel.org Signed-off-by: Eric Biggers

fscrypt: Avoid dynamic allocation in fscrypt_get_devices()

2026-07-20T17:39:24+00:00

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 Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/20260713023708.9245-1-ebiggers%40kernel.org Reviewed-by: Christoph Hellwig Link: https://patch.msgid.link/20260719055602.78828-1-ebiggers@kernel.org Signed-off-by: Eric Biggers

fscrypt: Fix key setup in edge case with multiple data unit sizes

2026-06-22T19:12:11+00:00

The addition of support for customizable data unit sizes introduced an edge case where a file's contents can be en/decrypted with the wrong data unit size. It occurs when there are multiple v2 policies that: - Have *different* data unit sizes, via the log2_data_unit_size field - Share the same master_key_identifier, contents_encryption_mode, and either FSCRYPT_POLICY_FLAG_DIRECT_KEY, FSCRYPT_POLICY_FLAG_IV_INO_LBLK_32, or FSCRYPT_POLICY_FLAG_IV_INO_LBLK_64 - Are being used on the same filesystem, which also must be mounted with the "inlinecrypt" mount option. Fortunately this edge case doesn't actually occur in practice. I just found it via code review. But it needs to be fixed regardless. The bug is caused by the data unit size not being fully considered when blk_crypto_keys are cached in mk_direct_keys, mk_iv_ino_lblk_32_keys, and mk_iv_ino_lblk_64_keys. They're differentiated only by master key, encryption mode, and flag. However, each one actually has a data unit size too. Only the first data unit size that is cached is used. To fix this, start using the data unit size to differentiate the cached keys. For several reasons, including avoiding increasing the size of struct fscrypt_master_key, just replace all three arrays with a single linked list instead of changing them into two-dimensional arrays. This works well when considering that in practice at most 2 entries are used across all three arrays, so it was already mostly wasted space. For simplicity, make the list also take over the publish/subscribe of the prepared key itself. That is, create separate list nodes for blk_crypto_keys vs crypto_skciphers, and add nodes to the list only when their key is actually prepared. (Note that the legacy fscrypt_direct_keys table in fs/crypto/keysetup_v1.c already works this way.) This eliminates the need for the additional memory barriers when reading and writing the fields of struct fscrypt_prepared_key. Note that I technically should have included the data unit size in the HKDF info string as well. But it's too late to change that. Fixes: 5b1188847180 ("fscrypt: support crypto data unit size less than filesystem block size") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260618180652.52742-1-ebiggers@kernel.org Signed-off-by: Eric Biggers

fscrypt: pass a byte offset to fscrypt_set_bio_crypt_ctx

2026-03-09T20:31:50+00:00

Logical offsets into an inode are usually expressed as bytes in the VFS. Switch fscrypt_set_bio_crypt_ctx to that convention. Signed-off-by: Christoph Hellwig Link: https://lore.kernel.org/r/20260302141922.370070-9-hch@lst.de Signed-off-by: Eric Biggers

fscrypt: pass a byte offset to fscrypt_mergeable_bio

2026-03-09T20:31:50+00:00

Logical offsets into an inode are usually expressed as bytes in the VFS. Switch fscrypt_mergeable_bio to that convention. Signed-off-by: Christoph Hellwig Link: https://lore.kernel.org/r/20260302141922.370070-8-hch@lst.de Signed-off-by: Eric Biggers