Look up another CVE · open CVE-2026-98331 in the interactive tracker
CVE-2026-98331
wifi: mac80211: unlist vifs when their netdev is unregistered
Published 2026-10-06 (13 days ago) by the Linux kernel CNA. Subsystem net/mac80211. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-98331 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | fixedDLA-4841-1 · 2026-10-17 · text | 6.1.190-1 | Update the kernel and reboot. DLA-4841-1 shipped the fix on 2026-10-17, in 6.1.190-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixedDSA-6568-1 · 2026-10-16 · text | 6.12.113-1 | Update the kernel and reboot. DSA-6568-1 shipped the fix on 2026-10-16, in 6.12.113-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.2.8-1 | Update the kernel and reboot. Fixed in 7.2.8-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.2.8-1 | Update the kernel and reboot. Fixed in 7.2.8-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
mac80211 only removes vifs from the local->interfaces list when an interface is removed via ieee80211_if_remove(), before it unregisters the netdev. However, it's possible for a netdev to be unregistered without going through that: When the netns that holds the wiphy is destroyed, the wiphy is supposed to move to the init_ns, but that can run into allocation failures. Then, mac80211 has an interface listed that doesn't exist, and will eventually hit BUG: failure at net/wireless/core.h:141/wiphy_to_rdev()! ... _cfg80211_unregister_wdev+0x24/0x36a [cfg80211] cfg80211_unregister_wdev+0x15/0x1d [cfg80211] ieee80211_remove_interfaces+0x1ff/0x257 [mac80211] ieee80211_unregister_hw+0x73/0x1d1 [mac80211] mac80211_hwsim_del_radio+0x114/0x166 [mac80211_hwsim] Remove the interface from the list in ->ndo_uninit if it's still around to avoid this.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
net/mac80211/iface.c
- What this is
- MAC80211MAINTAINERS section matched on net/mac80211/ · linux-wireless@vger.kernel.org · Maintained
- Kernel module
- mac80211
Check it on the machine
grep -w CONFIG_MAC80211 /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
lsmod | grep -w mac80211Prints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.
Show whether Debian builds this, per release
Debian builds this, but not on every flavour. At least one release below builds the code on some of its kernel flavours and not on others, so the answer depends on the architecture and flavour installed.
- bookwormMnot built on amd64/cloud-amd64, arm64/cloud-arm64
- trixie, forky, sidMnot built on amd64/cloud-amd64, arm64/cloud-arm64, s390x/s390x
- M
- a module where it is built at all; some flavours do not build it
- Build switch
- CONFIG_MAC80211
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-10-06 (13 days ago)source
- CVSS
- 7.0 high
CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.13%, higher than 2.4% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- net/mac80211
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 2.6.32 | 6.1.189 | a22c02863439 |
| 2.6.32 | 6.6.158 | 20a56e96a6f7 |
| 2.6.32 | 6.12.112 | b735ad1a9aca |
| 2.6.32 | 6.18.54 | d45bf731ec70 |
| 2.6.32 | 7.2.8 | 821bab0456df |
| 2.6.32 | 7.3 | eee2efd82867 |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4841-1 | 2026-10-17 | bookworm 6.1.190-1 | tracker |
| DSA-6568-1 | 2026-10-16 | trixie 6.12.113-1 | tracker |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- The trigger is local: tearing down a netns that holds a mac80211 wiphy runs cfg80211_pernet_exit()->cfg80211_switch_netns(). When dev_change_net_namespace() fails there, default_device_exit_batch() unregisters the netdev while ieee80211_uninit() leaves its sdata on local->interfaces. No WiFi frame supplies the failing state.
- AC:HAttack complexity, high
- It needs a wiphy already moved into an attacker-controlled netns (an admin step), plus a failed move back. The attacker can force the failure: an altname on the wlan netdev that clashes with an init_net name makes __dev_change_net_namespace() return -EEXIST, because cfg80211 doesn't strip altnames. The rare alternative is an allocation failure.
- PR:LPrivileges required, low
- With a phy delegated to a container, root in that user-namespace-owned netns, which is unprivileged on the host, can add the altname via RTM_NEWLINKPROP and destroy the netns. Moving a phy out of init_net yourself needs init-ns CAP_NET_ADMIN, and hwsim radios made in a user netns are deleted by hwsim_exit_net() before cfg80211 runs.
- UI:NUser interaction, none
- The container root adds the altname and exits the namespace on their own. No other user has to do anything.
- S:UScope, unchanged
- This is memory corruption in the host kernel's mac80211 interface list. Exploiting it is ordinary kernel privilege escalation within the same kernel authority; no hypervisor or IOMMU boundary is involved.
- C:HConfidentiality impact, high
- The netdev is freed via needs_free_netdev, but its sdata stays on local->interfaces. Every received frame then makes __ieee80211_rx_handle_packet() read the freed sdata through list_for_each_entry_rcu(), which gives a use-after-free read of an object an attacker can reallocate.
- I:HIntegrity impact, high
- Later removal of a neighbouring interface (list_del_rcu) and ieee80211_remove_interfaces() write into and dereference the stale sdata. That is a use-after-free write that heap reallocation could turn into memory corruption.
- A:HAvailability impact, high
- The dangling entry crashes the kernel: the commit shows a BUG in wiphy_to_rdev() reached from ieee80211_remove_interfaces() during ieee80211_unregister_hw(), and frame RX can touch freed memory.