Saturday, February 8, 2014

Irp->UserBuffer mess

Have you ever asked yourself a question - should a driver check Irp->UserBufer using ProbeForRead/Write depending on the previous mode (UserMode or KernelMode)?
The answer is - not it should not as the IO Manager already did this in NtReadFile or NtWriteFile or NtDeviceIoControlFile. This means that it is legitimate to receive Irp->UserBuffer pointing to the kernel space when previous mode is UserMode, e.g. this happens when a third party driver issues an IRP or substitutes the buffer.

Some file system drivers wrongly use Irp->RequestorMode to decide on calling ProbeForRead/ProbeForWrite , for example rdpdr.sys does this, in that case the best tactic is changing Irp->RequestorMode to KernelMode if the buffer is changed to a buffer allocated in the system address space, but do not forget to change the buffer, MdlAddress and RequestorMode to original one in your completion routine or the system might BSOD while completing IRP .

P.S. Though I am talking here about buffers substituting for read and write requests I strongly discourage to use this technique to implement an FSD filter that transparently changes file data. This approach will not work in general. The only viable solution for this case is so called FSD over FSD implementation, I will discuss this approach in a future post.
 Another word of caution - you must use SEH ( try/except ) while accessing a buffer for an IRP with previous mode set to UserMode, this does not hurt if a buffer happens to be in a kernel space because of actions of an upper filter.

No comments:

Post a Comment