Re: [PATCH] staging: rtl8723bs: fix potential speculative cpu oob read

[Linus Probert <linus.probert@gmail.com>]

On 2026-04-29 13:31:46+02:00, Greg Kroah-Hartman wrote:
> On Wed, Apr 29, 2026 at 01:10:16PM +0200, Linus Probert wrote:
> 
> > Fixes potential speculative cpu oob read in os_intfs.c by guarding the
> > index with array_index_nospec.
> > 
> > Fixes smatch warning:
> > warn: potential spectre issue 'rtw_1d_to_queue' [r]
> 
> Is this value controlled by a user?  Or is it just a normal operation
> that happens that is not controlled?  In other words, can a user
> manipulate this directly to be out of range?
> 
> thanks,
> 
> greg k-h

To my understanding, yes. Which is somewhat limited due to being rather
new to kernel code and not having access to this hardware. The priority
is extracted from ip header which can be user controlled.

However, looking closer at the execution before I see that in both cases
bounding is performed on the value as follows:

	dscp = ip_hdr(skb)->tos & 0xfc;
	prio = dscp >> 5;

So my change here adds no additional security. The smatch warning is a
false positive. It only warned on one of the cases. Most likely because
the bounding happened in a function call and it only sees the u32.

Some quick LLM research told me this (in my own words but have not
verified extensively):

The case where the bounding is performed in a function call could be
susceptible to *Spectre v4 (Speculative Store Bypass)*.
But the fix I applied here only applies to v1 so no additional security
on that front either.

This is probably best to NAK unless we just want to remove a false
positive smatch warning. But I personally don't agree with that.

Br,
Linus