Re: [PATCH] staging: rtl8723bs: bound WPS attribute copy in rtw_get_wps_attr_content()

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

On Tue, Sep 01, 2026 at 09:22:49AM +0200, Jesus Olmos wrote:
> rtw_get_wps_attr_content() copies attr_len - 4 (the WPS attribute's 2-byte
> data-length field, up to 0xffff) from a WPS information element into the
> caller's buffer with no destination-size bound:
> 
> 	memcpy(buf_content, attr_ptr + 4, attr_len - 4);
> 
> The information element comes straight from a received beacon / probe
> response: collect_bss_info() copies the frame's IEs verbatim into
> bssid->ies, which reaches the scan queue, so attr_len is attacker
> controlled. rtw_cfg80211_inform_bss() and two sites in rtw_mlme_ext.c call
> this for WPS_ATTR_SELECTED_REGISTRAR with a one-byte destination (u8 sr /
> u8 selected_registrar), because that attribute is a single byte by spec. A
> frame that declares a longer Selected Registrar attribute therefore
> overflows the one-byte stack variable during a scan, which happens
> automatically (NetworkManager/iwd), giving an unauthenticated adjacent
> attacker a remote stack buffer overflow (at minimum a stack-protector
> panic).
> 
> Commit 1463ca3ec660 ("staging: rtl8723bs: fix OOB reads in rtw_get_sec_ie(),
> rtw_get_wapi_ie(), and rtw_get_wps_attr()") added a bounds check for the
> attribute header in rtw_get_wps_attr() but not for the attribute data
> length, and did not touch rtw_get_wps_attr_content(), so the copy remained
> both an out-of-bounds read of the attribute data and an out-of-bounds write
> of the destination.
> 
> Reject attributes that claim more data than the IE holds (fixing the
> out-of-bounds read and the latent memcpy(buf_attr, ...) in
> rtw_get_wps_attr()), give rtw_get_wps_attr_content() the destination buffer
> size, and clamp the copy to it.
> 
> Found using mwemu (https://github.com/sha0coder/mwemu).

So shouldn't this have an Assisted-by: tag?

And have you tested this on real hardware?

Also, this looks a bit wrong, you have an endless loop in this patch :(

thanks,

greg k-h