From: Eric Biggers <ebiggers@kernel.org>
To: Alberto Garcia <berto@igalia.com>
Cc: Baokun Li <libaokun@linux.alibaba.com>,
Theodore Ts'o <tytso@mit.edu>,
Andreas Dilger <adilger.kernel@dilger.ca>,
Jan Kara <jack@suse.cz>, Ojaswin Mujoo <ojaswin@linux.ibm.com>,
"Ritesh Harjani (IBM)" <ritesh.list@gmail.com>,
Zhang Yi <yi.zhang@huawei.com>,
linux-ext4@vger.kernel.org
Subject: Re: [REGRESSION] ext4: oops in ext4_finish_bio() after enabling encryption on a mounted fs
Date: Thu, 24 Sep 2026 11:04:38 -0700 [thread overview]
Message-ID: <20260924180438.GB1978@sol> (raw)
In-Reply-To: <arU-kvN-75AEmNQw@igalia.com>
On Thu, Sep 24, 2026 at 05:15:30PM +0200, Alberto Garcia wrote:
> On Wed, Sep 23, 2026 at 06:01:19PM +0000, Eric Biggers wrote:
> > The proposed patch looks good
>
> As I said, I think we need an additional check to detect if encryption
> is set on a mounted filesystem that has blocksize > pagesize.
>
> Such a filesystem cannot be mounted (ext4_check_large_folio refuses),
> but if you do it after the fs is mounted you can crash the kernel
> using the same method.
>
> # mkfs.ext4 -b 16384 /dev/vdb
> # mount /dev/vdb /mnt/
> # fscrypt setup /mnt
> # tune2fs -O encrypt /dev/vdb
> # mkdir /mnt/foo
> # fscrypt encrypt /mnt/foo/
>
> The other patch alone does not prevent this.
>
> With this additional change, FS_IOC_SET_ENCRYPTION_POLICY returns
> -EOPNOTSUPP, so tune2fs succeeds, but 'fscrypt encrypt' fails:
>
> [ERROR] fscrypt encrypt: encryption not enabled on filesystem /mnt (/dev/vdb).
>
> --- a/fs/ext4/crypto.c
> +++ b/fs/ext4/crypto.c
> @@ -156,6 +156,9 @@ static int ext4_set_context(struct inode *inode, const void *ctx, size_t len,
> if (ext4_test_inode_flag(inode, EXT4_INODE_DAX))
> return -EOPNOTSUPP;
>
> + if (inode->i_sb->s_blocksize > PAGE_SIZE)
> + return -EOPNOTSUPP;
> +
> res = ext4_convert_inline_data(inode);
> if (res)
> return res;
>
> That prevents the crash, but the filesystem cannot be remounted:
>
> kernel: EXT4-fs (vdb): bs(16384) > ps(4096) unsupported for encrypt
>
> Would this be enough or is there anything else to take into account?
Right, encryption should work with large folios now, but not with
fs_block_size > PAGE_SIZE. For the latter, for now I think we need a
few different things to prevent it:
* (Already present) A mount-time check, to prevent mounting when the
encrypt feature flag is set and fs_block_size > PAGE_SIZE;
* A check in ext4_set_context(), as you suggested, to prevent new
encrypted files from being created when fs_block_size > PAGE_SIZE
after the encrypt feature flag was set at runtime;
* tune2fs should disallow setting the encrypt feature flag in the first
place when fs_block_size > PAGE_SIZE;
* 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.
(I don't remember whether ext4 claims to support this level of fuzzing
robustness, though. __ext4_iget() has a few similar checks for other
filesystem features, but it's very incomplete, so I'm not sure.)
- Eric
next prev parent reply other threads:[~2026-09-24 18:04 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-23 11:12 [REGRESSION] ext4: oops in ext4_finish_bio() after enabling encryption on a mounted fs Alberto Garcia
2026-09-23 11:43 ` sashiko-bot
2026-09-23 12:12 ` Baokun Li
2026-09-23 12:40 ` Alberto Garcia
2026-09-23 13:28 ` Baokun Li
2026-09-23 18:01 ` Eric Biggers
2026-09-24 10:19 ` Baokun Li
2026-09-24 15:15 ` Alberto Garcia
2026-09-24 18:04 ` Eric Biggers [this message]
2026-09-25 11:06 ` Alberto Garcia
2026-09-25 19:07 ` Eric Biggers
2026-09-27 22:12 ` Alberto Garcia
2026-09-29 11:18 ` Jan Kara
2026-09-23 13:29 ` Jan Kara
2026-09-23 13:39 ` Alberto Garcia
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260924180438.GB1978@sol \
--to=ebiggers@kernel.org \
--cc=adilger.kernel@dilger.ca \
--cc=berto@igalia.com \
--cc=jack@suse.cz \
--cc=libaokun@linux.alibaba.com \
--cc=linux-ext4@vger.kernel.org \
--cc=ojaswin@linux.ibm.com \
--cc=ritesh.list@gmail.com \
--cc=tytso@mit.edu \
--cc=yi.zhang@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.