CVE-2026-97572: bnxt_en: Propagate RX ring init failures in bnxt_init_nic()
In the Linux kernel, the following vulnerability has been resolved:
bnxten: Propagate RX ring init failures in bnxtinitnic()
bnxtinitrxrings() returns an error when bnxtalloconerxring() fails, but bnxtinitnic() discards that return value and calls bnxtinitchip(), which enables TPA.
If an allocation fails, this could leave rxr->rxtpa[] partially zeroed and TPA would be enabled over an array with zeroed entries. This would lead to a zeroed DMA address being handed out if the aggidx is translated to a SW index at a zeroed entry.
Fix this by propagating the error out of bnxtinitnic(). Both callers already check its return value and unwind with bnxtfreeskbs() and bnxtfreemem(), which tolerate a partially initialized RX ring.
Affected Software
Event History
Frequently Asked Questions
What conditions are required for this issue to occur?
An RX ring allocation must fail during bnxt_init_rx_rings(), leaving the RX TPA array partially initialized. The driver must then continue initialization and enable TPA, allowing a translated aggregation index to reference a zeroed entry.
What is the practical impact of the faulty initialization path?
The driver can hand out a zeroed DMA address when TPA is enabled over the partially initialized RX TPA array. The provided data does not specify a remote attack vector, required privileges, or a confirmed exploitation outcome beyond this invalid DMA-address condition.
What changes after applying the fix?
bnxt_init_nic() propagates RX ring initialization failures instead of continuing to bnxt_init_chip() and enabling TPA. Its callers already check the returned error and clean up with bnxt_free_skbs() and bnxt_free_mem(), which can handle partially initialized RX rings.