CVE-2026-80998
largeTX queue stall (DoS) in Linux kernel bnxt driver SW USO transmit path
The Linux kernel's Broadcom NetXtreme (bnxt) Ethernet driver can permanently stall a transmit queue when its software UDP segmentation offload (SW USO) path exits early. Under a burst of UDP GSO packets, the driver defers the TX doorbell to the end of the burst; if bnxt_sw_udp_gso_xmit returns early with NETDEV_TX_BUSY while a doorbell is pending, the device is never notified to transmit the buffer descriptors already written, so no completion is generated to wake the queue and the netdev TX watchdog fires. The impact is denial of service (transmit stall on the affected queue) with no confidentiality or integrity impact, and it was observed on a production system. Hosts most at risk run kernels containing the bnxt SW USO code and push bursts of UDP GSO traffic (e.g., QUIC/HTTP-3 or other UDP-based services) through Broadcom NetXtreme-C/E adapters. The flaw is fixed upstream, and no public proof of concept or active exploitation is known (not in CISA KEV).
What to do: Update to a kernel that includes the fix (the commit 'net: bnxt: ring the doorbell when SW USO exits early'); check your distribution's kernel changelog for the backported bnxt fix. As an interim workaround on affected bnxt interfaces, disable UDP segmentation offload (e.g., ethtool -K <iface> tx-udp-segmentation off) to bypass the vulnerable SW USO path. Monitor logs for 'NETDEV WATCHDOG ... transmit queue timed out' messages as an indicator of the stall; a driver reload or interface reset recovers the stalled queue.
| Linux kernel (bnxt network driver, SW USO path) | Kernel versions containing bnxt_sw_udp_gso_xmit prior to the fixing commit; no specific affected or fixed version numbers were published in the provided data |
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
In the Linux kernel, the following vulnerability has been resolved: net: bnxt: ring the doorbell when SW USO exits early When a burst of packets is handed down to the driver, the driver defers the doorbell to the end by setting txr->kick_pending = 1. The normal TX path handles this, but the SW USO path can miss it if it returns early. If bnxt_sw_udp_gso_xmit runs but returns early with NETDEV_TX_BUSY and txr->kick_pending was previously set to 1, then the TX queue can stall because the driver wrote some BDs but never wrote the doorbell. The device won't know to do the TX which would generate the completion that would wake the queue back up. Simplify bnxt_sw_udp_gso_xmit to set txr->kick_pending in its success case and check the flag on return. The added check after bnxt_sw_udp_gso_xmit returns ensures that any pending doorbells are written handling both successful USO and any early returns, which prevents the TX queue stall mentioned above. This TX queue stall was observed on a production system with a netdev TX watchdog informing about the queue stall.
- Vector
- CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
In the news0 stories
No ingested article mentions this CVE yet.