CVE-2026-74650: staging: rtl8723bs: fix OOB read in WMM_param_handler()
In the Linux kernel, the following vulnerability has been resolved:
staging: rtl8723bs: fix OOB read in WMMparamhandler()
WMMparamhandler() copies a fixed-size WMM parameter element out of a received information element without checking that the element is long enough, causing an out-of-bounds read for a short WMM IE.
The handler reads sizeof(struct WMMparaelement) (18) bytes at pIE->data + 6, so it requires pIE->length to be at least 24 (WLANWMMLEN), but it never validates the length. Two of its three callers reach it after matching only the WMM OUI: OnAssocRsp() in rtwmlmeext.c matches a 6-byte OUI, and joincmdhdl() matches a 4-byte OUI, before calling the handler. A vendor-specific IE carrying the WMM OUI but a length between 6 and 23, placed in an association response or in the IE blob handed to joincmdhdl(), passes the OUI check and then makes the memcmp() and memcpy() at pIE->data + 6 read past the end of the element. OnAssocRsp() parses a frame received from the AP, so this is reachable from a remote peer.
The remaining caller in rtwwlanutil.c already guards the handler with "pIE->length == WLANWMMLEN". Move the equivalent check into the handler itself so every caller is covered; the sibling IE handlers in the same parsing loop (HTcapshandler(), HTinfohandler(), ERPIEhandler()) likewise bound their accesses by pIE->length.
Affected Software
Event History
Frequently Asked Questions
Who can trigger the vulnerable path?
A remote AP can reach the path by sending an association response containing a vendor-specific information element with the WMM OUI. The affected code is in the rtl8723bs staging driver.
What does a malicious information element need to contain?
It must pass the WMM OUI check while having a length from 6 through 23 bytes. The handler then performs memcmp() and memcpy() starting at pIE->data + 6 and reads beyond the end of the element because it requires a length of at least 24 bytes.
Are all callers equally exposed?
No. The caller in rtw_wlan_util.c already invokes the handler only when pIE->length equals WLAN_WMM_LEN. OnAssocRsp() and join_cmd_hdl() can call it after checking only the WMM OUI, without validating the required element length.
How can code be checked for the fix?
The handler should validate that pIE->length is at least WLAN_WMM_LEN, which is 24, before reading the fixed-size WMM parameter element at pIE->data + 6. A check only in individual callers is insufficient because multiple callers reach the handler.