CVE-2026-98307
NoneCVSS
—
EPSS
0.2%
Published
Oct 6, 2026
CISA due date
—
Cloudanix analysis
A driver bug in some WiFi hardware can slowly leak small amounts of memory each time the hardware restarts, which might eventually affect system stability.
- Exploitation
- Local Privilege
- Attacker needs
- Low Privilege
- Complexity
- Theoretical
- Impact
- Denial Of Service
- Component
- OS kernel
- Class
- Memory Corruption
- Remediation
- Patch
- Effort
- Medium
- Patch risk
- Low
What it actually does
Incomplete cleanup of per-station rx_stats and tx_stats buffers in the ath11k WiFi driver when ieee80211_restart_hw is invoked after firmware crash, leaving allocated kernel objects unreferenced.
Why it matters to the business
Gradual kernel memory exhaustion on systems using ath11k hardware after repeated firmware restarts, potentially causing performance degradation or instability during long-running WiFi operations; low exploitation risk and no ransomware association reduce urgency.
How an attack unfolds
An attacker with the ability to trigger ath11k firmware crashes and subsequent station state transitions (via mac80211 or nl80211) can cause repeated allocation without corresponding free, leading to memory leaks; no known threat actor campaigns or public exploits exist.
How to fix it
Apply a kernel update that moves arsta cleanup into the new ath11k_mac_station_cleanup function and ensures it is called from both ath11k_mac_station_remove and ath11k_mac_peer_cleanup_all.
How to confirm the fix worked
Inspect driver source for the new ath11k_mac_station_cleanup helper; run kmemleak after simulated firmware restarts and confirm absence of unreferenced 1024-byte ath11k objects.
Typical attack path
- Trigger ath11k firmware crash to invoke ieee80211_restart_hw
- Perform repeated station addition and removal operations
- Trigger kernel memory leak of arsta statistics structures
- Monitor for cumulative memory growth until resource exhaustion
How to detect it
Search kernel logs and kmemleak reports for backtraces containing ath11k_mac_op_sta_state, __kmalloc_cache_noprof, and unreferenced objects sized 1024 bytes associated with station management.
What your security team should do
- Prioritize kernel updates for ath11k users once released
- Enable kmemleak debugging on test systems using ath11k hardware
- Monitor ath11k firmware crash logs for early restart_hw events
The record
In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: cleanup arsta in ath11k_mac_peer_cleanup_all() When mac80211 removes a sta, it calls .sta_state() which in turn calls ath11k_mac_station_remove(). In that function we clean up both peers & arsta related resources. But when the firmware crashes, ath11k calls ieee80211_restart_hw(), which assumes that all driver related resources are cleaned up beforehand. This cleanup is supposedly done by ath11k_mac_peer_cleanup_all() but does not in fact free arsta->rx_stats / tx_stats. Extract the arsta cleanup from ath11k_mac_station_remove() into a new ath11k_mac_station_cleanup() and call it from both there and ath11k_mac_peer_cleanup_all(). This should handle kmemleaks reports like: unreferenced object 0xffffff801ae66400 (size 1024): comm "hostapd", pid 1306, jiffies 4295011565 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc d61c08ec): kmemleak_alloc+0x3c/0x50 __kmalloc_cache_noprof+0x2b0/0x3e0 ath11k_mac_op_sta_state+0x1dc/0xb10 drv_sta_state+0xac/0x6f8 sta_info_insert_rcu+0x314/0x5e0 sta_info_insert+0x14/0x38 ieee80211_add_station+0x10c/0x1a0 nl80211_new_station+0x3e8/0x680 genl_family_rcv_msg_doit+0xc0/0x120 genl_rcv_msg+0x1b4/0x258 netlink_rcv_skb+0x4c/0x108 genl_rcv+0x38/0x60 netlink_unicast+0x190/0x278 netlink_sendmsg+0x15c/0x370 ____sys_sendmsg+0x120/0x290 ___sys_sendmsg+0x70/0xa0 Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.9.0.1-01977-QCAHKSWPL_SILICONZ-1
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|