All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.