CVE-2026-68409 in Linux
Summary
by MITRE • 08/10/2026
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: defer link RX stats percpu free to RCU
sta_remove_link() frees a removed MLO link's RX stats percpu buffer right away, but defers only the link container to RCU:
sta_info_free_link(&alloc->info); kfree_rcu(alloc, rcu_head);
The RX fast path reads link_sta under rcu_read_lock and writes the percpu stats. A reader that resolved link_sta before the removal keeps the pointer. The container stays alive from the kfree_rcu, so the read still works. But the percpu block it points to is already freed. This needs uses_rss. That is when pcpu_rx_stats exists.
The full STA teardown frees the deflink stats only after synchronize_net(). The link removal path had no such barrier. The race is hard to win in practice, but the free should still wait for RCU.
Free the link together with its data from a single RCU callback, so the percpu block is reclaimed only after readers drain.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/10/2026
This vulnerability exists within the linux kernel's mac80211 wireless subsystem where improper synchronization during mobile link object (MLO) link removal creates a potential race condition leading to use-after-free scenarios. The issue occurs in the sta_remove_link() function which handles cleanup of removed MLO links by freeing the RX stats percpu buffer immediately while deferring only the link container to RCU mechanism through kfree_rcu(). This asynchronous approach creates a timing window where readers accessing the link_sta pointer under rcu_read_lock may still hold references to memory that has already been freed, specifically when the pcpu_rx_stats structure exists and is being accessed by the fast path RX processing. The problem stems from the discrepancy between how full STA teardown handles cleanup versus the link removal path, where the former properly waits for synchronize_net() before freeing deflink stats while the latter lacks this necessary barrier.
The technical flaw manifests as a race condition between the RX fast path and the cleanup process where the percpu buffer containing RX statistics is freed prematurely relative to when RCU readers have finished accessing it. This creates a scenario where memory access violations can occur when the fast path attempts to write to freed percpu statistics, particularly impacting systems using uses_rss functionality. The vulnerability is classified as a use-after-free condition that can lead to system instability, data corruption, or potential privilege escalation depending on exploitation circumstances, with the timing window being difficult to exploit in practice but still represent a legitimate security concern.
The operational impact of this vulnerability extends beyond simple memory management issues into potential system stability and security implications. When exploited, the race condition could cause kernel crashes through memory access violations during wireless packet processing, potentially leading to denial of service attacks against wireless infrastructure. The vulnerability affects wireless networking performance and reliability across various linux distributions that utilize the mac80211 subsystem for wireless management. This issue aligns with CWE-416 use after free and CWE-362 concurrent execution using shared resource vulnerabilities, and maps to ATT&CK technique T1059.005 for system service exploitation through kernel-level memory corruption.
The recommended mitigation strategy involves modifying the link removal process to ensure that both the link container and its associated percpu data are freed together within a single RCU callback mechanism. This approach guarantees that the percpu block containing RX statistics is only reclaimed after all RCU readers have drained their references, effectively eliminating the race condition by maintaining proper synchronization between memory allocation and deallocation phases. The fix requires coordination between the RCU subsystem and the wireless driver's cleanup mechanisms to ensure that all readers complete processing before any memory in the percpu buffer is freed, thereby preventing use-after-free conditions while maintaining system performance characteristics of the wireless subsystem.