staging: rtl8723bs: fix protected RX frame validation in decrypt path

PATCH Superseded Tianchu Chen 2 participants 5 messages Aug 19 – Sep 7 Staging

lore

Share & tools

lore

Tianchu Chen

author

2026-08-19 14:22 UTC #0 lore raw

PATCH 1/1 staging: rtl8723bs: fix protected RX frame validation in decrypt path

From: Tianchu Chen <[email protected]>

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 [email protected]

Signed-off-by Tianchu Chen <[email protected]>

---
 drivers/staging/rtl8723bs/core/rtw_recv.c | 21 ++++++++++++++++++---
 1 file changed, 18 insertions(+), 3 deletions(-)

drivers/staging/rtl8723bs/core/rtw_recv.c +18 -3

index 7568fc514d7ce..4756e0fedd46f 100644
@@ -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;

Signature · 1 line

2.51.0

Greg KH

maintainer

2026-08-19 14:45 UTC #1 lore raw

Quoted 18 lines · Tianchu Chen

From: Tianchu Chen <[email protected]>
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.

Quoted 7 lines

Bail out immediately when decryptor() fails.
Discovered by Atuin - Automated Vulnerability Discovery Engine.
Fixes 554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver")
Cc [email protected]
Signed-off-by Tianchu Chen <[email protected]>

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

Tianchu Chen

author

2026-08-19 15:11 UTC #2 lore raw

Quoted 30 lines · Greg KH

Quoted 19 lines · Tianchu Chen
From: Tianchu Chen <[email protected]>
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.
Quoted 8 lines
Bail out immediately when decryptor() fails.
Discovered by Atuin - Automated Vulnerability Discovery Engine.
Fixes 554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver")
Cc [email protected]
Signed-off-by Tianchu Chen <[email protected]>

Quoted 5 lines

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

Quoted 1 line

So did you test this on the real hardware?

Unfortunately I have no real hardware.

Tianchu Chen

author

2026-09-07 16:00 UTC #3 lore raw

Quoted 39 lines · Tianchu Chen

Quoted 30 lines · Greg KH
On Wed, Aug 19, 2026 at 02:22:47PM +0000, Tianchu Chen wrote:
From: Tianchu Chen <[email protected]>
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 [email protected]
Signed-off-by Tianchu Chen <[email protected]>
Quoted 6 lines
No assisted-by: line?
And you have read this:
https://lore.kernel.org/all/2026080354-skater-urgent-31b2@gregkh
right?

Quoted 9 lines

Thanks for pointing out, I have not read this before.
Assisted-by kimi-code:kimi-k3
Quoted 3 lines
So did you test this on the real hardware?
Unfortunately I have no real hardware.

Hi Greg,

A while ago I had no access to real hardware with this chip, so I was not able to actually reproduce and verify the bug.

That has changed: I recently picked up a board with an RTL8723BS from the second-hand market. I can now confirm that the bug can be triggered by on-air Wi-Fi packets from a bogus AP.

The v2 patch with test report has been sent:

https://lore.kernel.org/linux-staging/[email protected]/

Hopefully this time it is good enough to be merged into staging.

Since this driver is built into distros like Ubuntu/debian by default, and there are presumably quite a few people actually using it, I believe fixing this bug is necessary.

Best regards,

Tianchu

Greg KH

maintainer

2026-09-07 16:12 UTC #4 lore raw

Quoted 57 lines · Tianchu Chen

Quoted 39 lines · Tianchu Chen
Quoted 30 lines · Greg KH
On Wed, Aug 19, 2026 at 02:22:47PM +0000, Tianchu Chen wrote:
From: Tianchu Chen <[email protected]>
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 [email protected]
Signed-off-by Tianchu Chen <[email protected]>
Quoted 6 lines
No assisted-by: line?
And you have read this:
https://lore.kernel.org/all/2026080354-skater-urgent-31b2@gregkh
right?
Quoted 9 lines
Thanks for pointing out, I have not read this before.
Assisted-by kimi-code:kimi-k3
Quoted 3 lines
So did you test this on the real hardware?
Unfortunately I have no real hardware.
Hi Greg,
A while ago I had no access to real hardware with this chip, so I was not able to actually reproduce and verify the bug.

Quoted 7 lines

That has changed: I recently picked up a board with an RTL8723BS from the second-hand market. I can now confirm that the bug can be triggered by on-air Wi-Fi packets from a bogus AP.
The v2 patch with test report has been sent:
https://lore.kernel.org/linux-staging/[email protected]/

Great!

Quoted 1 line

Hopefully this time it is good enough to be merged into staging.

It's a bit wrong, will go comment on it now...