Messages in this thread | | | From | Dmitry Vyukov <> | Date | Wed, 19 Apr 2017 22:05:22 +0200 | Subject | Re: fs/notify/inotify: slab-out-of-bounds write in strcpy |
| |
On Wed, Apr 19, 2017 at 9:31 PM, Dmitry Vyukov <dvyukov@google.com> wrote: > On Wed, Apr 12, 2017 at 5:58 AM, Andrew Zhu Aday > <andrew.aday@columbia.edu> wrote: >> 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 >> ================================================================== > > + 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.
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?
| |