Re: [RFC PATCH v7] staging: rtl8723bs: fix heap buffer overflow in cfg80211_rtw_add_key()

[Greg KH]

On Wed, Nov 04, 2026 at 02:04:29PM +0000, Feng Ning wrote:
> The cfg80211 framework allows userspace to specify a key sequence
> counter (NL80211_KEY_SEQ) of up to 16 bytes via NL80211_CMD_NEW_KEY
> netlink messages, but ieee_param.crypt.seq is a fixed 8-byte buffer.
> When cfg80211_rtw_add_key() copies the sequence counter via memcpy()
> without checking seq_len, a heap buffer overflow of up to 8 bytes
> occurs, overwriting bytes following seq within the same ieee_param
> structure (key_len and the trailing key[] flexible array).
> 
> Reject sequence counters longer than the destination buffer with
> -EINVAL instead of copying them, as discussed during review of v6.
> 
> This is sent as an RFC because it still lacks a Tested-by from real
> hardware.  A userspace trigger program for the overflow (libnl-based,
> NL80211_CMD_NEW_KEY with a 16-byte NL80211_ATTR_KEY_SEQ) follows in
> a reply to this thread; anyone with an rtl8723bs device who can run
> it against this patch would help unblock the fix.
> 
> Fixes: 554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver")
> Cc: stable@xxxxxxxxxxxxxxx
> Signed-off-by: Feng Ning <feng@xxxxxxxxx>
> ---
> Changes v6 -> v7:
>   - Replace silent min_t() truncation with an explicit -EINVAL when
>     seq_len exceeds sizeof(param->u.crypt.seq), per review feedback
>     (Greg KH, Sashiko automated review)
>   - Use the existing addkey_end cleanup path so param is freed on
>     the new error return
>   - Sent as RFC: code is complete but awaits a Tested-by from real
>     rtl8723bs hardware
> 
> Changes v5 -> v6:
>   - Restore the changelog that was lost in v5 (per Greg KH feedback)
>   - Add Cc: stable@xxxxxxxxxxxxxxx (user-reachable heap overflow)
>   - No code changes from v5
> 
>  drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c | 8 +++++++-

Please rebase this on the latest tree and see what happens :)