[PATCH net v3] usbnet: fix EVENT_RX_PAUSED race in usbnet_skb_return()

[PATCH net v3] usbnet: fix EVENT_RX_PAUSED race in usbnet_skb_return()

[Ömer Mete Kaya]

On SMP, usbnet_skb_return() can pass the test_bit(EVENT_RX_PAUSED) check
on CPU0 while usbnet_resume_rx() clears the flag and drains rxq_pause on
CPU1, leaving the skb stranded until the next MTU change or device stop.

Protect the flag check and enqueue with a double-check pattern under
rxq_pause.lock on the slow path, keeping the normal RX fast path
lock-free. Wrap clear_bit() in usbnet_resume_rx() under the same lock.

Fixes: 43daa96b166c ("usbnet: Stop RX Q on MTU change")
Signed-off-by: Ömer Mete Kaya <omermetekaya0@gmail.com>

---
v3: Use spin_lock() inside existing local_bh_disable() section in
    usbnet_resume_rx() instead of spin_lock_bh(); move local_bh_enable()
    before queue_work() to restore BH context correctly.

 drivers/net/usb/usbnet.c | 16 +++++++++++-----
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
index 84f97f448b2d..d138d353fd98 100644
--- a/drivers/net/usb/usbnet.c
+++ b/drivers/net/usb/usbnet.c
@@ -329,9 +329,14 @@ void usbnet_skb_return(struct usbnet *dev, struct sk_buff *skb)
 	unsigned long flags;
 	int	status;

