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