All of lore.kernel.org
 help / color / mirror / Atom feed
From: "HE WEI (ギカク)" <skyexpoc@gmail.com>
To: Brian Norris <briannorris@chromium.org>,
	Francesco Dolcini <francesco@dolcini.it>
Cc: "Miri Korenblit" <miriam.rachel.korenblit@intel.com>,
	"Johannes Berg" <johannes.berg@intel.com>,
	"Kalle Valo" <kvalo@kernel.org>, "Kees Cook" <kees@kernel.org>,
	linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org,
	"HE WEI (ギカク)" <skyexpoc@gmail.com>
Subject: [PATCH] wifi: mwifiex: bound uAP association event IEs to the event buffer
Date: Mon, 29 Jun 2026 21:03:33 +0900	[thread overview]
Message-ID: <20260629120333.94222-1-skyexpoc@gmail.com> (raw)

mwifiex_process_uap_event() handles EVENT_UAP_STA_ASSOC by exposing the
(re)association request IEs that the firmware copies into the event:

	sinfo->assoc_req_ies = &event->data[len];
	len = (u8 *)sinfo->assoc_req_ies - (u8 *)&event->frame_control;
	sinfo->assoc_req_ies_len = le16_to_cpu(event->len) - (u16)len;

event->len is supplied by the device firmware and is never validated,
and the subtraction is unchecked.  assoc_req_ies points into
adapter->event_body[MAX_EVENT_SIZE], a fixed-size array embedded in the
kmalloc()'d struct mwifiex_adapter.

On the ap_11n_enabled path mwifiex_set_sta_ht_cap() walks these IEs with
cfg80211_find_ie(), whose for_each_element() loop dereferences each
element header.  A firmware-reported event->len larger than the bytes
actually received makes assoc_req_ies_len describe IEs that extend past
event_body, so the walk reads out of the adapter slab object -- a
slab-out-of-bounds read (KASAN: slab-out-of-bounds in cfg80211_find_ie).
An event->len smaller than the header instead makes the int subtraction
negative, which wraps to a huge size_t when stored in assoc_req_ies_len.
The same length is handed to cfg80211_new_sta(), so a more modest
over-claim can also copy stale event_body bytes into the
NL80211_CMD_NEW_STATION notification.

A malicious or malfunctioning mwifiex device (USB/SDIO/PCIe) can deliver
such an event while the interface is in AP/uAP mode.

Validate event->len before use: reject a length that underflows the
header or that would place the IEs outside the event_body[] buffer the
event was copied into.  The bound is against event_body[MAX_EVENT_SIZE]
rather than the actually-received length because the transports store the
event differently (USB and SDIO leave the 4-byte event header in
event_skb, PCIe strips it via skb_pull), whereas event_body is the single
fixed buffer all of them copy the event into.  This is the event-path
analogue of the receive-path bounds checks added in commit 119585281617
("wifi: mwifiex: Fix OOB and integer underflow when rx packets").

Fixes: e568634ae7ac ("mwifiex: add AP event handling framework")
Signed-off-by: HE WEI (ギカク) <skyexpoc@gmail.com>
---
 .../net/wireless/marvell/mwifiex/uap_event.c   | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/drivers/net/wireless/marvell/mwifiex/uap_event.c b/drivers/net/wireless/marvell/mwifiex/uap_event.c
index 679fdae0f001..adca7da29f0f 100644
--- a/drivers/net/wireless/marvell/mwifiex/uap_event.c
+++ b/drivers/net/wireless/marvell/mwifiex/uap_event.c
@@ -126,6 +126,24 @@ int mwifiex_process_uap_event(struct mwifiex_private *priv)
 				sinfo->assoc_req_ies = &event->data[len];
 				len = (u8 *)sinfo->assoc_req_ies -
 				      (u8 *)&event->frame_control;
+
+				/*
+				 * event->len is reported by the device firmware and is not
+				 * otherwise validated.  Reject a length that underflows the
+				 * header, or that would place the association request IEs
+				 * outside the fixed-size event_body[] buffer the event was
+				 * copied into; otherwise the IE walk in
+				 * mwifiex_set_sta_ht_cap() reads past event_body and out
+				 * of the adapter slab object.
+				 */
+				if (le16_to_cpu(event->len) < len ||
+				    (u8 *)&event->frame_control + le16_to_cpu(event->len) >
+				    adapter->event_body + MAX_EVENT_SIZE) {
+					mwifiex_dbg(adapter, ERROR,
+						    "invalid STA assoc event length\n");
+					kfree(sinfo);
+					return -1;
+				}
 				sinfo->assoc_req_ies_len =
 					le16_to_cpu(event->len) - (u16)len;
 			}
-- 
2.54.0


             reply	other threads:[~2026-06-29 12:03 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-29 12:03 HE WEI (ギカク) [this message]
2026-07-10  7:21 ` [PATCH] wifi: mwifiex: bound uAP association event IEs to the event buffer Francesco Dolcini
2026-07-10  7:41   ` Johannes Berg
2026-07-10 10:44     ` skyexpoc
2026-07-10 14:23     ` Francesco Dolcini

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=20260629120333.94222-1-skyexpoc@gmail.com \
    --to=skyexpoc@gmail.com \
    --cc=briannorris@chromium.org \
    --cc=francesco@dolcini.it \
    --cc=johannes.berg@intel.com \
    --cc=kees@kernel.org \
    --cc=kvalo@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=miriam.rachel.korenblit@intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.