From: Johannes Berg <johannes@sipsolutions.net>
To: Masashi Honma <masashi.honma@gmail.com>, linux-wireless@vger.kernel.org
Subject: Re: [PATCH 1/3] Fix overread in PREQ frame processing
Date: Sat, 09 May 2026 11:17:10 +0200 [thread overview]
Message-ID: <db11380dfbe7fff538a1a052fdfc5905202981a4.camel@sipsolutions.net> (raw)
In-Reply-To: <20260508225905.29998-1-masashi.honma@gmail.com>
On Sat, 2026-05-09 at 07:59 +0900, Masashi Honma wrote:
>
> +/* IEEE Std 802.11-2016 9.4.2.113 PREQ element */
> +u8 mesh_path_parse_request_frame(const u8 *pos, u8 elen)
> +{
> + u8 target_count;
> + u8 expected_len;
> +
> + target_count = PREQ_IE_TARGET_COUNT(pos);
> + if (unlikely(target_count < 1 || target_count > 20))
> + return IEEE80211_PARSE_ERR_UNEXPECTED_ELEM;
not sure the likely/unlikely really is worth anything there - we don't
process *that* many frames.
> +
> + expected_len = 1 /* Flags */ + 1 /* Hop Count */ + 1 /* Element TTL */ +
> + 4 /* Path Discovery ID */ +
> + 6 /* Originator Mesh STA Address */ +
> + 4 /* Originator HWMP Sequence Number */ +
> + (AE_F_SET(pos) ? 6 : 0) /* Originator External Address */ +
> + 4 /* Lifetime */ + 4 /* Metric */ + 1 + /* Target Count */ +
> + target_count * (1 /* Per Target Flags */ +
> + 6 /* Target Address */ + 4 /* Target HWMP Sequence Number */);
> + if (unlikely(elen != expected_len))
> + return IEEE80211_PARSE_ERR_BAD_ELEM_SIZE;
I think there's a case to be made for doing this like many others, in an
inline in ieee80211-mesh.h, and calling it ..._size_ok() with a bool
return.
> +++ b/net/mac80211/parse.c
> @@ -547,8 +547,11 @@ _ieee802_11_parse_elems_full(struct ieee80211_elems_parse_params *params,
> elems->awake_window = (void *)pos;
> break;
> case WLAN_EID_PREQ:
> - elems->preq = pos;
> - elems->preq_len = elen;
> + elem_parse_failed = mesh_path_parse_request_frame(pos, elen);
> + if (likely(!elem_parse_failed)) {
that would also fix the build issue here if mesh isn't compiled in.
(and also here, not sure about likely/unlikely, doesn't really seem
worth it, and under attack maybe the failure becomes likely?)
johannes
next prev parent reply other threads:[~2026-05-09 9:17 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <8f0a2488540f4a65ea4d837a06225a27a10cc305.camel@sipsolutions.net>
2026-05-08 22:59 ` [PATCH 1/3] Fix overread in PREQ frame processing Masashi Honma
2026-05-08 22:59 ` [PATCH 2/3] Fix overread in PREP " Masashi Honma
2026-05-08 22:59 ` [PATCH 3/3] Fix PERR " Masashi Honma
2026-05-09 9:17 ` Johannes Berg [this message]
2026-05-09 23:41 ` [PATCH 1/3] Fix overread in PREQ " Masashi Honma
2026-05-09 23:41 ` [PATCH 2/3] Fix overread in PREP " Masashi Honma
2026-05-09 23:41 ` [PATCH 3/3] Fix PERR " Masashi Honma
2026-05-11 7:47 ` [PATCH 1/3] Fix overread in PREQ " Johannes Berg
2026-05-11 8:58 ` Masashi Honma
2026-05-11 9:01 ` Johannes Berg
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=db11380dfbe7fff538a1a052fdfc5905202981a4.camel@sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
--cc=masashi.honma@gmail.com \
/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