]> git.ipfire.org Git - thirdparty/kernel/stable-queue.git/commitdiff
5.4-stable patches
authorGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Tue, 10 Jan 2023 15:53:04 +0000 (16:53 +0100)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Tue, 10 Jan 2023 15:53:04 +0000 (16:53 +0100)
added patches:
ext4-don-t-allow-journal-inode-to-have-encrypt-flag.patch

queue-5.4/ext4-don-t-allow-journal-inode-to-have-encrypt-flag.patch [new file with mode: 0644]
queue-5.4/series

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 (file)
index 0000000..d58797c
--- /dev/null
@@ -0,0 +1,58 @@
+From 105c78e12468413e426625831faa7db4284e1fec Mon Sep 17 00:00:00 2001
+From: Eric Biggers <ebiggers@google.com>
+Date: Tue, 1 Nov 2022 22:33:12 -0700
+Subject: ext4: don't allow journal inode to have encrypt flag
+
+From: Eric Biggers <ebiggers@google.com>
+
+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 <ebiggers@google.com>
+Link: https://lore.kernel.org/r/20221102053312.189962-1-ebiggers@kernel.org
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Cc: stable@kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
index e6558e0fb4404f766d0fc8531a034f6ea93a00f2..c4596520ab3d1e290cfa1a22125888bd52f587f3 100644 (file)
@@ -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