CVE-2026-97511: wifi: mac80211: avoid out-of-bounds access in monitor
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: avoid out-of-bounds access in monitor
In NAN, we don't know on what band the frame will be sent. Therefore we set info->band to NUMNL80211BANDS. However, this leads to out-of-bound access in ieee80211addtxradiotapheader when we try to access the sbands array.
Fix it by not accessing the array if the band is NUMNL80211BANDS. This means that we will not report rate info for legacy rate in NAN. But nobody really cares about it.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-42.42 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1016.17 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1016.18 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1015.16 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1
Event History
Frequently Asked Questions
What traffic path triggers the out-of-bounds access?
The issue is triggered when mac80211 handles NAN traffic with an unknown transmission band and attempts to add a TX radiotap header. In that case, info->band is set to NUM_NL80211_BANDS, but the monitor-header code previously used it to index the supported-bands array.
What is the operational impact of the fix?
The fix avoids looking up band data when the band value is NUM_NL80211_BANDS. As a result, legacy-rate information is not reported for NAN frames in this case.
How can I identify whether the fix is present?
Check whether the kernel source or applied stable patches includes either referenced commit: 7f087f70e020b16a5b967332ee6e937817eaa173 or 03c41203ee5a833a9d7a7630be190830cede29d8.