The Linux kernel project released a fix for an out-of-bounds read vulnerability in the b43legacy Broadcom Wi‑Fi driver on May 28, 2026. Tracked as CVE-2026-46163, the flaw earned a CVSS 3.1 base score of 7.8 (High), though the actual risk depends entirely on whether ancient Broadcom hardware is present. The patch is tiny: it turns a diagnostic warning into an enforced frame drop when firmware supplies an invalid key index, closing a memory‑access gap that has existed since kernel 2.6.24.

The Flaw and the Fix: One Conditional, Years in the Making

Inside the b43legacy driver’s receive path, a function called b43legacy_rx() processes incoming Wi‑Fi frames. Part of that processing looks up a cryptographic key index supplied by the device’s firmware. The index is used to fetch state from an array named dev->key[]. The problem: the firmware‑provided value was never properly validated against the maximum number of keys the driver actually supports (dev->max_nr_keys).

Developers had recognized the risk. The code already contained a B43legacy_WARN_ON macro that would log a warning if the index exceeded the allowed range. But in production kernels—builds that most users and distributions ship—that warning is non‑fatal. It prints a message, then allows the driver to continue right into the out‑of‑bounds read. A warning is not a guardrail; it’s a note that something went wrong after the train has left the track.

The fix, backported to multiple kernel stable trees, replaces passive concern with active defense. The patched driver now checks the index explicitly, and if it’s invalid, it drops the frame immediately. No memory access outside the key array. No undefined behavior. The change amounts to a single conditional branch, but it redefines the trust boundary between the kernel and the firmware.

Who Is Actually Affected?

This is not a Windows vulnerability. The b43legacy driver lives inside the Linux kernel, not in Microsoft’s networking stack. But in the real world, Windows‑centric environments often run Linux somewhere, and that’s where the exposure hides.

Windows Users Who Dual‑Boot or Use Linux Live USBs
If you keep a Linux partition on your laptop, or occasionally boot a live USB stick for diagnostics, recovery, or hardware testing, your system may load the b43legacy driver automatically when it detects compatible Wi‑Fi hardware. Most modern laptops ship with Intel, Qualcomm, MediaTek, or newer Broadcom chips that use entirely different drivers, but older machines—especially refurbished enterprise laptops from the late 2000s and early 2010s—often carry Broadcom BCM43xx adapters. When you boot Linux on that hardware, the vulnerable code could be active. A patch in the kernel doesn’t help you until you update your installed Linux distribution and reboot into the new kernel.

Linux Administrators and Fleet Managers
For teams that manage Linux endpoints, the first step is inventory. Run lsmod | grep b43legacy or check if modinfo b43legacy returns anything. Most enterprise deployments won’t see it, but if you repurpose old desktops as firewall boxes, kiosks, or network monitors, you might be surprised. Even if the driver isn’t currently loaded, the module may be present and auto‑loaded when a matching device appears. The vulnerability is local by nature—an attacker needs proximity to trigger it over Wi‑Fi—but that local vector still matters in shared office spaces, labs, and public areas.

Embedded and Appliance Vendors
Linux powers countless routers, access points, IoT gateways, and industrial devices, many of which still rely on low‑cost Broadcom Wi‑Fi chips from the BCM43xx era. These devices often run stripped‑down kernels and receive firmware updates from the vendor rather than from upstream distributions. If your appliance vendor hasn’t shipped a kernel update that includes the CVE‑2026‑46163 fix, the device remains vulnerable. The patch timeline for such devices can stretch months or years, so this is a classic long‑tail problem.

Pure Windows Shops
If you run Windows exclusively, with no Linux installations, no dual‑booting, and no bootable Linux media, there is no direct exposure. Microsoft’s own Wi‑Fi drivers have their own attack surface, but this particular bug does not cross over. That said, the lessons about firmware trust extend to all platforms.

A Long Tail of Legacy Drivers

The b43legacy driver entered the mainline kernel with version 2.6.24, released in January 2008. It was written to support Broadcom’s older 802.11b/g chipsets that couldn’t use the more modern b43 driver. Seventeen years later, it’s still compiled and shipped by every major Linux distribution—not because anyone expects it to handle cutting‑edge performance, but because Linux’s hardware support promise means old adapters should just work.

