KASAN: slab-out-of-bounds Read in vhci_hub_control

KASAN: slab-out-of-bounds Read in vhci_hub_control

[syzbot]

Hello,

syzbot found the following crash on:

HEAD commit:    420f51f4ab6b Merge tag 'arm64-fixes' of git://git.kernel.o..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=126a6f0e400000
kernel config:  https://syzkaller.appspot.com/x/.config?x=531a917630d2a492
dashboard link: https://syzkaller.appspot.com/bug?extid=bccc1fe10b70fadc78d0
compiler:       gcc (GCC) 8.0.1 20180413 (experimental)
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=121caa46400000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=14ed8ab6400000

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+bccc1fe10b70fadc78d0@syzkaller.appspotmail.com

random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
vhci_hcd: invalid port number 132
==================================================================
BUG: KASAN: slab-out-of-bounds in vhci_hub_control+0x1b88/0x1bf0  
drivers/usb/usbip/vhci_hcd.c:441
Read of size 4 at addr ffff8801ce615ebc by task syz-executor741/4647

CPU: 1 PID: 4647 Comm: syz-executor741 Not tainted 4.19.0-rc1+ #217
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011
Call Trace:
  __dump_stack lib/dump_stack.c:77 [inline]
  dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113
  print_address_description+0x6c/0x20b mm/kasan/report.c:256
  kasan_report_error mm/kasan/report.c:354 [inline]
  kasan_report.cold.7+0x242/0x30d mm/kasan/report.c:412
  __asan_report_load4_noabort+0x14/0x20 mm/kasan/report.c:432
  vhci_hub_control+0x1b88/0x1bf0 drivers/usb/usbip/vhci_hcd.c:441
  rh_call_control drivers/usb/core/hcd.c:679 [inline]
  rh_urb_enqueue drivers/usb/core/hcd.c:838 [inline]
  usb_hcd_submit_urb+0x184a/0x2160 drivers/usb/core/hcd.c:1651
  usb_submit_urb+0x895/0x14d0 drivers/usb/core/urb.c:570
  usb_start_wait_urb+0x140/0x360 drivers/usb/core/message.c:57
  usb_internal_control_msg drivers/usb/core/message.c:101 [inline]
  usb_control_msg+0x332/0x4e0 drivers/usb/core/message.c:152
  proc_control+0x99b/0xef0 drivers/usb/core/devio.c:1106
  usbdev_do_ioctl+0x1eb4/0x3b30 drivers/usb/core/devio.c:2394
  usbdev_ioctl+0x25/0x30 drivers/usb/core/devio.c:2551
  vfs_ioctl fs/ioctl.c:46 [inline]
  file_ioctl fs/ioctl.c:501 [inline]
  do_vfs_ioctl+0x1de/0x1720 fs/ioctl.c:685
  ksys_ioctl+0xa9/0xd0 fs/ioctl.c:702
  __do_sys_ioctl fs/ioctl.c:709 [inline]
  __se_sys_ioctl fs/ioctl.c:707 [inline]
  __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:707
  do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
  entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x449329
Code: e8 ac b7 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7  
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff  
ff 0f 83 ab d6 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f8653ff9da8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00000000006dac28 RCX: 0000000000449329
RDX: 0000000020000100 RSI: 00000000c0185500 RDI: 0000000000000003
RBP: 00000000006dac20 R08: 00000000006dac2c R09: 0000000000000000
R10: 00007f8653ffa700 R11: 0000000000000246 R12: 00000000006dac2c
R13: 2330302f6273752f R14: 7375622f7665642f R15: 00000000006dad2c

