CVE-2026-90018

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.