Accessing user-land memory without safe functions

Accessing user-land memory without safe functions

[Scotty Bauer]

I Have been auditing a few drivers and have found some of them are
accessing user-land memory without either mapping the pages in, or
copying the data via the safe user access apis. 

The thing I have mostly been seeing is something along the lines of:

ioctl(etc, etc, arg) {

char buf[32];
__user *some_struct  = (type cast) arg;
 
size_t amount = some_struct->amount;

** do size check on amount **

copy_from_user(buf, some_struct->some_uland_addr, amount);

}


Above you see 2 unsafe user-land dereferences, the
some_struct->amount and some_struct->some_uland_addr.


Since I've seen this a couple times now I'm wondering if my
understanding of touching user-land memory is flawed.

For the above example Ioctl, the proper way to get access to those fields
through the safe copy_from_user or get_user() functions, correct?

I'm wondering if I should submit patches to fix the issues I've found,
but now I'm doubting whether they're really issues at all.

Thanks,
Scotty

Re: Accessing user-land memory without safe functions

[Jonathan Corbet]

On Thu, 3 Dec 2015 13:54:30 -0700
Scotty Bauer <sbauer@eng.utah.edu> wrote:

> Since I've seen this a couple times now I'm wondering if my
> understanding of touching user-land memory is flawed.
> 
> For the above example Ioctl, the proper way to get access to those fields
> through the safe copy_from_user or get_user() functions, correct?
> 
> I'm wondering if I should submit patches to fix the issues I've found,
> but now I'm doubting whether they're really issues at all.

They sound like bugs to me, though it would be easier to say for sure with
a pointer to a specific function in the kernel source.  Please point
something out, or, perhaps better, send a patch fixing one of them.

Thanks,

jon

Re: Accessing user-land memory without safe functions

[Scotty Bauer]

Hi Jon,

Thanks for the response.

Here is one such example, although benign due to the
function being called with CAP_SYS_ADMIN. I'll work on patches for some of the
other issues and send those soon as well.

https://lkml.org/lkml/2015/12/1/566




On 12/03/2015 05:12 PM, Jonathan Corbet wrote:
> On Thu, 3 Dec 2015 13:54:30 -0700
> Scotty Bauer <sbauer@eng.utah.edu> wrote:
> 
>> Since I've seen this a couple times now I'm wondering if my
>> understanding of touching user-land memory is flawed.
>>
>> For the above example Ioctl, the proper way to get access to those fields
>> through the safe copy_from_user or get_user() functions, correct?
>>
>> I'm wondering if I should submit patches to fix the issues I've found,
>> but now I'm doubting whether they're really issues at all.
> 
> They sound like bugs to me, though it would be easier to say for sure with
> a pointer to a specific function in the kernel source.  Please point
> something out, or, perhaps better, send a patch fixing one of them.
> 
> Thanks,
> 
> jon
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>