Allocated by task 1:
  save_stack+0x43/0xd0 mm/kasan/kasan.c:448
  set_track mm/kasan/kasan.c:460 [inline]
  kasan_kmalloc+0xc4/0xe0 mm/kasan/kasan.c:553
  kmem_cache_alloc_trace+0x152/0x730 mm/slab.c:3620
  kmalloc include/linux/slab.h:513 [inline]
  kzalloc include/linux/slab.h:707 [inline]
  usb_set_configuration+0x10e9/0x19f0 drivers/usb/core/message.c:1834
  generic_probe+0xb6/0x110 drivers/usb/core/generic.c:174
  usb_probe_device+0xaf/0x110 drivers/usb/core/driver.c:266
  really_probe+0x5be/0x850 drivers/base/dd.c:500
  driver_probe_device+0x108/0x210 drivers/base/dd.c:662
  __device_attach_driver+0x25a/0x2d0 drivers/base/dd.c:758
  bus_for_each_drv+0x16b/0x1f0 drivers/base/bus.c:461
  __device_attach+0x2a1/0x430 drivers/base/dd.c:815
  device_initial_probe+0x1a/0x20 drivers/base/dd.c:862
  bus_probe_device+0x1fb/0x2a0 drivers/base/bus.c:521
  device_add+0x93e/0x17b0 drivers/base/core.c:1927
  usb_new_device+0x8ac/0x12b0 drivers/usb/core/hub.c:2485
  register_root_hub drivers/usb/core/hcd.c:1105 [inline]
  usb_add_hcd+0xb1f/0x1910 drivers/usb/core/hcd.c:2882
  vhci_hcd_probe+0xfb/0x240 drivers/usb/usbip/vhci_hcd.c:1316
  platform_drv_probe+0x96/0x160 drivers/base/platform.c:579
  really_probe+0x5be/0x850 drivers/base/dd.c:500
  driver_probe_device+0x108/0x210 drivers/base/dd.c:662
  __device_attach_driver+0x25a/0x2d0 drivers/base/dd.c:758
  bus_for_each_drv+0x16b/0x1f0 drivers/base/bus.c:461
  __device_attach+0x2a1/0x430 drivers/base/dd.c:815
  device_initial_probe+0x1a/0x20 drivers/base/dd.c:862
  bus_probe_device+0x1fb/0x2a0 drivers/base/bus.c:521
  device_add+0x93e/0x17b0 drivers/base/core.c:1927
  platform_device_add+0x36e/0x6f0 drivers/base/platform.c:417
  vhci_hcd_init+0x386/0x4e0 drivers/usb/usbip/vhci_hcd.c:1500
  do_one_initcall+0x127/0x838 init/main.c:885
  do_initcall_level init/main.c:953 [inline]
  do_initcalls init/main.c:961 [inline]
  do_basic_setup init/main.c:979 [inline]
  kernel_init_freeable+0x4bb/0x5ae init/main.c:1144
  kernel_init+0x11/0x1b3 init/main.c:1063
  ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:413

Freed by task 0:
(stack is not available)

The buggy address belongs to the object at ffff8801ce615300
  which belongs to the cache kmalloc-2048 of size 2048
The buggy address is located 956 bytes to the right of
  2048-byte region [ffff8801ce615300, ffff8801ce615b00)
The buggy address belongs to the page:
page:ffffea0007398500 count:1 mapcount:0 mapping:ffff8801dac00c40 index:0x0  
compound_mapcount: 0
flags: 0x2fffc0000008100(slab|head)
raw: 02fffc0000008100 ffffea0007397988 ffffea0007398788 ffff8801dac00c40
raw: 0000000000000000 ffff8801ce614200 0000000100000003 0000000000000000
page dumped because: kasan: bad access detected

Memory state around the buggy address:
  ffff8801ce615d80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
  ffff8801ce615e00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ffff8801ce615e80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
                                         ^
  ffff8801ce615f00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
  ffff8801ce615f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
==================================================================


---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.

syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with  
syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches

Re: KASAN: slab-out-of-bounds Read in vhci_hub_control

[Shuah Khan]

On 09/04/2018 12:52 PM, syzbot wrote:
> Hello,
> 
> syzbot found the following crash on:
> 
> HEAD commit:    420f51f4ab6b Merge tag 'arm64-fixes' of git://git.kernel.o..
> git tree:       upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=126a6f0e400000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=531a917630d2a492
> dashboard link: https://syzkaller.appspot.com/bug?extid=bccc1fe10b70fadc78d0
> compiler:       gcc (GCC) 8.0.1 20180413 (experimental)
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=121caa46400000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=14ed8ab6400000

C producer doesn't reproduce the problem on 4.19-rc5. Does this C producer
depend on state of the machine? i.e what is the status of vhci_hcd - are
there any devices attached?

I can see the problem looking at the code and fix is easy. However, I would
like be able to reproduce it and verify the fix works. Also this would be a
good regression for the driver I could consider adding to selftests.

thanks,
-- Shuah

Re: KASAN: slab-out-of-bounds Read in vhci_hub_control

[Dmitry Vyukov]

On Tue, Oct 2, 2018 at 6:04 PM, Shuah Khan <shuah@kernel.org> wrote:
> On 09/04/2018 12:52 PM, syzbot wrote:
>> Hello,
>>
>> syzbot found the following crash on:
>>
>> HEAD commit:    420f51f4ab6b Merge tag 'arm64-fixes' of git://git.kernel.o..
>> git tree:       upstream
>> console output: https://syzkaller.appspot.com/x/log.txt?x=126a6f0e400000
>> kernel config:  https://syzkaller.appspot.com/x/.config?x=531a917630d2a492
>> dashboard link: https://syzkaller.appspot.com/bug?extid=bccc1fe10b70fadc78d0
>> compiler:       gcc (GCC) 8.0.1 20180413 (experimental)
>> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=121caa46400000
>> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=14ed8ab6400000
>
> C producer doesn't reproduce the problem on 4.19-rc5. Does this C producer
> depend on state of the machine? i.e what is the status of vhci_hcd - are
> there any devices attached?

