CVE-2026-64223: wifi: mac80211: consume only present negotiated TTLM maps
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: consume only present negotiated TTLM maps
ieee80211tidtolinkmapsizeok() validates negotiated TTLM elements against the number of link-map entries indicated by linkmappresence. ieee80211parsenegttlm() must consume the same layout.
The parser advanced its cursor for every TID, including TIDs whose presence bit is clear and therefore have no map bytes in the element. A sparse map can then make a later present TID read past the validated element.
The bad bytes land in negttlm->{up,down}link[tid] but are gated by validlinks before being applied to driver state, so a peer cannot turn the read into a policy change. Under KUnit + KASAN with an exact-sized element allocation the OOB read is reported as a slab-out-of-bounds; whether the same trigger fires under the production RX path depends on surrounding allocator state.
Advance the cursor only when the current TID has a map present.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Update ieee80211_parse_neg_ttlm() so it consumes only the same negotiated TTLM layout validated by ieee80211_tid_to_link_map_size_ok(): for each TID, advance the parser cursor only if the TID’s negotiated TTLM map is present (presence bit set), so bytes for non-present TIDs are not parsed/consumed.
Linux kernel (mac80211 / ieee80211_parse_neg_ttlm) cursor advancement for negotiated TTLM TIDs = Advance the cursor only when the current TID has a map present; do not advance for TIDs where the presence bit is clear
Event History
Frequently Asked Questions
What would an attacker need to do to trigger the out-of-bounds read?
An attacker would need to act as a Wi-Fi peer and supply a negotiated TTLM element with a sparse link_map_presence layout, where some TIDs have their presence bit clear. The malformed layout can cause parsing of a later present TID to read beyond the validated element.
Can this issue be used to change Wi-Fi link or traffic policy?
The described out-of-bounds bytes are stored in negotiated TTLM link fields, but valid_links gates them before they are applied to driver state. Based on the provided analysis, a peer cannot turn this read into a policy change.
Is a production system definitely affected when given the malformed element?
No. A slab-out-of-bounds read was reported under KUnit with KASAN when using an exact-sized element allocation, but whether the same trigger occurs on the production receive path depends on surrounding allocator state.
What is the relevant remediation?
Use a kernel version containing the fix that advances the parser cursor only for TIDs that have a link-map presence bit set. The supplied stable-kernel references identify commits carrying that correction.