Re: [REGRESSION] ext4: oops in ext4_finish_bio() after enabling encryption on a mounted fs

[Eric Biggers <ebiggers@kernel.org>]

On Fri, Sep 25, 2026 at 01:06:08PM +0200, Alberto Garcia wrote:
> On Thu, Sep 24, 2026 at 11:04:38AM -0700, Eric Biggers wrote:
> > * And maybe a check in __ext4_iget() to prevent existing encrypted
> >   inodes from being loaded when fs_block_size > PAGE_SIZE.  This would
> >   be needed for fuzzing robustness, where a fuzzer generates a
> >   filesystem that has encrypted files without the encrypt feature flag.
> 
> Does the kernel reject encrypted files on a fs without the encrypt
> flag? I'm asking in general, regardless of the block size. Should it?

On a filesystem without the encrypt flag, ext4 rejects creating new
encrypted directories, but it doesn't reject accessing existing
encrypted directories.

It *should* reject accessing existing encrypted directories.  I think
the fact that it doesn't is a holdout from the bug that ext4 originally
had where it didn't enforce the encrypt feature flag at all.

ext4 encryption was first supported in Linux v4.1.  ext4 incorrectly
allowed creating new encrypted directories on filesystems without the
encrypt feature flag until commit 9a200d075e5 ("ext4: require encryption
feature for EXT4_IOC_SET_ENCRYPTION_POLICY") in Linux v4.9.  ext4 also
allowed the FS_IOC_GET_ENCRYPTION_POLICY ioctl on filesystems without
the encrypt feature flag until commit 0642ea2409f3bf ("ext4 crypto: fix
to check feature status before get policy") in Linux v5.4.

Since v5.4 (7 years ago), ext4 has enforced ext4_has_feature_encrypt(sb)
for all encryption ioctls.

I think at this point would be pretty safe for ext4_iget() to reject any
encrypted inodes when the filesystem doesn't have the encrypt flag.  The
only caveat is that, technically, if an existing encrypted directory is
using the old policy version (which before v5.4 was the only option), it
can be unlocked and accessed without executing any of the encryption
ioctls.  So in theory someone could be depending on that on a filesystem
without the encrypt flag.  I think it's unlikely at this point, though.

(Android for example certainly isn't depending on that, since I updated
it to use 'tune2fs -O encrypt' many years ago.  Also, its keyctl() based
unlocking code was removed and only the ioctls are used now.)

So I would suggest we just fix this as well.

- Eric