Hi Shuah,

syzbot always runs tests reproducers on a clean machine. There is some
state are running a Debian wheezy init, but no test/fuzz/stress
workload is run before the reproducer.
syzbot also uses VMs, so there are no real devices attached. And it's
GCE VMs (not qemu), and I think GCE does not even emulate any USB
devices.

An obvious thing to try would be to use the exact commit and config
syzbot gave (rather than 4.19-rc5).
You can also take the image syzbot uses here:
https://github.com/google/syzkaller/blob/master/docs/syzbot.md#crash-does-not-reproduce


> I can see the problem looking at the code and fix is easy. However, I would
> like be able to reproduce it and verify the fix works. Also this would be a
> good regression for the driver I could consider adding to selftests.

syzbot can test fixes for bugs with reproducers:
https://github.com/google/syzkaller/blob/master/docs/syzbot.md#testing-patches
So it can test your fix. But this obviously won't help with a test.

Re: KASAN: slab-out-of-bounds Read in vhci_hub_control

[Shuah Khan]

On 10/02/2018 10:42 AM, Dmitry Vyukov wrote:
> On Tue, Oct 2, 2018 at 6:04 PM, Shuah Khan <shuah@kernel.org> wrote:
>> On 09/04/2018 12:52 PM, syzbot wrote:
>>> Hello,
>>>
>>> syzbot found the following crash on:
>>>
>>> HEAD commit:    420f51f4ab6b Merge tag 'arm64-fixes' of git://git.kernel.o..
>>> git tree:       upstream
>>> console output: https://syzkaller.appspot.com/x/log.txt?x=126a6f0e400000
>>> kernel config:  https://syzkaller.appspot.com/x/.config?x=531a917630d2a492
>>> dashboard link: https://syzkaller.appspot.com/bug?extid=bccc1fe10b70fadc78d0
>>> compiler:       gcc (GCC) 8.0.1 20180413 (experimental)
>>> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=121caa46400000
>>> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=14ed8ab6400000
>>
>> C producer doesn't reproduce the problem on 4.19-rc5. Does this C producer
>> depend on state of the machine? i.e what is the status of vhci_hcd - are
>> there any devices attached?
> 
> Hi Shuah,
> 
> syzbot always runs tests reproducers on a clean machine. There is some
> state are running a Debian wheezy init, but no test/fuzz/stress
> workload is run before the reproducer.
> syzbot also uses VMs, so there are no real devices attached. And it's
> GCE VMs (not qemu), and I think GCE does not even emulate any USB
> devices.
> 
> An obvious thing to try would be to use the exact commit and config
> syzbot gave (rather than 4.19-rc5).
> You can also take the image syzbot uses here:
> https://github.com/google/syzkaller/blob/master/docs/syzbot.md#crash-does-not-reproduce
> 
> 
>> I can see the problem looking at the code and fix is easy. However, I would
>> like be able to reproduce it and verify the fix works. Also this would be a
>> good regression for the driver I could consider adding to selftests.
> 
> syzbot can test fixes for bugs with reproducers:
> https://github.com/google/syzkaller/blob/master/docs/syzbot.md#testing-patches
> So it can test your fix. But this obviously won't help with a test.
> 

Tried the same config and no luck. Any chance you have the complete dmesg?

thanks,
-- Shuah

Re: KASAN: slab-out-of-bounds Read in vhci_hub_control

[Dmitry Vyukov]

On Wed, Oct 3, 2018 at 1:21 AM, Shuah Khan <shuah@kernel.org> wrote:
> On 10/02/2018 10:42 AM, Dmitry Vyukov wrote:
>> On Tue, Oct 2, 2018 at 6:04 PM, Shuah Khan <shuah@kernel.org> wrote:
>>> On 09/04/2018 12:52 PM, syzbot wrote:
>>>> Hello,
>>>>
>>>> syzbot found the following crash on:
>>>>
>>>> HEAD commit:    420f51f4ab6b Merge tag 'arm64-fixes' of git://git.kernel.o..
>>>> git tree:       upstream
>>>> console output: https://syzkaller.appspot.com/x/log.txt?x=126a6f0e400000
>>>> kernel config:  https://syzkaller.appspot.com/x/.config?x=531a917630d2a492
>>>> dashboard link: https://syzkaller.appspot.com/bug?extid=bccc1fe10b70fadc78d0
>>>> compiler:       gcc (GCC) 8.0.1 20180413 (experimental)
>>>> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=121caa46400000
>>>> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=14ed8ab6400000
>>>
>>> C producer doesn't reproduce the problem on 4.19-rc5. Does this C producer
>>> depend on state of the machine? i.e what is the status of vhci_hcd - are
>>> there any devices attached?
>>
>> Hi Shuah,
>>
>> syzbot always runs tests reproducers on a clean machine. There is some
>> state are running a Debian wheezy init, but no test/fuzz/stress
>> workload is run before the reproducer.
>> syzbot also uses VMs, so there are no real devices attached. And it's
>> GCE VMs (not qemu), and I think GCE does not even emulate any USB
>> devices.
>>
>> An obvious thing to try would be to use the exact commit and config
>> syzbot gave (rather than 4.19-rc5).
>> You can also take the image syzbot uses here:
>> https://github.com/google/syzkaller/blob/master/docs/syzbot.md#crash-does-not-reproduce
>>
>>
>>> I can see the problem looking at the code and fix is easy. However, I would
>>> like be able to reproduce it and verify the fix works. Also this would be a
>>> good regression for the driver I could consider adding to selftests.
>>
>> syzbot can test fixes for bugs with reproducers:
>> https://github.com/google/syzkaller/blob/master/docs/syzbot.md#testing-patches
>> So it can test your fix. But this obviously won't help with a test.
>>
>
> Tried the same config and no luck. Any chance you have the complete dmesg?

