[PATCH] staging: rtl8723bs: fix OOB write in HT_caps_handler()

[PATCH] staging: rtl8723bs: fix OOB write in HT_caps_handler()

[Greg Kroah-Hartman]

HT_caps_handler() loops up to pIE->length, the IE length byte taken
directly from an over-the-air association response, and uses the counter
to index pmlmeinfo->HT_caps.u.HT_cap[26].  A malicious AP can supply an
HT capabilities IE with a length byte up to 255, AND-writing into
adjacent fields of struct mlme_ext_info.  This is reachable in station
mode (the default) via OnAssocRsp.

HT_info_handler() already rejects oversized IEs so do the same thing in
HT_caps_handler() to resolve this.

Fixes: 554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver")
Assisted-by: gregkh_clanker_t1000
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/staging/rtl8723bs/core/rtw_wlan_util.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/staging/rtl8723bs/core/rtw_wlan_util.c b/drivers/staging/rtl8723bs/core/rtw_wlan_util.c
index 3242978da36c..a2e016c6a01f 100644
--- a/drivers/staging/rtl8723bs/core/rtw_wlan_util.c
+++ b/drivers/staging/rtl8723bs/core/rtw_wlan_util.c
@@ -932,6 +932,9 @@ void HT_caps_handler(struct adapter *padapter, struct ndis_80211_var_ie *pIE)
 	if (phtpriv->ht_option == false)
 		return;
 
