CVE-2026-80998: net: bnxt: ring the doorbell when SW USO exits early
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->kickpending = 1. The normal TX path handles this, but the SW USO path can miss it if it returns early.
If bnxtswudpgsoxmit runs but returns early with NETDEVTXBUSY and txr->kickpending 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 bnxtswudpgsoxmit to set txr->kickpending in its success case and check the flag on return. The added check after bnxtswudpgsoxmit 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.
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Ensure bnxt_sw_udp_gso_xmit sets txr->kick_pending = 1 when it exits early (returns NETDEV_TX_BUSY) so pending doorbells are rung and TX queue stalls are avoided when software USO exits without reaching the normal TX doorbell path.
Linux kernel (bnxt Ethernet driver) txr->kick_pending = 1
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using the Linux kernel bnxt network driver are exposed when the affected software UDP segmentation offload transmit path is used. The issue was observed in production under a burst of packets handed to the driver.
What conditions trigger the transmit queue stall?
The SW USO transmit routine must run and return early with NETDEV_TX_BUSY while a deferred doorbell is pending. In that state, the driver may have written buffer descriptors without ringing the doorbell, preventing the device from processing transmission and generating the completion needed to wake the queue.
How can an administrator identify a likely affected system?
A likely symptom is a stalled bnxt transmit queue accompanied by a netdev TX watchdog report indicating a queue stall. The described failure occurs when pending transmit work does not progress because the device was not notified through the doorbell.