kernel/git/stable/linux.git/fs/crypto, branch master

Merge tag 'fscrypt-for-linus' of git://git.kernel.org/pub/scm/fs/fscrypt/linux

2026-08-18T02:04:16+00:00

Pull fscrypt updates from Eric Biggers: "The main change this cycle is a significant simplification that's been overdue for a while now: standardizing on a single file contents encryption implementation in ext4 and f2fs, instead of having two. Specifically, the original filesystem-layer file contents encryption implementation is removed, and the blk-crypto implementation is now used unconditionally. blk-crypto delegates either to inline crypto hardware or to the CPU via blk-crypto-fallback. The latter is functionally equivalent to the original filesystem-layer code. The blk-crypto implementation already existed, but previously it was used only when the filesystem was mounted with "-o inlinecrypt". Now, "-o inlinecrypt" just selects whether inline crypto hardware is used. To allow maintaining that user control over hardware use, the blk-crypto API is extended with a new flag BLK_CRYPTO_CFG_ALLOW_HW. Overall, this removes quite a bit of redundant code from ext4, f2fs, and fs/crypto/. It should make things easier for ongoing filesystem efforts such as iomap support, large folios, and btrfs encryption (btrfs had already been planning to use blk-crypto exclusively.) There are two small behavior changes of note: - Direct I/O now works on encrypted files even without "-o inlinecrypt", rather than falling back to buffered I/O. This is effectively a bugfix, though I'll continue to keep an eye out for any user that may have been depending on the buffered I/O fallback. - IV_INO_LBLK_32 policies are no longer supported in certain cases that didn't make sense and have no known uses. This has been in linux-next since July 22 with no reported issues. All encryption xfstests pass on ext4 and f2fs. As usual I've also been using it on a system with an fscrypt-encrypted home directory. Of course, the blk-crypto code paths also aren't new and were already being used on many systems via the inlinecrypt mount option. In addition to the main change described above, there are a few other cleanups such as using lock guards for mutexes, improving documentation, and removing a workaround for outdated gcc versions" * tag 'fscrypt-for-linus' of git://git.kernel.org/pub/scm/fs/fscrypt/linux: (29 commits) blk-crypto: Update docs for blk-crypto-fallback motivation blk-crypto: Remove unused function blk_crypto_config_supported() fscrypt: Update docs for data path fscrypt: Remove unused function fscrypt_finalize_bounce_page() f2fs: Update outdated comment in f2fs_write_begin() fs: Update outdated comment for SB_INLINECRYPT fscrypt: Update encryption policy version docs fscrypt: Replace some variable-size memsets with fixed-size fscrypt: Add safety checks to non-block-based en/decryption fscrypt: Merge bio.c and inline_crypt.c into block.c fscrypt: Remove unused functions and workqueue fscrypt: Remove fs-layer zeroout code fscrypt: Remove fscrypt_dio_supported() fscrypt: Replace calls to fscrypt_inode_uses_inline_crypto() fs/buffer: Remove fs-layer decryption code f2fs: Remove fs-layer file contents en/decryption code ext4: Further de-generalize the bio postprocessing code ext4: Make ext4_bio_write_folio() return void ext4: Remove fs-layer file contents en/decryption code Documentation: fscrypt: Update docs for inlinecrypt ...

fscrypt: use the mount idmap for the owner check in fscrypt_ioctl_set_policy()

2026-07-29T04:19:44+00:00

fscrypt_ioctl_set_policy() calls inode_owner_or_capable() with &nop_mnt_idmap before allowing an encryption policy to be set, instead of the idmap of the mount the ioctl was issued on. fscrypt is used by filesystems that support idmapped mounts (e.g. ext4, f2fs), so on such a mount this compares the caller's fsuid against the unmapped on-disk owner rather than the mapped owner: the actual owner can be wrongly denied with -EACCES and an unrelated caller wrongly allowed. Use file_mnt_idmap(filp) instead. Fixes: 14f3db5542e6 ("ext4: support idmapped mounts") Cc: stable@vger.kernel.org Signed-off-by: Zhan Xusheng Link: https://patch.msgid.link/20260725080004.929328-1-zhanxusheng1024@gmail.com Signed-off-by: Eric Biggers

fscrypt: Replace some variable-size memsets with fixed-size

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

For zeroing IVs and raw keys, remove the misguided optimization of zeroing the actual size used (typically 16 and 64 bytes respectively) instead of the max size (32 and 64 bytes respectively). Using a compile-time constant size allows the compiler to specialize the memset for that size (typically by inlining a few 'mov' instructions), which is more important than zeroing a few extra bytes with these small sizes. Link: https://patch.msgid.link/20260718205606.50713-1-ebiggers@kernel.org Signed-off-by: Eric Biggers

fscrypt: Add safety checks to non-block-based en/decryption

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

fscrypt_encrypt_pagecache_blocks(), fscrypt_encrypt_block_inplace(), fscrypt_decrypt_block_inplace() would dereference a NULL fscrypt_inode_info pointer if they were to be called on a file that hasn't been opened yet or on a block-based filesystem. Since they have the ability to report errors anyway, add WARN_ON_ONCE checks for this. Reviewed-by: Christoph Hellwig Link: https://patch.msgid.link/20260713023708.9245-18-ebiggers@kernel.org Signed-off-by: Eric Biggers

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 unused functions and workqueue

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

Remove functions that are no longer used: - fscrypt_decrypt_bio() - fscrypt_decrypt_pagecache_blocks() - fscrypt_inode_uses_fs_layer_crypto() - fscrypt_inode_uses_inline_crypto() - fscrypt_enqueue_decrypt_work() This makes the decryption workqueue unused, so remove it too. Reviewed-by: Christoph Hellwig Link: https://patch.msgid.link/20260713023708.9245-16-ebiggers@kernel.org Signed-off-by: Eric Biggers

fscrypt: Remove fs-layer zeroout code

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

Now that fscrypt's file contents en/decryption is always implemented using blk-crypto when the filesystem is block-based, the fs-layer zeroout code in fs/crypto/bio.c is unused code. Remove it, then fold fscrypt_zeroout_range_inline_crypt() into fscrypt_zeroout_range(). Then make fscrypt_alloc_bounce_page() and fscrypt_crypt_data_unit() static, since they're no longer called from any other file. Reviewed-by: Christoph Hellwig Link: https://patch.msgid.link/20260713023708.9245-15-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