fs/notify/inotify: slab-out-of-bounds write in strcpy

[Andrew Zhu Aday]

Hi all,

Running syzkaller we've found a "slab-out-of-bounds write in strcpy" error.

Using kernel 4.10-rc7 from www.kernel.org/pub/linux/kernel/v4.x/testing/

Unfortunately, I have not been able to generate a reproducible program.

==================================================================
BUG: KASAN: slab-out-of-bounds in strcpy+0x30/0x50 lib/string.c:91 at addr ffff88003b332e96
Write of size 1 by task syz-executor2/3247
CPU: 1 PID: 3247 Comm: syz-executor2 Not tainted 4.10.0-rc7 #3
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_083030-gandalf 04/01/2014
Call Trace:
 __dump_stack lib/dump_stack.c:15 [inline]
 dump_stack+0x95/0xe3 lib/dump_stack.c:51
 kasan_object_err+0x1c/0x70 mm/kasan/report.c:162
 print_address_description mm/kasan/report.c:200 [inline]
 kasan_report_error mm/kasan/report.c:289 [inline]
 kasan_report.part.1+0x20e/0x4e0 mm/kasan/report.c:311
 kasan_report+0x20/0x30 mm/kasan/report.c:298
 check_memory_region_inline mm/kasan/kasan.c:315 [inline]
 __asan_store1+0x4a/0x50 mm/kasan/kasan.c:744
 strcpy+0x30/0x50 lib/string.c:91
 inotify_handle_event+0x148/0x260 fs/notify/inotify/inotify_fsnotify.c:109
 send_to_group fs/notify/fsnotify.c:179 [inline]
 fsnotify+0x50b/0xb50 fs/notify/fsnotify.c:275
 __fsnotify_parent+0xeb/0x190 fs/notify/fsnotify.c:112
 fsnotify_parent include/linux/fsnotify.h:25 [inline]
 fsnotify_close include/linux/fsnotify.h:240 [inline]
 __fput+0xfc/0x380 fs/file_table.c:194
 ____fput+0x15/0x20 fs/file_table.c:244
 task_work_run+0xcb/0x100 kernel/task_work.c:116
 tracehook_notify_resume include/linux/tracehook.h:191 [inline]
 exit_to_usermode_loop+0xc5/0xd0 arch/x86/entry/common.c:160
 prepare_exit_to_usermode arch/x86/entry/common.c:190 [inline]
 syscall_return_slowpath+0x128/0x130 arch/x86/entry/common.c:259
 entry_SYSCALL_64_fastpath+0xab/0xad
RIP: 0033:0x44e4f9
RSP: 002b:00007f9fed919b68 EFLAGS: 00000216 ORIG_RAX: 0000000000000003
RAX: 0000000000000000 RBX: 00000000006f8000 RCX: 000000000044e4f9
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000006
RBP: 0000000000000033 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000216 R12: 0000000000000006
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
Object at ffff88003b332e60, in cache kmalloc-64 size: 64
Allocated:
PID = 3247
 
[<ffffffff8104ba96>] save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:57
 
[<ffffffff81305916>] save_stack+0x46/0xd0 mm/kasan/kasan.c:502
 
[<ffffffff81305b9d>] set_track mm/kasan/kasan.c:514 [inline]
[<ffffffff81305b9d>] kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:605
 
[<ffffffff81301da5>] __kmalloc+0x115/0x2d0 mm/slub.c:3737
 
[<ffffffff8139ba74>] kmalloc include/linux/slab.h:495 [inline]
[<ffffffff8139ba74>] inotify_handle_event+0x84/0x260 fs/notify/inotify/inotify_fsnotify.c:99
 
[<ffffffff81397e4b>] send_to_group fs/notify/fsnotify.c:179 [inline]
[<ffffffff81397e4b>] fsnotify+0x50b/0xb50 fs/notify/fsnotify.c:275
 
[<ffffffff8139857b>] __fsnotify_parent+0xeb/0x190 fs/notify/fsnotify.c:112
 
[<ffffffff813191cc>] fsnotify_parent include/linux/fsnotify.h:25 [inline]
[<ffffffff813191cc>] fsnotify_close include/linux/fsnotify.h:240 [inline]
[<ffffffff813191cc>] __fput+0xfc/0x380 fs/file_table.c:194
 
[<ffffffff813194b5>] ____fput+0x15/0x20 fs/file_table.c:244
 
[<ffffffff810dfdcb>] task_work_run+0xcb/0x100 kernel/task_work.c:116
 
[<ffffffff810025a5>] tracehook_notify_resume include/linux/tracehook.h:191 [inline]
[<ffffffff810025a5>] exit_to_usermode_loop+0xc5/0xd0 arch/x86/entry/common.c:160
 
