CVE-2026-53177

What it actually does

This is a Linux kernel denial-of-service flaw in the Broadcom NetXtreme Ethernet driver, bnxt_en. During PCIe Advanced Error Reporting / PCIe error recovery, the kernel may invoke the driver error recovery path even when the NIC is administratively closed. In that closed state, the driver’s per-NAPI data structure can already be freed. The vulnerable code attempts to disable and synchronize interrupts and maps completion rings through that freed or NULL bnapi pointer, resulting in a NULL pointer dereference in kernel context. The likely outcome is a kernel oops and, depending on kernel panic settings and workload, a full system crash or forced reboot.

Why it matters to the business

Systems using affected Linux kernels with Broadcom NetXtreme NICs may crash during PCIe error recovery events, causing network service outages, workload interruption, failover events, or node loss in clustered environments. The current exploitation likelihood appears low: it is not listed in CISA KEV, is not known to be used in ransomware campaigns, has no public exploit maturity indicated, and has a very low EPSS score. However, the operational impact can still be significant for high-availability systems, virtualization hosts, storage nodes, Kubernetes workers, appliances, or any infrastructure where a kernel crash causes broad service disruption.

How an attack unfolds

An attacker would need a way to cause or influence PCIe error recovery affecting a system with the vulnerable bnxt_en driver and a Broadcom NetXtreme NIC that is closed or administratively down. When a PCIe Root Port or Downstream Port reports an error, Linux error recovery may run callbacks for subordinate devices regardless of whether the NIC is currently open. The bnxt_en error callback enters bnxt_io_error_detected(), attempts to disable and synchronize interrupts, and calls into code that expects the driver’s bnapi state to exist. Because bnapi is allocated when the NIC is opened and freed when it is closed, this path can dereference a NULL pointer. In practice, exploitation is most plausible through local administrative control, malicious or faulty PCIe hardware, fault injection, or an already-compromised host capable of manipulating device state and triggering PCIe/AER recovery. Successful exploitation causes denial of service rather than code execution.

How to fix it

Upgrade to a Linux kernel version that includes the bnxt_en fix adding a NULL check before disabling and synchronizing IRQs during PCIe error recovery. Because no product-specific fixed versions were provided, use the fixed kernel packages from the operating system or distribution vendor rather than attempting to infer safety from the upstream CVE alone. Prioritize systems with Broadcom NetXtreme adapters using the bnxt_en driver, especially production servers, hypervisors, storage systems, and clustered nodes. Where immediate patching is not possible, reduce exposure by avoiding unnecessary administrative down/close operations on bnxt_en interfaces, replacing or removing unstable PCIe hardware that generates AER events, ensuring crash recovery and HA failover are working, and considering temporary use of alternate NICs or drivers where operationally feasible. Disabling PCIe AER or blacklisting the driver may reduce triggerability in some environments but can hide hardware faults or remove network functionality, so those mitigations should be used only after risk review and testing.

How to confirm the fix worked

Confirm whether systems are exposed by checking for Broadcom NetXtreme adapters bound to the bnxt_en driver and verifying that the running kernel contains the vendor patch for this issue. On Linux, review `lspci -nnk` output for Ethernet controllers using `Kernel driver in use: bnxt_en`, and check the running kernel with `uname -r` against the distribution’s fixed kernel advisory. Validate remediation by booting into the patched kernel, confirming the bnxt_en module is loaded from the updated kernel tree, and ensuring normal NIC open/close operations do not produce kernel oops messages. In test environments only, controlled PCIe/AER recovery testing can be used to confirm the patched driver gracefully handles closed NIC state without dereferencing bnapi. Also review kernel logs after patching for continued PCIe/AER errors, since those may indicate underlying hardware instability even if the crash bug is fixed.

Typical attack path

1. Identify a Linux system using the bnxt_en driver for a Broadcom NetXtreme network adapter.
2. Place the affected NIC into a closed or administratively down state, or wait for it to be closed during normal operations.
3. Trigger or induce a PCIe/AER error condition on the relevant PCIe hierarchy, such as through faulty hardware, malicious peripheral behavior, physical access, or privileged local manipulation where possible.
4. Linux PCIe error recovery invokes the bnxt_en error recovery callback even though the NIC is closed.
5. The driver attempts to synchronize interrupts using driver state that has already been freed or was never allocated for the closed NIC.
6. The kernel dereferences a NULL pointer, causing a kernel oops and potentially a system panic or reboot.

How to detect it

To determine whether this issue may have already been triggered, review kernel, system, and crash logs for PCIe/AER events followed closely by bnxt_en driver error handling, NULL pointer dereference messages, kernel oopses, panics, or unexpected reboots. Relevant sources include `dmesg`, `journalctl -k`, `/var/log/kern.log`, `/var/log/messages`, `/var/log/syslog`, `kdump`/`crash` dumps, hypervisor host logs, out-of-band management event logs, and hardware platform logs that record PCIe bus errors. Focus on sequences where a Broadcom NetXtreme NIC using bnxt_en was administratively down or closed, a PCIe Root Port or Downstream Port reported an error, and the kernel then logged a NULL pointer dereference in or near bnxt_en functions such as `bnxt_io_error_detected`, `bnxt_disable_int_sync`, or `bnxt_cp_num_to_irq_num`. A single occurrence is more likely to indicate denial of service or hardware-triggered instability than data compromise, but repeated patterns should be investigated for faulty hardware, unsafe administrative automation, malicious peripheral activity, or local privileged abuse.

• bnxt_en
• BUG: kernel NULL pointer dereference
• Oops: 0000
• Kernel panic - not syncing
• PCIe Bus Error
• AER: Corrected error received
• AER: Uncorrected error received
• AER: device recovery successful
• AER: device recovery failed
• bnxt_io_error_detected
• bnxt_disable_int_sync
• bnxt_cp_num_to_irq_num
• Kernel driver in use: bnxt_en
• NMI watchdog: Watchdog detected hard LOCKUP
• soft lockup - CPU
• /var/log/kern.log
• /var/log/messages
• /var/log/syslog
• /proc/vmcore

What your security team should do

• Inventory Linux systems using Broadcom NetXtreme NICs with the bnxt_en driver, prioritizing externally critical, HA, virtualization, storage, and container-host infrastructure.
• Apply vendor-provided fixed Linux kernel updates to affected systems and reboot into the patched kernel.
• Because this is not KEV-listed, not known ransomware-used, and has low EPSS, treat it as operational resilience priority rather than an active mass-exploitation emergency unless local threat models include malicious hardware, hostile co-tenancy, or physical access risk.
• Monitor kernel logs for PCIe AER events, bnxt_en error recovery messages, NULL pointer dereferences, oopses, panics, and unexpected reboots.
• Investigate and remediate recurring PCIe hardware errors, as they may both trigger this flaw and indicate broader platform reliability issues.
• Ensure crash dump collection, watchdogs, clustering, and automated failover are configured so that any kernel-level denial of service has limited business impact.
• Avoid relying on disabling AER or removing the bnxt_en driver as a long-term fix; use those only as temporary, tested mitigations where patching cannot be performed promptly.