From: Johannes Berg <johannes@sipsolutions.net>
To: Devin Wittmayer <lucid_duck@justthetip.ca>
Cc: Felix Fietkau <nbd@nbd.name>,
linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH wireless] wifi: mac80211: refuse to make a monitor active when it has no queue
Date: Fri, 04 Sep 2026 12:18:59 +0200 [thread overview]
Message-ID: <efe435ed41cd5943a3fd60901d90f2e2087495a4.camel@sipsolutions.net> (raw)
In-Reply-To: <20260824003656.27049-1-lucid_duck@justthetip.ca>
On Sun, 2026-08-23 at 17:36 -0700, Devin Wittmayer wrote:
> commit 8105f9b8a887 ("mac80211: allocate TXQs for active monitor
> interfaces") reserved a TXQ for active monitors, because drivers using TXQ
> expect every interface handed to them to have one. It covers only
> interfaces created active: vif.txq is assigned in ieee80211_txq_init()
> from ieee80211_if_add(), and cannot be added later.
>
> MONITOR_FLAG_ACTIVE can still be set afterwards.
> ieee80211_set_mon_options() refuses that while the interface is up, but
> while it is down it just stores the flag. Such an interface then reaches
> the driver with vif->txq NULL, and ath9k resolves its multicast node's
> tids through that pointer unchecked:
>
> BUG: kernel NULL pointer dereference, address: 0000000000000066
> RIP: 0010:ath_tx_node_init+0x49/0x170 [ath9k]
> ath9k_add_interface+0x10c/0x140 [ath9k]
> drv_add_interface+0x54/0x250 [mac80211]
> ieee80211_do_open+0x32f/0x800 [mac80211]
>
> Two commands from a user with CAP_NET_ADMIN reach it:
>
> iw dev <iface> set monitor active
> ip link set <iface> up
>
> The fault happens with RTNL held, so it is never released and all later
> netlink operations block.
>
> Refuse the promotion when there is no queue to give.
>
> Fixes: 79af1f866193 ("mac80211: avoid allocating TXQs that won't be used")
> Cc: stable@vger.kernel.org
> Signed-off-by: Devin Wittmayer <lucid_duck@justthetip.ca>
> ---
> Reproduces on mac80211_hwsim, no hardware needed: create a monitor, take it
> down, make it active and bring it up, and the driver gets a NULL vif->txq.
> One created with flags active gets a real one. With the patch the first is
> refused, the second still works, and an interface created active, set to
> none and back to active, is still accepted. Same on an MT7922.
>
> Only drivers advertising NL80211_FEATURE_ACTIVE_MONITOR reach this, since
> cfg80211 refuses the flag otherwise. ath9k, mt7603 and mt76x02 deref
> vif->txq unchecked. mt7615, mt7915, mt7921, mt7925 and mt7996 test it
> first.
>
> Where it faults today, refusing costs nothing. On the drivers that check,
> I could not test whether a promoted interface actually works, so that is
> where a regression would show.
>
> Reserving a queue for every monitor instead would make the promotion work
> rather than refuse it, and would also cover a passive monitor reaching the
> driver under NO_VIRTUAL_MONITOR. That undoes 79af1f866193 deliberately, so
> I did not assume it. Happy to write it if you prefer.
I really gain nothing from reading LLM output all day long.
The fix seems legit, but please don't let LLMs write commit messages and
comments.
johannes
prev parent reply other threads:[~2026-09-04 10:19 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-24 0:36 Devin Wittmayer
2026-09-04 10:18 ` Johannes Berg [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=efe435ed41cd5943a3fd60901d90f2e2087495a4.camel@sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=lucid_duck@justthetip.ca \
--cc=nbd@nbd.name \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®