CVE-2026-64155

What it actually does

This is a Linux kernel memory-leak vulnerability in the ath11k Qualcomm Wi-Fi driver. In specific Wake-on-Wireless/WMI command error paths, the driver returns after ath11k_wmi_cmd_send(...) fails without freeing the allocated socket buffer. Repeatedly reaching that failure path can consume kernel memory over time and may lead to degraded Wi-Fi functionality, system instability, or a local denial of service through memory exhaustion. The issue is not known to provide code execution or privilege escalation by itself.

Why it matters to the business

Systems using affected Linux kernels with ath11k-supported Qualcomm Wi-Fi hardware may become unstable or unavailable if the vulnerable path is repeatedly triggered. The practical risk is disruption: laptops, embedded devices, access appliances, kiosks, or edge systems relying on Wi-Fi could experience degraded connectivity, forced reboots, or service outages. Public exploit maturity is currently reported as none, EPSS is low, and the issue is not in the CISA KEV catalog, so remediation should be handled through normal kernel update cycles unless the organization has high exposure to ath11k-based Wi-Fi devices or availability-sensitive wireless endpoints.

How an attack unfolds

An attacker would need a system running a vulnerable Linux kernel with an ath11k-supported wireless device and a way to repeatedly drive the affected Wake-on-Wireless/WMI code paths into failure. This is most plausibly achieved from local access or from a management context that can repeatedly change Wi-Fi power-management, WoW, suspend/resume, or wireless interface state. If the WMI command send fails, the vulnerable driver path leaks an skb allocation instead of freeing it. By repeatedly triggering the condition, the attacker can cause cumulative kernel memory loss until the host experiences memory pressure, network driver failure, process termination by the OOM killer, or a system hang/reboot. There is no public indication that this flaw is being exploited in the wild or used by named threat actors.

How to fix it

Apply a Linux kernel update that includes the ath11k fix for the WMI WOW error-path skb leak. If vendor kernels are used, install the relevant distribution, appliance, or device firmware update when available. If immediate patching is not possible, reduce exposure by disabling unused ath11k Wi-Fi interfaces, avoiding Wake-on-Wireless features where operationally feasible, limiting local users’ ability to modify wireless power-management settings, and monitoring systems for repeated ath11k errors or unexplained kernel memory pressure. Because no fixed package versions were provided in the input, use the kernel or distribution vendor advisory as the source of truth for exact patched versions.

How to confirm the fix worked

Confirm that the running kernel package or vendor firmware includes the ath11k WMI WOW skb leak fix. Validate the running kernel after reboot, not only the installed package. On Linux systems, check kernel version and package changelogs for the ath11k fix, and confirm ath11k hardware presence with standard PCI/driver inventory commands. Where safe, test suspend/resume or WoW-related workflows and verify that repeated failures do not cause steadily increasing unreclaimable kernel memory or recurring ath11k WMI errors. Exposure is only relevant on systems with the ath11k driver loaded or ath11k-supported Qualcomm Wi-Fi hardware present.

Typical attack path

1. Identify a Linux system using a vulnerable kernel and Qualcomm ath11k Wi-Fi hardware.
2. Obtain local access or control over operations that can repeatedly alter Wi-Fi power-management, Wake-on-Wireless, interface state, or suspend/resume behavior.
3. Trigger WMI WOW command paths while forcing or inducing ath11k_wmi_cmd_send failures.
4. Repeat the operation so each failed command leaks kernel memory.
5. Continue until kernel memory pressure causes Wi-Fi failure, system instability, OOM-killer activity, hang, or reboot.

How to detect it

Look for signs of repeated ath11k driver failures followed by kernel memory pressure or instability. Useful sources include journalctl, dmesg, /var/log/kern.log, /var/log/messages, crash dumps, kernel oops/panic logs, endpoint telemetry for reboots, and monitoring data for unreclaimable kernel memory growth. Focus on systems where the ath11k driver is loaded. Investigate clusters of ath11k WMI or WOW-related errors, suspend/resume loops, repeated Wi-Fi interface resets, OOM-killer events, page allocation failures, and unexplained reboots. Because this is a memory leak rather than a payload-execution flaw, durable forensic artifacts may be limited; absence of a file or process artifact does not rule out attempted exploitation.

• ath11k
• ath11k_wmi_cmd_send
• WMI WOW
• WOW
• failed to send WMI
• skb
• Out of memory: Killed process
• page allocation failure
• Kernel panic - not syncing
• oom-killer
• /sys/kernel/debug/ath11k
• ath11k_pci

What your security team should do

• Inventory Linux endpoints, embedded systems, and appliances using ath11k-supported Qualcomm Wi-Fi hardware.
• Prioritize kernel or vendor firmware updates for availability-sensitive wireless systems and devices that allow local users to change Wi-Fi power-management settings.
• Track vendor advisories for exact fixed kernel versions and ensure systems are rebooted into the patched kernel after update.
• Temporarily disable Wake-on-Wireless or unused Wi-Fi interfaces on systems that cannot be patched promptly.
• Monitor kernel logs for repeated ath11k WMI/WOW failures, OOM-killer activity, and unexplained reboots on systems with ath11k hardware.
• Treat this as a denial-of-service risk rather than a likely remote compromise path unless additional exploit details emerge.