CVE-2026-74650 in Linux
Summary
by MITRE • 08/22/2026
In the Linux kernel, the following vulnerability has been resolved:
staging: rtl8723bs: fix OOB read in WMM_param_handler()
WMM_param_handler() 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 WMM_para_element) (18) bytes at pIE->data + 6, so it requires pIE->length to be at least 24 (WLAN_WMM_LEN), but it never validates the length. Two of its three callers reach it after matching only the WMM OUI: OnAssocRsp() in rtw_mlme_ext.c matches a 6-byte OUI, and join_cmd_hdl() 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 join_cmd_hdl(), 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 rtw_wlan_util.c already guards the handler with "pIE->length == WLAN_WMM_LEN". Move the equivalent check into the handler itself so every caller is covered; the sibling IE handlers in the same parsing loop (HT_caps_handler(), HT_info_handler(), ERP_IE_handler()) likewise bound their accesses by pIE->length.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/22/2026
The Linux kernel staging driver for the Realtek rtl8723bs wireless chipset contains a critical out-of-bounds read vulnerability within its Wi-Fi Multimedia parameter handling logic. This flaw resides in the WMM_param_handler function, which is responsible for parsing and processing WMM information elements received from access points or other network peers during association procedures. The core technical deficiency lies in the absence of length validation before memory operations are performed on incoming data structures. Specifically, the handler attempts to copy a fixed-size structure representing WMM parameters, which requires reading eighteen bytes starting at an offset of six within the provided information element buffer. This operation assumes that the source buffer contains at least twenty-four bytes of valid data, corresponding to the standard WLAN_WMM_LEN constant. However, the function does not verify that the length field associated with the incoming information element meets this minimum requirement before proceeding with memory copy operations.
The vulnerability is exploitable because multiple code paths in the driver lead to WMM_param_handler without performing adequate bounds checking on the input data. In particular, two of the three callers invoke this handler after matching only against a specific vendor-specific organizationally unique identifier rather than validating the full length of the information element. The OnAssocRsp function matches a six-byte OUI from association response frames received from access points, while join_cmd_hdl matches a four-byte OUI before invoking the problematic handler. Consequently, if an attacker crafts a malicious Wi-Fi frame containing a vendor-specific information element that includes the correct WMM OUI but specifies a length value between six and twenty-three bytes, the driver will pass the initial identification check and proceed to execute memory reads beyond the allocated buffer boundaries. This results in reading arbitrary kernel memory contents adjacent to the packet data into the stack or heap structures used by the driver logic.
From an operational impact perspective, this out-of-bounds read poses a significant security risk due to its potential for remote exploitation. Since OnAssocRsp processes frames received directly from wireless access points during the association process, any device within radio range can trigger this vulnerability simply by transmitting specially crafted management frames. The immediate consequence is information disclosure, as the kernel may leak sensitive memory contents such as stack variables, pointers, or other confidential data residing in adjacent memory regions to an unauthenticated remote attacker. While out-of-bounds reads are generally less severe than write vulnerabilities because they do not directly allow code execution, they can facilitate further attacks by leaking cryptographic keys, session tokens, or kernel layout information that aids in bypassing security mitigations like KASLR. Additionally, depending on how the leaked data is subsequently processed within the driver stack, there may be secondary risks involving logic errors or crashes leading to denial of service conditions for wireless connectivity services running on the affected system.
This vulnerability aligns with CWE-125, which describes out-of-bounds read scenarios where software reads past the end of a buffer due to insufficient boundary checks. In terms of adversarial tactics, this flaw relates to ATT&CK technique T1083, specifically file and directory discovery or data exfiltration via memory scraping if the leaked information is systematically extracted over time. The root cause stems from inconsistent input validation practices within the driver's parsing loop; while sibling handlers for HT capabilities, HT info, and ERP information elements correctly bound their access by checking pIE->length against expected constants, WMM_param_handler lacked this defensive programming practice. To remediate this issue, developers must enforce strict length verification at the entry point of every handler function rather than relying on callers to perform validation. The appropriate mitigation involves adding a check within WMM_param_handler itself to ensure that pIE->length is greater than or equal to WLAN_WMM_LEN before any memcpy operations are executed. This ensures uniform protection across all code paths invoking the handler and prevents exploitation regardless of which entry point triggers the parsing logic. System administrators should apply kernel updates provided by their distribution vendors as soon as patches become available, ensuring that staging drivers for legacy wireless hardware are updated with these security fixes to maintain network integrity and prevent potential information leakage through crafted Wi-Fi frames.