By "complete" you mean "from the boot"? If yes, then no, we don't keep
it, full output can be huge and it's not a moving part.

I've captured boot output from another similar machine, unfortunately
dmesg buffer is not large enough to fit it all, so not sure if you
will find what you are looking for there:
https://gist.githubusercontent.com/dvyukov/11b83aeda0466a0f171451d86ab36e15/raw/57121db6cf1bbb5e57c08746241b03904bde95f6/gistfile1.txt

Re: KASAN: slab-out-of-bounds Read in vhci_hub_control

[Dmitry Vyukov]

On Wed, Oct 10, 2018 at 8:41 PM, Dmitry Vyukov <dvyukov@google.com> wrote:
> On Wed, Oct 3, 2018 at 1:21 AM, Shuah Khan <shuah@kernel.org> wrote:
>> On 10/02/2018 10:42 AM, Dmitry Vyukov wrote:
>>> On Tue, Oct 2, 2018 at 6:04 PM, Shuah Khan <shuah@kernel.org> wrote:
>>>> On 09/04/2018 12:52 PM, syzbot wrote:
>>>>> Hello,
>>>>>
>>>>> syzbot found the following crash on:
>>>>>
>>>>> HEAD commit:    420f51f4ab6b Merge tag 'arm64-fixes' of git://git.kernel.o..
>>>>> git tree:       upstream
>>>>> console output: https://syzkaller.appspot.com/x/log.txt?x=126a6f0e400000
>>>>> kernel config:  https://syzkaller.appspot.com/x/.config?x=531a917630d2a492
>>>>> dashboard link: https://syzkaller.appspot.com/bug?extid=bccc1fe10b70fadc78d0
>>>>> compiler:       gcc (GCC) 8.0.1 20180413 (experimental)
>>>>> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=121caa46400000
>>>>> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=14ed8ab6400000
>>>>
>>>> C producer doesn't reproduce the problem on 4.19-rc5. Does this C producer
>>>> depend on state of the machine? i.e what is the status of vhci_hcd - are
>>>> there any devices attached?
>>>
>>> Hi Shuah,
>>>
>>> syzbot always runs tests reproducers on a clean machine. There is some
>>> state are running a Debian wheezy init, but no test/fuzz/stress
>>> workload is run before the reproducer.
>>> syzbot also uses VMs, so there are no real devices attached. And it's
>>> GCE VMs (not qemu), and I think GCE does not even emulate any USB
>>> devices.
>>>
>>> An obvious thing to try would be to use the exact commit and config
>>> syzbot gave (rather than 4.19-rc5).
>>> You can also take the image syzbot uses here:
>>> https://github.com/google/syzkaller/blob/master/docs/syzbot.md#crash-does-not-reproduce
>>>
>>>
>>>> I can see the problem looking at the code and fix is easy. However, I would
>>>> like be able to reproduce it and verify the fix works. Also this would be a
>>>> good regression for the driver I could consider adding to selftests.
>>>
>>> syzbot can test fixes for bugs with reproducers:
>>> https://github.com/google/syzkaller/blob/master/docs/syzbot.md#testing-patches
>>> So it can test your fix. But this obviously won't help with a test.
>>>
>>
>> Tried the same config and no luck. Any chance you have the complete dmesg?
>
> By "complete" you mean "from the boot"? If yes, then no, we don't keep
> it, full output can be huge and it's not a moving part.
>
> I've captured boot output from another similar machine, unfortunately
> dmesg buffer is not large enough to fit it all, so not sure if you
> will find what you are looking for there:
> https://gist.githubusercontent.com/dvyukov/11b83aeda0466a0f171451d86ab36e15/raw/57121db6cf1bbb5e57c08746241b03904bde95f6/gistfile1.txt


