[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190429210917.GA251866@gmail.com>
Date: Mon, 29 Apr 2019 14:09:18 -0700
From: Eric Biggers <ebiggers@...nel.org>
To: Alan Stern <stern@...land.harvard.edu>
Cc: syzbot <syzbot+a9fefd18c7b240f19c54@...kaller.appspotmail.com>,
andreyknvl@...gle.com, gregkh@...uxfoundation.org,
linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org,
rafael@...nel.org, syzkaller-bugs@...glegroups.com
Subject: Re: KASAN: slab-out-of-bounds Read in hex_string
On Mon, Apr 29, 2019 at 04:07:04PM -0400, Alan Stern wrote:
> On Mon, 29 Apr 2019, syzbot wrote:
>
> > Hello,
> >
> > syzbot found the following crash on:
> >
> > HEAD commit: 43151d6c usb-fuzzer: main usb gadget fuzzer driver
> > git tree: https://github.com/google/kasan/tree/usb-fuzzer
> > console output: https://syzkaller.appspot.com/x/log.txt?x=139ac37f200000
> > kernel config: https://syzkaller.appspot.com/x/.config?x=4183eeef650d1234
> > dashboard link: https://syzkaller.appspot.com/bug?extid=a9fefd18c7b240f19c54
> > compiler: gcc (GCC) 9.0.0 20181231 (experimental)
> > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=17f3b338a00000
> >
> > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > Reported-by: syzbot+a9fefd18c7b240f19c54@...kaller.appspotmail.com
> >
> > ==================================================================
> > BUG: KASAN: slab-out-of-bounds in hex_string+0x418/0x4b0 lib/vsprintf.c:975
> > Read of size 1 at addr ffff88821a41bd38 by task kworker/0:1/12
> >
> > CPU: 0 PID: 12 Comm: kworker/0:1 Not tainted 5.1.0-rc3-319004-g43151d6 #6
> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> > Google 01/01/2011
> > Workqueue: usb_hub_wq hub_event
> > Call Trace:
> > __dump_stack lib/dump_stack.c:77 [inline]
> > dump_stack+0xe8/0x16e lib/dump_stack.c:113
> > print_address_description+0x6c/0x236 mm/kasan/report.c:187
> > kasan_report.cold+0x1a/0x3c mm/kasan/report.c:317
> > hex_string+0x418/0x4b0 lib/vsprintf.c:975
> > pointer+0x460/0x910 lib/vsprintf.c:1985
> > vsnprintf+0x5a0/0x16b0 lib/vsprintf.c:2400
> > pointer+0x60b/0x910 lib/vsprintf.c:2038
> > vsnprintf+0x5a0/0x16b0 lib/vsprintf.c:2400
> > vscnprintf+0x29/0x80 lib/vsprintf.c:2499
> > vprintk_store+0x45/0x4b0 kernel/printk/printk.c:1900
> > vprintk_emit+0x210/0x5a0 kernel/printk/printk.c:1957
> > dev_vprintk_emit+0x50e/0x553 drivers/base/core.c:3185
> > dev_printk_emit+0xbf/0xf6 drivers/base/core.c:3196
> > __dev_printk+0x1ed/0x215 drivers/base/core.c:3208
> > _dev_info+0xdc/0x10e drivers/base/core.c:3254
> > dlfb_parse_vendor_descriptor drivers/video/fbdev/udlfb.c:1532 [inline]
>
> Accessing beyond the end of the descriptor.
>
> #syz test: https://github.com/google/kasan.git usb-fuzzer
>
> --- a/drivers/video/fbdev/udlfb.c
> +++ b/drivers/video/fbdev/udlfb.c
> @@ -1511,6 +1511,7 @@ static int dlfb_parse_vendor_descriptor(
> char *buf;
> char *desc_end;
> int total_len;
> + int width;
>
> buf = kzalloc(MAX_VENDOR_DESCRIPTOR_SIZE, GFP_KERNEL);
> if (!buf)
> @@ -1529,9 +1530,10 @@ static int dlfb_parse_vendor_descriptor(
> }
>
> if (total_len > 5) {
> + width = min(total_len, 11);
> dev_info(&intf->dev,
> - "vendor descriptor length: %d data: %11ph\n",
> - total_len, desc);
> + "vendor descriptor length: %d data: %*ph\n",
> + total_len, width, desc);
>
> if ((desc[0] != total_len) || /* descriptor length */
> (desc[1] != 0x5f) || /* vendor descriptor type */
>
>
Why not write just:
dev_info(&intf->dev,
"vendor descriptor length: %d data: %*ph\n",
total_len, min(total_len, 11), desc);
Also, aren't there more out-of-bounds reads in the code just after? It only
checks for at least 1 byte available, but then it reads up to 7 bytes:
while (desc < desc_end) {
u8 length;
u16 key;
key = *desc++;
key |= (u16)*desc++ << 8;
length = *desc++;
switch (key) {
case 0x0200: { /* max_area */
u32 max_area = *desc++;
max_area |= (u32)*desc++ << 8;
max_area |= (u32)*desc++ << 16;
max_area |= (u32)*desc++ << 24;
dev_warn(&intf->dev,
"DL chip limited to %d pixel modes\n",
max_area);
dlfb->sku_pixel_limit = max_area;
break;
}
default:
break;
}
desc += length;
}
Also I couldn't help but notice it's also using 'char' rather than 'u8',
so bytes >= 0x80 are read incorrectly as they're sign extended...
- Eric
Powered by blists - more mailing lists