Re: Accessing pointers inside struct passed as argument to ioctl calls

Okay, thank you for the tips Kenneth! This is not real code but the case is, so I will do that checks that you pointed out!! Thanks again! Best regards, - dhs 2015-09-28 14:09 GMT-03:00 Kenneth Adam Miller : > You are right, and thank you for bringing this to the

Accessing pointers inside struct passed as argument to ioctl calls

Hi all, I have a doubt about using pointers inside structs that are passed (as pointers) to ioctl argument. Since pointers passed from userspace can't be trusted, I need to copy they to kernel before accessing they. In this case I have a pointer inside a struct that is passed to the ioctl call

Re: Accessing pointers inside struct passed as argument to ioctl calls

You are right, and thank you for bringing this to the mailing list to be sure about it. There are several catastrophic vulnerabilities I can see waiting to happen. First, you should be sure that the pointer that they passed in is checked, as in the pointer to the buffer should only reside in the

Re: Accessing pointers inside struct passed as argument to ioctl calls

Hi Yann, thank you, as I said this isn't real code, I just use to show my case. Anyway I will take the considerations in account. Thank you so much! And this get_user_page is new to me, thanks for pointing me out, I will read about it. The real thing is a driver to nrf24l01+ driver from Nordic. I

Re: Accessing pointers inside struct passed as argument to ioctl calls

I'm pretty sure that exchanging ownership of memory pages between the kernel and userland is a really huge no-go for security as well. If you do that, you've implicitly given the user control of the memory map table contents, so you have to think like a malicious abuser of your api would. Copy

Re: Accessing pointers inside struct passed as argument to ioctl calls

On Mon, 28 Sep 2015 19:59:41 -0300, "Daniel." said: > The real thing is a driver to nrf24l01+ driver from Nordic. I may use this > non copying aproach to exchange lot of frames without copying. This would > improve driver's performance. :) There is already well-developed zero-copy code for