From: Zhao Li <enderaoelyther@gmail.com>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: Mathy Vanhoef <Mathy.Vanhoef@kuleuven.be>,
Sven Eckelmann <sven@narfation.org>,
linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
Subject: [PATCH] wifi: mac80211: recheck injected headers after removing FCS
Date: Wed, 28 Oct 2026 22:21:01 +0800 [thread overview]
Message-ID: <20261028142101.11994-1-enderaoelyther@gmail.com> (raw)
Injecting a short frame with IEEE80211_RADIOTAP_F_FCS on a monitor
interface can pass a truncated 802.11 header to transmit handlers.
ieee80211_monitor_start_xmit() validates the linear 802.11 header before
parsing radiotap. Radiotap parsing then removes the four-byte FCS without
rechecking the remaining header length. Software encryption can subtract
the larger header length and pass the resulting negative length as an
unsigned size.
Recheck the required linear header length after pulling the radiotap
header and before handing the frame to the transmit path. Require at
least addr1, which the transmit path reads even for extension frames
whose header is shorter.
LLM assistance was used to find the bug and review.
Fixes: bddc0c411a45 ("mac80211: Fix NULL ptr deref for injected rate info")
Cc: stable@vger.kernel.org
Signed-off-by: Zhao Li <enderaoelyther@gmail.com>
---
Validation: A W=1 module build with MODPOST passed. In a QEMU KASAN
guest on the declared base, six truncated data and QoS-data injections
with the FCS flag reached transmit before the change and were dropped
after it. Injections that keep a full header, including 10-byte ACK and
extension frames, were unchanged. KASAN reported nothing in either
kernel, as expected for a length check. A reproducer is available on
request.
Sparse C=2 passed. Targeted Smatch introduced no new diagnostics.
net/mac80211/tx.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 32f94761cf32..f2772b1736f0 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -2511,6 +2511,12 @@ netdev_tx_t ieee80211_monitor_start_xmit(struct sk_buff *skb,
/* remove the injection radiotap header */
skb_pull(skb, len_rthdr);
+ /* FCS removal may have shortened the 802.11 header. */
+ hdrlen = max_t(int, hdrlen,
+ offsetofend(struct ieee80211_hdr, addr1));
+ if (skb_headlen(skb) < hdrlen)
+ goto fail_rcu;
+
ieee80211_xmit(sdata, NULL, skb);
rcu_read_unlock();
base-commit: 25e73f1d6868c759c8eb56cad4e411692c5341b4
--
2.56.0
reply other threads:[~2026-10-28 14:21 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20261028142101.11994-1-enderaoelyther@gmail.com \
--to=enderaoelyther@gmail.com \
--cc=Mathy.Vanhoef@kuleuven.be \
--cc=johannes@sipsolutions.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=stable@vger.kernel.org \
--cc=sven@narfation.org \
/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