KASAN: slab-out-of-bounds Read in ld_usb_read (3)

39 views
Skip to first unread message

syzbot

unread,
Oct 16, 2019, 9:42:11ā€ÆPM10/16/19
to andre...@google.com, enric.b...@collabora.com, gre...@linuxfoundation.org, jo...@kernel.org, ki...@nexedi.com, linux-...@vger.kernel.org, linu...@vger.kernel.org, li...@roeck-us.net, log...@deltatee.com, syzkall...@googlegroups.com
Hello,

syzbot found the following crash on:

HEAD commit: 22be26f7 usb-fuzzer: main usb gadget fuzzer driver
git tree: https://github.com/google/kasan.git usb-fuzzer
console output: https://syzkaller.appspot.com/x/log.txt?x=14f6dc5f600000
kernel config: https://syzkaller.appspot.com/x/.config?x=387eccb7ac68ec5
dashboard link: https://syzkaller.appspot.com/bug?extid=6fe95b826644f7f12b0b
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=102c3227600000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=12a503a0e00000

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

ldusb 1-1:0.28: Read buffer overflow, -131383859965943 bytes dropped
==================================================================
BUG: KASAN: slab-out-of-bounds in _copy_to_user+0x124/0x150
lib/usercopy.c:28
Read of size 102391 at addr ffff8881cfb40008 by task syz-executor372/1737

CPU: 0 PID: 1737 Comm: syz-executor372 Not tainted 5.4.0-rc3+ #0
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+0xca/0x13e lib/dump_stack.c:113
print_address_description.constprop.0+0x36/0x50 mm/kasan/report.c:374
__kasan_report.cold+0x1a/0x33 mm/kasan/report.c:506
kasan_report+0xe/0x20 mm/kasan/common.c:634
check_memory_region_inline mm/kasan/generic.c:185 [inline]
check_memory_region+0x128/0x190 mm/kasan/generic.c:192
_copy_to_user+0x124/0x150 lib/usercopy.c:28
copy_to_user include/linux/uaccess.h:152 [inline]
ld_usb_read+0x329/0x760 drivers/usb/misc/ldusb.c:492
__vfs_read+0x76/0x100 fs/read_write.c:425
vfs_read+0x1ea/0x430 fs/read_write.c:461
ksys_read+0x1e8/0x250 fs/read_write.c:587
do_syscall_64+0xb7/0x580 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x4421d9
Code: e8 7c e7 ff ff 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 bb 07 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007ffc08eb0888 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
RAX: ffffffffffffffda RBX: 00007ffc08eb0ae0 RCX: 00000000004421d9
RDX: 0000000000018ff7 RSI: 0000000020000a80 RDI: 0000000000000004
RBP: 0000000000000000 R08: 000000000000000f R09: 0000000000402eb0
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 0000000000402eb0 R14: 0000000000000000 R15: 0000000000000000

The buggy address belongs to the page:
page:ffffea00073ed000 refcount:1 mapcount:0 mapping:0000000000000000
index:0x0 compound_mapcount: 0
flags: 0x200000000010000(head)
raw: 0200000000010000 dead000000000100 dead000000000122 0000000000000000
raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected

Memory state around the buggy address:
ffff8881cfb55500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff8881cfb55580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> ffff8881cfb55600: fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe
^
ffff8881cfb55680: fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe
ffff8881cfb55700: fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe
==================================================================


---
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 syzk...@googlegroups.com.

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

Johan Hovold

unread,
Oct 17, 2019, 6:25:06ā€ÆAM10/17/19
to syzbot, andre...@google.com, enric.b...@collabora.com, gre...@linuxfoundation.org, jo...@kernel.org, ki...@nexedi.com, linux-...@vger.kernel.org, linu...@vger.kernel.org, li...@roeck-us.net, log...@deltatee.com, syzkall...@googlegroups.com
On Wed, Oct 16, 2019 at 06:42:10PM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 22be26f7 usb-fuzzer: main usb gadget fuzzer driver
> git tree: https://github.com/google/kasan.git usb-fuzzer
> console output: https://syzkaller.appspot.com/x/log.txt?x=14f6dc5f600000
> kernel config: https://syzkaller.appspot.com/x/.config?x=387eccb7ac68ec5
> dashboard link: https://syzkaller.appspot.com/bug?extid=6fe95b826644f7f12b0b
> compiler: gcc (GCC) 9.0.0 20181231 (experimental)
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=102c3227600000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=12a503a0e00000
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+6fe95b...@syzkaller.appspotmail.com
>
> ldusb 1-1:0.28: Read buffer overflow, -131383859965943 bytes dropped

This warning should be using %zu and thus read 18446612689849585673.

Apparently, *actual_buffer holds a kernel address ffff8881cfb42000
instead of a transfer length. Possibly a stale value since the buffer is
not cleared on allocation.

> ==================================================================
> BUG: KASAN: slab-out-of-bounds in _copy_to_user+0x124/0x150
> lib/usercopy.c:28
> Read of size 102391 at addr ffff8881cfb40008 by task syz-executor372/1737

And due to missing sanity checks the driver proceeds to access data
beyond the ring-buffer entry.
The drivers ring-buffer implementation is broken so this could
potentially be a memory-ordering issue (e.g. the entry is read before it
has been updated).

Let's try the below.

Johan


#syz test: https://github.com/google/kasan.git 22be26f7

