lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 13 Aug 2019 17:08:21 +0200 From: Andrey Konovalov <andreyknvl@...gle.com> To: Oliver Neukum <oneukum@...e.com> Cc: syzbot <syzbot+6966546b78d050bb0b5d@...kaller.appspotmail.com>, "David S. Miller" <davem@...emloft.net>, Alexander Potapenko <glider@...gle.com>, syzkaller-bugs <syzkaller-bugs@...glegroups.com>, steve.glendinning@...well.net, LKML <linux-kernel@...r.kernel.org>, USB list <linux-usb@...r.kernel.org>, netdev <netdev@...r.kernel.org> Subject: Re: KMSAN: uninit-value in smsc75xx_bind On Tue, Aug 13, 2019 at 2:43 PM Oliver Neukum <oneukum@...e.com> 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@...c75xx_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?
Powered by blists - more mailing lists