]> git.ipfire.org Git - thirdparty/linux.git/commitdiff
Merge tag 'fscrypt-for-linus' of git://git.kernel.org/pub/scm/fs/fscrypt/linux
authorLinus Torvalds <torvalds@linux-foundation.org>
Tue, 18 Aug 2026 02:04:16 +0000 (19:04 -0700)
committerLinus Torvalds <torvalds@linux-foundation.org>
Tue, 18 Aug 2026 02:04:16 +0000 (19:04 -0700)
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
  ...

1  2 
fs/buffer.c
fs/crypto/policy.c
fs/ext4/ext4.h
fs/ext4/inode.c
fs/ext4/super.c
fs/f2fs/data.c
fs/f2fs/super.c
include/linux/fs/super_types.h

diff --cc fs/buffer.c
Simple merge
index c80b24a941ad05c54c55ae8adccb1ddc95c1d650,a7322dba7557e564f68ae4cfe9a112a213a57521..6dd510f93e6d690469c496677f179684cfbcb16c
@@@ -518,23 -534,11 +534,11 @@@ int fscrypt_ioctl_set_policy(struct fil
        if (size <= 0)
                return -EINVAL;
  
-       /*
-        * We should just copy the remaining 'size - 1' bytes here, but a
-        * bizarre bug in gcc 7 and earlier (fixed by gcc r255731) causes gcc to
-        * think that size can be 0 here (despite the check above!) *and* that
-        * it's a compile-time constant.  Thus it would think copy_from_user()
-        * is passed compile-time constant ULONG_MAX, causing the compile-time
-        * buffer overflow check to fail, breaking the build. This only occurred
-        * when building an i386 kernel with -Os and branch profiling enabled.
-        *
-        * Work around it by just copying the first byte again...
-        */
-       version = policy.version;
-       if (copy_from_user(&policy, arg, size))
+       if (copy_from_user((u8 *)&policy + 1, (const u8 __user *)arg + 1,
+                          size - 1))
                return -EFAULT;
-       policy.version = version;
  
 -      if (!inode_owner_or_capable(&nop_mnt_idmap, inode))
 +      if (!inode_owner_or_capable(file_mnt_idmap(filp), inode))
                return -EACCES;
  
        ret = mnt_want_write_file(filp);
diff --cc fs/ext4/ext4.h
Simple merge
diff --cc fs/ext4/inode.c
Simple merge
diff --cc fs/ext4/super.c
Simple merge
diff --cc fs/f2fs/data.c
Simple merge
diff --cc fs/f2fs/super.c
Simple merge
Simple merge