CVE-2026-46152

What it actually does

This is a race condition in the Linux kernel mac80211 Wi-Fi stack fast receive path. A per-packet receive result variable in ieee80211_invoke_fast_rx() was incorrectly declared static, causing concurrent receive processing paths to share the same state. Under parallel RX activity, one caller can overwrite another caller’s rx_result between ieee80211_rx_mesh_data() and the subsequent switch on the result. This can cause packets that were already queued or consumed to be processed again by ieee80211_rx_8023(), or cause packets that should continue processing to be treated as queued. Because this occurs in kernel networking code, successful exploitation could potentially affect confidentiality, integrity, and availability through packet misclassification, memory-safety side effects, kernel instability, or unintended traffic handling, though no public exploit is currently reported.

Why it matters to the business

Organizations using Linux systems with affected wireless/mac80211 functionality could face risk of system crashes, network disruption, or unintended packet processing when exposed to malicious or malformed nearby Wi-Fi traffic. The attack vector is adjacent-network rather than internet-routable, so exploitation generally requires an attacker to be within radio range of the target Wi-Fi interface. Systems such as laptops, embedded Linux devices, routers, IoT gateways, and mesh-capable wireless deployments may be more exposed than servers without active Wi-Fi. The CVSS score is high, but EPSS is currently low and the issue is not listed in CISA KEV, so remediation should be prioritized for Wi-Fi-enabled Linux assets, especially those operating in untrusted physical locations or using mesh/monitor/AP-style wireless roles.

How an attack unfolds

An attacker must be within wireless range of a vulnerable Linux device using the mac80211 stack. They generate conditions that cause concurrent receive handling, particularly around fast-RX and mesh data processing. Because ieee80211_invoke_fast_rx() uses a shared static rx_result variable, two parallel RX invocations can interfere with each other. By carefully timing or flooding crafted wireless traffic, the attacker attempts to overwrite the shared result value between the point where ieee80211_rx_mesh_data() decides how a packet was handled and the later switch statement that acts on that decision. If successful, the kernel may process a packet through the wrong path, such as passing an already consumed or queued packet into ieee80211_rx_8023(), or prematurely treating a packet as queued. The practical outcome may range from anomalous wireless behavior and dropped or duplicated packets to kernel instability or other security-relevant side effects, depending on driver, hardware, kernel build, and traffic conditions. No public exploit maturity is currently indicated.

How to fix it

Apply vendor kernel updates that include the mac80211 fix changing the fast-RX rx_result from static shared storage to a per-invocation automatic variable. Because no fixed package versions were provided, track updates from the relevant Linux distribution, kernel vendor, appliance vendor, or device OEM for this CVE or for the upstream mac80211 change described as dropping the stray static from fast-RX rx_result. Prioritize patching Wi-Fi-enabled laptops, mobile workstations, embedded systems, routers, access points, mesh devices, and any Linux systems operating in untrusted RF environments. Where immediate patching is not possible, reduce exposure by disabling unused Wi-Fi interfaces, disabling mesh/AP/monitor modes where not required, preferring wired networking for sensitive systems, restricting physical access to areas near critical wireless devices, and using wireless IDS/monitoring to detect anomalous high-rate or malformed 802.11 traffic. Reboot into the patched kernel after installation; merely installing kernel packages is insufficient if the system continues running the vulnerable kernel.

How to confirm the fix worked

Confirm the system is running a vendor kernel build that contains the mac80211 patch for ieee80211_invoke_fast_rx() using distribution advisories, package changelogs, or source inspection. Validate that the running kernel, not only the installed kernel package, is updated by checking uname -a and the distribution package manager. If source is available, confirm that the rx_result variable in ieee80211_invoke_fast_rx() is not declared static. Inventory systems for active Wi-Fi interfaces and mac80211-based drivers using commands such as iw dev, rfkill list, lspci -k, lsusb, and lsmod to identify wireless exposure. After patching and rebooting, perform regression testing of Wi-Fi connectivity, mesh/AP functions if used, and kernel stability under normal wireless traffic. For appliances or embedded devices, confirm the vendor firmware release notes explicitly include the kernel/mac80211 fix or a kernel version known to contain it.

