From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Tue, 18 Aug 2026 02:04:16 +0000 (-0700)
Subject: Merge tag 'fscrypt-for-linus' of git://git.kernel.org/pub/scm/fs/fscrypt/linux
X-Git-Url: http://git.ipfire.org/gitweb/index.cgi?a=commitdiff_plain;h=1d7443e4dca1e8637930f3baf64e2fe82033e669;p=thirdparty%2Flinux.git

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

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
  ...
---

1d7443e4dca1e8637930f3baf64e2fe82033e669
diff --cc fs/crypto/policy.c
index c80b24a941ad0,a7322dba7557e..6dd510f93e6d6
--- a/fs/crypto/policy.c
+++ b/fs/crypto/policy.c
@@@ -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);