| Message ID | 20221102053312.189962-1-ebiggers@kernel.org (mailing list archive) |
|---|---|
| State | Accepted |
| Headers | show |
| Series | ext4: don't allow journal inode to have encrypt flag | expand |
On Tue, Nov 01, 2022 at 10:33:12PM -0700, Eric Biggers wrote: > From: Eric Biggers <ebiggers@google.com> > > Mounting a filesystem whose journal inode has the encrypt flag causes a > NULL dereference in fscrypt_limit_io_blocks() when the 'inlinecrypt' > mount option is used. > > The problem is that when jbd2_journal_init_inode() calls bmap(), it > eventually finds its way into ext4_iomap_begin(), which calls > fscrypt_limit_io_blocks(). fscrypt_limit_io_blocks() requires that if > the inode is encrypted, then its encryption key must already be set up. > That's not the case here, since the journal inode is never "opened" like > a normal file would be. Hence the crash. > > A reproducer is: > > mkfs.ext4 -F /dev/vdb > debugfs -w /dev/vdb -R "set_inode_field <8> flags 0x80808" > mount /dev/vdb /mnt -o inlinecrypt > > To fix this, make ext4 consider journal inodes with the encrypt flag to > be invalid. (Note, maybe other flags should be rejected on the journal > inode too. For now, this is just the minimal fix for the above issue.) > > I've marked this as fixing the commit that introduced the call to > fscrypt_limit_io_blocks(), since that's what made an actual crash start > being possible. But this fix could be applied to any version of ext4 > that supports the encrypt feature. > > Reported-by: syzbot+ba9dac45bc76c490b7c3@syzkaller.appspotmail.com > Fixes: 38ea50daa7a4 ("ext4: support direct I/O with fscrypt using blk-crypto") > Cc: stable@vger.kernel.org > Signed-off-by: Eric Biggers <ebiggers@google.com> > --- > fs/ext4/super.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/fs/ext4/super.c b/fs/ext4/super.c > index 7950904fbf04f..2274f730b87e5 100644 > --- a/fs/ext4/super.c > +++ b/fs/ext4/super.c > @@ -5723,7 +5723,7 @@ static struct inode *ext4_get_journal_inode(struct super_block *sb, > > ext4_debug("Journal inode found at %p: %lld bytes\n", > journal_inode, journal_inode->i_size); > - if (!S_ISREG(journal_inode->i_mode)) { > + if (!S_ISREG(journal_inode->i_mode) || IS_ENCRYPTED(journal_inode)) { > ext4_msg(sb, KERN_ERR, "invalid journal inode"); > iput(journal_inode); > return NULL; > > base-commit: 8f71a2b3f435f29b787537d1abedaa7d8ebe6647 > -- Ping. - Eric
On Tue, 1 Nov 2022 22:33:12 -0700, Eric Biggers wrote: > From: Eric Biggers <ebiggers@google.com> > > Mounting a filesystem whose journal inode has the encrypt flag causes a > NULL dereference in fscrypt_limit_io_blocks() when the 'inlinecrypt' > mount option is used. > > The problem is that when jbd2_journal_init_inode() calls bmap(), it > eventually finds its way into ext4_iomap_begin(), which calls > fscrypt_limit_io_blocks(). fscrypt_limit_io_blocks() requires that if > the inode is encrypted, then its encryption key must already be set up. > That's not the case here, since the journal inode is never "opened" like > a normal file would be. Hence the crash. > > [...] Applied, thanks! [1/1] ext4: don't allow journal inode to have encrypt flag commit: 29cef51d8522c4d8953856afaffcaf1b754e4f6c Best regards,
On Tue, Dec 06, 2022 at 04:01:48PM -0500, Theodore Ts'o wrote: > On Tue, 1 Nov 2022 22:33:12 -0700, Eric Biggers wrote: > > From: Eric Biggers <ebiggers@google.com> > > > > Mounting a filesystem whose journal inode has the encrypt flag causes a > > NULL dereference in fscrypt_limit_io_blocks() when the 'inlinecrypt' > > mount option is used. > > > > The problem is that when jbd2_journal_init_inode() calls bmap(), it > > eventually finds its way into ext4_iomap_begin(), which calls > > fscrypt_limit_io_blocks(). fscrypt_limit_io_blocks() requires that if > > the inode is encrypted, then its encryption key must already be set up. > > That's not the case here, since the journal inode is never "opened" like > > a normal file would be. Hence the crash. > > > > [...] > > Applied, thanks! > > [1/1] ext4: don't allow journal inode to have encrypt flag > commit: 29cef51d8522c4d8953856afaffcaf1b754e4f6c > > Best regards, > -- > Theodore Ts'o <tytso@mit.edu> Thanks Ted. Note that I also sent an e2fsprogs patch to make e2fsck fix this situation: https://lore.kernel.org/r/20221102220551.3940-1-ebiggers@kernel.org - Eric
diff --git a/fs/ext4/super.c b/fs/ext4/super.c index 7950904fbf04f..2274f730b87e5 100644 --- a/fs/ext4/super.c +++ b/fs/ext4/super.c @@ -5723,7 +5723,7 @@ static struct inode *ext4_get_journal_inode(struct super_block *sb, ext4_debug("Journal inode found at %p: %lld bytes\n", journal_inode, journal_inode->i_size); - if (!S_ISREG(journal_inode->i_mode)) { + if (!S_ISREG(journal_inode->i_mode) || IS_ENCRYPTED(journal_inode)) { ext4_msg(sb, KERN_ERR, "invalid journal inode"); iput(journal_inode); return NULL;