CVE-2026-97573 in Linux
Summary
by MITRE • 09/25/2026
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.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/25/2026
The Linux kernel driver for Broadcom NetXtreme-E network adapters contains a critical resource management flaw within the bnxt_en module that compromises system stability and potentially enables denial of service conditions. The vulnerability resides specifically in the bnxt_rx_ring_reset function, which is responsible for resetting receive rings during device initialization or error recovery scenarios. This routine attempts to free existing ring buffers and subsequently reallocate them to prepare for incoming network traffic. However, the implementation fails to adequately handle allocation failures that may occur during this process, creating a gap in defensive programming practices that leaves the driver state inconsistent with hardware expectations.
The technical root cause involves the interaction between bnxt_rx_ring_reset and its helper function bnxt_alloc_one_tpa_info_data. When allocating memory for Transmit Packet Aggregation information structures, if the system encounters an out-of-memory condition or other allocation failure, bnxt_alloc_one_tpa_info_data returns a negative error code indicating -ENOMEM. Crucially, this function leaves the remaining entries in the rxr->rx_tpa array zeroed rather than marking them as invalid or handling the partial state gracefully. Because the calling loop in bnxt_rx_ring_reset ignores these return values, it proceeds to completion regardless of whether all necessary resources were successfully allocated. This lack of error propagation means that subsequent code assumes a fully initialized structure when only a subset was actually provisioned by the kernel memory allocator.
The operational impact of this oversight is severe and directly affects hardware operation through incorrect DMA address handling. The driver maps aggregate identifiers from the network interface card to software indices within the rxr->rx_tpa array. If an uninitialized slot in this array, which contains zeroed values due to the failed allocation, is selected by the hardware mapping logic, it results in a zero DMA address being passed to the device. A zero DMA address typically points to invalid or protected memory regions, causing the network adapter to write data into incorrect locations upon receiving packets. This can lead to immediate kernel panics, system crashes, or silent data corruption depending on how the operating system handles such illegal hardware access attempts.
From a security and reliability perspective, this vulnerability aligns with CWE-252, which describes unchecked return values leading to unexpected behavior, as well as CWE-401 regarding missing release of memory after successful allocation in certain code paths that lead to inconsistent states. The failure mode allows an attacker who can trigger network traffic patterns or reset events to potentially induce a denial of service by forcing the driver into this corrupted state repeatedly. While direct remote exploitation for arbitrary code execution is unlikely due to the nature of DMA errors typically causing crashes rather than control flow hijacking, the reliability impact on critical infrastructure services hosted behind these adapters remains significant.
To mitigate this risk, the fix involves modifying bnxt_rx_ring_reset to detect allocation failures and immediately fall back to a global reset procedure. This approach mirrors existing error handling logic used for other failure cases within the driver but ensures that TPA is not re-enabled if its underlying data structures are incomplete. By returning early from the function when memory allocation fails, the driver prevents the hardware from being configured with invalid DMA addresses and maintains system integrity during recovery operations. Administrators should ensure their systems are updated to include patches addressing this specific bnxt_en issue, particularly in environments where network interface resets or high-load conditions might trigger these code paths frequently.