[<ffffffff81003ae8>] prepare_exit_to_usermode arch/x86/entry/common.c:190 [inline]
[<ffffffff81003ae8>] syscall_return_slowpath+0x128/0x130 arch/x86/entry/common.c:259
 
[<ffffffff822e48bd>] entry_SYSCALL_64_fastpath+0xab/0xad
Freed:
PID = 29969
 
[<ffffffff8104ba96>] save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:57
 
[<ffffffff81305916>] save_stack+0x46/0xd0 mm/kasan/kasan.c:502
 
[<ffffffff81306183>] set_track mm/kasan/kasan.c:514 [inline]
[<ffffffff81306183>] kasan_slab_free+0x73/0xc0 mm/kasan/kasan.c:578
 
[<ffffffff81300a84>] slab_free_hook mm/slub.c:1355 [inline]
[<ffffffff81300a84>] slab_free_freelist_hook mm/slub.c:1377 [inline]
[<ffffffff81300a84>] slab_free mm/slub.c:2954 [inline]
[<ffffffff81300a84>] kfree+0xd4/0x2a0 mm/slub.c:3874
 
[<ffffffff81410ba7>] free_rb_tree_fname+0x67/0xa0 fs/ext4/dir.c:402
 
[<ffffffff81410c12>] ext4_htree_free_dir_info fs/ext4/dir.c:424 [inline]
[<ffffffff81410c12>] ext4_release_dir+0x32/0x50 fs/ext4/dir.c:622
 
[<ffffffff81319265>] __fput+0x195/0x380 fs/file_table.c:208
 
[<ffffffff813194b5>] ____fput+0x15/0x20 fs/file_table.c:244
 
[<ffffffff810dfdcb>] task_work_run+0xcb/0x100 kernel/task_work.c:116
 
[<ffffffff810025a5>] tracehook_notify_resume include/linux/tracehook.h:191 [inline]
[<ffffffff810025a5>] exit_to_usermode_loop+0xc5/0xd0 arch/x86/entry/common.c:160
 
[<ffffffff81003ae8>] prepare_exit_to_usermode arch/x86/entry/common.c:190 [inline]
[<ffffffff81003ae8>] syscall_return_slowpath+0x128/0x130 arch/x86/entry/common.c:259
 
[<ffffffff822e48bd>] entry_SYSCALL_64_fastpath+0xab/0xad
Memory state around the buggy address:
 ffff88003b332d80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
 ffff88003b332e00: fc fc fc fc fc fc fc fc fc fc fc fc 00 00 00 00
>ffff88003b332e80: 00 00 06 fc fc fc fc fc fc fc fc fc fc fc fc fc
                         ^
 ffff88003b332f00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
 ffff88003b332f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fb
==================================================================
Disabling lock debugging due to kernel taint
Kernel panic - not syncing: panic_on_warn set ...

[Andrew Zhu Aday]

[Andrew Zhu Aday]

[Andrew Zhu Aday]

[Dmitry Vyukov]

+ inotify_fsnotify.c maintainers

The only explanation I have for the report is that file_name has
changed in between strlen and strcpy. Is it possible under any
circumstances? That would also explain why it is not reproducible.

[Dmitry Vyukov]

FTR syzkaller program that triggered this is:

mmap(&(0x7f0000000000/0x14000)=nil, (0x14000), 0x3, 0x32,
0xffffffffffffffff, 0x0)
r0 = inotify_init()
r1 = inotify_add_watch(r0, &(0x7f0000000000)="2e", 0xfff)
chmod(&(0x7f0000001000)="2e", 0x1ed)
creat(&(0x7f0000002000)="746573745f66696c6531", 0x1ed)
rename(&(0x7f0000006000-0xa)="746573745f66696c6531",
&(0x7f0000004000)="2e2f66696c653000")
unlink(&(0x7f0000007000)="746573745f66696c6532")
rename(&(0x7f0000008000)="2f746d702f696e6f3047433078462e72656e616d6531",
&(0x7f0000009000)="2f746d702f696e6f3047433078462e72656e616d6532")
rename(&(0x7f000000a000)="2e2f66696c653000",
&(0x7f0000006000-0xa)="746573745f66696c6531")
read(r0, &(0x7f000000c000)="0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
0x1af)
ioctl$TCGETS(r1, 0x5401, &(0x7f000000d000)={0x0, 0x0, 0x0, 0x0, 0x0,
0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0})
close(0xffffffffffffffff)
open(&(0x7f0000010000)="2f746d702f696e6f304743307846", 0x90800, 0x0)


All these syscalls can be executed concurrently from different
threads. Indeed there are some rename calls. Can they change file_name
concurrently?