CVE-2026-97569
UnknownSummary
In the Linux kernel, the bnxt_en driver has a bug that can cause the transmit queue to stop. When the driver defers completions for a burst of packets and then a large USO packet cannot fit in a small ring, the ring may become full of packets with suppressed completions, permanently stalling the queue. This affects small rings (up to 457 descriptors) and was fixed by clearing the NO_CMPL bit in bnxt_txr_db_kick().
Risk Assessment
This can cause a permanent network queue stall, leading to loss of connectivity and requiring an interface or system restart. The risk is low because it requires a small ring size and a specific traffic pattern.
Recommendation
Update the Linux kernel to a version containing the fix for CVE-2026-97569. If updating is not possible, consider increasing the transmit ring size above 457 descriptors to avoid the triggering conditions.
Other vulnerabilities in Linux kernel bnxt_en driver
See all- CVE-2026-97570Unknown
In the Linux kernel, the bnxt_en driver has an out-of-bounds write in bnxt_alloc_agg_idx. When firmware advertises fewer concurrent TPAs (e.g., 32) than the maximum, the TPA ID can exceed the size of the rx_tpa array, leading to invalid memory access and a kernel crash at boot.
- CVE-2026-43260High
A vulnerability related to the RSS context deletion logic in the bnxt_en driver has been fixed in the Linux kernel. The issue was that an incorrect check of the network interface state led to VNIC leaks in firmware, potentially resulting in the loss of active RSS contexts.
Original NVD description (English source)
In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Prevent queue stop with deferred completions When the driver receives a burst of packets, it can mark a BD with the NO_CMPL bit to defer completions. The expectation is that the last packet in the ring will have this bit unset and the completion generated by that packet will cleanup that packet and the ones preceding it. This helps to reduce the number of completions fired. The suppressed completions are controlled by the driver and the number of packets with suppressed completions scales with the size of the ring. SW USO packets, on the other hand, have an upper bound on the maximum number of BDs which can be consumed which does not scale with the ring size. So, for small rings it is possible that: a burst of packets is handed to the driver, the driver defers completions for all of the packets because the number of free descriptors stays above the threshold in the driver. Then, a USO packet arrives, but the number of BDs available is not enough and the USO code exits early. In this case, you end up in a state where the ring is full of packets with their completions suppressed, which can cause the queue to stop and never be restarted. Assuming default CONFIG_MAX_SKB_FRAGS, this is only possible for small rings (<= 457 descriptors, below the driver default value) when a burst of packets fills the ring, followed by a large USO packet that can't fit. For larger rings, the delta between the completion suppression threshold and the BDs required for SW USO is large enough that completions will fire and this case is unreachable. This issue was pointed out by Sashiko and while it seems fairly unlikely given that the queue size must be small to trigger this, it is indeed possible. Fix this by tracking the last BD which deferred completions and centralizing the logic for deciding when to ring the doorbell. The NO_CMPL bit is now cleared in bnxt_txr_db_kick(), so every doorbell site is covered, including the SW USO early exit. This guarantees the ring always ends in a BD which generates a completion to clean it and wake the queue.