[syzbot] [hfs?] KMSAN: uninit-value in hfsplus_listxattr

[syzbot] [hfs?] KMSAN: uninit-value in hfsplus_listxattr

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:    80383273f7a0 kmsan: silence -Wmissing-prototypes warnings
git tree:       https://github.com/google/kmsan.git master
console output: https://syzkaller.appspot.com/x/log.txt?x=17960fd6480000
kernel config:  https://syzkaller.appspot.com/x/.config?x=b63e082c4fda2e77
dashboard link: https://syzkaller.appspot.com/bug?extid=92ef9ee419803871020e
compiler:       clang version 15.0.0 (https://github.com/llvm/llvm-project.git 610139d2d9ce6746b3c617fb3e2f7886272d26ff), GNU ld (GNU Binutils for Debian) 2.35.2
userspace arch: i386

Unfortunately, I don't have any reproducer for this issue yet.

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/f76b21f14e30/disk-80383273.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/ac1c985c1983/vmlinux-80383273.xz
kernel image: https://storage.googleapis.com/syzbot-assets/d6710cffdb38/bzImage-80383273.xz

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+92ef9ee419803871020e@syzkaller.appspotmail.com

loop4: detected capacity change from 0 to 1024
=====================================================
BUG: KMSAN: uninit-value in strncmp+0x11b/0x180 lib/string.c:307
 strncmp+0x11b/0x180 lib/string.c:307
 hfsplus_listxattr+0x996/0x1aa0
 vfs_listxattr fs/xattr.c:472 [inline]
 listxattr+0x703/0x780 fs/xattr.c:820
 path_listxattr fs/xattr.c:844 [inline]
 __do_sys_llistxattr fs/xattr.c:862 [inline]
 __se_sys_llistxattr fs/xattr.c:859 [inline]
 __ia32_sys_llistxattr+0x16d/0x300 fs/xattr.c:859
 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline]
 __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178
 do_fast_syscall_32+0x33/0x70 arch/x86/entry/common.c:203
 do_SYSENTER_32+0x1b/0x20 arch/x86/entry/common.c:246
 entry_SYSENTER_compat_after_hwframe+0x70/0x82

Uninit was created at:
 slab_post_alloc_hook mm/slab.h:766 [inline]
 slab_alloc_node mm/slub.c:3452 [inline]
 __kmem_cache_alloc_node+0x71f/0xce0 mm/slub.c:3491
 kmalloc_trace+0x4d/0x1f0 mm/slab_common.c:1062
 kmalloc include/linux/slab.h:580 [inline]
 hfsplus_listxattr+0x4dc/0x1aa0 fs/hfsplus/xattr.c:702
 vfs_listxattr fs/xattr.c:472 [inline]
 listxattr+0x703/0x780 fs/xattr.c:820
 path_listxattr fs/xattr.c:844 [inline]
 __do_sys_llistxattr fs/xattr.c:862 [inline]
 __se_sys_llistxattr fs/xattr.c:859 [inline]
 __ia32_sys_llistxattr+0x16d/0x300 fs/xattr.c:859
 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline]
 __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178
 do_fast_syscall_32+0x33/0x70 arch/x86/entry/common.c:203
 do_SYSENTER_32+0x1b/0x20 arch/x86/entry/common.c:246
 entry_SYSENTER_compat_after_hwframe+0x70/0x82

CPU: 1 PID: 11511 Comm: syz-executor.4 Not tainted 6.2.0-rc3-syzkaller-79341-g80383273f7a0 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
=====================================================


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

Re: [syzbot] [hfs?] KMSAN: uninit-value in hfsplus_listxattr

[侯伟桃 Vincent Hou]

Since the strbuf in hfsplus_listxattr was allocated with kmalloc and filled with hfsplus_uni2asc,
which did not fill "\0" in last byte,  in some cases,  the uninited byte may be accessed when
compare the strbuf with known namespace.  But I still need check the value of xattr in strbuf
to confirm the root cause.  Please help test with below debug patch.

#syz test: https://github.com/google/kmsan.git 80383273f7a0

--- a/fs/hfsplus/xattr.c
+++ b/fs/hfsplus/xattr.c
@@ -671,6 +671,7 @@ static ssize_t hfsplus_listxattr_finder_info(struct dentry *dentry,
 	return res;
 }
 
+extern bool kmsan_enabled;
 ssize_t hfsplus_listxattr(struct dentry *dentry, char *buffer, size_t size)
 {
 	ssize_t err;
@@ -681,6 +682,8 @@ ssize_t hfsplus_listxattr(struct dentry *dentry, char *buffer, size_t size)
 	struct hfsplus_attr_key attr_key;
 	char *strbuf;
 	int xattr_name_len;
+	int off = 0;
+	char *dumpinfo;
 
 	if ((!S_ISREG(inode->i_mode) &&
 			!S_ISDIR(inode->i_mode)) ||
@@ -705,6 +708,12 @@ ssize_t hfsplus_listxattr(struct dentry *dentry, char *buffer, size_t size)
 		res = -ENOMEM;
 		goto out;
 	}
+	dumpinfo = kzalloc(200, GFP_KERNEL);
+	if (!dumpinfo) {
+		kfree(strbuf);
+		res = -ENOMEM;
+		goto out;
+	}
 
 	err = hfsplus_find_attr(inode->i_sb, inode->i_ino, NULL, &fd);
 	if (err) {
@@ -741,6 +750,15 @@ ssize_t hfsplus_listxattr(struct dentry *dentry, char *buffer, size_t size)
 			goto end_listxattr;
 		}
 
+		pr_info("find xattr size:%ld and dump strbuf pre 20 bytes:\n", size);
+		WRITE_ONCE(kmsan_enabled, false);
+		if (kmsan_enabled == false) {
+			for (off = 0; off < 20; off++) {
+				sprintf(dumpinfo + off * 5, " 0x%02x", strbuf[off]);
+			}
+			pr_info("%s\n", dumpinfo);
+		}
+		WRITE_ONCE(kmsan_enabled, true);
 		if (!buffer || !size) {
 			if (can_list(strbuf))
 				res += name_len(strbuf, xattr_name_len);
@@ -759,6 +777,7 @@ ssize_t hfsplus_listxattr(struct dentry *dentry, char *buffer, size_t size)
 
 end_listxattr:
 	kfree(strbuf);
+	kfree(dumpinfo);
 out:
 	hfs_find_exit(&fd);
 	return res;

Re: [syzbot] [hfs?] KMSAN: uninit-value in hfsplus_listxattr

[Christian Brauner]

On Mon, May 22, 2023 at 10:12:38AM +0000, 侯伟桃 Vincent Hou wrote:
> Since the strbuf in hfsplus_listxattr was allocated with kmalloc and filled with hfsplus_uni2asc,
> which did not fill "\0" in last byte,  in some cases,  the uninited byte may be accessed when
> compare the strbuf with known namespace.  But I still need check the value of xattr in strbuf
> to confirm the root cause.  Please help test with below debug patch.

Uhm, no... The fs maintainers aren't responsible for testing random
debug patches sent to the list. This thing is also orphaned so the
chance of someone doing the work for you is drastically close to zero.