CVE-2026-64117

What it actually does

This is a Linux kernel use-after-free flaw in the mac80211 Wi-Fi subsystem, specifically in mesh networking receive/forward handling. During fast-RX processing, the kernel reads receive status data from skb->cb storage, but the mesh forwarding path can reuse that same control-buffer memory for transmit metadata and may also free the skb before the caller finishes using the receive status. As a result, the kernel may operate on zeroed or freed memory in ieee80211_prepare_and_rx_handle(), producing memory corruption, kernel crashes, or potentially attacker-influenced kernel code execution. The CVSS vector indicates adjacent-network exploitation, no privileges, no user interaction, and high confidentiality, integrity, and availability impact.

Why it matters to the business

Systems using affected Linux kernels with Wi-Fi mesh/mac80211 functionality may be exposed to attacks from nearby wireless range. Successful exploitation could crash affected devices, disrupt wireless infrastructure, or in a worst case allow compromise at kernel privilege level. This is especially relevant for embedded Linux devices, routers, access points, IoT gateways, industrial wireless nodes, and Linux endpoints that enable 802.11 mesh features. Although EPSS is currently low and there is no known KEV listing or reported ransomware use, the high severity and unauthenticated adjacent-network attack vector make patching important for any environment using wireless mesh capabilities.

How an attack unfolds

An attacker must be within wireless range of a vulnerable system using the affected mac80211 mesh receive/forwarding path. The attacker sends crafted 802.11 mesh traffic that causes the kernel to enter the unicast mesh forwarding path. In that path, the same skb control-buffer storage that previously held receive status is reused for transmit information and may be cleared or the skb may be freed when no route exists. After returning to the caller, the receive handling code still attempts to encode rate information using the stale status pointer. Depending on timing, kernel configuration, allocator behavior, and memory layout, this can result in a kernel use-after-free, producing a crash, KASAN report, or potentially exploitable memory corruption. Practical exploitation for reliable code execution would require kernel-specific knowledge and control over memory reuse, but denial of service is the most straightforward outcome.

How to fix it

Upgrade to a Linux kernel build that includes the upstream fix for mac80211 fast-RX rate capture before mesh skb control-buffer reuse. Because no exact fixed package versions were provided, use vendor advisories for the relevant distribution, appliance, router, access point, embedded platform, or kernel branch to identify the corrected kernel package. Prioritize systems with Wi-Fi enabled, 802.11s mesh mode, mesh forwarding, or mac80211-based wireless drivers. If immediate patching is not possible, reduce exposure by disabling Wi-Fi mesh functionality, disabling affected wireless interfaces where feasible, restricting mesh participation to trusted locations, reducing radio exposure, and monitoring/restricting physical proximity to critical wireless infrastructure. Reboot into the patched kernel after installation; merely installing a kernel package is not sufficient if the running kernel remains vulnerable.

How to confirm the fix worked

Confirm the running kernel, not just the installed package, contains the fix. Validate by checking the active kernel version with uname -a and comparing it against the distribution or vendor advisory for this issue. For source-based or custom kernels, verify the mac80211 change that captures/encodes the RX rate before ieee80211_rx_mesh_data() can reuse skb->cb is present in the deployed source tree or build artifacts. Confirm whether 802.11 mesh is enabled by reviewing wireless interface modes and configuration, such as iw dev output, mesh interface definitions, and network-manager/systemd-networkd/hostapd or embedded wireless configuration. After remediation, reboot and ensure the system is running the patched kernel. In test environments, regression testing should include mesh receive/forward traffic while monitoring dmesg/journalctl for KASAN, use-after-free, skb, mac80211, or ieee80211 warnings.

Typical attack path

1. Attacker positions within radio range of a vulnerable Linux system or device participating in 802.11 mesh networking.
2. Attacker identifies that the target is using a vulnerable kernel/mac80211 mesh configuration.
3. Attacker transmits crafted mesh unicast forwarding traffic that exercises ieee80211_rx_mesh_data() and the fast-RX receive path.
4. The mesh forwarding code reuses or frees skb control-buffer memory while the caller still later references receive status data.
5. The kernel reads stale, zeroed, or freed memory when encoding receive-rate statistics.
6. The target experiences kernel memory-safety failure, which may manifest as a kernel warning, KASAN use-after-free report, panic, reboot, service disruption, or potentially deeper kernel compromise.

How to detect it

Look for evidence of kernel memory-safety failures or instability on systems using mac80211 mesh networking. Primary log sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, crash dumps, pstore/ramoops, netconsole logs, and appliance-specific system logs. Search for KASAN use-after-free reports involving ieee80211_prepare_and_rx_handle, ieee80211_invoke_fast_rx, ieee80211_rx_mesh_data, sta_stats_encode_rate, mac80211, skb, or mesh forwarding. Also investigate unexplained wireless-node reboots, kernel panics, watchdog resets, sudden mesh link instability, or crashes temporally correlated with unusual nearby wireless activity. Because exploitation occurs over adjacent wireless traffic, conventional network IDS may not see the triggering frames unless wireless monitor-mode capture is in place. If wireless telemetry is available, review for bursts of 802.11 mesh data frames, abnormal unicast forwarding behavior, no-route forwarding failures, or repeated mesh peer/path anomalies preceding kernel faults. Absence of these indicators does not prove non-exploitation, especially on production kernels without KASAN or persistent crash logging.

• KASAN: slab-use-after-free
• use-after-free in ieee80211_prepare_and_rx_handle
• ieee80211_prepare_and_rx_handle
• ieee80211_invoke_fast_rx
• ieee80211_rx_mesh_data
• sta_stats_encode_rate
• mac80211
• skb->cb
• RX_QUEUED
• BUG: KASAN: slab-use-after-free
• kernel panic
• Oops:
• watchdog: BUG: soft lockup
• pstore
• ramoops

What your security team should do

• Inventory Linux systems, embedded devices, routers, access points, and IoT/OT gateways that use Wi-Fi, mac80211 drivers, or 802.11s mesh networking.
• Prioritize patching devices with mesh mode enabled or deployed in physically accessible areas where an attacker could be within wireless range.
• Apply vendor-provided kernel updates and reboot systems into the fixed kernel.
• If patching is delayed, disable 802.11 mesh mode or affected wireless interfaces where operationally acceptable.
• Increase monitoring for kernel crashes, unexpected reboots, KASAN reports, mac80211 warnings, and mesh networking anomalies on exposed devices.
• Review wireless security posture and physical proximity risk for critical infrastructure that uses mesh networking.
• Track vendor advisories for exact fixed versions, especially for downstream appliances and embedded distributions that may lag upstream kernel fixes.
• Because this is not currently listed in KEV and has low EPSS, balance urgency against exposure: internet-facing prioritization is less relevant, while radio-range exposure and mesh usage should drive priority.