[PATCH v2] ext4: fix kernel infoleak via ext4_extent_header

[PATCH v2] ext4: fix kernel infoleak via ext4_extent_header

[Anirudh Rayabharam]

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

Re: [PATCH v2] ext4: fix kernel infoleak via ext4_extent_header

[Theodore Ts'o]

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

[PATCH] ext4: fix kernel infoleak via ext4_extent_header

[eadavis]

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

How can this fix prevent information from leaking to user space and prevent the kernel from crashing?

[Lizhi Xu]

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

Re: How can this fix prevent information from leaking to user space and prevent the kernel from crashing?

[Eric Biggers]

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