Here is all vhci stuff in /sys if it help.
But it's really just a VM with no hardware, so should be reproducible
everywhere.

root@syzkaller:~# find /sys -name "*vhci*"
/sys/class/misc/vhci
/sys/devices/platform/vhci_hcd.15
/sys/devices/platform/vhci_hcd.13
/sys/devices/platform/vhci_hcd.8
/sys/devices/platform/vhci_hcd.11
/sys/devices/platform/vhci_hcd.6
/sys/devices/platform/vhci_hcd.4
/sys/devices/platform/vhci_hcd.2
/sys/devices/platform/vhci_hcd.0
/sys/devices/platform/vhci_hcd.14
/sys/devices/platform/vhci_hcd.9
/sys/devices/platform/vhci_hcd.12
/sys/devices/platform/vhci_hcd.7
/sys/devices/platform/vhci_hcd.10
/sys/devices/platform/vhci_hcd.5
/sys/devices/platform/vhci_hcd.3
/sys/devices/platform/vhci_hcd.1
/sys/devices/virtual/misc/vhci
/sys/bus/platform/devices/vhci_hcd.15
/sys/bus/platform/devices/vhci_hcd.13
/sys/bus/platform/devices/vhci_hcd.8
/sys/bus/platform/devices/vhci_hcd.11
/sys/bus/platform/devices/vhci_hcd.6
/sys/bus/platform/devices/vhci_hcd.4
/sys/bus/platform/devices/vhci_hcd.2
/sys/bus/platform/devices/vhci_hcd.0
/sys/bus/platform/devices/vhci_hcd.14
/sys/bus/platform/devices/vhci_hcd.9
/sys/bus/platform/devices/vhci_hcd.12
/sys/bus/platform/devices/vhci_hcd.7
/sys/bus/platform/devices/vhci_hcd.10
/sys/bus/platform/devices/vhci_hcd.5
/sys/bus/platform/devices/vhci_hcd.3
/sys/bus/platform/devices/vhci_hcd.1
/sys/bus/platform/drivers/vhci_hcd
/sys/bus/platform/drivers/vhci_hcd/vhci_hcd.15
/sys/bus/platform/drivers/vhci_hcd/vhci_hcd.13
/sys/bus/platform/drivers/vhci_hcd/vhci_hcd.8
/sys/bus/platform/drivers/vhci_hcd/vhci_hcd.11
/sys/bus/platform/drivers/vhci_hcd/vhci_hcd.6
/sys/bus/platform/drivers/vhci_hcd/vhci_hcd.4
/sys/bus/platform/drivers/vhci_hcd/vhci_hcd.2
/sys/bus/platform/drivers/vhci_hcd/vhci_hcd.0
/sys/bus/platform/drivers/vhci_hcd/vhci_hcd.14
/sys/bus/platform/drivers/vhci_hcd/vhci_hcd.9
/sys/bus/platform/drivers/vhci_hcd/vhci_hcd.12
/sys/bus/platform/drivers/vhci_hcd/vhci_hcd.7
/sys/bus/platform/drivers/vhci_hcd/vhci_hcd.10
/sys/bus/platform/drivers/vhci_hcd/vhci_hcd.5
/sys/bus/platform/drivers/vhci_hcd/vhci_hcd.3
/sys/bus/platform/drivers/vhci_hcd/vhci_hcd.1
/sys/module/hci_vhci

Re: KASAN: slab-out-of-bounds Read in vhci_hub_control

[Dmitry Vyukov]

On Tue, Oct 2, 2018 at 6:04 PM, Shuah Khan <shuah@kernel.org> wrote:
> On 09/04/2018 12:52 PM, syzbot wrote:
>> Hello,
>>
>> syzbot found the following crash on:
>>
>> HEAD commit:    420f51f4ab6b Merge tag 'arm64-fixes' of git://git.kernel.o..
>> git tree:       upstream
>> console output: https://syzkaller.appspot.com/x/log.txt?x=126a6f0e400000
>> kernel config:  https://syzkaller.appspot.com/x/.config?x=531a917630d2a492
>> dashboard link: https://syzkaller.appspot.com/bug?extid=bccc1fe10b70fadc78d0
>> compiler:       gcc (GCC) 8.0.1 20180413 (experimental)
>> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=121caa46400000
>> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=14ed8ab6400000
>
> C producer doesn't reproduce the problem on 4.19-rc5. Does this C producer
> depend on state of the machine? i.e what is the status of vhci_hcd - are
> there any devices attached?
>
> I can see the problem looking at the code and fix is easy. However, I would
> like be able to reproduce it and verify the fix works. Also this would be a
> good regression for the driver I could consider adding to selftests.



