[Clarification] writes to kernel addresses that came from userspace

[Kees Cook]

On Mon, Sep 13, 2021 at 09:59:36AM +0200, Bernd Petrovitsch wrote:
> Hi all!
> 
> On 12/09/2021 18:20, Len Baker wrote:
> [...]
> > [extracted from the KSPP]
> > 
> > It should be possible to perform taint tracking of addresses in the kernel
> > to avoid flaws of the form:
> > 
> > copy_from_user(object, src, ...);
> > ...
> > memcpy(object.address, something, ...);
> > 
> > [end of extracted]
> > 
> > My question is: Why is this scenario a flaw?
> > 
> > If I understand correctly, the copy_from_user() function copies n bytes of
> > src (in user space address) to object (in kernel space address). I think > that it is the correct way to act. Then, in kernel space the object is
> 
> Yup.
> 
> > modified. So, I don't see the problem. Sorry if it is a trivial question
> > but I can not figure it out on my own.
> 
> Shouldn't the memcpy() be a copy_to_user() as object.address is setup by the
> user space and thus a user space address?

Right, _correct_ code would pass a userspace address, and use
copy_to_user() for writing to it. The goal here would be to find the
kinds of paths that might lead to bad conditions (i.e. answering "is it
possible for a userspace-controlled value to reach a place in the kernel
that didn't sanity-check it before doing indexing, sizing, etc?").

-- 
Kees Cook