On Sun, 22 Jun 2025 09:57:20 -0700
Linus Torvalds <torva...@linux-foundation.org> wrote:
> On Sun, 22 Jun 2025 at 02:52, Christophe Leroy
> <christophe.le...@csgroup.eu> wrote:
> >
> > The results of "access_ok()" can be mis-speculated.
>
> Hmm. This code is critical. I think it should be converted to use that
> masked address thing if we have to add it here.
If access_ok() is mis-speculated then you get a read from the user-specified
kernel address - I don't think that matters.
The hacker would need to find somewhere where the read value was used
in a test or memory access so that side effects (typically cache line
evictions) can be detected.
But copy_from_user_iter() is pretty much always used for 'data' not
'control pane' - so you'd be hard pushed to find somewhere 'useful'.
Not only that the cpu would have to return from copy_from_user_iter()
before correcting the mis-speculation.
I can't imagine that happening - even without all the 'return thunk' stuff.
The same might be true for copy_from_user().
It might only be get_user() that actually has any chance of being exploited.
>
> And at some point this access_ok() didn't even exist, because we check
> the addresses at iter creation time. So this one might be a "belt and
> suspenders" check, rather than something critical.
IIRC there was a patch to move the access_ok() much nearer the use copy.
But it didn't go as far as removing the one from import_iovec().
Although removing that one might make sense.
(I've also looked about whether the 'direction' is needed in the 'iter'.
98% of the code knows what it should be - and may contain pointless
checks, but some bits seem to rely on it.)
David
>
> (Although I also suspect that when we added ITER_UBUF we might have
> created cases where those user addresses aren't checked at iter
> creation time any more).
>
> Linus
