All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Vyukov <dvyukov@google.com>
To: Andrew Zhu Aday <andrew.aday@columbia.edu>,
	john@johnmccutchan.com, rlove@rlove.org,
	Eric Paris <eparis@parisplace.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
	syzkaller <syzkaller@googlegroups.com>,
	Shankara Pailoor <sp3485@columbia.edu>
Subject: Re: fs/notify/inotify: slab-out-of-bounds write in strcpy
Date: Wed, 19 Apr 2017 22:05:22 +0200	[thread overview]
Message-ID: <CACT4Y+ax3bRtY4zYYeXud9QSy5SgRTaGt7SD2zZDOCMrPWKL1g@mail.gmail.com> (raw)
In-Reply-To: <CACT4Y+Zp7WT0qOj74NqauuKSha+FPjeoN7DDDmKrT_ig9gBZZA@mail.gmail.com>

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?

  reply	other threads:[~2017-04-19 20:05 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAHAAGF=SVZ-=c87u7gft3LDajvmug87vVB4aL3dnJ=8i22Hpyg@mail.gmail.com>
2017-04-19 19:31 ` fs/notify/inotify: slab-out-of-bounds write in strcpy Dmitry Vyukov
2017-04-19 20:05   ` Dmitry Vyukov [this message]
2017-04-12  4:34 Andrew Zhu Aday

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CACT4Y+ax3bRtY4zYYeXud9QSy5SgRTaGt7SD2zZDOCMrPWKL1g@mail.gmail.com \
    --to=dvyukov@google.com \
    --cc=andrew.aday@columbia.edu \
    --cc=eparis@parisplace.org \
    --cc=john@johnmccutchan.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rlove@rlove.org \
    --cc=sp3485@columbia.edu \
    --cc=syzkaller@googlegroups.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.