CVE-2026-98182: wifi: mac80211: refuse to make a monitor active when it has no queue
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: refuse to make a monitor active when it has no queue
A monitor interface only gets a TXQ if it's created active, and one can't be added later. Setting the flag on a down interface is still allowed, so the driver is handed a monitor with no queue. ath9k dereferences it:
BUG: kernel NULL pointer dereference, address: 0000000000000066 RIP: 0010:athtxnodeinit+0x49/0x170 [ath9k] ath9kaddinterface+0x10c/0x140 [ath9k] drvaddinterface+0x54/0x250 [mac80211] ieee80211doopen+0x32f/0x800 [mac80211]
Reached with CAPNETADMIN by "iw dev X set monitor active" followed by "ip link set X up". RTNL is held, so netlink operations block behind it.
Refuse the flag when there is no queue to give.
Affected Software
Event History
Frequently Asked Questions
Who can trigger this issue?
An attacker needs CAP_NET_ADMIN and the ability to configure a wireless monitor interface. The documented trigger sets a monitor interface active while it is down, then brings it up.
What is the practical impact of successful exploitation?
The affected driver can dereference a NULL queue pointer, causing a kernel NULL pointer dereference. The provided crash trace identifies ath9k as a driver where this occurs.
Are systems affected by the monitor interface configuration by default?
The issue requires a specific monitor-interface state: the interface has no TXQ because it was not created active, then is marked active while down. The data does not indicate that this state exists by default.
What should be done if an update cannot be applied immediately?
Avoid setting a down monitor interface to active and subsequently bringing it up when it has no transmit queue. Restrict CAP_NET_ADMIN to trusted users, since this capability is required for the documented trigger.