linux-kernel - Re: <Query> Looking more details and reasons for using orig_add

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 15 Feb 2017 12:09:48 +0000
From:   James Morse <james.morse@....com>
To:     Sodagudi Prasad <psodagud@...eaurora.org>, shijie.huang@....com
CC:     catalin.marinas@....com, will.deacon@....com, mark.rutland@....com,
        akpm@...ux-foundation.org, sandeepa.s.prabhu@...il.com,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: <Query> Looking more details and reasons for using orig_add_limit.

Hi Prasad,

On 15/02/17 05:52, Sodagudi Prasad wrote:
> When any sys call is made from user space orig_addr_limit will be zero and after
> that driver is calling set_fs(KERNEL_DS) and  then copy_to_user() to user space
> memory. 

Don't do this, its exactly the case PAN+UAO and the code you pointed to are
designed to catch. Accessing userspace needs doing carefully, setting USER_DS
and using the put_user()/copy_to_user() accessors are the required steps.

Which driver is doing this? Is it in mainline?

> If there is permission fault for user space address the above condition
> is leading to kernel crash. Because orig_add_limit is having KERNEL_DS as set_fs
> called before copy_to_user().
> 
> 1)    So I would like to understand that,  is that user space pointer leading to
> permission fault not correct(condition_1) in this scenario?

The correct thing has happened here. To access user space set_fs(USER_DS) first.
(and set it back to whatever it was afterwards).

> 2)    Are there any corner cases where these if conditions (condition_1 and
> condition2) would lead to kernel crash ?

If you do this on behalf of a user space process the kernel will try to clean up
as best it can and carry on. If you access user space from an interrupt handler
or from a kernel thread you can expect the kernel to panic().

> 3)    What are all scenarios these if conditions (condition_1 and condition2) 
> would like to take care?

I'm not sure I understand this question. PAN prevents general kernel code from
accessing user space, you have to use the accessors. When you have UAO too, it
can enforce the set_fs() limit as PAN will generate permission faults when the
accessors touch the kernel/user-space after setting the other set_fs() limit.

I hope this helps!

Thanks,

James