Closed dvyukov closed 2 years ago
Not sure about this particular error report, but the currently reproducible one:
==================================================================
BUG: KMSAN: kernel-infoleak in _copy_to_user+0x16b/0x1f0 lib/usercopy.c:32
CPU: 1 PID: 12435 Comm: rsyslogd Not tainted 5.2.0+ #15
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+0x191/0x1f0 lib/dump_stack.c:113
kmsan_report+0x162/0x2d0 mm/kmsan/kmsan_report.c:109
kmsan_internal_check_memory+0x544/0xa80 mm/kmsan/kmsan.c:522
kmsan_copy_to_user+0xa9/0xb0 mm/kmsan/kmsan_hooks.c:493
_copy_to_user+0x16b/0x1f0 lib/usercopy.c:32
copy_to_user include/linux/uaccess.h:174 [inline]
syslog_print kernel/printk/printk.c:1406 [inline]
do_syslog+0x2e62/0x3160 kernel/printk/printk.c:1531
kmsg_read+0x142/0x1a0 fs/proc/kmsg.c:40
proc_reg_read+0x25f/0x360 fs/proc/inode.c:221
__vfs_read+0x1a9/0xc90 fs/read_write.c:425
vfs_read+0x359/0x6f0 fs/read_write.c:461
ksys_read+0x265/0x430 fs/read_write.c:587
__do_sys_read fs/read_write.c:597 [inline]
__se_sys_read+0x92/0xb0 fs/read_write.c:595
__x64_sys_read+0x4a/0x70 fs/read_write.c:595
do_syscall_64+0xbc/0xf0 arch/x86/entry/common.c:302
entry_SYSCALL_64_after_hwframe+0x63/0xe7
RIP: 0033:0x7feb18b301fd
Code: d1 20 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 5e fa ff ff 48 89 04 24 b8 00 00 00 00 0f 05 <48> 8b 3c 24 48 89 c2 e8 a7 fa ff ff 48 89 d0 48 83 c4 08 48 3d 01
RSP: 002b:00007feb160cfe30 EFLAGS: 00000293 ORIG_RAX: 0000000000000000
RAX: ffffffffffffffda RBX: 0000000000c9b4b0 RCX: 00007feb18b301fd
RDX: 0000000000000fff RSI: 00007feb179045a0 RDI: 0000000000000004
RBP: 0000000000000000 R08: 0000000000c86260 R09: 0000000004000001
R10: 0000000000000001 R11: 0000000000000293 R12: 000000000065e420
R13: 00007feb160d09c0 R14: 00007feb19175040 R15: 0000000000000003
Uninit was created at:
kmsan_save_stack_with_flags mm/kmsan/kmsan.c:187 [inline]
kmsan_internal_poison_shadow+0x53/0xa0 mm/kmsan/kmsan.c:146
kmsan_slab_alloc+0xaa/0x120 mm/kmsan/kmsan_hooks.c:175
slab_alloc_node mm/slub.c:2771 [inline]
slab_alloc mm/slub.c:2780 [inline]
kmem_cache_alloc_trace+0x873/0xa50 mm/slub.c:2797
kmalloc include/linux/slab.h:547 [inline]
syslog_print kernel/printk/printk.c:1358 [inline]
do_syslog+0x263b/0x3160 kernel/printk/printk.c:1531
kmsg_read+0x142/0x1a0 fs/proc/kmsg.c:40
proc_reg_read+0x25f/0x360 fs/proc/inode.c:221
__vfs_read+0x1a9/0xc90 fs/read_write.c:425
vfs_read+0x359/0x6f0 fs/read_write.c:461
ksys_read+0x265/0x430 fs/read_write.c:587
__do_sys_read fs/read_write.c:597 [inline]
__se_sys_read+0x92/0xb0 fs/read_write.c:595
__x64_sys_read+0x4a/0x70 fs/read_write.c:595
do_syscall_64+0xbc/0xf0 arch/x86/entry/common.c:302
entry_SYSCALL_64_after_hwframe+0x63/0xe7
Byte 116 of 118 is uninitialized
Memory access of size 118 starts at ffff88811b37ec00
Data copied to user address 00007feb179045a0
==================================================================
seems to be an actual bug in syslog_print() that goes away if I change it to allocate with
kzalloc()`.
Not sure yet what's causing it.
Checking uninit printk arguments is doable, yet requires some changes to printk implementation.
The problem is that printk()
iterates over the arguments under the console lock that disables error reporting.
There's been a bunch of printk changes in the past years, I think we are better at reporting bugs in printk() now
Example report below. We only detect the uninit when we read out console output from /dev/kmsg. If we don't read it out, we don't detect it. Even if we do, we detect it too late and attribute all such info leaks to do_syslog. We should detect them right in printk and attribute to the function that prints uninits.