From: Alberto Garcia <berto@igalia.com>
To: Eric Biggers <ebiggers@kernel.org>
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 17:15:30 +0200 [thread overview]
Message-ID: <arU-kvN-75AEmNQw@igalia.com> (raw)
In-Reply-To: <20260923180119.GA1506901@google.com>
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?
Regards,
Berto
next prev parent reply other threads:[~2026-09-24 15:16 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 [this message]
2026-09-24 18:04 ` Eric Biggers
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=arU-kvN-75AEmNQw@igalia.com \
--to=berto@igalia.com \
--cc=adilger.kernel@dilger.ca \
--cc=ebiggers@kernel.org \
--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.