usbnet:fix NPE during rx_complete

PATCH Superseded Ying Lu 2 participants 8 messages Apr 1, 2025 – Apr 2, 2025

Subsystems (5)

Networking Network drivers USB USB networking drivers +1 more subsystems

lore

Share & tools

lore

Ying Lu

author

2025-04-01 10:18 UTC #0 lore raw

cover usbnet:fix NPE during rx_complete

From: luying1 <[email protected]>

The patchset fix the issue caused by the following modifications:
commit 04e906839a053f092ef53f4fb2d610983412b904 (usbnet: fix cyclical race on disconnect with work queue)

The issue:
The usb_submit_urb function lacks a usbnet_going_away validation, whereas __usbnet_queue_skb includes this check. This inconsistency creates a race condition where: A URB request may succeed, but the corresponding SKB data fails to be queued.

Subsequent processes (e.g., rx_complete → defer_bh → __skb_unlink(skb, list)) attempt to access skb->next, triggering a NULL pointer dereference (Kernel Panic).

Fix issue:
adding the usbnet_going_away check in usb_submit_urb to synchronize the validation logic.

luying1 (1):
usbnet:fix NPE during rx_complete

 drivers/net/usb/usbnet.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

Signature · 1 line

2.40.1

Ying Lu

author

2025-04-01 10:18 UTC #1 lore raw

PATCH 1/1 usbnet:fix NPE during rx_complete

From: luying1 <[email protected]>

Missing usbnet_going_away Check in Critical Path. The usb_submit_urb function lacks a usbnet_going_away validation, whereas __usbnet_queue_skb includes this check.

This inconsistency creates a race condition where:
A URB request may succeed, but the corresponding SKB data fails to be queued.

Subsequent processes:
(e.g., rx_complete → defer_bh → __skb_unlink(skb, list)) attempt to access skb->next, triggering a NULL pointer dereference (Kernel Panic).

Signed-off-by luying1 <[email protected]>

---
 drivers/net/usb/usbnet.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

drivers/net/usb/usbnet.c +3 -3

index 44179f4e807f..5161bb5d824b 100644
@@ -519,7 +519,8 @@ static int rx_submit (struct usbnet *dev, struct urb *urb, gfp_t flags)
 	    netif_device_present (dev->net) &&
 	    test_bit(EVENT_DEV_OPEN, &dev->flags) &&
 	    !test_bit (EVENT_RX_HALT, &dev->flags) &&