That promise is a double‑edged sword. It keeps perfectly usable hardware out of landfills and lets hobbyists, schools, and resource‑constrained parts of the world run current software on old machines. But it also means the kernel’s attack surface includes code paths that haven’t been aggressively maintained or security‑reviewed in years. When a researcher or a maintainer finally looks closely, they often find that assumptions baked into the code no longer hold up against modern threat models.

CVE-2026-46163 didn’t appear in isolation. It mirrors a companion fix for the newer b43 driver, which suffered from the same firmware‑controlled key index issue. The fact that both drivers had identical, long‑standing trust flaws suggests a systemic oversight: driver authors perceived firmware as a trusted companion rather than an untrusted input source. Once the b43 patched was merged, maintainers naturally audited b43legacy and found the same gap.

What to Do Now: Patch Advice for Every Camp

For Linux Desktop and Server Users
Use your distribution’s standard update mechanism. A list of patched stable kernel series includes 5.10.258, 5.15.209, 6.1.175, 6.6.140, 6.12.88, 6.18.30, and 7.0.7. If your distribution packages a kernel older than these, check its security advisory page; most enterprise distros backport fixes without bumping the version number. For example, Red Hat and Ubuntu often assign their own update IDs. After updating, reboot to activate the new kernel.

For dual‑booting Windows users
Boot into your Linux installation and run the update process. Do not assume that because you mostly use Windows, the Linux side is safe—especially if it auto‑connects to Wi‑Fi networks. If you haven’t touched your Linux partition in months, now is the time to apply patches.

For administrators of mixed environments
Don’t forget about rescue sticks and diagnostic USBs. Many IT toolkits include a Linux live image (like SystemRescue or Ubuntu Live). Those images are often built with generic kernels that include the b43legacy module. When booted on older hardware, they can become a temporarily vulnerable node on your network. Update your toolkit images regularly.

For embedded and appliance owners
Check with your vendor. If the device uses a Broadcom BCM4306, 4309, 4318, or similar chip, it likely depends on b43legacy. Ask whether a firmware update that includes the CVE‑2026‑46163 fix is planned, and what the timeline looks like. If the device is out of support and still deployed, consider replacing it or isolating it on a dedicated VLAN.

For everyone
No special workarounds are necessary. The vulnerability cannot be exploited if the driver isn’t handling Wi‑Fi frames. Turning off Wi‑Fi on an affected Linux system would reduce exposure, but simply updating the kernel is the correct fix. There is no need to manually patch driver source code or fiddle with kernel module parameters.

The Bigger Picture: Why Tiny Driver Patches Still Matter

CVE-2026-46163 will not dominate tech headlines. It will be noted, patched, and forgotten by most. Yet it exemplifies a quiet, ongoing shift in kernel security culture: treating driver code as a hostile‑input boundary. Every new fuzzer, every static analysis run, every backport of a one‑line fix is an incremental hardening of the kernel’s vast attack surface.

Out‑of‑bounds reads are not always catastrophic, but they should never be dismissed. In this case, an attacker with local Wi‑Fi proximity could craft a frame that forces the driver to read adjacent memory. Depending on what sits next to the key array—pointers, kernel heap metadata, dangling crypto material—the impact could range from a system crash to information disclosure that aids a more sophisticated exploit chain. The CVSS 3.1 score of 7.8 reflects the high potential for confidentiality, integrity, and availability impact, albeit with local access required.

For Windows users, the lesson is transferable. All complex operating systems depend on drivers that parse data from devices. Whether it’s a Windows Wi‑Fi driver, a graphics driver, or a Thunderbolt controller, the principle holds: firmware and hardware are not inherently trustworthy. Bounds checks must be enforced, not merely logged. Microsoft’s own driver development practices and its recent push for Rust in the kernel reflect the same recognition that old habits die hard.

The b43legacy fix also underscores a maintenance challenge. Linux supports more hardware than any other general‑purpose OS, and that support is a feature, not a bug. But it comes with the responsibility to keep even the dusty corners of the codebase secure. As the kernel community continues to retire truly unused drivers (like the floppy driver that was removed in 2025) and refactors others, we should expect more of these narrow, late‑discovered patches.

Outlook

Expect this vulnerability to be fully absorbed into distribution updates within weeks. The patch is trivial, well‑understood, and already in multiple stable trees. The real story will unfold over months, as appliance vendors trickle out updates and asset managers inventory old hardware. For most people, the next security scare will come from somewhere else. But the principle—treat every firmware‑supplied value as a potential weapon—will remain at the center of kernel hardening for years to come.