+	if (pIE->length > sizeof(pmlmeinfo->HT_caps))
+		return;
+
 	pmlmeinfo->HT_caps_enable = 1;
 
 	for (i = 0; i < (pIE->length); i++) {
-- 
2.53.0

Re: [PATCH] staging: rtl8723bs: fix OOB write in HT_caps_handler()

[Luka Gejak]

On Tue Apr 14, 2026 at 7:19 PM CEST, Greg Kroah-Hartman wrote:
> HT_caps_handler() loops up to pIE->length, the IE length byte taken
> directly from an over-the-air association response, and uses the counter
> to index pmlmeinfo->HT_caps.u.HT_cap[26].  A malicious AP can supply an
> HT capabilities IE with a length byte up to 255, AND-writing into
> adjacent fields of struct mlme_ext_info.  This is reachable in station
> mode (the default) via OnAssocRsp.
>
> HT_info_handler() already rejects oversized IEs so do the same thing in
> HT_caps_handler() to resolve this.
>
> Fixes: 554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver")
> Assisted-by: gregkh_clanker_t1000
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
>  drivers/staging/rtl8723bs/core/rtw_wlan_util.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/drivers/staging/rtl8723bs/core/rtw_wlan_util.c b/drivers/staging/rtl8723bs/core/rtw_wlan_util.c
> index 3242978da36c..a2e016c6a01f 100644
> --- a/drivers/staging/rtl8723bs/core/rtw_wlan_util.c
> +++ b/drivers/staging/rtl8723bs/core/rtw_wlan_util.c
> @@ -932,6 +932,9 @@ void HT_caps_handler(struct adapter *padapter, struct ndis_80211_var_ie *pIE)
>  	if (phtpriv->ht_option == false)
>  		return;
>  
> +	if (pIE->length > sizeof(pmlmeinfo->HT_caps))
> +		return;
> +
>  	pmlmeinfo->HT_caps_enable = 1;
>  
>  	for (i = 0; i < (pIE->length); i++) {

Good catch. Trusting pIE->length blindly from an unauthenticated 
association response is a classic oob write vector. Since HT_cap is 
fixed-size within the mlme_ext_info struct, this is a clear remote heap
corruption risk if a malicious AP is in range.
Reviewed-by: Luka Gejak <luka.gejak@linux.dev>

Re: [PATCH] staging: rtl8723bs: fix OOB write in HT_caps_handler()

[Greg Kroah-Hartman]

On Tue, Apr 14, 2026 at 08:39:59PM +0200, Luka Gejak wrote:
> On Tue Apr 14, 2026 at 7:19 PM CEST, Greg Kroah-Hartman wrote:
> > HT_caps_handler() loops up to pIE->length, the IE length byte taken
> > directly from an over-the-air association response, and uses the counter
> > to index pmlmeinfo->HT_caps.u.HT_cap[26].  A malicious AP can supply an
> > HT capabilities IE with a length byte up to 255, AND-writing into
> > adjacent fields of struct mlme_ext_info.  This is reachable in station
> > mode (the default) via OnAssocRsp.
> >
> > HT_info_handler() already rejects oversized IEs so do the same thing in
> > HT_caps_handler() to resolve this.
> >
> > Fixes: 554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver")
> > Assisted-by: gregkh_clanker_t1000
> > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > ---
> >  drivers/staging/rtl8723bs/core/rtw_wlan_util.c | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/staging/rtl8723bs/core/rtw_wlan_util.c b/drivers/staging/rtl8723bs/core/rtw_wlan_util.c
> > index 3242978da36c..a2e016c6a01f 100644
> > --- a/drivers/staging/rtl8723bs/core/rtw_wlan_util.c
> > +++ b/drivers/staging/rtl8723bs/core/rtw_wlan_util.c
> > @@ -932,6 +932,9 @@ void HT_caps_handler(struct adapter *padapter, struct ndis_80211_var_ie *pIE)
> >  	if (phtpriv->ht_option == false)
> >  		return;
> >  
> > +	if (pIE->length > sizeof(pmlmeinfo->HT_caps))
> > +		return;
> > +
> >  	pmlmeinfo->HT_caps_enable = 1;
> >  
> >  	for (i = 0; i < (pIE->length); i++) {
> 
> Good catch. Trusting pIE->length blindly from an unauthenticated 
> association response is a classic oob write vector. Since HT_cap is 
> fixed-size within the mlme_ext_info struct, this is a clear remote heap
> corruption risk if a malicious AP is in range.
> Reviewed-by: Luka Gejak <luka.gejak@linux.dev>

And it's wrong, as per the AI review :(

Also, you have trailing whitespace on your review comments :)

thanks,

greg k-h

[PATCH] staging: rtl8723bs: fix OOB write in HT_caps_handler()

[Alexandru Hossu]

Hi Greg,

Here is the fix.

Alexandru

---

The loop in HT_caps_handler() iterates up to pIE->length times, but
HT_cap[] is only 26 bytes. pIE->length comes from the HT Capability IE
in the association response and can be up to 255. This lets a rogue AP
write up to 229 bytes past the array using a bitwise AND into adjacent
struct fields.

Clamp the iteration count to the array size.

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 4f41f88908d7..e271d1e395a5 100644
--- a/drivers/staging/rtl8723bs/core/rtw_wlan_util.c
+++ b/drivers/staging/rtl8723bs/core/rtw_wlan_util.c
@@ -935,7 +935,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. */

Re: [PATCH] staging: rtl8723bs: fix OOB write in HT_caps_handler()

[Dan Carpenter]

On Fri, May 15, 2026 at 03:42:03AM -0700, Alexandru Hossu wrote:
> Hi Greg,
> 
> Here is the fix.
> 
> Alexandru
> 
> ---
> 
> The loop in HT_caps_handler() iterates up to pIE->length times, but
> HT_cap[] is only 26 bytes. pIE->length comes from the HT Capability IE
> in the association response and can be up to 255. This lets a rogue AP
> write up to 229 bytes past the array using a bitwise AND into adjacent
> struct fields.
> 
> Clamp the iteration count to the array size.
> 
> Signed-off-by: Alexandru Hossu <hossu.alexandru@gmail.com>
> ---

This isn't how you send a patch.  Try applying your email with:
`cat raw_email.txt | git am` and use git log to see the problem.

>  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 4f41f88908d7..e271d1e395a5 100644
> --- a/drivers/staging/rtl8723bs/core/rtw_wlan_util.c
> +++ b/drivers/staging/rtl8723bs/core/rtw_wlan_util.c
> @@ -935,7 +935,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++) {

Just use min() instead of min_t().  They're both unsigned.

regards,
dan carpenter

Re: [PATCH] staging: rtl8723bs: fix OOB write in HT_caps_handler()

[Greg KH]

On Fri, May 15, 2026 at 03:42:03AM -0700, Alexandru Hossu wrote:
> Hi Greg,
> 
> Here is the fix.
> 
> Alexandru
> 
> ---
> 
> The loop in HT_caps_handler() iterates up to pIE->length times, but
> HT_cap[] is only 26 bytes. pIE->length comes from the HT Capability IE
> in the association response and can be up to 255. This lets a rogue AP
> write up to 229 bytes past the array using a bitwise AND into adjacent
> struct fields.
> 
> Clamp the iteration count to the array size.
> 
> 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 4f41f88908d7..e271d1e395a5 100644
> --- a/drivers/staging/rtl8723bs/core/rtw_wlan_util.c
> +++ b/drivers/staging/rtl8723bs/core/rtw_wlan_util.c
> @@ -935,7 +935,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. */

How does this compare with this patch:
	https://lore.kernel.org/r/2026041408-grill-mahogany-d1e3@gregkh

or the others sent recently tothe staging list to fix this "issue" that
the LLM tools keep tripping over?

thanks,

greg k-h

Re: [PATCH] staging: rtl8723bs: fix OOB write in HT_caps_handler()

[Alexandru Hossu]

On Fri, May 15, 2026 at 01:34:52PM +0200, Greg KH wrote:
> How does this compare with this patch:
>     https://lore.kernel.org/r/2026041408-grill-mahogany-d1e3@gregkh
> or the others sent recently to the staging list to fix this "issue" that
> the LLM tools keep tripping over?

Apologies to both of you. I should have checked lore and the current
tree state before sending anything. The fix is already in linux-next
and I sent this without looking first.

Format note taken, Dan -- will use git send-email properly next time.

Withdrawing this patch.

Alexandru

Re: [PATCH] staging: rtl8723bs: fix OOB write in HT_caps_handler()

[M.samet Duman]

Was this patch written with LLM? Why is there separate text on the patch? It could have been mentioned in the cover letter.

--
Samet

> 2026. 5. 15. 오후 2:08, Alexandru Hossu <hossu.alexandru@gmail.com> 작성:
> 
> Hi Greg,
> 
> Here is the fix.
> 
> Alexandru
> 
> ---
> 
> The loop in HT_caps_handler() iterates up to pIE->length times, but
> HT_cap[] is only 26 bytes. pIE->length comes from the HT Capability IE
> in the association response and can be up to 255. This lets a rogue AP
> write up to 229 bytes past the array using a bitwise AND into adjacent
> struct fields.
> 
> Clamp the iteration count to the array size.
> 
> 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 4f41f88908d7..e271d1e395a5 100644
> --- a/drivers/staging/rtl8723bs/core/rtw_wlan_util.c
> +++ b/drivers/staging/rtl8723bs/core/rtw_wlan_util.c
> @@ -935,7 +935,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. */

Re: [PATCH] staging: rtl8723bs: fix OOB write in HT_caps_handler()

[Alexandru Hossu]

On Fri, May 15, 2026 at 04:01:22PM +0300, M.samet Duman wrote:
> Was this patch written with LLM? Why is there separate text on the
> patch? It could have been mentioned in the cover letter.

I was experimenting with some local tooling and clearly it didn't
produce proper output. Sorry for the noise. Noted for next time.

Alexandru