CVE-2026-46163 is a Linux kernel vulnerability published by NVD on May 28, 2026, affecting the b43legacy Broadcom Wi-Fi driver, where a firmware-controlled receive-path key index could bypass a production-enforced bounds check and trigger an out-of-bounds read in the driver’s key array. The fix is small, almost boring: reject the frame when the key index is invalid. But the lesson is larger than the patch. In kernel security, the difference between a warning and a guardrail is often the difference between “we noticed” and “we stopped it.”
The vulnerable code sits in
The existing code had a warning macro,
The kernel fix changes the posture: if firmware reports an invalid key index, the driver drops the frame. That is not a dramatic mitigation, but it is the correct one. The RX path is not the place to trust a device-controlled value after it has already proved it can point past the end of the table.
There is a quiet elegance to this kind of patch. It does not invent a new subsystem, add a security framework, or rework the driver’s architecture. It simply treats a bounds check as a rule rather than a comment.
That matters because device firmware occupies an awkward place in the trust model. It is close enough to hardware that operating systems often have to accept its metadata to move packets efficiently. It is also opaque enough that treating every firmware-reported field as inherently safe is wishful thinking. Drivers live in that compromise.
In this case, the key index was controlled by firmware and could exceed
The practical exploitability is not fully established by the NVD record, and NVD had not assigned CVSS metrics at publication. That absence matters. An out-of-bounds read in a legacy Wi-Fi driver is not automatically a remote-code-execution emergency, and responsible handling requires saying so. But it is also not nothing. Reads past an array can expose adjacent memory, destabilize the driver, or become useful as part of a more complex chain depending on layout, triggering conditions, and attacker proximity.
Linux supports old hardware because users, distributions, embedded builders, refurbishers, labs, and hobbyists still run it. A Broadcom BCM43xx adapter may not be headline hardware in 2026, but the driver’s existence means the kernel still carries its attack surface. Once code ships in widely used kernels, it does not need to be fashionable to matter.
This is especially relevant for WindowsForum readers who dual-boot, maintain rescue media, operate mixed fleets, or keep Linux around for diagnostics. A vulnerability in a Linux Wi-Fi driver may not affect a stock Windows installation, but it can matter on the same physical laptop when booted into Linux, on a technician’s toolkit USB, or on a small appliance quietly using an older wireless chipset.
The industry has grown comfortable discussing “legacy” as a lifecycle problem for applications and operating systems. Hardware support deserves the same treatment. Old drivers are not just compatibility assets; they are long-lived parsers of hostile input, often written in C, often close to DMA, firmware, interrupts, and packet paths.
That parallel is revealing. The bug class was not limited to one dusty code path; it reflected a shared assumption across related Broadcom wireless driver code. Once maintainers noticed that a warning was not sufficient in one driver, it made sense to audit the sibling driver that handles older devices.
This is how many good kernel fixes happen. A narrow bug report becomes a pattern search. The patch is tiny, but the act of applying it across related code says maintainers understood the vulnerability as a design mistake rather than a single typo.
The b43legacy patch also references the original introduction of the mac80211-based legacy driver. That lineage matters because driver code can preserve assumptions for years. A warning that felt adequate in an earlier debugging context can become a security liability once the same code is evaluated under modern vulnerability discipline.
Kernel warning macros are valuable. They tell developers that an invariant has been violated, produce breadcrumbs for debugging, and sometimes reveal rare hardware or firmware behavior. But security boundaries must change control flow. If a value is too large for an array, the program must not index the array.
That distinction is easy to blur in low-level code because the culture of kernel development prizes visibility into impossible states. A developer may reasonably want a warning to fire if firmware hands back an absurd key index. But the warning cannot be the only thing standing between absurd input and memory access.
The fix for CVE-2026-46163 is therefore less about Wi-Fi than about intent. It takes an invariant that was previously documented by a warning and makes it operational. Invalid key index, frame dropped, path ends. That is what a bounds check is supposed to mean.
A plausible risk model starts with local radio proximity. Wi-Fi vulnerabilities often require an attacker to be within wireless range, able to send crafted frames, influence association state, or interact with the device under particular encryption and driver conditions. That is different from an internet-facing daemon exposed to the world, but it is not equivalent to physical access either.
The impact also depends on whether the b43legacy driver is loaded and the affected hardware is present. Most modern laptops will not use this driver. Many enterprise Linux endpoints will rely on Intel, Qualcomm, MediaTek, Realtek, or newer Broadcom stacks. Still, Linux distributions ship broad kernel driver support precisely so users do not have to think about it until a matching device appears.
The lack of an NVD score at publication should not be read as reassurance. It simply means enrichment had not caught up with the record. For now, the technically grounded assessment is modest but real: systems using b43legacy should take the fix through their normal kernel update channel, and fleet owners should not spend emergency-change capital unless they actually have affected hardware.
But Windows-centric environments are rarely Windows-only anymore. Admins boot Linux live images to recover BitLocker-adjacent data, clone disks, test hardware, run diagnostics, or operate security tooling. Developers use Linux on dual-boot laptops and in lab machines. Small businesses repurpose old PCs into routers, monitoring boxes, or workshop systems.
That is where this CVE becomes relevant to a WindowsForum audience. The risk is not that Windows Update missed a Linux driver bug. The risk is that a machine treated as “just an old spare” may be running a general-purpose Linux kernel with a legacy wireless adapter and a driver most administrators have never inventoried.
The broader lesson travels well across platforms. Windows, Linux, and macOS all depend on driver code that mediates between untrusted input and privileged kernel memory. The names of the subsystems differ, but the failure mode is familiar: metadata arrives from a lower layer, code assumes it is sane, and a bounds check turns out to be advisory instead of enforced.
Mainline and stable trees can carry the patch quickly, but distributions backport fixes into their supported kernel versions on their own schedules. Enterprise distributions often preserve older kernel version numbers while applying security patches underneath. Rolling distributions may pick up the fix through a routine kernel package update. Embedded and appliance vendors may take longer, particularly if the device is old enough to still depend on b43legacy-class hardware.
This is why version-number advice is hazardous without distribution context. A user running an enterprise kernel with an old-looking version may already be patched, while another user on an unsupported community image may not be. The right operational question is not merely “what kernel version am I on?” but “has my vendor shipped the b43legacy RX key-index bounds check fix?”
For individual Linux users, the pragmatic answer is simpler: update the kernel from the distribution’s trusted repositories and reboot into it. For administrators, check whether any assets actually bind to b43legacy, then confirm whether your supported kernel stream has incorporated the relevant stable patch.
An out-of-bounds read can leak data, influence control flow indirectly, reveal layout information, or crash a component in ways that enable denial of service. In kernel space, even small reads must be treated with suspicion because the surrounding memory may contain sensitive state, pointers, flags, or data that helps defeat mitigations elsewhere.
That does not mean every OOB read is catastrophic. It means defenders should avoid the opposite mistake of treating reads as harmless by default. The severity depends on what can be read, how reliably it can be triggered, whether the attacker can observe consequences, and whether the bug composes with other weaknesses.
CVE-2026-46163’s public description does not prove a dramatic impact. It does prove that a firmware-supplied value could drive an array access beyond the intended key table and that the kernel maintainers considered this a vulnerability worth assigning a CVE and backporting. That is enough to justify patching without panic.
That pattern is common in old driver code. Hardware and firmware are treated as quirky but mostly trusted companions. Defensive checks are added for debug visibility. Over time, the threat model changes, fuzzing improves, wireless attack research matures, and the same checks are reinterpreted as incomplete security controls.
The Linux kernel has spent years moving toward harder boundaries in parsers, drivers, and subsystem interfaces. Bounds checks have become more explicit. Sanitizers and fuzzers have made “impossible” states visible. Stable backports increasingly carry patches that look trivial but encode a stricter view of trust.
CVE-2026-46163 fits that trend. It is not a blockbuster vulnerability. It is a maintenance signal: old driver code is being revisited under a model where firmware-controlled input is not magically safe, and where a warning that lets execution continue is no longer good enough.
That promise is valuable. It keeps hardware out of landfills, enables refurbishing, supports research, and gives Linux a practical advantage over operating systems that abandon devices more aggressively. But the cost is that the kernel’s attack surface includes code paths most users will never touch and most administrators will never inventory.
Security teams often think in terms of installed packages and running services. Kernel drivers complicate that picture. A module may be present but unloaded, autoloaded only when hardware appears, or included in an initramfs that travels between machines. A live USB used for recovery may carry a broad driver set by design.
The answer is not to rip out legacy support indiscriminately. The answer is to treat legacy support as an active security product, with the same expectations of bounds checking, input validation, and timely backporting that we apply to newer code. Compatibility without maintenance is just deferred risk.
That world is gone. Firmware can be buggy, vendor-supplied, redistributed by operating systems, reverse engineered, patched, extracted, or replaced. Even when firmware is honest, the values it reports may reflect malformed input received from the air or wire. A kernel driver should not need to solve every firmware mystery, but it must validate values before using them as array indexes.
This is where CVE-2026-46163 has meaning beyond Broadcom hardware. The index was firmware-controlled. The driver had a finite key array. The only sane contract is that firmware may suggest an index, but the kernel decides whether the index is valid.
That model scales. Whether the subsystem is Wi-Fi, graphics, storage, Bluetooth, or USB, privileged host code should treat device-originated metadata as untrusted until checked. Firmware is not a security oracle. It is another input source.
Administrators should resist both extremes. Do not ignore the issue simply because the hardware is old. Do not declare a fleet emergency without evidence that affected adapters exist in the environment. The right move is targeted inventory followed by normal patch hygiene.
Linux endpoint managers can check loaded modules, hardware inventories, and distribution advisories. Security teams managing mixed environments should include bootable Linux media and lab machines in their patch thinking. Those systems are often forgotten because they are not production servers, yet they may connect to real networks and process real wireless traffic.
The fix drops invalid frames. That is the right failure mode. A malformed or inconsistent receive path event should not be allowed to drag the driver past the end of a key table just because a warning macro noticed the cliff.
A One-Line Driver Fix Exposes a Very Old Kernel Habit
The vulnerable code sits in b43legacy_rx(), the receive path for legacy Broadcom BCM43xx wireless hardware supported by Linux’s b43legacy driver. The kernel receives a frame, consults metadata supplied by firmware, and uses a key index to look up cryptographic state in dev->key[]. If that index is beyond the number of valid keys, the driver has left the safe shape of the array and entered the land of undefined assumptions.The existing code had a warning macro,
B43legacy_WARN_ON, intended to flag the bad condition. That sounds protective until you remember what warnings are for. They are diagnostics, not policy. In production builds, a warning can record that something has gone wrong while still allowing the code to continue into the risky access.The kernel fix changes the posture: if firmware reports an invalid key index, the driver drops the frame. That is not a dramatic mitigation, but it is the correct one. The RX path is not the place to trust a device-controlled value after it has already proved it can point past the end of the table.
There is a quiet elegance to this kind of patch. It does not invent a new subsystem, add a security framework, or rework the driver’s architecture. It simply treats a bounds check as a rule rather than a comment.
The Vulnerability Is Narrow, but the Trust Boundary Is Not
CVE write-ups often flatten vulnerabilities into a few phrases: out-of-bounds read, RX path, firmware-controlled index, invalid frame dropped. Those words are accurate, but they can hide the more interesting architectural boundary. The kernel is not merely parsing data from a remote peer; it is also consuming values delivered through device firmware and hardware-facing driver logic.That matters because device firmware occupies an awkward place in the trust model. It is close enough to hardware that operating systems often have to accept its metadata to move packets efficiently. It is also opaque enough that treating every firmware-reported field as inherently safe is wishful thinking. Drivers live in that compromise.
In this case, the key index was controlled by firmware and could exceed
dev->max_nr_keys. The driver already knew enough to warn about it, which is why the bug feels less like a missing insight and more like an unenforced decision. The code recognized a boundary; it just did not make crossing that boundary fatal to the current frame.The practical exploitability is not fully established by the NVD record, and NVD had not assigned CVSS metrics at publication. That absence matters. An out-of-bounds read in a legacy Wi-Fi driver is not automatically a remote-code-execution emergency, and responsible handling requires saying so. But it is also not nothing. Reads past an array can expose adjacent memory, destabilize the driver, or become useful as part of a more complex chain depending on layout, triggering conditions, and attacker proximity.
Legacy Wi-Fi Is Still Kernel Attack Surface
The word legacy does a lot of emotional work in driver names. It can make old hardware sound irrelevant, as though the vulnerable code exists only for museum machines and spare parts bins. That is a dangerous assumption in the Linux world.Linux supports old hardware because users, distributions, embedded builders, refurbishers, labs, and hobbyists still run it. A Broadcom BCM43xx adapter may not be headline hardware in 2026, but the driver’s existence means the kernel still carries its attack surface. Once code ships in widely used kernels, it does not need to be fashionable to matter.
This is especially relevant for WindowsForum readers who dual-boot, maintain rescue media, operate mixed fleets, or keep Linux around for diagnostics. A vulnerability in a Linux Wi-Fi driver may not affect a stock Windows installation, but it can matter on the same physical laptop when booted into Linux, on a technician’s toolkit USB, or on a small appliance quietly using an older wireless chipset.
The industry has grown comfortable discussing “legacy” as a lifecycle problem for applications and operating systems. Hardware support deserves the same treatment. Old drivers are not just compatibility assets; they are long-lived parsers of hostile input, often written in C, often close to DMA, firmware, interrupts, and packet paths.
The Patch Mirrors a Companion Fix in b43
CVE-2026-46163 did not emerge in isolation. The b43legacy fix follows the same pattern as a companion fix for the modern b43 Broadcom driver. In the b43 case, the firmware-controlled key index inb43_rx() could exceed the dev->key[] array size, and the warning was converted into an enforcing conditional that sends invalid frames to the drop path.That parallel is revealing. The bug class was not limited to one dusty code path; it reflected a shared assumption across related Broadcom wireless driver code. Once maintainers noticed that a warning was not sufficient in one driver, it made sense to audit the sibling driver that handles older devices.
This is how many good kernel fixes happen. A narrow bug report becomes a pattern search. The patch is tiny, but the act of applying it across related code says maintainers understood the vulnerability as a design mistake rather than a single typo.
The b43legacy patch also references the original introduction of the mac80211-based legacy driver. That lineage matters because driver code can preserve assumptions for years. A warning that felt adequate in an earlier debugging context can become a security liability once the same code is evaluated under modern vulnerability discipline.
Warnings Are Not Security Boundaries
The most important word in the CVE description is not “firmware” or “out-of-bounds.” It is “non-enforcing.” A non-enforcing check is a statement of concern, not a safety mechanism.Kernel warning macros are valuable. They tell developers that an invariant has been violated, produce breadcrumbs for debugging, and sometimes reveal rare hardware or firmware behavior. But security boundaries must change control flow. If a value is too large for an array, the program must not index the array.
That distinction is easy to blur in low-level code because the culture of kernel development prizes visibility into impossible states. A developer may reasonably want a warning to fire if firmware hands back an absurd key index. But the warning cannot be the only thing standing between absurd input and memory access.
The fix for CVE-2026-46163 is therefore less about Wi-Fi than about intent. It takes an invariant that was previously documented by a warning and makes it operational. Invalid key index, frame dropped, path ends. That is what a bounds check is supposed to mean.
The Attack Story Depends on Proximity and Hardware
For administrators, the obvious question is whether this is remotely exploitable. The honest answer is that the public record does not yet provide enough detail to make a sweeping claim. The vulnerable logic is in a Wi-Fi receive path, which naturally raises concerns about over-the-air triggering, but the CVE description emphasizes firmware-controlled key index behavior rather than a complete external exploit recipe.A plausible risk model starts with local radio proximity. Wi-Fi vulnerabilities often require an attacker to be within wireless range, able to send crafted frames, influence association state, or interact with the device under particular encryption and driver conditions. That is different from an internet-facing daemon exposed to the world, but it is not equivalent to physical access either.
The impact also depends on whether the b43legacy driver is loaded and the affected hardware is present. Most modern laptops will not use this driver. Many enterprise Linux endpoints will rely on Intel, Qualcomm, MediaTek, Realtek, or newer Broadcom stacks. Still, Linux distributions ship broad kernel driver support precisely so users do not have to think about it until a matching device appears.
The lack of an NVD score at publication should not be read as reassurance. It simply means enrichment had not caught up with the record. For now, the technically grounded assessment is modest but real: systems using b43legacy should take the fix through their normal kernel update channel, and fleet owners should not spend emergency-change capital unless they actually have affected hardware.
Windows Users Are Adjacent, Not Immune
A vulnerability in a Linux kernel driver is not a Windows vulnerability. That line should be clear. CVE-2026-46163 does not mean Microsoft’s Wi-Fi stack is affected, and it does not apply to Windows drivers simply because the hardware vendor name is Broadcom.But Windows-centric environments are rarely Windows-only anymore. Admins boot Linux live images to recover BitLocker-adjacent data, clone disks, test hardware, run diagnostics, or operate security tooling. Developers use Linux on dual-boot laptops and in lab machines. Small businesses repurpose old PCs into routers, monitoring boxes, or workshop systems.
That is where this CVE becomes relevant to a WindowsForum audience. The risk is not that Windows Update missed a Linux driver bug. The risk is that a machine treated as “just an old spare” may be running a general-purpose Linux kernel with a legacy wireless adapter and a driver most administrators have never inventoried.
The broader lesson travels well across platforms. Windows, Linux, and macOS all depend on driver code that mediates between untrusted input and privileged kernel memory. The names of the subsystems differ, but the failure mode is familiar: metadata arrives from a lower layer, code assumes it is sane, and a bounds check turns out to be advisory instead of enforced.
Distribution Timing Will Matter More Than the CVE Page
The NVD record is a useful anchor, but it is not where most users will actually receive protection. Linux users will get the fix through stable kernel updates, distribution kernels, vendor advisories, or appliance firmware bundles. That path is slower and messier than the pristine commit history suggests.Mainline and stable trees can carry the patch quickly, but distributions backport fixes into their supported kernel versions on their own schedules. Enterprise distributions often preserve older kernel version numbers while applying security patches underneath. Rolling distributions may pick up the fix through a routine kernel package update. Embedded and appliance vendors may take longer, particularly if the device is old enough to still depend on b43legacy-class hardware.
This is why version-number advice is hazardous without distribution context. A user running an enterprise kernel with an old-looking version may already be patched, while another user on an unsupported community image may not be. The right operational question is not merely “what kernel version am I on?” but “has my vendor shipped the b43legacy RX key-index bounds check fix?”
For individual Linux users, the pragmatic answer is simpler: update the kernel from the distribution’s trusted repositories and reboot into it. For administrators, check whether any assets actually bind to b43legacy, then confirm whether your supported kernel stream has incorporated the relevant stable patch.
Small Memory Bugs Still Deserve Serious Triage
There is a temptation to dismiss out-of-bounds reads as second-tier vulnerabilities, especially when compared with write primitives, use-after-free conditions, or authentication bypasses. That instinct is understandable and sometimes correct. It is also a common way to underestimate how exploit chains are built.An out-of-bounds read can leak data, influence control flow indirectly, reveal layout information, or crash a component in ways that enable denial of service. In kernel space, even small reads must be treated with suspicion because the surrounding memory may contain sensitive state, pointers, flags, or data that helps defeat mitigations elsewhere.
That does not mean every OOB read is catastrophic. It means defenders should avoid the opposite mistake of treating reads as harmless by default. The severity depends on what can be read, how reliably it can be triggered, whether the attacker can observe consequences, and whether the bug composes with other weaknesses.
CVE-2026-46163’s public description does not prove a dramatic impact. It does prove that a firmware-supplied value could drive an array access beyond the intended key table and that the kernel maintainers considered this a vulnerability worth assigning a CVE and backporting. That is enough to justify patching without panic.
The Real Fix Is Cultural, Not Just Conditional
The most interesting part of this issue is that the code already had an assertion-like warning. Somebody had considered the invalid-index case. The vulnerability survived because recognition was not paired with enforcement.That pattern is common in old driver code. Hardware and firmware are treated as quirky but mostly trusted companions. Defensive checks are added for debug visibility. Over time, the threat model changes, fuzzing improves, wireless attack research matures, and the same checks are reinterpreted as incomplete security controls.
The Linux kernel has spent years moving toward harder boundaries in parsers, drivers, and subsystem interfaces. Bounds checks have become more explicit. Sanitizers and fuzzers have made “impossible” states visible. Stable backports increasingly carry patches that look trivial but encode a stricter view of trust.
CVE-2026-46163 fits that trend. It is not a blockbuster vulnerability. It is a maintenance signal: old driver code is being revisited under a model where firmware-controlled input is not magically safe, and where a warning that lets execution continue is no longer good enough.
The Kernel’s Long Tail Is a Security Product
Linux’s hardware support is one of its triumphs. It is also one of its burdens. Every old wireless adapter, storage controller, webcam, TV tuner, and laptop hotkey device preserved in the tree represents a promise to users and a maintenance obligation to everyone else.That promise is valuable. It keeps hardware out of landfills, enables refurbishing, supports research, and gives Linux a practical advantage over operating systems that abandon devices more aggressively. But the cost is that the kernel’s attack surface includes code paths most users will never touch and most administrators will never inventory.
Security teams often think in terms of installed packages and running services. Kernel drivers complicate that picture. A module may be present but unloaded, autoloaded only when hardware appears, or included in an initramfs that travels between machines. A live USB used for recovery may carry a broad driver set by design.
The answer is not to rip out legacy support indiscriminately. The answer is to treat legacy support as an active security product, with the same expectations of bounds checking, input validation, and timely backporting that we apply to newer code. Compatibility without maintenance is just deferred risk.
Firmware Is Not a Priesthood
The firmware angle is especially important because it challenges a habit that predates modern supply-chain anxiety. For years, operating systems frequently treated device firmware as a specialized black box: not fully trusted, exactly, but trusted enough that drivers would accept its bookkeeping unless obvious hardware faults appeared.That world is gone. Firmware can be buggy, vendor-supplied, redistributed by operating systems, reverse engineered, patched, extracted, or replaced. Even when firmware is honest, the values it reports may reflect malformed input received from the air or wire. A kernel driver should not need to solve every firmware mystery, but it must validate values before using them as array indexes.
This is where CVE-2026-46163 has meaning beyond Broadcom hardware. The index was firmware-controlled. The driver had a finite key array. The only sane contract is that firmware may suggest an index, but the kernel decides whether the index is valid.
That model scales. Whether the subsystem is Wi-Fi, graphics, storage, Bluetooth, or USB, privileged host code should treat device-originated metadata as untrusted until checked. Firmware is not a security oracle. It is another input source.
The Practical Response Is Boring, Which Is Good
For most users, there is no need for theatrical mitigation. If you do not have old Broadcom BCM43xx hardware using b43legacy, this CVE is mostly a kernel-maintenance story. If you do, the correct response is to install the kernel update that includes the enforcing bounds check and reboot.Administrators should resist both extremes. Do not ignore the issue simply because the hardware is old. Do not declare a fleet emergency without evidence that affected adapters exist in the environment. The right move is targeted inventory followed by normal patch hygiene.
Linux endpoint managers can check loaded modules, hardware inventories, and distribution advisories. Security teams managing mixed environments should include bootable Linux media and lab machines in their patch thinking. Those systems are often forgotten because they are not production servers, yet they may connect to real networks and process real wireless traffic.
The fix drops invalid frames. That is the right failure mode. A malformed or inconsistent receive path event should not be allowed to drag the driver past the end of a key table just because a warning macro noticed the cliff.
The Lesson Hiding in Broadcom’s Old Receive Path
The concrete takeaways are modest, but they are exactly the kind that prevent small driver flaws from becoming larger operational surprises. CVE-2026-46163 is best understood as a low-drama kernel hardening fix with a real trust-boundary lesson attached.- CVE-2026-46163 affects the Linux kernel’s b43legacy Broadcom Wi-Fi driver, not the Windows networking stack.
- The vulnerable condition involves a firmware-controlled key index in the receive path exceeding the driver’s valid key range.
- The previous warning was not enough because production code could continue toward an out-of-bounds read after the warning condition.
- The kernel fix enforces the check by dropping frames that carry invalid key indexes.
- The practical exposure depends on whether a system actually uses legacy Broadcom hardware with the b43legacy driver.
- The right response is to take the relevant kernel update through trusted distribution channels rather than trying to hand-patch driver code.
References
- Primary source: NVD / Linux Kernel
Published: 2026-05-29T01:02:55-07:00
NVD - CVE-2026-46163
nvd.nist.gov
- Security advisory: MSRC
Published: 2026-05-29T01:02:55-07:00
Original feed URL
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Related coverage: spinics.net
Re: [PATCH v2 2/2] wifi: b43: fix OOB read from hardware key index in b43_rx() — Linux Kernel
Linux Kernel: Re: [PATCH v2 2/2] wifi: b43: fix OOB read from hardware key index in b43_rx()
www.spinics.net
- Related coverage: lists.debian.org
- Related coverage: kernel.googlesource.com
- Related coverage: support.bull.com
