CVE-2026-46122

What it actually does

This vulnerability is an out-of-bounds read in the Linux kernel b43 wireless driver receive path. The driver accepts a firmware-provided key index in b43_rx() and uses it to access the dev->key[] array, which contains 58 entries. In vulnerable kernels, the existing B43_WARN_ON check may not stop execution in production builds, so an invalid key index can cause the driver to read memory outside the intended array. Depending on kernel build, memory layout, and runtime conditions, this can lead to kernel memory disclosure, driver instability, kernel crash, or potentially assist further local privilege-escalation exploitation.

Why it matters to the business

Systems using affected Linux kernels with the b43 Broadcom wireless driver may be exposed to local kernel-level compromise or denial of service. Workstations, embedded Linux devices, and legacy systems using Broadcom 43xx Wi-Fi hardware are most relevant. Although public exploit maturity is currently reported as none, the CVSS score is high and kernel vulnerabilities can create significant operational risk because successful exploitation may compromise the entire host. This issue is not currently listed in CISA KEV and is not known to be used in ransomware campaigns.

How an attack unfolds

An attacker first needs access to a vulnerable Linux system where the b43 driver is loaded and the affected wireless hardware path is active. The attacker then triggers receive processing in the b43 driver under conditions where the firmware reports an invalid key index greater than the dev->key[] array bounds. Because the production warning check does not enforce termination of the receive path, the kernel continues and reads outside the valid key array. The attacker may use repeated triggering to cause a kernel crash, observe side effects, or potentially use the out-of-bounds read as part of a broader kernel exploitation chain. Exploitation is currently assessed as not publicly mature, and the CVSS vector indicates local access with low privileges is required.

How to fix it

Upgrade to a Linux kernel version from the relevant distribution or upstream stable branch that includes the b43 fix enforcing bounds validation on the firmware key index in b43_rx() and dropping frames with invalid key indexes. No exact fixed package versions were provided, so use vendor advisories and distribution security repositories to identify the corrected kernel package. Where immediate patching is not possible, mitigate by disabling or blacklisting the b43 driver on systems that do not require it, removing affected Broadcom 43xx Wi-Fi hardware from service, or using an alternative supported wireless adapter/driver. Reboot systems after kernel update or driver mitigation to ensure the vulnerable code is no longer loaded.

How to confirm the fix worked

Confirm that systems have booted into a patched kernel supplied by the OS vendor or upstream stable kernel that contains the b43 bounds-check fix. Verify whether the b43 module is loaded using standard module inventory tooling such as lsmod, modinfo, or endpoint management telemetry. If mitigating rather than patching, confirm the b43 module cannot load through modprobe blacklist configuration and that no active network interface is using the driver. Review package manager history and kernel build metadata to ensure the running kernel, not only the installed kernel package, is fixed. Functional validation should include confirming Wi-Fi operation remains stable or that the driver is intentionally disabled.

Typical attack path

1. Identify a Linux host running an affected kernel with the b43 wireless driver loaded.
2. Obtain low-privileged local access to the system or the ability to exercise the affected wireless receive path under local attack assumptions.
3. Trigger b43_rx() receive handling while causing the firmware-controlled key index to exceed the valid dev->key[] array range.
4. Cause the vulnerable kernel code to read outside the intended key array because the warning check is non-enforcing in production builds.
5. Use the resulting memory disclosure, instability, or crash condition for denial of service or as part of a larger kernel compromise chain.

How to detect it

There are no known public exploit indicators or threat-actor-specific artifacts for this vulnerability. Detection should focus on exposure and abnormal kernel behavior. Collect kernel logs from journald, syslog, dmesg, crash dumps, and endpoint telemetry. Look for b43 driver warnings, kernel oops or panic events, KASAN or UBSAN out-of-bounds read reports, and crashes occurring during wireless receive activity. Investigate systems where the b43 module is loaded and logs show repeated driver warnings or receive-path faults. Because successful kernel exploitation may leave few application-level traces, correlate suspicious local user activity, recent privilege changes, unexpected kernel crashes, and module-loading events around the same time.

• b43_rx
• b43
• B43_WARN_ON
• BUG: KASAN: slab-out-of-bounds
• BUG: KASAN: global-out-of-bounds
• out-of-bounds read
• kernel BUG
• Oops:
• general protection fault
• Call Trace:
• Modules linked in: b43
• b43-phy
• firmware key index
• key index

What your security team should do

• Prioritize patching Linux endpoints and embedded systems that use Broadcom 43xx Wi-Fi hardware or have the b43 kernel module loaded.
• Inventory systems for loaded b43 modules and affected wireless hardware before broad remediation to focus effort on exposed assets.
• Apply vendor kernel updates and reboot into the fixed kernel; do not rely on package installation alone.
• Where patching is delayed, blacklist or unload the b43 driver if business operations do not require it.
• Monitor kernel logs for b43-related warnings, KASAN reports, kernel oopses, or crashes around wireless receive handling.
• Treat confirmed exploitation indicators as potential kernel compromise and perform full host investigation, since kernel memory corruption issues can undermine endpoint integrity.
• Track distribution advisories for exact fixed kernel package versions because none were supplied in the input.