[PATCH v2 0/2] staging: rtl8723bs: fix OOB write in HT_caps_handler and OOB read in OnAssocRsp

[PATCH v2 0/2] staging: rtl8723bs: fix OOB write in HT_caps_handler and OOB read in OnAssocRsp

[Alexandru Hossu]

v2, addressing Greg's feedback on 1/2. Greg, please drop your patch
and take this one instead.

Changes from v1:
 - 1/2: switch from early return to min_t() truncation, so APs that
   send an oversized HT Caps element are handled gracefully rather
   than rejected outright (Greg KH)

2/2 is unchanged from v1.

Alexandru Hossu (2):
  staging: rtl8723bs: fix OOB write in HT_caps_handler()
  staging: rtl8723bs: fix OOB read in OnAssocRsp() IE loop

 drivers/staging/rtl8723bs/core/rtw_mlme_ext.c  | 4 ++++
 drivers/staging/rtl8723bs/core/rtw_wlan_util.c | 3 ++-
 2 files changed, 6 insertions(+), 1 deletion(-)

-- 
2.53.0

[PATCH v2 1/2] staging: rtl8723bs: fix OOB write in HT_caps_handler()

[Alexandru Hossu]

HT_caps_handler() iterates pIE->length bytes and writes into
HT_caps.u.HT_cap[], which is a fixed 26-byte array (sizeof struct
HT_caps_element). Because pIE->length is a raw u8 from an over-the-air
802.11 AssocResponse frame and is never validated, a malicious AP can set
it up to 255, causing up to 229 bytes of out-of-bounds writes into
adjacent fields of struct mlme_ext_info.

Truncate the iteration count to the size of HT_caps.u.HT_cap using
min_t() so that data from a longer-than-expected IE is silently ignored
rather than written out of bounds, preserving interoperability with APs
that pad the element.

Fixes: 554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver")
Cc: stable@vger.kernel.org
Signed-off-by: Alexandru Hossu <hossu.alexandru@gmail.com>
---
 drivers/staging/rtl8723bs/core/rtw_wlan_util.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8723bs/core/rtw_wlan_util.c b/drivers/staging/rtl8723bs/core/rtw_wlan_util.c
index e0d73c267786..3247565f41bd 100644
--- a/drivers/staging/rtl8723bs/core/rtw_wlan_util.c
+++ b/drivers/staging/rtl8723bs/core/rtw_wlan_util.c
@@ -936,7 +936,8 @@ void HT_caps_handler(struct adapter *padapter, struct ndis_80211_var_ie *pIE)
 
 	pmlmeinfo->HT_caps_enable = 1;
 
