netdev - Re: [PATCH] Fix netdev_printk null dereference

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 5 Mar 2010 16:32:03 +0000
From:	Steve.Glendinning@...c.com
To:	David Miller <davem@...emloft.net>
Cc:	netdev@...r.kernel.org
Subject: Re: [PATCH] Fix netdev_printk null dereference

David Miller <davem@...emloft.net> wrote on 05/03/2010 15:43:35:

> It seems to me that really you only need this parent NULL check where
> you notice the USB control operation failed and want to print a
> message about that.
> 
> That should cover all the necessary cases shouldn't it?

That's the easily reproducible case - during initialisation there are
a lot of register reads and writes, so it's quite easy to trigger by
manually unplugging ~500ms after connection. In this case usbnet is
still in usbnet_probe.

Theoretically though, this device could be disconnected at any time,
and there are other places in the code where we print messages not
triggered by a usb failure (for example set_multicast).  Could it
be possibly unsafe to call netdev_printk here?

> Even more importantly, why does a USB disconnect NULL out the netdev
> parent device pointer?  Until you actually release this USB device in
> the driver, the parent pointer should stay there.

Most of the time it's not nulled out, and the code succesfully prints
errors as expected, but maybe 1 time in 20 dev.parent is NULL.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html