CVE-2026-90018
largeKernel stack overflow via crafted WPS frames in Linux rtl8723bs Wi-Fi driver
The rtw_get_wps_attr() function in the Linux kernel's staging rtl8723bs driver (Realtek RTL8723BS SDIO Wi-Fi) validates only that a WPS attribute's fixed 4-byte header fits inside the WPS information element, but copies attr_len bytes — a value read directly from the wire and never checked against the remaining IE length — via memcpy(). A crafted WPS IE in a beacon or probe response received during Wi-Fi scanning therefore causes both an out-of-bounds heap read and, at several call sites where the destination is a single-byte stack variable, a stack buffer overflow in the parsing thread. An attacker in radio range can trigger this without authentication or user interaction, potentially crashing the kernel, leaking memory, or gaining code execution in the kernel via stack corruption. Only Linux systems that use the staging rtl8723bs driver (i.e., devices with RTL8723BS Wi-Fi hardware) are affected. No public proof-of-concept is known, the issue is not in CISA's KEV, and no in-the-wild exploitation has been reported.
What to do: Update the Linux kernel to a release or stable branch that includes the fix adding the missing attr_len bounds check in rtw_get_wps_attr(); check with your distro for patched kernel packages. If patching is not possible, blacklist or disable the r8723bs staging driver, or restrict affected devices to trusted wireless networks since exploitation requires an attacker within radio range. Only systems with RTL8723BS Wi-Fi hardware are impacted; other Realtek drivers and Wi-Fi chipsets are not affected by this bug.
| Linux kernel staging rtl8723bs driver (Realtek RTL8723BS SDIO Wi-Fi) | — |
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB read / stack overflow in rtw_get_wps_attr() rtw_get_wps_attr() walks WPS attributes inside a WPS IE taken from a wireless management frame. For each candidate attribute it only checks that the fixed 4-byte attribute header (2-byte ID + 2-byte length) fits inside the IE: if (attr_ptr + 4 > wps_ie + wps_ielen) break; u16 attr_id = get_unaligned_be16(attr_ptr); u16 attr_data_len = get_unaligned_be16(attr_ptr + 2); u16 attr_len = attr_data_len + 4; attr_data_len (and therefore attr_len) is read directly from the wire and is never checked against the remaining bytes in the IE before being used as the size of: memcpy(buf_attr, attr_ptr, attr_len); Since attr_len is fully attacker controlled (0 to 65535+4), this is both a heap OOB read of wps_ie, and, more seriously, a stack buffer overflow at several call sites where buf_attr is a single-byte stack variable, e.g. rtw_get_wps_attr_content()'s callers passing WPS_ATTR_SELECTED_REGISTRAR into a stack "u8 sr"/"u8 selected_registrar" (drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c, drivers/staging/rtl8723bs/core/rtw_mlme_ext.c). A crafted WPS IE in a beacon or probe response processed during scanning can therefore smash the stack of the parsing thread. rtw_get_wps_attr_content() itself has no independent length check and simply trusts the attr_len it gets back from rtw_get_wps_attr(), so fixing the bound here also fixes that caller. The "attr_ptr + 4 > wps_ie + wps_ielen" header check above was added by commit 1463ca3ec6601 ("staging: rtl8723bs: fix OOB reads in rtw_get_sec_ie(), rtw_get_wapi_ie(), and rtw_get_wps_attr()"), which bounded the fixed header but never extended the check to cover the variable-length attribute data that follows it. Add that missing check before attr_len is used as a memcpy() length or accepted as a match.
- Vector
- CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
In the news0 stories
No ingested article mentions this CVE yet.