-	    !test_bit (EVENT_DEV_ASLEEP, &dev->flags)) {
+	    !test_bit (EVENT_DEV_ASLEEP, &dev->flags) &&
+	    !usbnet_going_away(dev)) {
 		switch (retval = usb_submit_urb (urb, GFP_ATOMIC)) {
 		case -EPIPE:
 			usbnet_defer_kevent (dev, EVENT_RX_HALT);

@@ -540,8 +541,7 @@ static int rx_submit (struct usbnet *dev, struct urb *urb, gfp_t flags)
 			tasklet_schedule (&dev->bh);
 			break;
 		case 0:
-			if (!usbnet_going_away(dev))
-				__usbnet_queue_skb(&dev->rxq, skb, rx_start);
+			__usbnet_queue_skb(&dev->rxq, skb, rx_start);
 		}
 	} else {
 		netif_dbg(dev, ifdown, dev->net, "rx: stopped\n");

Signature · 1 line

2.40.1

Greg KH

maintainer

2025-04-01 10:31 UTC #2 lore raw

Quoted 10 lines · Ying Lu

From: luying1 <[email protected]>
Missing usbnet_going_away Check in Critical Path. The usb_submit_urb function lacks a usbnet_going_away validation, whereas __usbnet_queue_skb includes this check.
This inconsistency creates a race condition where:
A URB request may succeed, but the corresponding SKB data fails to be queued.

Quoted 6 lines

Subsequent processes:
(e.g., rx_complete → defer_bh → __skb_unlink(skb, list)) attempt to access skb->next, triggering a NULL pointer dereference (Kernel Panic).
Signed-off-by luying1 <[email protected]>

Please use your name, not an email alias.

Also, what commit id does this fix? Should it be applied to stable kernels?

thanks,

greg k-h

Ying Lu

author

2025-04-01 12:48 UTC #3 lore raw

Quoted 12 lines · Greg KH

Quoted 10 lines · Ying Lu
From: luying1 <[email protected]>
Missing usbnet_going_away Check in Critical Path. The usb_submit_urb function lacks a usbnet_going_away validation, whereas __usbnet_queue_skb includes this check.
This inconsistency creates a race condition where:
A URB request may succeed, but the corresponding SKB data fails to be queued.

Quoted 9 lines

Quoted 6 lines
Subsequent processes:
(e.g., rx_complete → defer_bh → __skb_unlink(skb, list)) attempt to access skb->next, triggering a NULL pointer dereference (Kernel Panic).
Signed-off-by luying1 <[email protected]>
Please use your name, not an email alias.

OK, I have updated. please check the Patch v2

Quoted 2 lines

Also, what commit id does this fix? Should it be applied to stable kernels?

The commit id is 04e906839a053f092ef53f4fb2d610983412b904 (usbnet: fix cyclical race on disconnect with work queue) Should it be applied to stable kernels? -- Yes

Quoted 3 lines

thanks,
greg k-h

Greg KH

maintainer

2025-04-01 13:48 UTC #4 lore raw

Quoted 22 lines · Ying Lu

Quoted 12 lines · Greg KH
Quoted 10 lines · Ying Lu
From: luying1 <[email protected]>
Missing usbnet_going_away Check in Critical Path. The usb_submit_urb function lacks a usbnet_going_away validation, whereas __usbnet_queue_skb includes this check.
This inconsistency creates a race condition where:
A URB request may succeed, but the corresponding SKB data fails to be queued.
Quoted 9 lines
Quoted 6 lines
Subsequent processes:
(e.g., rx_complete → defer_bh → __skb_unlink(skb, list)) attempt to access skb->next, triggering a NULL pointer dereference (Kernel Panic).
Signed-off-by luying1 <[email protected]>
Please use your name, not an email alias.

Quoted 7 lines

OK, I have updated. please check the Patch v2
Quoted 2 lines
Also, what commit id does this fix? Should it be applied to stable kernels?
The commit id is 04e906839a053f092ef53f4fb2d610983412b904 (usbnet: fix cyclical race on disconnect with work queue) Should it be applied to stable kernels? -- Yes

Please mark the commit with that information, you seem to have not done so for the v2 version :(

Ying Lu

author

2025-04-02 00:12 UTC #5 lore raw

Quoted 26 lines · Greg KH

Quoted 24 lines · Ying Lu
Quoted 12 lines · Greg KH
Quoted 10 lines · Ying Lu
From: luying1 <[email protected]>
Missing usbnet_going_away Check in Critical Path. The usb_submit_urb function lacks a usbnet_going_away validation, whereas __usbnet_queue_skb includes this check.
This inconsistency creates a race condition where:
A URB request may succeed, but the corresponding SKB data fails to be queued.
Quoted 9 lines
Quoted 6 lines
Subsequent processes:
(e.g., rx_complete → defer_bh → __skb_unlink(skb, list)) attempt to access skb->next, triggering a NULL pointer dereference (Kernel Panic).
Signed-off-by luying1 <[email protected]>
Please use your name, not an email alias.
OK, I have updated. please check the Patch v2

Quoted 8 lines

Quoted 5 lines
Quoted 2 lines
Also, what commit id does this fix? Should it be applied to stable kernels?
The commit id is 04e906839a053f092ef53f4fb2d610983412b904 (usbnet: fix cyclical race on disconnect with work queue) Should it be applied to stable kernels? -- Yes
Please mark the commit with that information, you seem to have not done so for the v2 version :(

Thank you for your response. Could you please confirm if I understand correctly:
Should we include in our commit message which commit id we're fixing?

Greg KH

maintainer

2025-04-02 07:12 UTC #6 lore raw

Quoted 29 lines · Ying Lu

Quoted 28 lines · Greg KH
Quoted 26 lines · Ying Lu
Quoted 12 lines · Greg KH
Quoted 10 lines · Ying Lu
From: luying1 <[email protected]>
Missing usbnet_going_away Check in Critical Path. The usb_submit_urb function lacks a usbnet_going_away validation, whereas __usbnet_queue_skb includes this check.
This inconsistency creates a race condition where:
A URB request may succeed, but the corresponding SKB data fails to be queued.
Quoted 9 lines
Quoted 6 lines
Subsequent processes:
(e.g., rx_complete → defer_bh → __skb_unlink(skb, list)) attempt to access skb->next, triggering a NULL pointer dereference (Kernel Panic).
Signed-off-by luying1 <[email protected]>
Please use your name, not an email alias.
OK, I have updated. please check the Patch v2
Quoted 2 lines
Also, what commit id does this fix? Should it be applied to stable kernels?

Quoted 8 lines

Quoted 6 lines
Quoted 3 lines
The commit id is 04e906839a053f092ef53f4fb2d610983412b904 (usbnet: fix cyclical race on disconnect with work queue) Should it be applied to stable kernels? -- Yes
Please mark the commit with that information, you seem to have not done so for the v2 version :(
Thank you for your response. Could you please confirm if I understand correctly:
Should we include in our commit message which commit id we're fixing?

No, use the correct "Fixes:" tag format as described in the documentation.

thanks,

greg k-h

Ying Lu

author

2025-04-02 08:17 UTC #7 lore raw

Quoted 40 lines · Greg KH

Quoted 29 lines · Ying Lu
Quoted 28 lines · Greg KH
Quoted 26 lines · Ying Lu
Quoted 12 lines · Greg KH
Quoted 10 lines · Ying Lu
From: luying1 <[email protected]>
Missing usbnet_going_away Check in Critical Path. The usb_submit_urb function lacks a usbnet_going_away validation, whereas __usbnet_queue_skb includes this check.
This inconsistency creates a race condition where:
A URB request may succeed, but the corresponding SKB data fails to be queued.
Quoted 9 lines
Quoted 6 lines
Subsequent processes:
(e.g., rx_complete → defer_bh → __skb_unlink(skb, list)) attempt to access skb->next, triggering a NULL pointer dereference (Kernel Panic).
Signed-off-by luying1 <[email protected]>
Please use your name, not an email alias.
OK, I have updated. please check the Patch v2
Quoted 2 lines
Also, what commit id does this fix? Should it be applied to stable kernels?
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
The commit id is 04e906839a053f092ef53f4fb2d610983412b904 (usbnet: fix cyclical race on disconnect with work queue) Should it be applied to stable kernels? -- Yes
Please mark the commit with that information, you seem to have not done so for the v2 version :(
Thank you for your response. Could you please confirm if I understand correctly:
Should we include in our commit message which commit id we're fixing?

Quoted 6 lines

No, use the correct "Fixes:" tag format as described in the documentation.
thanks,
greg k-h

Oh, I see. Thank you very much for the reminder!
I've already fixed it in the PATCH v3. Could you please take another look?

Thanks,

Ying Lu