Are you sure you used the provided config/commit?
I've followed these instructions:
https://github.com/google/syzkaller/blob/master/docs/syzbot.md#crash-does-not-reproduce
and the C repro gave me this in a second:

[   57.259910] ==================================================================
[   57.262304] BUG: KASAN: slab-out-of-bounds in vhci_hub_control+0x169c/0x1a70
[   57.264508] Read of size 4 at addr ffff880064641fbc by task a.out/4253
[   57.266581]
[   57.267093] CPU: 3 PID: 4253 Comm: a.out Not tainted 4.19.0-rc5+ #13
[   57.269107] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS 1.10.2-1 04/01/2014
[   57.271324] Call Trace:
[   57.271786]  dump_stack+0x1af/0x295
[   57.272449]  ? arch_local_irq_restore+0x53/0x53
[   57.273249]  ? kmsg_dump_rewind_nolock+0xe4/0xe4
[   57.274049]  ? trace_hardirqs_off_caller+0x270/0x270
[   57.274920]  print_address_description+0x73/0x250
[   57.275735]  kasan_report+0x256/0x380
[   57.276373]  ? vhci_hub_control+0x169c/0x1a70
[   57.277139]  __asan_report_load4_noabort+0x14/0x20
[   57.277982]  vhci_hub_control+0x169c/0x1a70
[   57.278731]  ? vhci_hcd_probe+0x330/0x330
[   57.279453]  ? rcu_read_lock_sched_held+0x108/0x120
[   57.280308]  ? __kmalloc+0x312/0x710
[   57.280945]  ? kasan_check_write+0x14/0x20
[   57.281669]  ? do_raw_spin_lock+0xc1/0x230
[   57.282425]  ? usb_hcd_submit_urb+0x689/0x1e70
[   57.283209]  usb_hcd_submit_urb+0x161f/0x1e70
[   57.283967]  ? vhci_hcd_probe+0x330/0x330
[   57.284672]  ? __asan_alloca_poison+0x14/0xa0
[   57.285437]  ? usb_create_hcd+0x40/0x40
[   57.286113]  ? __x64_sys_ioctl+0x73/0xb0
[   57.286810]  ? do_syscall_64+0x192/0x770
[   57.287502]  ? entry_SYSCALL_64_after_hwframe+0x49/0xbe
[   57.288413]  ? find_held_lock+0x35/0x1d0
[   57.289104]  ? __lockdep_init_map+0xe4/0x650
[   57.289856]  ? __lockdep_init_map+0xe4/0x650
[   57.290611]  ? lockdep_init_map+0x9/0x10
[   57.291303]  usb_submit_urb+0x829/0x11a0
[   57.292017]  ? rcu_pm_notify+0xc0/0xc0
[   57.292676]  usb_start_wait_urb+0x140/0x330
[   57.293422]  ? sg_clean+0x220/0x220
[   57.294046]  usb_control_msg+0x334/0x4c0
[   57.294779]  ? usb_start_wait_urb+0x330/0x330
[   57.295542]  proc_control+0x913/0xe50
[   57.296189]  ? proc_bulk+0x9d0/0x9d0
[   57.296822]  usbdev_do_ioctl+0x2260/0x3690
[   57.297576]  ? processcompl_compat+0x5e0/0x5e0
[   57.298366]  ? mark_held_locks+0x100/0x100
[   57.299086]  ? futex_wait_setup+0x410/0x410
[   57.299821]  ? kasan_check_write+0x14/0x20
[   57.300539]  ? wake_up_q+0x9d/0xf0
[   57.301139]  ? drop_futex_key_refs.isra.14+0x71/0xc0
[   57.302016]  ? futex_wake+0x2e5/0x6b0
[   57.302671]  ? lock_downgrade+0x9a0/0x9a0
[   57.303372]  ? check_noncircular+0x20/0x20
[   57.304115]  ? kasan_check_read+0x11/0x20
[   57.304816]  ? do_futex+0x874/0x22c0
[   57.305445]  ? find_held_lock+0x35/0x1d0
[   57.306130]  ? lock_acquire+0x1db/0x520
[   57.306834]  ? lock_downgrade+0x9a0/0x9a0
[   57.307535]  ? kasan_check_read+0x11/0x20
[   57.308231]  ? rcu_is_watching+0x8c/0x150
[   57.308930]  ? rcu_cleanup_dead_rnp+0x210/0x210
[   57.309724]  ? __fget+0x428/0x660
[   57.310310]  ? iterate_fd+0x400/0x400
[   57.310957]  ? kasan_check_write+0x14/0x20
[   57.311670]  ? do_raw_spin_lock+0xc1/0x230
[   57.312396]  ? trace_hardirqs_off+0x9c/0x280
[   57.313135]  ? usbdev_compat_ioctl+0x30/0x30
[   57.313871]  usbdev_ioctl+0x25/0x30
[   57.314488]  do_vfs_ioctl+0x1c2/0x15b0
[   57.315147]  ? rcu_is_watching+0x8c/0x150
[   57.315839]  ? trace_hardirqs_on+0xa1/0x280
[   57.316564]  ? ioctl_preallocate+0x2d0/0x2d0
[   57.317302]  ? __fget_light+0x2c4/0x410
[   57.317968]  ? fget_raw+0x20/0x20
[   57.318561]  ? putname+0xee/0x130
[   57.319140]  ? rcu_read_lock_sched_held+0x108/0x120
[   57.319987]  ? kmem_cache_free+0x21d/0x270
[   57.320702]  ? __x64_sys_futex+0x344/0x4b0
[   57.321411]  ? do_syscall_64+0x9a/0x770
[   57.322082]  ? do_syscall_64+0x9a/0x770
[   57.322780]  ? lockdep_hardirqs_on+0x421/0x5c0
[   57.323541]  ? security_file_ioctl+0x87/0xb0
[   57.324268]  ksys_ioctl+0x94/0xb0
[   57.324837]  __x64_sys_ioctl+0x73/0xb0
[   57.325478]  do_syscall_64+0x192/0x770
[   57.326117]  ? entry_SYSCALL_64_after_hwframe+0x3e/0xbe
[   57.327038]  ? syscall_return_slowpath+0x560/0x560
[   57.327880]  ? trace_hardirqs_off_thunk+0x1a/0x1c
[   57.328709]  ? trace_hardirqs_on+0x280/0x280
[   57.329462]  ? prepare_exit_to_usermode+0x360/0x360
[   57.330319]  ? recalc_sigpending_tsk+0x150/0x150
[   57.331148]  ? prepare_exit_to_usermode+0x22f/0x360
[   57.332006]  ? trace_hardirqs_off_thunk+0x1a/0x1c
[   57.332843]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
[   57.333731] RIP: 0033:0x4417c9
[   57.334280] Code: e8 9c 5a 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00
00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24
08 0f 05 <48> 3d 01 f0 ff ff 0f 83 0b 9c fc ff c3 66 2e 0f 1f 84 00 00
00 00
[   57.337498] RSP: 002b:00007ff768d47d78 EFLAGS: 00000246 ORIG_RAX:
0000000000000010
[   57.338782] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00000000004417c9
[   57.339980] RDX: 0000000020000100 RSI: 00000000c0185500 RDI: 0000000000000003
[   57.341179] RBP: 00007ff768d47da0 R08: 0000000000000000 R09: 0000000000000000
[   57.342411] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
[   57.343607] R13: 00007ffdc26d041f R14: 00007ff768d48700 R15: 0000000000000000
[   57.344809]
[   57.345081] Allocated by task 4081:
[   57.345684]  save_stack+0x43/0xd0
[   57.346257]  kasan_kmalloc+0xad/0xe0
[   57.346877]  kasan_slab_alloc+0x12/0x20
[   57.347518]  kmem_cache_alloc+0x12e/0x700
[   57.348192]  getname_flags+0xcb/0x580
[   57.348810]  __x64_sys_unlinkat+0x9e/0x100
[   57.349502]  do_syscall_64+0x192/0x770
[   57.350139]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
[   57.350985]
[   57.351252] Freed by task 4081:
[   57.351790]  save_stack+0x43/0xd0
[   57.352358]  __kasan_slab_free+0x11a/0x170
[   57.353050]  kasan_slab_free+0xe/0x10
[   57.353677]  kmem_cache_free+0x83/0x270
[   57.354325]  putname+0xee/0x130
[   57.354876]  filename_parentat+0x46d/0x570
[   57.355566]  do_unlinkat+0x160/0x970
[   57.356169]  __x64_sys_unlinkat+0xa8/0x100
[   57.356865]  do_syscall_64+0x192/0x770
[   57.357498]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
[   57.358351]
[   57.358630] The buggy address belongs to the object at ffff880064640880
[   57.358630]  which belongs to the cache names_cache of size 4096
[   57.360718] The buggy address is located 1852 bytes to the right of
[   57.360718]  4096-byte region [ffff880064640880, ffff880064641880)
[   57.362785] The buggy address belongs to the page:
[   57.363599] page:ffffea0001919000 count:1 mapcount:0
mapping:ffff88006c56bd80 index:0x0 compound_mapcount: 0
[   57.365241] flags: 0x1fffc0000008100(slab|head)
[   57.366014] raw: 01fffc0000008100 ffffea0001764388 ffffea0001ac7b08
ffff88006c56bd80
[   57.367322] raw: 0000000000000000 ffff880064640880 0000000100000001
0000000000000000
[   57.368608] page dumped because: kasan: bad access detected
[   57.369518]
[   57.369796] Memory state around the buggy address:
[   57.370638]  ffff880064641e80: fc fc fc fc fc fc fc fc fc fc fc fc
fc fc fc fc
[   57.371838]  ffff880064641f00: fc fc fc fc fc fc fc fc fc fc fc fc
fc fc fc fc
[   57.373132] >ffff880064641f80: fc fc fc fc fc fc fc fc fc fc fc fc
fc fc fc fc
[   57.374320]                                         ^
[   57.375179]  ffff880064642000: fc fc fc fc fc fc fc fc fc fc fc fc
fc fc fc fc
[   57.376380]  ffff880064642080: fc fc fc fc fc fc fc fc fc fc fc fc
fc fc fc fc
[   57.377563] ==================================================================

