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?