CVE-2026-98699: wifi: mac80211: fix mesh fast xmit path deletion UAF
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: fix mesh fast xmit path deletion UAF
meshfasttxcache() stores raw meshpath pointers. Path deletion flushes the cache and then frees the path with kfreercu(), but a lookup that already holds the path can insert a new cache entry after the flush. The cache then points at freed memory.
Set MESHPATHDELETED before flushing, and skip inserting a cache entry if the path or MPP path is already deleted. Check this under the cache walk lock so it is ordered with the flush. Use WRITEONCE() for the deletion flag updates because the cache check reads flags without taking statelock.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.6.160 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.12.113 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.18.56 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 7.2.10 - Compensating control
Fix mac80211 mesh fast xmit path deletion handling by setting MESH_PATH_DELETED with WRITE_ONCE() before flushing the cache, checking the deletion flag under the cache walk lock so it is ordered with the flush, and skipping cache insertion when the mesh path or MPP path is already deleted.
Event History
Frequently Asked Questions
Which systems are exposed to this use-after-free condition?
Linux kernel systems using mac80211 mesh networking with the mesh fast transmit path are exposed. The issue concerns mesh path cache entries created while mesh paths are being deleted.
What concurrent activity is required for the flaw to occur?
A mesh path deletion must race with a lookup that already holds the path. The deletion flushes the fast-transmit cache, but the concurrent lookup can otherwise add a new cache entry referencing the path after it has been scheduled for RCU freeing.
How can I tell whether a kernel includes the fix?
Check whether the kernel contains any of the referenced stable commits: 0117f1aa189495e6f1ff608681678817995aee39, 128e800a41270ab197b1cc8043637a2924865608, or 93da3ec938bfdcfb3899428f04c6d0c56fe32952. The fix marks mesh paths as deleted before cache flushing and prevents cache insertion for deleted mesh or MPP paths.