CVE-2026-46125

What it actually does

CVE-2026-46125 is a Linux kernel mac80211 flaw in the cleanup path for Wi-Fi Multi-Link Operation (MLO) connection preparation failures. When an MLO connection setup fails, the virtual interface can be reset from MLD to non-MLD state while an associated station object remains linked to resources that are being removed and recreated, including debugfs entries when debugfs is enabled. This can lead to use-after-free or double-free memory corruption in kernel context. Successful exploitation could cause kernel crashes and, depending on heap state and exploitability of the corrupted object lifecycle, may allow arbitrary kernel memory access or code execution with kernel privileges.

Why it matters to the business

Systems using affected Linux kernels with Wi-Fi client functionality, especially newer Wi-Fi 7 / 802.11be MLO-capable devices, may be exposed to adjacent-network attacks from within wireless range. The most likely operational impact is device instability, kernel panic, or denial of service during wireless connection attempts; in a worst-case scenario, kernel memory corruption could compromise the entire host. The issue is not listed in CISA KEV, has no known mature public exploit, and has a low EPSS score, but the CVSS rating is high because exploitation requires no credentials or user interaction once an attacker is in radio range.

How an attack unfolds

An attacker positions themselves within Wi-Fi range of a vulnerable Linux system and interacts with the wireless connection process, for example by presenting or manipulating an MLO-capable access point or wireless exchange that causes MLO connection preparation to fail. During the failure path, mac80211 resets the virtual interface from MLD mode to non-MLD mode. In vulnerable kernels, an existing station object associated with the removed link is not deleted at the right time. If debugfs is enabled, the interface transition recreates debugfs structures while stale station-related state remains, creating a use-after-free or double-free condition in kernel memory. The attacker’s practical outcome is likely a kernel crash or device reboot, though kernel memory corruption bugs of this type can sometimes be developed into privilege escalation or code execution primitives if heap layout and timing can be controlled.

How to fix it

Apply the Linux kernel update from the relevant distribution or vendor that includes the mac80211 fix to remove the station object when MLO connection preparation fails. No exact fixed kernel version was provided in the input, so remediation should be tracked through vendor advisories for the deployed kernel branches. Prioritize updates for laptops, workstations, embedded Linux devices, and appliances with Wi-Fi 7 / MLO-capable chipsets. Where immediate patching is not possible, reduce exposure by disabling Wi-Fi on systems that do not require it, disabling MLO or Wi-Fi 7 features if supported by the driver/vendor, avoiding untrusted wireless networks, and restricting use of debugfs in production where feasible. Note that disabling debugfs may reduce one known crash path but should not be treated as a complete fix for the underlying kernel object-lifecycle bug.

How to confirm the fix worked

Confirm the running kernel build includes the vendor patch for the mac80211 station cleanup issue. Validate by checking distribution security advisories, kernel changelogs, or package metadata for the fix referencing mac80211 MLO connection preparation failure cleanup. On Linux systems, verify the active kernel with `uname -r` and ensure the installed kernel package is the patched release for that distribution. Confirm whether debugfs is mounted with `mount | grep debugfs` and whether Wi-Fi debugfs paths exist under `/sys/kernel/debug/ieee80211`. For exposure assessment, identify systems with wireless interfaces using `iw dev`, `ip link`, or hardware inventory, and prioritize those with MLO-capable drivers/chipsets. After patching, reboot into the fixed kernel and confirm the vulnerable kernel is no longer running.

Typical attack path

1. Attacker gets within adjacent wireless range of a vulnerable Linux system with an affected Wi-Fi stack.
2. Attacker triggers or influences an MLO-capable Wi-Fi connection attempt, such as by operating a crafted or malicious access point.
3. The MLO connection preparation path fails and the kernel resets the virtual interface from MLD to non-MLD mode.
4. Vulnerable mac80211 cleanup leaves a stale station object associated with a removed link.
5. debugfs-related station/interface state is removed or recreated while stale references remain.
6. The stale reference causes a kernel use-after-free or double-free condition.
7. The system may crash, reboot, or potentially suffer broader kernel compromise if the memory corruption is reliably exploitable.

How to detect it

Review kernel and system logs for signs of memory corruption or crashes occurring during Wi-Fi association, roaming, or MLO connection attempts. Useful sources include `journalctl -k`, `/var/log/kern.log`, `/var/log/messages`, `/var/log/syslog`, crash dumps, pstore, kdump/vmcore artifacts, and endpoint telemetry that records kernel panics or unexpected reboots. Focus on events containing mac80211, cfg80211, ieee80211, MLO, MLD, debugfs, station cleanup, KASAN, slab corruption, use-after-free, double-free, general protection faults, kernel BUG/Oops, or panic messages. Correlate suspicious crashes with wireless connection attempts, new or unknown nearby access points, repeated association failures, or changes in BSSID/SSID around the same time. Because there are no known public exploit artifacts and exploitation is adjacent-network, absence of file-based IOCs does not rule out attempted exploitation.

• BUG: KASAN: use-after-free
• KASAN: use-after-free
• BUG: KASAN: double-free
• double free
• use-after-free
• kernel BUG
• Oops:
• general protection fault
• slab-use-after-free
• invalid opcode: 0000
• Kernel panic
• mac80211
• cfg80211
• ieee80211
• debugfs
• /sys/kernel/debug/ieee80211
• MLO
• MLD
• wlan

What your security team should do

• Inventory Linux systems with active Wi-Fi interfaces, especially laptops, embedded devices, kiosks, and appliances using modern Wi-Fi 6E/7 chipsets.
• Prioritize vendor kernel updates for Wi-Fi-enabled systems in environments where attackers could be physically nearby, such as offices, public spaces, warehouses, campuses, and shared facilities.
• If patching is delayed, disable Wi-Fi, disable MLO/Wi-Fi 7 features where supported, or require wired networking for high-value systems.
• Avoid mounting debugfs on production systems unless operationally required; where required, restrict access to privileged administrators only.
• Monitor kernel logs for mac80211, cfg80211, debugfs, KASAN, slab allocator, use-after-free, double-free, panic, or unexpected reboot events around Wi-Fi association attempts.
• Treat unexplained kernel crashes on Wi-Fi-enabled Linux systems as potentially security-relevant until logs and wireless context are reviewed.
• Track distribution advisories because fixed versions vary by kernel branch and vendor backport policy.