CVE-2026-43034: Linux Kernel Privilege Escalation Flaw

CVE-2026-43034 Overview

CVE-2026-43034 is a Linux kernel vulnerability in the Broadcom NetXtreme (bnxt_en) Ethernet driver. The flaw resides in the bnxt_hwrm_func_backing_store_qcaps_v2() function, which stored the firmware response field resp->type directly into ctxm->type. That value was then used to index fixed backing-store metadata arrays such as ctx_arr[] and bnxt_bstore_to_trace[]. Because ctxm->type is fixed by the current backing-store query type and must match the array index of ctx->ctx_arr, sourcing it from firmware-supplied data could result in incorrect array indexing. The fix sets ctxm->type from the loop variable instead of the firmware response.

Critical Impact

Incorrect indexing of fixed backing-store metadata arrays in the bnxt_en driver could lead to out-of-bounds access or driver state inconsistency on systems using Broadcom NetXtreme adapters.

Affected Products

• Linux kernel versions containing the bnxt_en driver with backing store v2 query support
• Systems using Broadcom NetXtreme Ethernet adapters relying on the bnxt_en driver
• Stable kernel branches receiving the upstream backports referenced in the patch commits

Discovery Timeline

• 2026-05-01 - CVE-2026-43034 published to NVD
• 2026-05-01 - Last updated in NVD database

Technical Details for CVE-2026-43034

Vulnerability Analysis

The vulnerability exists in the Broadcom NetXtreme Ethernet driver (bnxt_en) within the kernel's network subsystem. The function bnxt_hwrm_func_backing_store_qcaps_v2() queries firmware for backing store capabilities using a Hardware Resource Manager (HWRM) command. The driver iterates through backing store types and stores firmware response data describing each type. The original implementation assigned resp->type, taken directly from the firmware response, into ctxm->type. The driver then used ctxm->type to index fixed metadata arrays including ctx_arr[] and bnxt_bstore_to_trace[]. These arrays are statically sized and indexed by the local query type, not by arbitrary firmware-supplied values. A mismatch between firmware-supplied type and the expected loop index could produce inconsistent state or out-of-bounds array indexing in kernel memory.

Root Cause

The root cause is improper input validation of firmware-supplied data used as an array index. The driver trusted resp->type from the firmware response and used it without verifying it matched the loop iteration variable. The corrected code sets ctxm->type from the current loop variable, which always matches the array index of ctx->ctx_arr. The patch also restructures the loop to advance type from next_valid_type directly in the for statement, simplifying control flow for non-valid and unchanged entries.

Attack Vector

The issue requires the firmware response to contain an unexpected type value. Exploitation prerequisites depend on the trust boundary between the kernel driver and Broadcom NIC firmware. Practical exploitation by an unprivileged attacker is not described in the public commit data. The fix is a defensive correction rather than a response to a demonstrated remote attack. Refer to the upstream kernel commits for the precise change scope.

No verified exploitation code is available. The vulnerability mechanism is described in the upstream patches at the Kernel Git Commit 29732b68, Kernel Git Commit 4ee93710, and Kernel Git Commit c8d53b70.

Detection Methods for CVE-2026-43034

Indicators of Compromise

• Kernel log messages referencing bnxt_en driver errors during backing store capability queries at boot or NIC reset
• Unexpected NIC reset behavior or driver probe failures on Broadcom NetXtreme adapters
• Kernel oops or warning traces originating from bnxt_hwrm_func_backing_store_qcaps_v2()

Detection Strategies

• Inventory hosts running affected kernel versions with the bnxt_en driver loaded by checking lsmod | grep bnxt_en and kernel version against patched stable branches
• Compare deployed kernel build hashes against the fixed commits 29732b68, 4ee93710, and c8d53b70
• Audit dmesg output for anomalous bnxt_en warnings tied to backing store metadata processing

Monitoring Recommendations

• Forward kernel ring buffer logs to a centralized log platform and alert on bnxt_en warning or error patterns
• Track Broadcom NetXtreme firmware versions across the fleet and validate they are current with vendor guidance
• Monitor NIC link state and driver reload events on systems using Broadcom adapters

How to Mitigate CVE-2026-43034

Immediate Actions Required

• Apply the upstream Linux kernel patches referenced in commits 29732b68, 4ee93710, and c8d53b70 or upgrade to a stable kernel release containing those fixes
• Identify all systems running the bnxt_en driver on Broadcom NetXtreme hardware and prioritize them for kernel updates
• Validate that distribution kernels include the backport before considering the issue remediated

Patch Information

The fix sets ctxm->type from the current loop variable in bnxt_hwrm_func_backing_store_qcaps_v2() rather than from the firmware response field resp->type. The loop is restructured so that type advances from next_valid_type in the for statement, simplifying handling of non-valid and unchanged entries. The corrected code is available in the upstream commits 29732b68, 4ee93710, and c8d53b70.

Workarounds

• No supported workaround replaces applying the kernel patch; firmware updates from Broadcom may reduce exposure but do not remove the kernel-side indexing flaw
• On non-critical systems, unloading the bnxt_en driver where Broadcom NetXtreme connectivity is not required avoids exposure to the affected code path

# Verify kernel version and bnxt_en driver status
uname -r
lsmod | grep bnxt_en
modinfo bnxt_en | grep -E '^(version|filename):'
dmesg | grep -i bnxt_en