From: Takashi Iwai <tiwai@suse.de>
To: Pengpeng Hou <pengpeng@iscas.ac.cn>
Cc: Johannes Berg <johannes.berg@intel.com>,
linux-wireless@vger.kernel.org, libertas-dev@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] wifi: libertas: reject short monitor TX frames
Date: Fri, 02 Oct 2026 18:00:29 +0200 [thread overview]
Message-ID: <877bk0ytwi.wl-tiwai@suse.de> (raw)
In-Reply-To: <20260704011140.37639-1-pengpeng@iscas.ac.cn>
On Sat, 04 Jul 2026 03:11:40 +0200,
Pengpeng Hou wrote:
>
> In monitor mode, lbs_hard_start_xmit() casts skb->data to a
> radiotap TX header, skips that header, and then copies the 802.11
> destination address from offset 4 in the remaining frame. The
> generic length check only rejects zero-length and oversized skbs, so
> a short monitor frame can be read past the end of the skb data.
>
> Require enough bytes for the radiotap TX header and the destination
> address field before using the monitor-mode header layout.
>
> Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
> ---
> drivers/net/wireless/marvell/libertas/tx.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> --- a/drivers/net/wireless/marvell/libertas/tx.c
> +++ b/drivers/net/wireless/marvell/libertas/tx.c
> @@ -117,6 +117,13 @@
> if (priv->wdev->iftype == NL80211_IFTYPE_MONITOR) {
> struct tx_radiotap_hdr *rtap_hdr = (void *)skb->data;
>
> + if (skb->len < sizeof(*rtap_hdr) + 4 + ETH_ALEN) {
> + lbs_deb_tx("tx err: short monitor frame %u\n", skb->len);
> + dev->stats.tx_dropped++;
> + dev->stats.tx_errors++;
> + goto free;
> + }
> +
> /* set txpd fields from the radiotap header */
> txpd->tx_control = cpu_to_le32(convert_radiotap_rate_to_mv(rtap_hdr->rate));
>
>
>
Now this commit is included in the stable trees, and the review for
distro kernel indicated some bugs.
The place you jump with goto-free is outside the priv->driver_lock
spinlock, while jumping to free follows the spin_unlock_irqrestore():
```
free:
dev_kfree_skb_any(skb);
}
unlock:
spin_unlock_irqrestore(&priv->driver_lock, flags);
wake_up(&priv->waitq);
return ret;
}
```
So this patch introduced an unbalanced spinlock.
Moreover, at that point, priv->tx_pending_len is set to -1. Then
netif queues won't be woken up because priv->tx_pending_len isn't
restored -- which may lead to permanently blocking transmission.
I guess this fix needs to be revisited or reverted.
thanks,
Takashi
prev parent reply other threads:[~2026-10-02 16:00 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-04 1:11 Pengpeng Hou
2026-10-02 16:00 ` Takashi Iwai [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=877bk0ytwi.wl-tiwai@suse.de \
--to=tiwai@suse.de \
--cc=johannes.berg@intel.com \
--cc=libertas-dev@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=pengpeng@iscas.ac.cn \
/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®