From 61c87ec9b1311949e313f633e84aab5c73975078 Mon Sep 17 00:00:00 2001
From: Johan Hovold <jo...@kernel.org>
Date: Thu, 17 Oct 2019 11:53:04 +0200
Subject: [PATCH] wip: USB: lsusb: fix ring-buffer locking

Signed-off-by: Johan Hovold <jo...@kernel.org>
---
drivers/usb/misc/ldusb.c | 17 ++++++++++++-----
1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/misc/ldusb.c b/drivers/usb/misc/ldusb.c
index f3108d85e768..c8d09ac7ade9 100644
--- a/drivers/usb/misc/ldusb.c
+++ b/drivers/usb/misc/ldusb.c
@@ -467,7 +467,7 @@ static ssize_t ld_usb_read(struct file *file, char __user *buffer, size_t count,

/* wait for data */
spin_lock_irq(&dev->rbsl);
- if (dev->ring_head == dev->ring_tail) {
+ while (dev->ring_head == dev->ring_tail) {
dev->interrupt_in_done = 0;
spin_unlock_irq(&dev->rbsl);
if (file->f_flags & O_NONBLOCK) {
@@ -477,8 +477,8 @@ static ssize_t ld_usb_read(struct file *file, char __user *buffer, size_t count,
retval = wait_event_interruptible(dev->read_wait, dev->interrupt_in_done);
if (retval < 0)
goto unlock_exit;
- } else {
- spin_unlock_irq(&dev->rbsl);
+
+ spin_lock_irq(&dev->rbsl);
}

/* actual_buffer contains actual_length + interrupt_in_buffer */
@@ -487,17 +487,19 @@ static ssize_t ld_usb_read(struct file *file, char __user *buffer, size_t count,
if (bytes_to_read < *actual_buffer)
dev_warn(&dev->intf->dev, "Read buffer overflow, %zd bytes dropped\n",
*actual_buffer-bytes_to_read);
+ spin_unlock_irq(&dev->rbsl);

/* copy one interrupt_in_buffer from ring_buffer into userspace */
if (copy_to_user(buffer, actual_buffer+1, bytes_to_read)) {
retval = -EFAULT;
goto unlock_exit;
}
- dev->ring_tail = (dev->ring_tail+1) % ring_buffer_size;
-
retval = bytes_to_read;

spin_lock_irq(&dev->rbsl);
+
+ dev->ring_tail = (dev->ring_tail+1) % ring_buffer_size;
+
if (dev->buffer_overflow) {
dev->buffer_overflow = 0;
spin_unlock_irq(&dev->rbsl);
@@ -693,12 +695,17 @@ static int ld_usb_probe(struct usb_interface *intf, const struct usb_device_id *
dev_warn(&intf->dev, "Interrupt out endpoint not found (using control endpoint instead)\n");

dev->interrupt_in_endpoint_size = usb_endpoint_maxp(dev->interrupt_in_endpoint);
+ dev_info(&intf->dev, "%s - interrupt_in_endpoint_size = %zu\n",
+ __func__, dev->interrupt_in_endpoint_size);
dev->ring_buffer =
kmalloc_array(ring_buffer_size,
sizeof(size_t) + dev->interrupt_in_endpoint_size,
GFP_KERNEL);
if (!dev->ring_buffer)
goto error;
+ dev_info(&intf->dev, "%s - ring_buffer = %px\n", __func__,
+ dev->ring_buffer);
+
dev->interrupt_in_buffer = kmalloc(dev->interrupt_in_endpoint_size, GFP_KERNEL);
if (!dev->interrupt_in_buffer)
goto error;
--
2.23.0

syzbot

unread,
Oct 17, 2019, 6:45:01ā€ÆAM10/17/19
to andre...@google.com, enric.b...@collabora.com, gre...@linuxfoundation.org, jo...@kernel.org, ki...@nexedi.com, linux-...@vger.kernel.org, linu...@vger.kernel.org, li...@roeck-us.net, log...@deltatee.com, syzkall...@googlegroups.com
Hello,

syzbot has tested the proposed patch and the reproducer did not trigger
crash:

Reported-and-tested-by:
syzbot+6fe95b...@syzkaller.appspotmail.com

Tested on:

commit: 22be26f7 usb-fuzzer: main usb gadget fuzzer driver
git tree: https://github.com/google/kasan.git
kernel config: https://syzkaller.appspot.com/x/.config?x=387eccb7ac68ec5
dashboard link: https://syzkaller.appspot.com/bug?extid=6fe95b826644f7f12b0b
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
patch: https://syzkaller.appspot.com/x/patch.diff?x=14745c87600000

Note: testing is done by a robot and is best-effort only.

Johan Hovold

unread,
Oct 17, 2019, 6:46:42ā€ÆAM10/17/19
to syzbot, andre...@google.com, enric.b...@collabora.com, gre...@linuxfoundation.org, jo...@kernel.org, ki...@nexedi.com, linux-...@vger.kernel.org, linu...@vger.kernel.org, li...@roeck-us.net, log...@deltatee.com, syzkall...@googlegroups.com
Heh, it doesn't even need to race to trigger this; the driver sets
dev->interrupt_in_done when the URB is killed on disconnect() and read
happily continues with reading the next entry which was never updated.

> Let's try the below.

The below should work, but should be amended so that a blocking read()
returns after disconnect().
Reply all
Reply to author
Forward
0 new messages