[PATCH 5.10] staging: rtl8723bs: fix OOB read in OnAssocRsp() IE loop

[PATCH 5.10] staging: rtl8723bs: fix OOB read in OnAssocRsp() IE loop

[Mikhail Dmitrichenko]

From: Alexandru Hossu <hossu.alexandru@gmail.com>

commit f9654207e92283e0acac5d64fe5f8835383b5a23 upstream.

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 <stable@kernel.org>
Signed-off-by: Alexandru Hossu <hossu.alexandru@gmail.com>
Reviewed-by: Luka Gejak <luka.gejak@linux.dev>
Link: https://patch.msgid.link/20260522004531.1038924-6-hossu.alexandru@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ mdmitrichenko: adapt to 5.10: struct ndis_80211_var_ie still has the
  CamelCase Length field and a one-element data[1] array here, so
  sizeof(*pIE) is 3 rather than the 2-byte IE header. Use the explicit
  header size 2, as the existing i += (pIE->Length + 2) does, so that a
  valid IE ending exactly at pkt_len is not dropped. ]
Signed-off-by: Mikhail Dmitrichenko <mdmitrichenko@astralinux.ru>
---
Backport fix for CVE-2026-64444
 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 46ce8ca12c02..527121dbd1e7 100644
--- a/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c
+++ b/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c
@@ -1682,7 +1682,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 + 2 > pkt_len)
+			break;
 		pIE = (struct ndis_80211_var_ie *)(pframe + i);
+		if (i + 2 + pIE->Length > pkt_len)
+			break;
 
 		switch (pIE->ElementID) {
 		case _VENDOR_SPECIFIC_IE_:
-- 
2.47.3

Re: [PATCH 5.10] staging: rtl8723bs: fix OOB read in OnAssocRsp() IE loop

[Luka Gejak]

October 12, 2026 at 4:06 PM, "Mikhail Dmitrichenko" <mdmitrichenko@astralinux.ru> wrote:


> 
> From: Alexandru Hossu <hossu.alexandru@gmail.com>
> 
> commit f9654207e92283e0acac5d64fe5f8835383b5a23 upstream.
> 
> 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 <stable@kernel.org>
> Signed-off-by: Alexandru Hossu <hossu.alexandru@gmail.com>
> Reviewed-by: Luka Gejak <luka.gejak@linux.dev>
> Link: https://patch.msgid.link/20260522004531.1038924-6-hossu.alexandru@gmail.com
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[...]

Hi Mikhail,

It seems to me that this was sent by accident by running git format-patch -1

You probably forgot to commit so git made last commit into a patch file.

Either way staging rtl8723bs is getting removed in linux 7.4 so any
further commits for rtl8723bs are discouraged.

Best regards,
Luka Gejak

Re: [PATCH 5.10] staging: rtl8723bs: fix OOB read in OnAssocRsp() IE loop

[Михаил Дмитриченко]

On Mon, 12 Oct 2026 at 17:19 MSK, Luka Gejak <luka.gejak@linux.dev> wrote:
> It seems to me that this was sent by accident by running git format-patch -1
>
> You probably forgot to commit so git made last commit into a patch file.
>
> Either way staging rtl8723bs is getting removed in linux 7.4 so any
> further commits for rtl8723bs are discouraged.

Hi Luka,

Thanks for taking a look. This was intentional: it is a backport of
your reviewed fix f9654207e922 for the 5.10.y stable tree (hence the
[PATCH 5.10] prefix). The upstream commit is tagged Cc: stable and is
already in 5.15.y and newer, but 5.10.y is still missing it
(CVE-2026-64444). 

As far as I understand, the removal in 7.4 affects mainline only; the
driver is still part of 5.10.y, so the fix is still relevant there.

Best regards,
Mikhail

Re: [PATCH 5.10] staging: rtl8723bs: fix OOB read in OnAssocRsp() IE loop

[Luka Gejak]

October 12, 2026 at 5:33 PM, "Михаил Дмитриченко" <mdmitrichenko@astralinux.ru> wrote:


> 
> On Mon, 12 Oct 2026 at 17:19 MSK, Luka Gejak <luka.gejak@linux.dev> wrote:
> 
> > 
> > It seems to me that this was sent by accident by running git format-patch -1
> > 
> >  You probably forgot to commit so git made last commit into a patch file.
> > 
> >  Either way staging rtl8723bs is getting removed in linux 7.4 so any
> >  further commits for rtl8723bs are discouraged.
> > 
> Hi Luka,
> 
> Thanks for taking a look. This was intentional: it is a backport of
> your reviewed fix f9654207e922 for the 5.10.y stable tree (hence the
> [PATCH 5.10] prefix). The upstream commit is tagged Cc: stable and is
> already in 5.15.y and newer, but 5.10.y is still missing it
> (CVE-2026-64444). 
> 
> As far as I understand, the removal in 7.4 affects mainline only; the
> driver is still part of 5.10.y, so the fix is still relevant there.
> 
> Best regards,
> Mikhail
>

Understandable, I wasn't aware it isn't backported as it seems to me
it was merged quite some time ago.

Best regards,
Luka Gejak