CVE-2026-43034

What it actually does

This vulnerability affects the Linux kernel Broadcom NetXtreme-C/E Ethernet driver, bnxt_en. The driver processes a firmware response field, resp->type, and uses it to select entries in fixed backing-store metadata arrays. Because that response value may not reliably match the query type currently being processed, the driver can index the wrong array entry or potentially access memory out of bounds. The resolved behavior derives ctxm->type from the driver’s current query loop variable instead of trusting the firmware-provided response type. The practical technical impact is local denial of service: a low-privileged local user who can trigger the vulnerable driver path may be able to crash the kernel, reset networking, or destabilize the host. The CVSS vector indicates local access, low attack complexity, low privileges, no user interaction, and high availability impact, with no expected confidentiality or integrity impact.

Why it matters to the business

Systems using affected Linux kernels with Broadcom bnxt_en-supported network adapters may be exposed to host instability or outages. Successful exploitation can cause a kernel crash or networking disruption, which may interrupt workloads, terminate active sessions, trigger failover events, or reduce service availability. The EPSS score is very low and there is no known CISA KEV listing or known ransomware association, so broad active exploitation is not currently indicated; however, because the vulnerable component is kernel-level networking code, affected production systems should still be patched during normal kernel maintenance windows, with higher priority for multi-user systems, virtualization hosts, container hosts, and systems where untrusted local users can execute code.

How an attack unfolds

An attacker first needs local access to a system running an affected Linux kernel with the bnxt_en driver in use or available. With low privileges, the attacker attempts to trigger code paths that query or reinitialize Broadcom network-device backing-store capabilities, such as driver initialization, device reset, interface reconfiguration, or other operations that cause the driver to process firmware capability responses. In the vulnerable implementation, the driver records the backing-store type from the firmware response and later uses that value as an index into fixed metadata arrays. If the processed type is unexpected or inconsistent with the driver’s current query state, the kernel may access invalid metadata, leading to a crash or other availability failure. Exploitation is expected to result in denial of service rather than data theft or privilege escalation based on the published impact.

How to fix it

Upgrade to a Linux kernel version that includes the bnxt_en fix for this issue. No exact fixed package versions were provided in the input, so use the fixed kernel packages from the relevant Linux distribution, vendor advisory, or upstream stable kernel branch. Prioritize systems with Broadcom NetXtreme-C/E adapters using the bnxt_en driver. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted users and workloads, preventing unprivileged users from performing network-device management operations, and avoiding unnecessary reloads or resets of the bnxt_en driver. If the hardware is not required, consider disabling or blacklisting the bnxt_en module as a temporary mitigation, after validating operational impact.

How to confirm the fix worked

Confirm exposure by checking whether the system is running an affected kernel and whether the bnxt_en module is present or loaded. Useful checks include `uname -r`, distribution package manager queries for the installed kernel version, `lsmod | grep '^bnxt_en'`, `modinfo bnxt_en`, and hardware inventory commands such as `lspci -nn | grep -i -E 'Broadcom|NetXtreme'`. Confirm remediation by verifying the installed kernel package includes the vendor fix, rebooting into the fixed kernel, and confirming the active kernel version with `uname -r`. Also verify that bnxt_en remains stable during interface initialization, link changes, and device reset testing, and that kernel logs do not show new bnxt_en-related oops, panic, or general protection fault messages.

Typical attack path

1. Obtain low-privileged local access to a Linux system running an affected kernel.
2. Confirm that the Broadcom bnxt_en driver is loaded, present, or bound to a supported network adapter.
3. Trigger driver or device operations that cause backing-store capability queries, such as network-device reset, reinitialization, or configuration changes.
4. Cause the vulnerable driver path to process an inconsistent backing-store type value.
5. Induce a kernel fault, panic, network-driver failure, or host instability, resulting in denial of service.

How to detect it

Look for evidence of kernel instability around the bnxt_en driver. Primary log sources are kernel logs, `dmesg`, systemd journal entries from `journalctl -k`, `/var/log/kern.log`, `/var/log/messages`, `/var/log/syslog`, crash dumps, kdump/vmcore artifacts, and host monitoring alerts for unexpected reboots or network-interface failures. Search for bnxt_en messages near kernel oops, panic, general protection fault, NULL pointer dereference, slab out-of-bounds, or watchdog events. Pay particular attention to stack traces containing `bnxt_hwrm_func_backing_store_qcaps_v2`, `bnxt_hwrm_func_backing_store_qcaps`, `bnxt_bstore_to_trace`, or `ctx_arr`. Correlate suspicious events with local user activity, interface resets, driver reloads, ethtool or iproute2 operations, PCI device resets, and unexpected process activity shortly before the crash. Because this is a denial-of-service issue and no public exploit maturity or KEV exploitation is indicated, detection will usually rely on crash artifacts and temporal correlation rather than a unique exploit signature.

• bnxt_en
• bnxt_hwrm_func_backing_store_qcaps_v2
• bnxt_hwrm_func_backing_store_qcaps
• bnxt_bstore_to_trace
• ctx_arr
• Oops:
• kernel BUG
• Kernel panic
• general protection fault
• BUG: kernel NULL pointer dereference
• slab-out-of-bounds
• KASAN:
• watchdog: BUG: soft lockup
• watchdog: BUG: hard LOCKUP
• NETDEV WATCHDOG
• bnxt_en:
• bnxt_en 0000:
• Broadcom NetXtreme
• /var/crash/
• /var/lib/systemd/coredump/
• /proc/modules
• /sys/module/bnxt_en

What your security team should do

• Inventory Linux systems using Broadcom NetXtreme-C/E network adapters or loading the bnxt_en kernel module.
• Map those systems to installed kernel versions and vendor advisories to determine whether the bnxt_en fix is present.
• Patch affected systems through the normal kernel update process, prioritizing multi-user servers, virtualization hosts, container hosts, and systems with untrusted local code execution.
• Reboot systems into the fixed kernel and verify the active kernel version after patching.
• Restrict local access and network-device administration capabilities on systems that cannot be patched immediately.
• Monitor kernel logs for bnxt_en-related crashes, oops messages, panics, or resets that may indicate attempted exploitation or instability.
• If bnxt_en-supported hardware is unused, consider disabling or blacklisting the module after operational validation.