CVE-2026-53177: Linux Kernel bnxt_en NULL Pointer Dereference DoS Vulnerability

Technical summary

The vulnerability exists in the bnxt_en driver's PCIe error recovery pathway. When a PCIe error is detected by a Root Port or Downstream Port, the kernel initiates error recovery on all subordinate devices, invoking the .error_detected() callback regardless of whether the device is administratively open or closed. The bnxt_io_error_detected() function calls bnxt_disable_int_sync(), which in turn invokes bnxt_cp_num_to_irq_num() to map completion rings to IRQ numbers using the bp->bnapi structure. However, bp->bnapi is dynamically allocated during NIC open and freed during NIC close. If a PCIe error occurs while the NIC is closed, the callback dereferences a NULL pointer, causing a kernel panic. The fix adds a NULL check before attempting to disable and synchronize IRQs.

Business impact

Systems running affected Linux kernel versions with Broadcom NetXtreme NICs face denial-of-service risk. A local attacker with ability to trigger PCIe errors or with physical access to the system can force a crash, resulting in unplanned downtime. This is particularly concerning in virtualized environments where PCIe error injection may be possible, and in data centers where multiple hosts share the same PCIe fabric. Service availability is the primary impact; data confidentiality and integrity are not affected.

Affected systems

The Linux kernel is affected across multiple versions. The vulnerability impacts any system running the bnxt_en driver (Broadcom NetXtreme Ethernet driver) for Broadcom network controllers. This includes servers and data center equipment using BCM57402, BCM57404, BCM57406, and related Broadcom NetXtreme controllers. Both bare-metal Linux systems and virtualized environments are at risk if they expose PCIe devices to untrusted code paths or administrative domains.

Exploitability

Exploitability requires local access (AV:L) and low privilege (PR:L), with no user interaction required. The attack surface is limited to scenarios where an attacker can either directly trigger PCIe errors on the NIC or cause conditions that induce PCIe error recovery. In most environments, this is not a trivial attack; however, in cloud or virtualized settings, guest VMs may have some ability to induce PCIe errors. The condition is easily triggered once access is obtained, making this a straightforward denial-of-service vector for privileged local users. Public exploit code has not been widely disclosed.

Remediation

Apply kernel updates that include the NULL pointer check in bnxt_io_error_detected(). Verify that your Linux distribution has incorporated the fix into their kernel maintenance branches. As an interim mitigation, if possible, avoid administratively closing and opening network interfaces with bnxt_en drivers while systems are under active PCIe error recovery stress. Monitor kernel logs for PCIe error messages and coordinate with hardware vendors if PCIe errors are frequent.

Patch guidance

Consult your Linux distribution's security advisory for the specific kernel version number containing this fix. Patches are typically available through standard package managers (apt, yum, dnf, zypper). Verify that the patched kernel includes the commit that adds NULL pointer validation before the bnxt_disable_int_sync() call in the .error_detected() callback handler. Test patched kernels in non-production environments first to ensure compatibility with your Broadcom NIC firmware and other system components.

Detection guidance

Monitor system logs and kernel messages for PCIe error events correlating with bnxt_en driver activity or NIC state transitions. Crash dumps or kernel panic messages containing stack traces through bnxt_io_error_detected() and bnxt_cp_num_to_irq_num() indicate exploitation. Implement kernel crash dump analysis (kdump) to capture panic data. In virtualized environments, monitor hypervisor-level PCIe error injection or AER (Advanced Error Reporting) events. Intrusion detection systems should flag unexpected PCIe errors followed by system reboots on affected platforms.

Why prioritize this

This vulnerability merits prompt but measured prioritization. The CVSS score of 5.5 reflects the local-access requirement and lack of confidentiality or integrity impact, placing it in MEDIUM severity. However, the exploitability is straightforward and the impact—system crash—is severe from an availability standpoint. Organizations with Broadcom NetXtreme NICs in production data centers or cloud environments should prioritize patching within standard maintenance windows. The lack of KEV listing indicates low weaponization pressure to date, reducing urgency for emergency patching, but the fix is simple and low-risk.

Risk score, explained

The CVSS 3.1 score of 5.5 reflects: Attack Vector (Local) indicating the attacker must have local system access; Attack Complexity (Low) because the NULL dereference is straightforward to trigger given the access; Privileges Required (Low) as only standard user or guest privileges are needed; User Interaction (None) since the attack is automatic upon PCIe error; Scope (Unchanged) as the impact is limited to the affected system; Confidentiality (None), Integrity (None), and Availability (High) indicating that only system availability is compromised. The medium rating appropriately captures a denial-of-service vulnerability that requires local access but poses no data breach risk.

Frequently asked questions