Typical attack path

1. Identify a Linux target with an active Wi-Fi interface using the mac80211 subsystem.
2. Move within radio range of the target wireless interface or wireless mesh/AP environment.
3. Generate high-volume or carefully timed 802.11 traffic to induce concurrent receive processing in the fast-RX path.
4. Trigger interaction between ieee80211_rx_mesh_data() and ieee80211_invoke_fast_rx() where the shared static rx_result can be overwritten by another RX invocation.
5. Cause the kernel to take an incorrect packet-processing branch, such as reprocessing a consumed packet or treating a packet as queued.
6. Attempt to convert the incorrect packet handling into denial of service, traffic manipulation, information exposure, or other kernel-level impact.

How to detect it

Detection should focus on evidence of attempted wireless-layer triggering and resulting kernel/mac80211 instability. Review system journals, dmesg, kern.log, syslog, and crash dump repositories for mac80211, cfg80211, wireless driver, RX path, kernel oops, panic, soft lockup, use-after-free, page fault, or interface reset messages around periods of unusual Wi-Fi activity. On systems with wireless IDS, AP controller logs, or RF monitoring, look for high-volume frame bursts, abnormal mesh data traffic, malformed 802.11 frames, repeated association/disassociation events, deauthentication floods, or unusual traffic from nearby unknown radios. Correlate wireless instability with endpoint kernel logs and crash times. There are no reliable CVE-specific network IOCs because exploitation would occur at the 802.11 frame-processing layer and may vary by hardware and driver. For forensic triage, preserve full journal logs, kernel ring buffer output, vmcore/kdump artifacts, wireless driver logs, and any packet captures from monitor-mode sensors covering the incident window.

• ieee80211_invoke_fast_rx
• ieee80211_rx_mesh_data
• ieee80211_rx_8023
• mac80211
• cfg80211
• kernel: BUG:
• kernel: Oops:
• kernel panic
• soft lockup
• hard LOCKUP
• WARNING: CPU:
• general protection fault
• unable to handle kernel NULL pointer dereference
• wlan0: deauthenticated
• wlan0: disassociated
• wlan0: reset
• wlan0: failed to stop TX DMA
• phy0:
• /var/log/kern.log
• /var/log/syslog
• /var/log/messages
• /var/crash/
• /var/lib/systemd/coredump/

What your security team should do

• Inventory Linux assets with active Wi-Fi interfaces, especially laptops, embedded devices, routers, APs, mesh nodes, and systems in public or untrusted physical locations.
• Prioritize kernel or firmware updates for Wi-Fi-enabled Linux systems; ensure systems reboot into the patched kernel after updates.
• For systems that do not require wireless networking, disable Wi-Fi in the OS, firmware, or hardware controls to remove the adjacent-network attack surface.
• Monitor distribution and device-vendor advisories for exact fixed kernel package versions and backported patches, since fixed versions were not provided in the input.
• Increase wireless monitoring in sensitive locations for unusual 802.11 floods, malformed frames, mesh traffic anomalies, or repeated deauthentication/association instability that could indicate attempts to trigger receive-path edge cases.
• Review kernel logs for wireless driver/mac80211 warnings, crashes, soft lockups, oopses, or sudden interface resets on affected systems.
• Treat unexplained kernel crashes or Wi-Fi instability on unpatched systems as potentially security-relevant and preserve logs, crash dumps, and wireless telemetry for investigation.
• Because EPSS is currently low and there is no KEV listing or known public exploit, align broad remediation with normal kernel patch cycles, but accelerate remediation for exposed wireless infrastructure and high-risk mobile fleets.