Message-ID: <CACT4Y+ax3bRtY4zYYeXud9QSy5SgRTaGt7SD2zZDOCMrPWKL1g@mail.gmail.com>
Date:   Wed, 19 Apr 2017 22:05:22 +0200
From:   Dmitry Vyukov <dvyukov@...gle.com>
To:     Andrew Zhu Aday <andrew.aday@...umbia.edu>, john@...nmccutchan.com,
        rlove@...ve.org, Eric Paris <eparis@...isplace.org>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        syzkaller <syzkaller@...glegroups.com>,
        Shankara Pailoor <sp3485@...umbia.edu>
Subject: Re: fs/notify/inotify: slab-out-of-bounds write in strcpy

On Wed, Apr 19, 2017 at 9:31 PM, Dmitry Vyukov <dvyukov@...gle.com> wrote:
> On Wed, Apr 12, 2017 at 5:58 AM, Andrew Zhu Aday
> <andrew.aday@...umbia.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?

Powered by blists - more mailing lists