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