-	if (test_bit(EVENT_RX_PAUSED, &dev->flags)) {
-		skb_queue_tail(&dev->rxq_pause, skb);
-		return;
+	if (unlikely(test_bit(EVENT_RX_PAUSED, &dev->flags))) {
+		spin_lock_bh(&dev->rxq_pause.lock);
+		if (test_bit(EVENT_RX_PAUSED, &dev->flags)) {
+			__skb_queue_tail(&dev->rxq_pause, skb);
+			spin_unlock_bh(&dev->rxq_pause.lock);
+			return;
+		}
+		spin_unlock_bh(&dev->rxq_pause.lock);
 	}

 	/* only update if unset to allow minidriver rx_fixup override */
@@ -702,15 +707,16 @@ void usbnet_resume_rx(struct usbnet *dev)
 	int num = 0;

 	local_bh_disable();
+	spin_lock(&dev->rxq_pause.lock);
 	clear_bit(EVENT_RX_PAUSED, &dev->flags);
-
+	spin_unlock(&dev->rxq_pause.lock);
 	while ((skb = skb_dequeue(&dev->rxq_pause)) != NULL) {
 		usbnet_skb_return(dev, skb);
 		num++;
 	}

-	queue_work(system_bh_wq, &dev->bh_work);
 	local_bh_enable();
+	queue_work(system_bh_wq, &dev->bh_work);

 	netif_dbg(dev, rx_status, dev->net,
 		  "paused rx queue disabled, %d skbs requeued\n", num);
--
2.56.0

Re: [PATCH net v3] usbnet: fix EVENT_RX_PAUSED race in usbnet_skb_return()

[netdev-bot+sinfo]

Hi!

This is an automated message. This series looks like a fix, but its
commit messages seem to be missing some information:

 - How the issue was discovered, e.g. hit in production, hit during
   development, syzbot report, manual code inspection, LLM or static
   analysis tool scan.

 - Whether the issue was actually triggered, or is only theoretical
   (e.g. found by code inspection). If it was triggered please include
   the symptoms, like the stack trace or error messages.

Please do not repost the series just to address the above. Instead,
reply to this email with the missing information, so that reviewers
can take it into account. If the series needs another revision for
other reasons, please include the information in the commit messages
then.

The evaluation is done by an LLM so it may be wrong, if you think
that is the case please reply and explain.

Re: [PATCH net v3] usbnet: fix EVENT_RX_PAUSED race in usbnet_skb_return()

[Jakub Kicinski]

On Wed, 07 Oct 2026 22:09:08 +0000 netdev-bot+sinfo@kernel.org wrote:
> This is an automated message. This series looks like a fix, but its
> commit messages seem to be missing some information:
> 
>  - How the issue was discovered, e.g. hit in production, hit during
>    development, syzbot report, manual code inspection, LLM or static
>    analysis tool scan.
> 
>  - Whether the issue was actually triggered, or is only theoretical
>    (e.g. found by code inspection). If it was triggered please include
>    the symptoms, like the stack trace or error messages.

Hi, please answer these questions, and try to include the answers in
the commit msg of future submissions.

Re: [PATCH net v3] usbnet: fix EVENT_RX_PAUSED race in usbnet_skb_return()

[Ömer Mete Kaya]

On 10/8/26 18:40, Jakub Kicinski wrote:
> Hi, please answer these questions, and try to include the answers in
> the commit msg of future submissions.

Hi, I couldnt add reported-by tag when it comes from sashiko,
should I include the answers under the "---" for future submissions?

Thanks.

Re: [PATCH net v3] usbnet: fix EVENT_RX_PAUSED race in usbnet_skb_return()

[Jakub Kicinski]

On Thu, 8 Oct 2026 18:47:07 +0300 Ömer Mete Kaya wrote:
> On 10/8/26 18:40, Jakub Kicinski wrote:
> > Hi, please answer these questions, and try to include the answers in
> > the commit msg of future submissions.  
> 
> Hi, I couldnt add reported-by tag when it comes from sashiko,
> should I include the answers under the "---" for future submissions?

In the main body is better, this is very useful info for risk / benefit
analysis for backporters.

Single sentence like this seems suitable here:

Discovered by Sashiko, not triggered, not tested on real HW.

Re: [PATCH net v3] usbnet: fix EVENT_RX_PAUSED race in usbnet_skb_return()

[Ömer Mete Kaya]

On 10/8/26 01:09, netdev-bot+sinfo@kernel.org wrote:
> Hi!
> 
> This is an automated message. This series looks like a fix, but its
> commit messages seem to be missing some information:
> 
>  - How the issue was discovered, e.g. hit in production, hit during
>    development, syzbot report, manual code inspection, LLM or static
>    analysis tool scan.

Sashiko AI suggestion.

>  - Whether the issue was actually triggered, or is only theoretical
>    (e.g. found by code inspection). If it was triggered please include
>    the symptoms, like the stack trace or error messages.

Theoretical.

> Please do not repost the series just to address the above. Instead,
> reply to this email with the missing information, so that reviewers
> can take it into account. If the series needs another revision for
> other reasons, please include the information in the commit messages
> then.
> 
> The evaluation is done by an LLM so it may be wrong, if you think
> that is the case please reply and explain.

Re: [PATCH net v3] usbnet: fix EVENT_RX_PAUSED race in usbnet_skb_return()

[netdev-bot+sashiko]

Thank you for your contribution! Sashiko AI review found 1 potential
issue(s) to consider.

Critical: 0 · High: 0 (1) · Medium: 1 · Low: 0

If you believe none of the issues are legitimate, please reply to each
issue of Medium severity or higher and explain why the AI is wrong.
If any of them are legitimate and you plan to respin, please let patchwork
know by including "pw-bot: cr" as a separate line at the end of your reply
(one such reply per series is enough).

- [Medium] The patch takes dev->rxq_pause.lock with hardirqs enabled in
  two places.

Pre-existing issues:
- [High] usbnet_resume_rx() always queues dev->bh_work, and
  usbnet_change_mtu() reaches it even when the interface is down.

--

usbnet: fix EVENT_RX_PAUSED race in usbnet_skb_return()

This patch closes a race where usbnet_skb_return() could queue an skb on
rxq_pause after usbnet_resume_rx() had already cleared EVENT_RX_PAUSED
and drained the queue. On the slow path it now rechecks the flag under
rxq_pause.lock, and usbnet_resume_rx() clears the flag under the same
lock. The patch also moves queue_work() after local_bh_enable() in
usbnet_resume_rx().

> diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
> index a19ecf718f36a..d1ec3ba1e10e6 100644
> --- a/drivers/net/usb/usbnet.c
> +++ b/drivers/net/usb/usbnet.c
> @@ -329,9 +329,14 @@ void usbnet_skb_return(struct usbnet *dev, struct sk_buff *skb)
>  	unsigned long flags;
>  	int	status;
>  
> -	if (test_bit(EVENT_RX_PAUSED, &dev->flags)) {
> -		skb_queue_tail(&dev->rxq_pause, skb);
> -		return;
> +	if (unlikely(test_bit(EVENT_RX_PAUSED, &dev->flags))) {
> +		spin_lock_bh(&dev->rxq_pause.lock);
> +		if (test_bit(EVENT_RX_PAUSED, &dev->flags)) {
> +			__skb_queue_tail(&dev->rxq_pause, skb);
> +			spin_unlock_bh(&dev->rxq_pause.lock);
> +			return;
> +		}
> +		spin_unlock_bh(&dev->rxq_pause.lock);
>  	}

[Severity: Medium]
Will lockdep complain now that this lock is taken with hardirqs enabled?

Before this patch, rxq_pause.lock was only taken through skb_queue_tail()
and skb_dequeue(). Both use spin_lock_irqsave(). Here the lock is taken
with spin_lock_bh(). usbnet_resume_rx() below takes it with plain
spin_lock() inside local_bh_disable().

usbnet_probe() initializes all four queues with the same inline helper,
so they appear to share one lockdep class:

usbnet_probe() {
    ...
	skb_queue_head_init (&dev->rxq);
	skb_queue_head_init (&dev->txq);
	skb_queue_head_init (&dev->done);
	skb_queue_head_init(&dev->rxq_pause);
    ...
}

defer_bh() relies on this too. It uses spin_lock_nested() for
dev->done.lock while it holds rxq.lock or txq.lock.

Some host controllers do not set HCD_BH (OHCI, UHCI, musb and others).
On those, usb_hcd_giveback_urb() runs the completion directly from the
HCD interrupt handler, so rx_complete()->defer_bh() takes that lock class
in hardirq:

defer_bh() {
	spin_lock_irqsave(&list->lock, flags);
	...
	spin_lock_nested(&dev->done.lock, SINGLE_DEPTH_NESTING);
    ...
}

With CONFIG_PROVE_LOCKING, wouldn't the first qualifying MTU increase
through usbnet_change_mtu()->usbnet_resume_rx() then trigger an
"inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage" report and turn
lockdep off?

No code takes rxq_pause.lock itself from hardirq today, so no real
deadlock is known. Using spin_lock_irqsave()/spin_unlock_irqrestore() in
both new critical sections would match every other sk_buff_head lock use
in usbnet.c.

> @@ -700,15 +705,16 @@ void usbnet_resume_rx(struct usbnet *dev)
>  	int num = 0;
>  
>  	local_bh_disable();
> +	spin_lock(&dev->rxq_pause.lock);
>  	clear_bit(EVENT_RX_PAUSED, &dev->flags);
> -
> +	spin_unlock(&dev->rxq_pause.lock);
>  	while ((skb = skb_dequeue(&dev->rxq_pause)) != NULL) {
>  		usbnet_skb_return(dev, skb);
>  		num++;
>  	}
>  
> -	queue_work(system_bh_wq, &dev->bh_work);
>  	local_bh_enable();
> +	queue_work(system_bh_wq, &dev->bh_work);

[Severity: High]
This is a pre-existing issue, but moving queue_work() after
local_bh_enable() seems to widen a use-after-free window on dev->bh_work.

usbnet_change_mtu() can reach usbnet_resume_rx() while the interface is
down. It only needs dev->rx_urb_size == old_hard_mtu and a larger new RX
buffer:

usbnet_change_mtu() {
    ...
	if (dev->rx_urb_size == old_hard_mtu) {
		dev->rx_urb_size = dev->hard_mtu;
		if (dev->rx_urb_size > old_rx_urb_size) {
			usbnet_pause_rx(dev);
			usbnet_unlink_rx_urbs(dev);
			usbnet_resume_rx(dev);
		}
	}
    ...
}

If the device is then disconnected, unregister_netdev() does not call
ndo_stop for a device that is not IFF_UP:

netif_close_many() {
    ...
		if (!(dev->flags & IFF_UP))
			list_del_init(&dev->close_list);
    ...
}

So usbnet_stop() and its cancel_work_sync(&dev->bh_work) never run.
usbnet_disconnect() cancels only kevent before it frees the netdev:

usbnet_disconnect() {
    ...
	unregister_netdev(net);

	cancel_work_sync(&dev->kevent);
    ...
	free_netdev(net);
}

If bh_work is still pending at that point, can the BH workqueue run
usbnet_bh_work()->usbnet_bh() on the freed struct usbnet (dev->done,
dev->bql_spinlock, dev->wait, dev->net)?

Before this patch, queue_work() ran inside the local_bh_disable()
section. The work therefore almost always ran at local_bh_enable(),
before usbnet_resume_rx() returned.

Now the work is queued from process context with BHs enabled, so the
softirq is handed to ksoftirqd. The work can stay pending after the MTU
change returns. With threadirqs, or with ksoftirqd starved on that CPU,
it could stay pending through unregister_netdev() and free_netdev() on
another CPU.

Would it make sense to add cancel_work_sync(&dev->bh_work) to
usbnet_disconnect() before free_netdev(), once further submissions are
blocked?

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261007220311.113827-1-omermetekaya0%40gmail.com