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

From: Dmitry Vyukov
Date: Wed Apr 19 2017 - 16:05:52 EST

Next message: Alexandre Belloni: "[PATCH] rtc: m41t80: Add proper compatible for rv4162"
Previous message: Tony Lindgren: "Re: [PATCH 1/2] clk: ti: divider: try to fix ti_clk_register_divider"
In reply to: Dmitry Vyukov: "Re: fs/notify/inotify: slab-out-of-bounds write in strcpy"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

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

Next message: Alexandre Belloni: "[PATCH] rtc: m41t80: Add proper compatible for rv4162"
Previous message: Tony Lindgren: "Re: [PATCH 1/2] clk: ti: divider: try to fix ti_clk_register_divider"
In reply to: Dmitry Vyukov: "Re: fs/notify/inotify: slab-out-of-bounds write in strcpy"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]