[PATCH] staging: rtl8723bs: fix protected RX frame validation in decrypt path

[PATCH] staging: rtl8723bs: fix protected RX frame validation in decrypt path

[Tianchu Chen]

From: Tianchu Chen <flynnnchen@tencent.com>

The RX software decrypt path mishandles crafted protected frames from a
malicious AP in two ways:

1) decryptor() never checks that a protected frame is long enough to
hold the 802.11 header plus the per-cipher trailer(IV, ICV/MIC).

Implementations like rtw_wep_decrypt() and rtw_aes_decrypt() all compute
length = hdr.len - hdrlen - iv_len. and a shorter frame underflows the 
unsigned subtraction, turning into OOB reads/writes.

Reject such frames in decryptor() before touching the IV.

2) validate_80211w_mgmt() uses the skb before checking whether
decryptor() returned NULL. On decrypt failure the skb has been freed
before being used.

Bail out immediately when decryptor() fails.

Discovered by Atuin - Automated Vulnerability Discovery Engine.

Fixes: 554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver")
Cc: stable@vger.kernel.org
Signed-off-by: Tianchu Chen <flynnnchen@tencent.com>
---
 drivers/staging/rtl8723bs/core/rtw_recv.c | 21 ++++++++++++++++++---
 1 file changed, 18 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/rtl8723bs/core/rtw_recv.c b/drivers/staging/rtl8723bs/core/rtw_recv.c
index 7568fc514d7ce..4756e0fedd46f 100644
--- a/drivers/staging/rtl8723bs/core/rtw_recv.c
+++ b/drivers/staging/rtl8723bs/core/rtw_recv.c
@@ -426,8 +426,21 @@ static union recv_frame *decryptor(struct adapter *padapter, union recv_frame *p
 	u32  res = _SUCCESS;
 
 	if (prxattrib->encrypt > 0) {
-		u8 *iv = precv_frame->u.hdr.rx_data + prxattrib->hdrlen;
+		u8 *iv;
+		u32 min_len = prxattrib->hdrlen + prxattrib->iv_len + prxattrib->icv_len;
 
+		/* TKIP appends an 8-byte Michael MIC that icv_len doesn't account for */
+		if (prxattrib->encrypt == _TKIP_)
+			min_len += 8;
+
+		/* a protected frame must be long enough to hold the IV and ICV/MIC */
+		if (precv_frame->u.hdr.len < min_len) {
+			rtw_free_recvframe(precv_frame,
+					   &padapter->recvpriv.free_recv_queue);
+			return NULL;
+		}
+
+		iv = precv_frame->u.hdr.rx_data + prxattrib->hdrlen;
 		prxattrib->key_index = (((iv[3]) >> 6) & 0x3);
 
 		if (prxattrib->key_index > WEP_KEYS) {
@@ -1395,6 +1408,10 @@ static signed int validate_80211w_mgmt(struct adapter *adapter, union recv_frame
 			if (!mgmt_DATA)
 				goto validate_80211w_fail;
 			precv_frame = decryptor(adapter, precv_frame);
+			if (!precv_frame) {
+				kfree(mgmt_DATA);
+				goto validate_80211w_fail;
+			}
 			/* save actual management data frame body */
 			memcpy(mgmt_DATA, ptr + pattrib->hdrlen + pattrib->iv_len, data_len);
 			/* overwrite the iv field */
@@ -1402,8 +1419,6 @@ static signed int validate_80211w_mgmt(struct adapter *adapter, union recv_frame
 			/* remove the iv and icv length */
 			pattrib->pkt_len = pattrib->pkt_len - pattrib->iv_len - pattrib->icv_len;
 			kfree(mgmt_DATA);
-			if (!precv_frame)
-				goto validate_80211w_fail;
 		} else if (is_multicast_ether_addr(GetAddr1Ptr(ptr)) &&
 			(subtype == WIFI_DEAUTH || subtype == WIFI_DISASSOC)) {
 			signed int BIP_ret = _SUCCESS;
-- 
2.51.0

Re: [PATCH] staging: rtl8723bs: fix protected RX frame validation in decrypt path

[Greg KH]

On Wed, Aug 19, 2026 at 02:22:47PM +0000, Tianchu Chen wrote:
> From: Tianchu Chen <flynnnchen@tencent.com>
> 
> The RX software decrypt path mishandles crafted protected frames from a
> malicious AP in two ways:
> 
> 1) decryptor() never checks that a protected frame is long enough to
> hold the 802.11 header plus the per-cipher trailer(IV, ICV/MIC).
> 
> Implementations like rtw_wep_decrypt() and rtw_aes_decrypt() all compute
> length = hdr.len - hdrlen - iv_len. and a shorter frame underflows the 
> unsigned subtraction, turning into OOB reads/writes.
> 
> Reject such frames in decryptor() before touching the IV.
> 
> 2) validate_80211w_mgmt() uses the skb before checking whether
> decryptor() returned NULL. On decrypt failure the skb has been freed
> before being used.
> 
> Bail out immediately when decryptor() fails.
> 
> Discovered by Atuin - Automated Vulnerability Discovery Engine.
> 
> Fixes: 554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver")
> Cc: stable@vger.kernel.org
> Signed-off-by: Tianchu Chen <flynnnchen@tencent.com>

No assisted-by: line?

And you have read this:
	https://lore.kernel.org/all/2026080354-skater-urgent-31b2@gregkh
right?

So did you test this on the real hardware?

thanks

greg k-h

Re: [PATCH] staging: rtl8723bs: fix protected RX frame validation in decrypt path

[Tianchu Chen]

August 19, 2026 at 10:45 PM, "Greg KH" <gregkh@linuxfoundation.org mailto:gregkh@linuxfoundation.org?to=%22Greg%20KH%22%20%3Cgregkh%40linuxfoundation.org%3E > wrote:


> 
> On Wed, Aug 19, 2026 at 02:22:47PM +0000, Tianchu Chen wrote:
> 
> > 
> > From: Tianchu Chen <flynnnchen@tencent.com>
> >  
> >  The RX software decrypt path mishandles crafted protected frames from a
> >  malicious AP in two ways:
> >  
> >  1) decryptor() never checks that a protected frame is long enough to
> >  hold the 802.11 header plus the per-cipher trailer(IV, ICV/MIC).
> >  
> >  Implementations like rtw_wep_decrypt() and rtw_aes_decrypt() all compute
> >  length = hdr.len - hdrlen - iv_len. and a shorter frame underflows the 
> >  unsigned subtraction, turning into OOB reads/writes.
> >  
> >  Reject such frames in decryptor() before touching the IV.
> >  
> >  2) validate_80211w_mgmt() uses the skb before checking whether
> >  decryptor() returned NULL. On decrypt failure the skb has been freed
> >  before being used.
> >  
> >  Bail out immediately when decryptor() fails.
> >  
> >  Discovered by Atuin - Automated Vulnerability Discovery Engine.
> >  
> >  Fixes: 554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver")
> >  Cc: stable@vger.kernel.org
> >  Signed-off-by: Tianchu Chen <flynnnchen@tencent.com>
> > 
> No assisted-by: line?
> 
> And you have read this:
>  https://lore.kernel.org/all/2026080354-skater-urgent-31b2@gregkh
> right?


Thanks for pointing out, I have not read this before.

Assisted-by: kimi-code:kimi-k3

> So did you test this on the real hardware?

Unfortunately I have no real hardware.