High [CVE-2026-68409] defer link RX stats percpu free to RCU
This high-severity Red Hat Linux advisory covers CVE-2026-68409 affecting Red Hat Enterprise Linux 10, Red Hat Enterprise Linux 8, Red Hat Enterprise Linux 9.
Aggregated and source-linked by VulniPulse. Data sources, validation and limitations.
VulniPulse record published Record updated
Android app · Google Play
Monitor future Red Hat Linux CVEs from your phone.
Choose a whole vendor or a precise platform, then receive matching security advisories by phone notification, email, or both. Coverage follows 34 official vendor sources and 160+ reviewed platform categories.
Summary
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. When an MLO (Multi-Link Operation) link is removed, the RX statistics per-CPU buffer is freed immediately, while the link container is deferred to RCU (Read-Copy-Update).
This timing issue can lead to a use-after-free vulnerability, where a reader might still access the freed memory. While difficult to exploit in practice, this could potentially lead to system instability or denial of service.
Affected versions
No affected-version range was extracted from the source record. The vendor advisory is authoritative — check it before change work.
Official advisory · high-confidence parse· fetched 4 hours ago·verify at source
- kernel-0:6.12.0-211.53.1.el10_2
- RHSA-2026:65334
Official advisory · high-confidence parse· fetched 4 hours ago·verify at source
Mitigation checklist
- To mitigate this vulnerability, prevent the mac80211 kernel module from loading on systems where wireless networking is not required. 1. Create a configuration file to prevent the module from loading: ``` echo "install mac80211 /bin/true" > /etc/modprobe.d/disable-mac80211.conf echo "blacklist mac80211" >> /etc/modprobe.d/disable-mac80211.conf ``` 2. If the module is currently loaded, attempt to remove it: ``` modprobe -r mac80211 ``` Caveats: Disabling this module will disable wireless network interfaces relying on the mac80211 subsystem. Warning: If the mac80211 module is currently in use by active network hardware or dependent modules, unloading it will fail, and a system reboot is required for the configuration changes to take effect.
Official advisory · high-confidence parse· fetched 4 hours ago·verify at source
Discussion(0)
No comments yet. Share field notes, upgrade gotchas, or questions — verify against the vendor advisory before acting on community advice.
Sign in to join the discussion.