* [PATCH v2] ext4: fix kernel infoleak via ext4_extent_header
@ 2021-05-06 18:56 Anirudh Rayabharam
2021-06-16 23:45 ` Theodore Ts'o
2022-12-26 14:31 ` How can this fix prevent information from leaking to user space and prevent the kernel from crashing? Lizhi Xu
0 siblings, 2 replies; 5+ messages in thread
From: Anirudh Rayabharam @ 2021-05-06 18:56 UTC (permalink / raw)
To: Theodore Ts'o, Andreas Dilger, Dave Kleikamp, Alex Tomas,
Andrew Morton
Cc: linux-kernel, syzbot+2dcfeaf8cb49b05e8f1a, linux-ext4,
linux-kernel-mentees
Initialize eh_generation of struct ext4_extent_header to prevent leaking
info to userspace. Fixes KMSAN kernel-infoleak bug reported by syzbot at:
http://syzkaller.appspot.com/bug?id=78e9ad0e6952a3ca16e8234724b2fa92d041b9b8
Reported-by: syzbot+2dcfeaf8cb49b05e8f1a@syzkaller.appspotmail.com
Fixes: a86c61812637 ("[PATCH] ext3: add extent map support")
Signed-off-by: Anirudh Rayabharam <mail@anirudhrb.com>
---
Changes in v2:
Added a "Fixes:" tag.
v1: https://lore.kernel.org/lkml/20210505133011.32484-1-mail@anirudhrb.com/
---
fs/ext4/extents.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
index 77c84d6f1af6..677d4821bcc1 100644
--- a/fs/ext4/extents.c
+++ b/fs/ext4/extents.c
@@ -825,6 +825,7 @@ void ext4_ext_tree_init(handle_t *handle, struct inode *inode)
eh->eh_entries = 0;
eh->eh_magic = EXT4_EXT_MAGIC;
eh->eh_max = cpu_to_le16(ext4_ext_space_root(inode, 0));
+ eh->eh_generation = 0;
ext4_mark_inode_dirty(handle, inode);
}
@@ -1090,6 +1091,7 @@ static int ext4_ext_split(handle_t *handle, struct inode *inode,
neh->eh_max = cpu_to_le16(ext4_ext_space_block(inode, 0));
neh->eh_magic = EXT4_EXT_MAGIC;
neh->eh_depth = 0;
+ neh->eh_generation = 0;
/* move remainder of path[depth] to the new leaf */
if (unlikely(path[depth].p_hdr->eh_entries !=
@@ -1167,6 +1169,7 @@ static int ext4_ext_split(handle_t *handle, struct inode *inode,
neh->eh_magic = EXT4_EXT_MAGIC;
neh->eh_max = cpu_to_le16(ext4_ext_space_block_idx(inode, 0));
neh->eh_depth = cpu_to_le16(depth - i);
+ neh->eh_generation = 0;
fidx = EXT_FIRST_INDEX(neh);
fidx->ei_block = border;
ext4_idx_store_pblock(fidx, oldblock);
--
2.26.2
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees
^ permalink raw reply related [flat|nested] 5+ messages in thread* Re: [PATCH v2] ext4: fix kernel infoleak via ext4_extent_header 2021-05-06 18:56 [PATCH v2] ext4: fix kernel infoleak via ext4_extent_header Anirudh Rayabharam @ 2021-06-16 23:45 ` Theodore Ts'o 2022-09-08 23:11 ` [PATCH] " eadavis 2022-12-26 14:31 ` How can this fix prevent information from leaking to user space and prevent the kernel from crashing? Lizhi Xu 1 sibling, 1 reply; 5+ messages in thread From: Theodore Ts'o @ 2021-06-16 23:45 UTC (permalink / raw) To: Anirudh Rayabharam Cc: Andrew Morton, linux-kernel-mentees, linux-kernel, Andreas Dilger, Dave Kleikamp, syzbot+2dcfeaf8cb49b05e8f1a, linux-ext4, Alex Tomas On Fri, May 07, 2021 at 12:26:54AM +0530, Anirudh Rayabharam wrote: > Initialize eh_generation of struct ext4_extent_header to prevent leaking > info to userspace. Fixes KMSAN kernel-infoleak bug reported by syzbot at: > http://syzkaller.appspot.com/bug?id=78e9ad0e6952a3ca16e8234724b2fa92d041b9b8 > > Reported-by: syzbot+2dcfeaf8cb49b05e8f1a@syzkaller.appspotmail.com > Fixes: a86c61812637 ("[PATCH] ext3: add extent map support") > Signed-off-by: Anirudh Rayabharam <mail@anirudhrb.com> Applied, thanks. - Ted _______________________________________________ Linux-kernel-mentees mailing list Linux-kernel-mentees@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees ^ permalink raw reply [flat|nested] 5+ messages in thread
* [PATCH] ext4: fix kernel infoleak via ext4_extent_header 2021-06-16 23:45 ` Theodore Ts'o @ 2022-09-08 23:11 ` eadavis 0 siblings, 0 replies; 5+ messages in thread From: eadavis @ 2022-09-08 23:11 UTC (permalink / raw) To: tytso Cc: akpm, hdanton, linux-kernel-mentees, linux-kernel, mail, adilger.kernel, shaggy, syzbot+2dcfeaf8cb49b05e8f1a, linux-ext4, alex, Edward Adam Davis From: Edward Adam Davis <eadavis@sina.com> Hi Ted, http://syzkaller.appspot.com/bug?id=78e9ad0e6952a3ca16e8234724b2fa92d041b9b8 1. Syzbot report "kernel-infoleak in copy_page_to_iter" 2. Sample crash report: IPv6: ADDRCONF(NETDEV_UP): veth1: link is not ready IPv6: ADDRCONF(NETDEV_CHANGE): veth1: link becomes ready IPv6: ADDRCONF(NETDEV_CHANGE): veth0: link becomes ready 8021q: adding VLAN 0 to HW filter on device team0 ================================================================== BUG: KMSAN: kernel-infoleak in copyout lib/iov_iter.c:140 [inline] BUG: KMSAN: kernel-infoleak in copy_page_to_iter_iovec lib/iov_iter.c:212 [inline] BUG: KMSAN: kernel-infoleak in copy_page_to_iter+0x77a/0x1ac0 lib/iov_iter.c:846 CPU: 0 PID: 5005 Comm: blkid Not tainted 4.19.0-rc1+ #39 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x14b/0x190 lib/dump_stack.c:113 kmsan_report+0x183/0x2b0 mm/kmsan/kmsan.c:956 kmsan_internal_check_memory+0x17e/0x1f0 mm/kmsan/kmsan.c:1020 kmsan_copy_to_user+0x73/0xb0 mm/kmsan/kmsan_hooks.c:479 copyout lib/iov_iter.c:140 [inline] copy_page_to_iter_iovec lib/iov_iter.c:212 [inline] copy_page_to_iter+0x77a/0x1ac0 lib/iov_iter.c:846 generic_file_buffered_read mm/filemap.c:2185 [inline] generic_file_read_iter+0x3469/0x4430 mm/filemap.c:2362 blkdev_read_iter+0x20d/0x270 fs/block_dev.c:1936 call_read_iter include/linux/fs.h:1801 [inline] new_sync_read fs/read_write.c:406 [inline] __vfs_read+0x7bb/0x9f0 fs/read_write.c:418 vfs_read+0x36f/0x6a0 fs/read_write.c:452 ksys_read fs/read_write.c:578 [inline] __do_sys_read fs/read_write.c:588 [inline] __se_sys_read fs/read_write.c:586 [inline] __x64_sys_read+0x1b7/0x3c0 fs/read_write.c:586 do_syscall_64+0x15b/0x220 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x63/0xe7 RIP: 0033:0x7f6bf4959310 Code: 73 01 c3 48 8b 0d 28 4b 2b 00 31 d2 48 29 c2 64 89 11 48 83 c8 ff eb ea 90 90 83 3d e5 a2 2b 00 00 75 10 b8 00 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 6e 8a 01 00 48 89 04 24 RSP: 002b:00007fff70489898 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 RAX: ffffffffffffffda RBX: 0000000000037000 RCX: 00007f6bf4959310 RDX: 0000000000000029 RSI: 0000000000ddf1c8 RDI: 0000000000000003 RBP: 0000000000ddf1a0 R08: 0000000000000058 R09: 0101010101010101 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000dd9030 R13: 0000000000000029 R14: 0000000000dd9080 R15: 0000000000ddf1b8 Uninit was created at: kmsan_save_stack_with_flags mm/kmsan/kmsan.c:256 [inline] kmsan_internal_alloc_meta_for_pages+0x146/0x700 mm/kmsan/kmsan.c:694 kmsan_alloc_page+0x75/0xd0 mm/kmsan/kmsan_hooks.c:250 __alloc_pages_nodemask+0xf6b/0x5c80 mm/page_alloc.c:4411 alloc_pages_current+0x6b1/0x970 mm/mempolicy.c:2093 alloc_pages include/linux/gfp.h:511 [inline] __page_cache_alloc+0x95/0x320 mm/filemap.c:946 page_cache_alloc include/linux/pagemap.h:234 [inline] generic_file_buffered_read mm/filemap.c:2273 [inline] generic_file_read_iter+0x27a4/0x4430 mm/filemap.c:2362 blkdev_read_iter+0x20d/0x270 fs/block_dev.c:1936 call_read_iter include/linux/fs.h:1801 [inline] new_sync_read fs/read_write.c:406 [inline] __vfs_read+0x7bb/0x9f0 fs/read_write.c:418 vfs_read+0x36f/0x6a0 fs/read_write.c:452 ksys_read fs/read_write.c:578 [inline] __do_sys_read fs/read_write.c:588 [inline] __se_sys_read fs/read_write.c:586 [inline] __x64_sys_read+0x1b7/0x3c0 fs/read_write.c:586 do_syscall_64+0x15b/0x220 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x63/0xe7 Bytes 0-40 of 41 are uninitialized Memory access starts at ffff8801b1729000 ================================================================== 3. Why initial the "eh_generation to 0" can prevent the infoleak to user space ? 3.1 In the kernel source code, there is no code that calls eh_generation a except initialization to 0 4. The var kiocb in func "new_sync_read" maybe save old value, it will make the infoleak to user space 5. So use the following patch must prevent the infoleak to user space diff --git a/fs/read_write.c b/fs/read_write.c index 5db58b8c78d0..77b9e6a07626 100644 --- a/fs/read_write.c +++ b/fs/read_write.c @@ -408,6 +408,7 @@ static ssize_t new_sync_read(struct file *filp, char __user *buf, size_t len, lo struct iov_iter iter; ssize_t ret; + memset(&kiocb, 0, sizeof(struct kiocb)); init_sync_kiocb(&kiocb, filp); kiocb.ki_pos = (ppos ? *ppos : 0); iov_iter_init(&iter, READ, &iov, 1, len); 6. How do you think ? Adam, Thanks. _______________________________________________ Linux-kernel-mentees mailing list Linux-kernel-mentees@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees ^ permalink raw reply related [flat|nested] 5+ messages in thread
* How can this fix prevent information from leaking to user space and prevent the kernel from crashing? 2021-05-06 18:56 [PATCH v2] ext4: fix kernel infoleak via ext4_extent_header Anirudh Rayabharam 2021-06-16 23:45 ` Theodore Ts'o @ 2022-12-26 14:31 ` Lizhi Xu 2022-12-29 20:30 ` Eric Biggers 1 sibling, 1 reply; 5+ messages in thread From: Lizhi Xu @ 2022-12-26 14:31 UTC (permalink / raw) To: mail Cc: akpm, tytso, linux-kernel-mentees, linux-kernel, adilger.kernel, shaggy, syzbot+2dcfeaf8cb49b05e8f1a, linux-ext4, alex Hi, Anirudh Rayabharam I verify this patch in the following environment, using reproducer: https://syzkaller.appspot.com/x/repro.c?x=122870ff800000 1. kernel version: kernel version 5.15.72 2. gcc 11.3 3. libc 2.35 Because the kernel version 5.15.72 already contains this patch ce3aba43599f0b50adbebff133df8d08a3d5fffe, So I deleted this patch to make a kernel image to reproduce the problem, On the other hand, I reserve this patch to verify that the problem has been fixed, The result of the experiment is that no matter whether this patch is applied or not, this problem cannot be reproduced in kernel version 5.15.72. In addition, I am also very confused. There are three places to initialize "eh_generation". There is no other reference to the parameter "eh_generation" in all the source code of the kernel, At the same time, there is no indirect operation on the parameter "eh_generation" in reproducer, How can this fix prevent information from leaking to user space and prevent the kernel from crashing? > diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c > index 77c84d6f1af6..677d4821bcc1 100644 > --- a/fs/ext4/extents.c > +++ b/fs/ext4/extents.c > @@ -825,6 +825,7 @@ void ext4_ext_tree_init(handle_t *handle, struct inode *inode) > eh->eh_entries = 0; > eh->eh_magic = EXT4_EXT_MAGIC; > eh->eh_max = cpu_to_le16(ext4_ext_space_root(inode, 0)); > + eh->eh_generation = 0; > ext4_mark_inode_dirty(handle, inode); > } > > @@ -1090,6 +1091,7 @@ static int ext4_ext_split(handle_t *handle, struct inode *inode, > neh->eh_max = cpu_to_le16(ext4_ext_space_block(inode, 0)); > neh->eh_magic = EXT4_EXT_MAGIC; > neh->eh_depth = 0; > + neh->eh_generation = 0; > > /* move remainder of path[depth] to the new leaf */ > if (unlikely(path[depth].p_hdr->eh_entries != > @@ -1167,6 +1169,7 @@ static int ext4_ext_split(handle_t *handle, struct inode *inode, > neh->eh_magic = EXT4_EXT_MAGIC; > neh->eh_max = cpu_to_le16(ext4_ext_space_block_idx(inode, 0)); > neh->eh_depth = cpu_to_le16(depth - i); > + neh->eh_generation = 0; > fidx = EXT_FIRST_INDEX(neh); > fidx->ei_block = border; > ext4_idx_store_pblock(fidx, oldblock); > -- > 2.26.2 _______________________________________________ Linux-kernel-mentees mailing list Linux-kernel-mentees@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: How can this fix prevent information from leaking to user space and prevent the kernel from crashing? 2022-12-26 14:31 ` How can this fix prevent information from leaking to user space and prevent the kernel from crashing? Lizhi Xu @ 2022-12-29 20:30 ` Eric Biggers 0 siblings, 0 replies; 5+ messages in thread From: Eric Biggers @ 2022-12-29 20:30 UTC (permalink / raw) To: Lizhi Xu Cc: akpm, tytso, linux-kernel, mail, adilger.kernel, shaggy, syzbot+2dcfeaf8cb49b05e8f1a, linux-ext4, alex, linux-kernel-mentees On Mon, Dec 26, 2022 at 10:31:19PM +0800, Lizhi Xu wrote: > Hi, Anirudh Rayabharam > > I verify this patch in the following environment, using reproducer: https://syzkaller.appspot.com/x/repro.c?x=122870ff800000 > > 1. kernel version: kernel version 5.15.72 > 2. gcc 11.3 > 3. libc 2.35 > > Because the kernel version 5.15.72 already contains this patch ce3aba43599f0b50adbebff133df8d08a3d5fffe, > So I deleted this patch to make a kernel image to reproduce the problem, > On the other hand, I reserve this patch to verify that the problem has been fixed, > The result of the experiment is that no matter whether this patch is applied or not, > this problem cannot be reproduced in kernel version 5.15.72. > > In addition, I am also very confused. There are three places to initialize "eh_generation". > There is no other reference to the parameter "eh_generation" in all the source code of the kernel, > At the same time, there is no indirect operation on the parameter "eh_generation" in reproducer, > How can this fix prevent information from leaking to user space and prevent the kernel from crashing? > > > diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c > > index 77c84d6f1af6..677d4821bcc1 100644 > > --- a/fs/ext4/extents.c > > +++ b/fs/ext4/extents.c > > @@ -825,6 +825,7 @@ void ext4_ext_tree_init(handle_t *handle, struct inode *inode) > > eh->eh_entries = 0; > > eh->eh_magic = EXT4_EXT_MAGIC; > > eh->eh_max = cpu_to_le16(ext4_ext_space_root(inode, 0)); > > + eh->eh_generation = 0; > > ext4_mark_inode_dirty(handle, inode); > > } > > > > @@ -1090,6 +1091,7 @@ static int ext4_ext_split(handle_t *handle, struct inode *inode, > > neh->eh_max = cpu_to_le16(ext4_ext_space_block(inode, 0)); > > neh->eh_magic = EXT4_EXT_MAGIC; > > neh->eh_depth = 0; > > + neh->eh_generation = 0; > > > > /* move remainder of path[depth] to the new leaf */ > > if (unlikely(path[depth].p_hdr->eh_entries != > > @@ -1167,6 +1169,7 @@ static int ext4_ext_split(handle_t *handle, struct inode *inode, > > neh->eh_magic = EXT4_EXT_MAGIC; > > neh->eh_max = cpu_to_le16(ext4_ext_space_block_idx(inode, 0)); > > neh->eh_depth = cpu_to_le16(depth - i); > > + neh->eh_generation = 0; > > fidx = EXT_FIRST_INDEX(neh); > > fidx->ei_block = border; > > ext4_idx_store_pblock(fidx, oldblock); The information leak was that uninitialized memory was being written to disk. The way this bug was detected is with KMSAN. If your kernel does not have KMSAN enabled, the reproducer will not appear to do anything. Note that KMSAN requires Linux v6.1 or later and clang v14.0.6 or later. - Eric _______________________________________________ Linux-kernel-mentees mailing list Linux-kernel-mentees@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2022-12-29 20:30 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2021-05-06 18:56 [PATCH v2] ext4: fix kernel infoleak via ext4_extent_header Anirudh Rayabharam 2021-06-16 23:45 ` Theodore Ts'o 2022-09-08 23:11 ` [PATCH] " eadavis 2022-12-26 14:31 ` How can this fix prevent information from leaking to user space and prevent the kernel from crashing? Lizhi Xu 2022-12-29 20:30 ` Eric Biggers
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox