linux-kernel - Re: [PATCH] net: usb: usbnet: fix use-after-free in race on workqueue

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]

Message-ID: <560fa48a-7e0b-4b50-bebb-b3600efaadd3@suse.com>
Date: Wed, 2 Jul 2025 12:54:23 +0200
From: Oliver Neukum <oneukum@...e.com>
To: Jakub Kicinski <kuba@...nel.org>, Oliver Neukum <oneukum@...e.com>
Cc: Paolo Abeni <pabeni@...hat.com>, "Peter GJ. Park"
 <gyujoon.park@...sung.com>, Andrew Lunn <andrew+netdev@...n.ch>,
 "David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
 netdev@...r.kernel.org, linux-usb@...r.kernel.org,
 linux-kernel@...r.kernel.org, Ming Lei <ming.lei@...onical.com>
Subject: Re: [PATCH] net: usb: usbnet: fix use-after-free in race on workqueue

On 02.07.25 03:26, Jakub Kicinski wrote:
> On Tue, 1 Jul 2025 15:22:54 +0200 Oliver Neukum wrote:

>> That is indeed a core question, which we really need an answer to.
>> Do I interpret dev_close_many() correctly, if I state that the
>> ndo_stop() method will _not_ be called if the device has never been
>> opened?
> 
> Correct, open and close are paired. Most drivers would crash if we
> tried to close them before they ever got opened.

Thank you for clarifying that.

>> I am sorry to be a stickler here, but if that turns out to be true,
>> usbnet is not the only driver that has this bug.
> 
> Shooting from the hip slightly, but its unusual for a driver to start
> link monitoring before open. After all there can be no packets on a
> device that's closed. Why not something like:

It turns out that user space wants to know whether there is carrier
even before it uses an interface because it uses that information
to decide whether to use the link.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=444043

However, it looks to me like the issue is specifically
queuing work for kevent. That would call for reverting
0162c55463057 ("usbnet: apply usbnet_link_change")
[taking author into CC]

	Regards
		Oliver