UBUNTU-CVE-2026-74650: Medium severity ubuntu/linux-azure vulnerability
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
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ubuntu/linux-aws-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1117.124~20.04.1 - Upgrade
Upgrade
ubuntu/linux-azure-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1123.132~20.04.1 - Upgrade
Upgrade
ubuntu/linux-azure-fde-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1122.131~20.04.1 - Upgrade
Upgrade
ubuntu/linux-gcp-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1118.128~20.04.1 - Upgrade
Upgrade
ubuntu/linux-hwe-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-198.208~20.04.1 - Upgrade
Upgrade
ubuntu/linux-ibm-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1111.115~20.04.1 - Upgrade
Upgrade
ubuntu/linux-intel-iotg-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1112.118~20.04.1 - Upgrade
Upgrade
ubuntu/linux-lowlatency-hwe-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-195.205~20.04.1 - Upgrade
Upgrade
ubuntu/linux-oracle-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1114.120~20.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1111.115~20.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 5.15.0-198.208 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 5.15.0-1117.124 - Upgrade
Upgrade
ubuntu/linux-azureto a version that resolves this vulnerability.Fixed in 5.15.0-1123.132 - Upgrade
Upgrade
ubuntu/linux-azure-fdeto a version that resolves this vulnerability.Fixed in 5.15.0-1122.131 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 5.15.0-1118.128 - Upgrade
Upgrade
ubuntu/linux-gketo a version that resolves this vulnerability.Fixed in 5.15.0-1113.119 - Upgrade
Upgrade
ubuntu/linux-gkeopto a version that resolves this vulnerability.Fixed in 5.15.0-1100.108 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 5.15.0-1111.115 - Upgrade
Upgrade
ubuntu/linux-intel-iotgto a version that resolves this vulnerability.Fixed in 5.15.0-1112.118 - Upgrade
Upgrade
ubuntu/linux-kvmto a version that resolves this vulnerability.Fixed in 5.15.0-1109.114 - Upgrade
Upgrade
ubuntu/linux-lowlatencyto a version that resolves this vulnerability.Fixed in 5.15.0-195.205 - Upgrade
Upgrade
ubuntu/linux-nvidiato a version that resolves this vulnerability.Fixed in 5.15.0-1112.113 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 5.15.0-1114.120 - Upgrade
Upgrade
ubuntu/linux-xilinx-zynqmpto a version that resolves this vulnerability.Fixed in 5.15.0-1080.84 - Upgrade
Upgrade
ubuntu/linux-bluefieldto a version that resolves this vulnerability.Fixed in 5.15.0-1101.103 - Upgrade
Upgrade
ubuntu/linux-intel-iot-realtimeto a version that resolves this vulnerability.Fixed in 5.15.0-1109.111 - Upgrade
Upgrade
ubuntu/linux-realtimeto a version that resolves this vulnerability.Fixed in 5.15.0-1116.125 - Upgrade
Upgrade
ubuntu/linux-aws-fipsto a version that resolves this vulnerability.Fixed in 5.15.0-1117.124+fips1 - Upgrade
Upgrade
ubuntu/linux-azure-fipsto a version that resolves this vulnerability.Fixed in 5.15.0-1123.132+fips1 - Upgrade
Upgrade
ubuntu/linux-fipsto a version that resolves this vulnerability.Fixed in 5.15.0-198.208+fips1 - Upgrade
Upgrade
ubuntu/linux-gcp-fipsto a version that resolves this vulnerability.Fixed in 5.15.0-1118.128+fips1 - Compensating control
In WMM_param_handler(), validate that pIE->length is at least WLAN_WMM_LEN (24) before reading sizeof(struct WMM_para_element) (18 bytes) at pIE->data + 6; perform the check inside the handler so callers such as OnAssocRsp() and join_cmd_hdl() are covered.
Event History
Frequently Asked Questions
Which systems are realistically exposed to remote exploitation?
Systems using the staging rtl8723bs wireless driver are exposed when they process association responses from an access point. A remote or rogue AP can supply a malformed vendor-specific WMM information element that reaches the vulnerable handler.
What must an attacker send to trigger the out-of-bounds read?
The attacker needs to provide a vendor-specific information element with the WMM OUI and a length from 6 through 23 bytes. This passes the existing OUI-only checks, while the handler then reads 18 bytes starting at offset 6 even though a 24-byte element is required.
Are all calls to the vulnerable handler affected?
No. The caller in rtw_wlan_util.c already invokes the handler only when the information-element length equals WLAN_WMM_LEN. The association-response and join-command paths did not enforce this length check before calling it.
What change resolves the issue?
The fix moves the WMM element-length validation into WMM_param_handler() itself, ensuring the handler rejects elements shorter than WLAN_WMM_LEN before performing the memcmp() and memcpy().