From c493b525e856d455d94529c0037a690a6557661e Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Tue, 10 Jan 2023 16:53:04 +0100 Subject: [PATCH] 5.4-stable patches added patches: ext4-don-t-allow-journal-inode-to-have-encrypt-flag.patch --- ...w-journal-inode-to-have-encrypt-flag.patch | 58 +++++++++++++++++++ queue-5.4/series | 1 + 2 files changed, 59 insertions(+) create mode 100644 queue-5.4/ext4-don-t-allow-journal-inode-to-have-encrypt-flag.patch diff --git a/queue-5.4/ext4-don-t-allow-journal-inode-to-have-encrypt-flag.patch b/queue-5.4/ext4-don-t-allow-journal-inode-to-have-encrypt-flag.patch new file mode 100644 index 00000000000..d58797c324f --- /dev/null +++ b/queue-5.4/ext4-don-t-allow-journal-inode-to-have-encrypt-flag.patch @@ -0,0 +1,58 @@ +From 105c78e12468413e426625831faa7db4284e1fec Mon Sep 17 00:00:00 2001 +From: Eric Biggers +Date: Tue, 1 Nov 2022 22:33:12 -0700 +Subject: ext4: don't allow journal inode to have encrypt flag + +From: Eric Biggers + +commit 105c78e12468413e426625831faa7db4284e1fec upstream. + +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 +Link: https://lore.kernel.org/r/20221102053312.189962-1-ebiggers@kernel.org +Signed-off-by: Theodore Ts'o +Cc: stable@kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + fs/ext4/super.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/fs/ext4/super.c ++++ b/fs/ext4/super.c +@@ -4836,7 +4836,7 @@ static struct inode *ext4_get_journal_in + + jbd_debug(2, "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; diff --git a/queue-5.4/series b/queue-5.4/series index e6558e0fb44..c4596520ab3 100644 --- a/queue-5.4/series +++ b/queue-5.4/series @@ -591,3 +591,4 @@ asoc-intel-bytcr_rt5640-add-quirk-for-the-advantech-.patch x86-bugs-flush-ibp-in-ib_prctl_set.patch nfsd-fix-handling-of-readdir-in-v4root-vs.-mount-upcall-timeout.patch riscv-uaccess-fix-type-of-0-variable-on-error-in-get_user.patch +ext4-don-t-allow-journal-inode-to-have-encrypt-flag.patch -- 2.47.3