-	for (i = 0; i < (pIE->length); i++) {
+	for (i = 0; i < min_t(unsigned int, pIE->length,
+			       sizeof(pmlmeinfo->HT_caps.u.HT_cap)); i++) {
 		if (i != 2) {
 			/* Commented by Albert 2010/07/12 */
 			/* Got the endian issue here. */
-- 
2.53.0

[PATCH v2 2/2] staging: rtl8723bs: fix OOB read in OnAssocRsp() IE loop

[Alexandru Hossu]

The IE parsing loop in OnAssocRsp() advances by (pIE->length + 2) each
iteration but only guards on i < pkt_len. When a malicious AP sends an
AssocResponse whose last IE has only one byte remaining in the frame
(the element_id byte lands at pkt_len-1), the loop reads pIE->length
from pframe[pkt_len], which is one byte past the allocated receive buffer.

Additionally, even when the header bytes are in bounds, pIE->length
itself can extend the data window beyond pkt_len, silently passing a
truncated IE to the handler functions.

Add two guards at the top of the loop body:
  1. Break if fewer than sizeof(*pIE) bytes remain (can't read header).
  2. Break if the IE's declared data extends past pkt_len.

Fixes: 554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver")
Cc: stable@vger.kernel.org
Signed-off-by: Alexandru Hossu <hossu.alexandru@gmail.com>
---
 drivers/staging/rtl8723bs/core/rtw_mlme_ext.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c b/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c
index c646dc2a1741..68ce422305ed 100644
--- a/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c
+++ b/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c
@@ -1406,7 +1406,11 @@ unsigned int OnAssocRsp(struct adapter *padapter, union recv_frame *precv_frame)
 	/* to handle HT, WMM, rate adaptive, update MAC reg */
 	/* for not to handle the synchronous IO in the tasklet */
 	for (i = (6 + WLAN_HDR_A3_LEN); i < pkt_len;) {
+		if (i + sizeof(*pIE) > pkt_len)
+			break;
 		pIE = (struct ndis_80211_var_ie *)(pframe + i);
+		if (i + sizeof(*pIE) + pIE->length > pkt_len)
+			break;
 
 		switch (pIE->element_id) {
 		case WLAN_EID_VENDOR_SPECIFIC:
-- 
2.53.0

Re: [PATCH v2 1/2] staging: rtl8723bs: fix OOB write in HT_caps_handler()

[Dan Carpenter]

On Mon, Apr 27, 2026 at 10:17:47AM +0200, Alexandru Hossu wrote:
> HT_caps_handler() iterates pIE->length bytes and writes into
> HT_caps.u.HT_cap[], which is a fixed 26-byte array (sizeof struct
> HT_caps_element). Because pIE->length is a raw u8 from an over-the-air
> 802.11 AssocResponse frame and is never validated, a malicious AP can set
> it up to 255, causing up to 229 bytes of out-of-bounds writes into
> adjacent fields of struct mlme_ext_info.
> 
> Truncate the iteration count to the size of HT_caps.u.HT_cap using
> min_t() so that data from a longer-than-expected IE is silently ignored
> rather than written out of bounds, preserving interoperability with APs
> that pad the element.
> 
> Fixes: 554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver")
> Cc: stable@vger.kernel.org
> Signed-off-by: Alexandru Hossu <hossu.alexandru@gmail.com>
> ---

We need a little change log here.  I was hoping you would provide
a link to the AI review in the changelog.

I feel like the AI review is probabl wrong.  In this case the
original code corrupted memory so the code didn't "work" before, it
corrupted memory.  But I'm interested to see the AI review.

regards,
dan carpenter

Re: [PATCH v2 1/2] staging: rtl8723bs: fix OOB write in HT_caps_handler()

[Alexandru Hossu]

On Mon, Apr 27, 2026 at 11:17 AM, Dan Carpenter wrote:
> We need a little change log here.  I was hoping you would provide
> a link to the AI review in the changelog.

Hi Dan,

Sorry about the missing changelog, will add it in v3.

For the AI review link, I don't have a direct link to the bot output. What I know is from Greg's reply in the v1 thread on lore.kernel.org, where he said both his fix and mine would break things on some systems according to the review bot and asked me to use truncation instead. I went with min_t() specifically because he asked for it.

You're right that technically early return would have been strictly better than the original, the original was already writing out of bounds so it wasn't working to begin with. But since Greg asked for truncation I kept it that way.

Thank you.

Alexandru

Re: [PATCH v2 1/2] staging: rtl8723bs: fix OOB write in HT_caps_handler()

[Dan Carpenter]

On Mon, Apr 27, 2026 at 02:28:39AM -0700, Alexandru Hossu wrote:
> On Mon, Apr 27, 2026 at 11:17 AM, Dan Carpenter wrote:
> > We need a little change log here.  I was hoping you would provide
> > a link to the AI review in the changelog.
> 
> Hi Dan,
> 
> Sorry about the missing changelog, will add it in v3.
> 
> For the AI review link, I don't have a direct link to the bot output.
> What I know is from Greg's reply in the v1 thread on lore.kernel.org,

What about a link to the email on lore?

> where he said both his fix and mine would break things on some systems
> according to the review bot and asked me to use truncation instead.
> I went with min_t() specifically because he asked for it.
> 
> You're right that technically early return would have been strictly
> better than the original, the original was already writing out of
> bounds so it wasn't working to begin with. But since Greg asked for
> truncation I kept it that way.

This is the path of least resistance, but it's better to push back
on bad advice from AI.  Greg won't be offended.  And if he still
doesn't like after you push back then you can still do the min_t()
version.  Both versions are fine really, but I generally go with
the stricter one when it doesn't break anything that wasn't already
very broken.

Better to use umin() instead of min_t(), btw.

regards,
dan carpenter

Re: [PATCH v2 1/2] staging: rtl8723bs: fix OOB write in HT_caps_handler()

[Greg KH]

On Mon, Apr 27, 2026 at 12:48:38PM +0300, Dan Carpenter wrote:
> On Mon, Apr 27, 2026 at 02:28:39AM -0700, Alexandru Hossu wrote:
> > On Mon, Apr 27, 2026 at 11:17 AM, Dan Carpenter wrote:
> > > We need a little change log here.  I was hoping you would provide
> > > a link to the AI review in the changelog.
> > 
> > Hi Dan,
> > 
> > Sorry about the missing changelog, will add it in v3.
> > 
> > For the AI review link, I don't have a direct link to the bot output.
> > What I know is from Greg's reply in the v1 thread on lore.kernel.org,
> 
> What about a link to the email on lore?

Sorry, I was on a plane with no connectivity to look it up, here's the
AI review for my patch:
	https://sashiko.dev/#/patchset/2026041408-grill-mahogany-d1e3%40gregkh

> > where he said both his fix and mine would break things on some systems
> > according to the review bot and asked me to use truncation instead.
> > I went with min_t() specifically because he asked for it.
> > 
> > You're right that technically early return would have been strictly
> > better than the original, the original was already writing out of
> > bounds so it wasn't working to begin with. But since Greg asked for
> > truncation I kept it that way.
> 
> This is the path of least resistance, but it's better to push back
> on bad advice from AI.  Greg won't be offended.  And if he still
> doesn't like after you push back then you can still do the min_t()
> version.  Both versions are fine really, but I generally go with
> the stricter one when it doesn't break anything that wasn't already
> very broken.

Agreed, it takes a lot to offend me these days :)

thanks,

greg k-h