CVE-2026-98700: wifi: mac80211: set info->band for 802.3 encap offload frames
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: set info->band for 802.3 encap offload frames
Unlike the 802.11 TX paths, ieee802118023xmit() does not set info->band from the channel context on non-MLD interfaces. It stays at 0, so ieee80211gettxrates() uses the wrong band for these frames.
Set it the same way as ieee80211buildhdr(): drop the frame if there is no channel context, and leave the band at 0 on MLD interfaces.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.12.113-1 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 7.2.10-1 - Upgrade
Upgrade
debian/linux-6.12to a version that resolves this vulnerability.Fixed in 6.12.113-1~deb12u1 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.12.115-2Fixed in 7.2.12-1Fixed in 7.2.15-1 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 5.10.273 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 5.15.224 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.1.191 - 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 - Upgrade
Upgrade
azurelinux/kernelto a version that resolves this vulnerability.Fixed in 6.6.161.1-1
Event History
Frequently Asked Questions
Which traffic path is affected?
The issue affects 802.3 encapsulation offload frames transmitted through mac80211 on non-MLD interfaces. In that path, the band can remain set to 0, causing transmit-rate selection to use the wrong band.
Are MLD interfaces handled the same way?
No. The fix leaves the band at 0 for MLD interfaces; the missing band assignment applies to non-MLD interfaces.
What happens when no channel context is available after the fix?
The corrected behavior drops the frame when no channel context is available, matching the handling used by the 802.11 header-building path.