CVE-2026-64445: staging: rtl8723bs: fix WEP length underflow and OOB read in OnAuth()
In the Linux kernel, the following vulnerability has been resolved:
staging: rtl8723bs: fix WEP length underflow and OOB read in OnAuth()
OnAuth() has two bugs in the shared-key authentication path.
When the Privacy bit is set, rtwwepdecrypt() is called without verifying that the frame is long enough to contain a valid WEP IV and ICV. Inside rtwwepdecrypt(), length is computed as:
length = len - WLANHDRA3LEN - ivlen
and then passed as (length - 4) to crc32le(). If len is less than WLANHDRA3LEN + ivlen + icvlen (32 bytes), length - 4 is negative and, after the implicit cast to sizet, causes crc32le() to read far beyond the frame buffer. Add a minimum length check before accessing the IV field and calling the decryption path.
When processing a seq=3 response, rtwgetie() stores the Challenge Text IE length in ielen, but the subsequent memcmp() always reads 128 bytes regardless of ielen. IEEE 802.11 mandates a challenge text of exactly 128 bytes; reject any IE whose length field differs, matching the check already applied to OnAuthClient().
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
In the OnAuth / WEP decryption path (rtl8723bs staging), add a minimum length check before accessing ICV/processing WEP so that computed length = len - WLAN_HDR_A3_LEN - iv_len cannot become negative; verify the frame is long enough to contain a valid WEP IV and reject any IE whose length field differs (expected IE length exactly 128 bytes) so memcmp and subsequent reads do not go past the frame buffer.
Linux kernel (rtl8723bs staging) rtw_wep_decrypt() WEP length validation before crc32_le() = Reject frames where length underflows (i.e., where frame length is not at least WLAN_HDR_A3_LEN + iv_len + icv_len) and reject any IE whose length field differs from expected IE length
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using the Linux kernel's staging rtl8723bs driver are exposed when they process malicious 802.11 shared-key authentication frames. The attack vector is adjacent network access, so an attacker must be within wireless range.
Does exploitation require credentials or user interaction?
No. The CVSS vector specifies no privileges required and no user interaction, with low attack complexity.
What malformed traffic triggers the vulnerable paths?
One path uses a Privacy-marked authentication frame shorter than the required WEP IV and ICV data, causing an underflow that can drive an out-of-bounds read. Another uses a sequence-3 shared-key authentication response with a Challenge Text information element whose declared length is not 128 bytes.
What should be done if an update cannot be applied immediately?
The provided data identifies the affected component as the rtl8723bs staging driver and the attack as wireless-network adjacent. Reducing exposure to untrusted devices within wireless range can limit opportunities to deliver malicious authentication frames, but no specific workaround is provided.