Description

In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Handle buffer allocation failure in bnxt_rx_ring_reset() bnxt_rx_ring_reset() frees the ring buffers and then reallocates them, ignoring the result. bnxt_alloc_one_rx_ring() can fail in bnxt_alloc_one_tpa_info_data(), which returns -ENOMEM on the first failed allocation and leaves the remaining rxr->rx_tpa[] entries zeroed. The error isn't propagated up, so the loop in bnxt_rx_ring_reset continues and at the end the code re-enables TPA with partially unallocated rx_tpa array. This means that when the agg_id from hardware is mapped to a SW index in rxr->rx_tpa[], an uninitialized slot can be chosen which would hand a zero DMA address to the device. Fix this by falling back to a global reset, which is what the existing code already does when other functions fail, but unlike the other failure cases this particular failure has to return because TPA can't be re-enabled since the allocation failed.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.1",
  "pubDate": "2026-09-25T11:17:08.017Z",
  "pubdate": "2026-09-25T11:17:08.017Z",
  "executiveSummary": "A memory allocation vulnerability exists in the bnxt_en driver within the Linux kernel, specifically within the bnxt_rx_ring_reset() function. The vulnerability is classified as an improper error handling issue leading to a potential NULL or zeroed pointer dereference during DMA operations.\nThe flaw occurs when bnxt_alloc_one_rx_ring() fails to allocate memory for the TPA (Transparent Packet Aggregation) info data structures. The driver fails to propagate this error, proceeding to re-enable TPA with an inconsistent, partially unallocated state. This creates a scenario where hardware aggregation IDs may map to uninitialized slots containing zeroed DMA addresses.\nThis vulnerability impacts the network interface controller (NIC) communication layer. If exploited, an attacker could potentially induce system instability, memory corruption, or undefined hardware behavior by triggering high-pressure memory conditions that force allocation failures. While requiring specific kernel memory pressure or resource constraints, the impact is critical due to the potential for kernel-space memory corruption and Denial of Service (DoS).",
  "technicalDetails": "The root cause lies in the insufficient error propagation within the bnxt_rx_ring_reset() function in the bnxt_en driver. During a reset cycle, the function deallocates existing ring buffers and attempts to reallocate them via bnxt_alloc_one_rx_ring().\nInternally, bnxt_alloc_one_rx_ring() calls bnxt_alloc_one_tpa_info_data() to manage TPA buffers. If this function fails due to memory exhaustion (-ENOMEM), it returns an error and leaves the associated rxr->rx_tpa[] entries in a zeroed or uninitialized state. Because the caller, bnxt_rx_ring_reset(), ignores the return value of the allocation routine, the logic proceeds as if the ring reset were successful.\nThe exploitation flow begins under memory-constrained conditions where the driver enters the reset path. Because the TPA state remains partially uninitialized, subsequent network traffic utilizing hardware TPA will trigger a lookup where the hardware agg_id is mapped to an entry in the rxr->rx_tpa[] array. Since the array index is uninitialized (or zeroed), the system provides a zero-valued DMA address to the NIC hardware.\nWhen the NIC hardware performs DMA transactions to this zeroed address, it may result in illegal memory access or data corruption within the kernel's memory space, depending on the kernel's memory layout and IOMMU configuration. This effectively bypasses the expected integrity checks for buffer memory management.\nThe vulnerability is localized to the initialization and reset logic of the Broadcom NetXtreme Ethernet driver. There are no authentication requirements for this flaw as it resides in the low-level packet processing path; however, the attacker must have a means to trigger high system load or memory pressure to facilitate the allocation failure condition.\nPost-exploitation impact includes kernel panics, potential for arbitrary memory corruption, and a persistent Denial of Service (DoS) resulting from the driver's inability to reconcile its internal state with the hardware's expected memory buffers. Recovery typically requires a full system reboot as the interface becomes permanently stuck in an unstable state."
}