On Tue, Aug 13, 2019 at 2:43 PM Oliver Neukum <oneukum@xxxxxxxx> wrote:
>
> Am Freitag, den 09.08.2019, 01:48 -0700 schrieb syzbot:
> > Hello,
> >
> > syzbot found the following crash on:
> >
> > HEAD commit: beaab8a3 fix KASAN build
> > git tree: kmsan
>
> [..]
> > Call Trace:
> > __dump_stack lib/dump_stack.c:77 [inline]
> > dump_stack+0x191/0x1f0 lib/dump_stack.c:113
> > kmsan_report+0x162/0x2d0 mm/kmsan/kmsan_report.c:109
> > __msan_warning+0x75/0xe0 mm/kmsan/kmsan_instr.c:294
> > smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:976 [inline]
> > smsc75xx_bind+0x541/0x12d0 drivers/net/usb/smsc75xx.c:1483
>
> >
> > Local variable description: ----buf.i93@smsc75xx_bind
> > Variable was created at:
> > __smsc75xx_read_reg drivers/net/usb/smsc75xx.c:83 [inline]
> > smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:969 [inline]
> > smsc75xx_bind+0x44c/0x12d0 drivers/net/usb/smsc75xx.c:1483
> > usbnet_probe+0x10d3/0x3950 drivers/net/usb/usbnet.c:1722
>
> Hi,
>
> this looks like a false positive to me.
> The offending code is likely this:
>
> if (size) {
> buf = kmalloc(size, GFP_KERNEL);
> if (!buf)
> goto out;
> }
>
> err = usb_control_msg(dev->udev, usb_rcvctrlpipe(dev->udev, 0),
> cmd, reqtype, value, index, buf, size,
> USB_CTRL_GET_TIMEOUT);
>
> which uses 'buf' uninitialized. But it is used for input.
> What is happening here?
AFAICS, the uninitialized use of buf that KMSAN points out is in the
"if (buf & PMT_CTL_DEV_RDY)" statement in smsc75xx_wait_ready(). Does
__smsc75xx_read_reg/usb_control_msg() always initialize buf? Can it
just initialize the first few bytes for example?