Re: KASAN: slab-out-of-bounds Read in vhci_hub_control

[Shuah Khan]

On 10/10/2018 01:42 PM, Dmitry Vyukov wrote:
> On Tue, Oct 2, 2018 at 6:04 PM, Shuah Khan <shuah@kernel.org> wrote:
>> On 09/04/2018 12:52 PM, syzbot wrote:
>>> Hello,
>>>
>>> syzbot found the following crash on:
>>>
>>> HEAD commit:    420f51f4ab6b Merge tag 'arm64-fixes' of git://git.kernel.o..
>>> git tree:       upstream
>>> console output: https://syzkaller.appspot.com/x/log.txt?x=126a6f0e400000
>>> kernel config:  https://syzkaller.appspot.com/x/.config?x=531a917630d2a492
>>> dashboard link: https://syzkaller.appspot.com/bug?extid=bccc1fe10b70fadc78d0
>>> compiler:       gcc (GCC) 8.0.1 20180413 (experimental)
>>> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=121caa46400000
>>> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=14ed8ab6400000
>>
>> C producer doesn't reproduce the problem on 4.19-rc5. Does this C producer
>> depend on state of the machine? i.e what is the status of vhci_hcd - are
>> there any devices attached?
>>
>> I can see the problem looking at the code and fix is easy. However, I would
>> like be able to reproduce it and verify the fix works. Also this would be a
>> good regression for the driver I could consider adding to selftests.
> 
> 
> 
> Are you sure you used the provided config/commit?
> I've followed these instructions:
> https://github.com/google/syzkaller/blob/master/docs/syzbot.md#crash-does-not-reproduce
> and the C repro gave me this in a second:

