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

August 19, 2026 at 11:11 PM, "Tianchu Chen" <tianchu.chen@linux.dev mailto:tianchu.chen@linux.dev?to=%22Tianchu%20Chen%22%20%3Ctianchu.chen%40linux.dev%3E > wrote:

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:

quoted

On Wed, Aug 19, 2026 at 02:22:47PM +0000, Tianchu Chen wrote:
 
 
 From: Tianchu Chen [off-list ref]
 
 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 [off-list ref]
 
 No assisted-by: line?
 
 And you have read this:
 https://lore.kernel.org/all/2026080354-skater-urgent-31b2@gregkh (local)
 right?

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

Assisted-by: kimi-code:kimi-k3

quoted

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/7848fcb635963ddb8474924ed71fdd687b5d6ec7@linux.dev/ (local)

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