CVE-2026-46163

What it actually does

This vulnerability is an improper input validation flaw in the Linux kernel b43legacy wireless driver receive path. The driver trusts a firmware-controlled encryption key index and only performs a non-enforcing warning when the index is outside the valid dev->key[] bounds. In production builds, an invalid index can therefore cause an out-of-bounds read from kernel memory. Depending on surrounding memory layout and code paths, this can lead to kernel memory disclosure, use of unintended key-related structures, driver instability, or potentially broader kernel compromise. The CVSS vector indicates local attack requirements with low complexity and low privileges, no user interaction, and high confidentiality, integrity, and availability impact.

Why it matters to the business

Systems using affected Linux kernels with the b43legacy Wi-Fi driver and compatible legacy Broadcom wireless hardware may be exposed to local privilege escalation, sensitive memory disclosure, or kernel crashes. The operational risk is highest for laptops, embedded systems, kiosks, industrial devices, or legacy Linux endpoints where this driver is present and untrusted local users or code can interact with the wireless stack. The vulnerability is not currently listed in CISA KEV, has low EPSS, and no public exploit maturity is reported, which lowers immediate internet-scale exploitation concern, but kernel-level impact makes remediation important during normal patch cycles.

How an attack unfolds

An attacker first needs local access or the ability to run code with low privileges on a Linux system using the affected b43legacy driver. The attacker then triggers receive-path processing in the vulnerable driver while causing the firmware-controlled key index to exceed the valid number of configured keys. Because the existing check is only a warning and does not stop processing in production kernels, the driver continues and reads outside the intended key array. The attacker may use repeated attempts to leak adjacent kernel memory, influence driver behavior, or destabilize the kernel. Successful exploitation could expose sensitive kernel data, corrupt expected security assumptions around wireless key handling, or cause a denial of service through a kernel fault or crash.

How to fix it

Apply a Linux kernel update from the operating system or device vendor that includes the b43legacy fix enforcing the key-index bounds check and dropping frames with invalid indices. No exact fixed package versions were provided, so use vendor advisories for the affected distribution, kernel branch, or appliance firmware to identify the corrected release. Where immediate patching is not possible, reduce exposure by disabling or blacklisting the b43legacy driver if the hardware is not required, removing legacy Broadcom Wi-Fi devices from sensitive systems, restricting local shell access, and preventing untrusted users or workloads from interacting with host wireless interfaces. Example mitigations include unloading the module with modprobe -r b43legacy where safe and adding a modprobe blacklist entry for b43legacy, followed by reboot or initramfs regeneration as required by the distribution.

How to confirm the fix worked

Confirm remediation by verifying the running kernel package is at or above the vendor-fixed version and that the vendor changelog includes the b43legacy receive-path key-index bounds-check fix. Validate whether the driver is in use with commands such as lsmod | grep b43legacy, modinfo b43legacy, lspci -k, and dmesg logs referencing b43legacy. If the driver is not required, confirm it cannot be loaded after mitigation by checking lsmod, modprobe --showconfig, and boot-time kernel logs. For source-based or custom kernels, confirm the b43legacy_rx() path drops frames when the firmware-provided key index is greater than or equal to the maximum key count rather than only issuing a warning.

Typical attack path

1. Identify a Linux system running an affected kernel with the b43legacy wireless driver loaded or available.
2. Obtain local low-privileged execution on the system.
3. Interact with the wireless subsystem or driver receive path in a way that causes a firmware-controlled key index to be invalid.
4. Trigger b43legacy_rx() processing with the out-of-range key index.
5. Abuse the non-enforcing bounds check to cause an out-of-bounds read from the driver key array.
6. Use the resulting memory disclosure, abnormal driver behavior, or crash condition to further the attack or disrupt the system.

How to detect it

To assess whether exploitation may have occurred, review kernel and system logs for b43legacy driver warnings, receive-path errors, kernel oops messages, panics, general protection faults, or crashes around wireless activity. Relevant sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, crash dumps, kdump/vmcore artifacts, and endpoint telemetry showing module load or unload events. Because this is an out-of-bounds read in kernel driver code, exploitation may leave limited direct artifacts; absence of logs does not prove absence of exploitation. Focus on systems where b43legacy was loaded and look for repeated driver warnings or crashes preceding privilege escalation activity, unexplained process credential changes, kernel taint messages, or sudden reboots. If named threat actors or campaign-specific indicators are not available, detection should be behavior- and artifact-based rather than signature-only.

• b43legacy
• b43legacy_rx
• B43legacy_WARN_ON
• WARNING: CPU:
• kernel BUG
• BUG: unable to handle kernel
• Oops:
• general protection fault
• Kernel panic
• b43legacy:
• /var/log/kern.log
• /var/log/messages
• /proc/modules
• /sys/module/b43legacy
• /etc/modprobe.d/blacklist-b43legacy.conf

What your security team should do

• Inventory Linux systems for loaded or available b43legacy driver support, prioritizing laptops, embedded systems, and legacy hardware fleets.
• Patch affected Linux kernels through the appropriate vendor channel and prioritize systems where local users, shared workloads, or untrusted code execution are possible.
• Disable or blacklist b43legacy on systems that do not require legacy Broadcom Wi-Fi support.
• Restrict local access to affected systems until patched, especially for multi-user systems and devices exposed to untrusted workloads.
• Monitor kernel logs for b43legacy warnings, crashes, or anomalous wireless-driver behavior that may indicate probing or exploitation attempts.
• For custom kernel builds, backport the upstream fix that enforces the bounds check and drops frames with invalid firmware key indices.
• Track vendor advisories because fixed versions vary by distribution and kernel maintenance branch.