mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: netdev-bot+sashiko@kernel.org
To: omermetekaya0@gmail.com
Cc: netdev@vger.kernel.org, oneukum@suse.com, andrew+netdev@lunn.ch,
	davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
	pabeni@redhat.com, linux-usb@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH net v3] usbnet: fix EVENT_RX_PAUSED race in usbnet_skb_return()
Date: Sun, 11 Oct 2026 22:02:33 +0000	[thread overview]
Message-ID: <179175615306.434549.2652185067157444525@kernel.org> (raw)
In-Reply-To: <20261007220311.113827-1-omermetekaya0@gmail.com>

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

      parent reply	other threads:[~2026-10-11 22:02 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-07 22:01 Ömer Mete Kaya
2026-10-07 22:09 ` netdev-bot+sinfo
2026-10-08 15:40   ` Jakub Kicinski
2026-10-08 15:47     ` Ömer Mete Kaya
2026-10-08 18:03       ` Jakub Kicinski
2026-10-08 15:42   ` Ömer Mete Kaya
2026-10-11 22:02 ` netdev-bot+sashiko [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=179175615306.434549.2652185067157444525@kernel.org \
    --to=netdev-bot+sashiko@kernel.org \
    --cc=andrew+netdev@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=omermetekaya0@gmail.com \
    --cc=oneukum@suse.com \
    --cc=pabeni@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®