HIGH Introduced in 7.1
bnxt Doorbell Stall
CVE-2026-80998
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
KernelScan AI6.1MEDIUM
01Description
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.
02KernelScan AI Analysis
Risk summary
A local unprivileged process sending UDP GSO packets through a Broadcom bnxt network interface can permanently stall the transmit queue. The NIC never receives the doorbell notification to process pending descriptors, so no completions are generated and the queue never resumes. This results in a denial of service affecting network transmission on the interface.
Vulnerability analysis
When the bnxt driver processes a burst of packets, it defers the hardware doorbell write to the end of the burst by setting a pending flag. The normal transmit path handles this correctly, but the software UDP GSO offload path could return early — for instance when the transmit ring is full — without ever writing the deferred doorbell. The NIC would then be unaware that transmit descriptors were already written, so it would never process them, never generate completions, and the transmit queue would stall indefinitely. The fix changes the software USO path to set the pending-doorbell flag instead of writing the doorbell directly, and the main transmit function now checks this flag after the USO function returns — regardless of whether it completed normally or exited early — and rings the doorbell if needed. Any local process that can send UDP GSO packets through a bnxt interface can trigger this; no special privileges are required, though the hardware must lack native UDP GSO support so the software fallback path is used.
Lifecycle
03Fix Versions
| Branch | Introduced | Fixed in | Patch commit |
|---|---|---|---|
| 7.2 | 7.1 | 7.2.4 | 48d1c9665db6 |
| mainline | 7.1 | 7.3 | 4e15e89faac9 |