I managed to reproduce and fix it. I did add reported by tag as well.

Here is fix:
https://patchwork.kernel.org/patch/10628833/

Sudip verified the patch.

thanks,
-- Shuah

Re: KASAN: slab-out-of-bounds Read in vhci_hub_control

[Dmitry Vyukov]

On Wed, Oct 10, 2018 at 10:26 PM, Shuah Khan <shuah@kernel.org> wrote:
> On 10/10/2018 01:42 PM, Dmitry Vyukov wrote:
>> On Tue, Oct 2, 2018 at 6:04 PM, Shuah Khan <shuah@kernel.org> wrote:
>>> On 09/04/2018 12:52 PM, syzbot wrote:
>>>> Hello,
>>>>
>>>> syzbot found the following crash on:
>>>>
>>>> HEAD commit:    420f51f4ab6b Merge tag 'arm64-fixes' of git://git.kernel.o..
>>>> git tree:       upstream
>>>> console output: https://syzkaller.appspot.com/x/log.txt?x=126a6f0e400000
>>>> kernel config:  https://syzkaller.appspot.com/x/.config?x=531a917630d2a492
>>>> dashboard link: https://syzkaller.appspot.com/bug?extid=bccc1fe10b70fadc78d0
>>>> compiler:       gcc (GCC) 8.0.1 20180413 (experimental)
>>>> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=121caa46400000
>>>> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=14ed8ab6400000
>>>
>>> C producer doesn't reproduce the problem on 4.19-rc5. Does this C producer
>>> depend on state of the machine? i.e what is the status of vhci_hcd - are
>>> there any devices attached?
>>>
>>> I can see the problem looking at the code and fix is easy. However, I would
>>> like be able to reproduce it and verify the fix works. Also this would be a
>>> good regression for the driver I could consider adding to selftests.
>>
>>
>>
>> Are you sure you used the provided config/commit?
>> I've followed these instructions:
>> https://github.com/google/syzkaller/blob/master/docs/syzbot.md#crash-does-not-reproduce
>> and the C repro gave me this in a second:
>
> I managed to reproduce and fix it. I did add reported by tag as well.
>
> Here is fix:
> https://patchwork.kernel.org/patch/10628833/
>
> Sudip verified the patch.

Great. Thanks!