Im writing a bus driver. A WDFREQUEST gets sent into my queue from a lower level device driver. I get the memory address of the WDFREQUEST and send the address out of the kernel in a TCP/IP message. The address arrives back in an IOCTL sometime later in another thread context. I try to dereference the address handed to me to get the original WDFREQUEST as i want to complete it, but it bugchecks, when i try to get the params of the request. Im thinking somehow the address of the WDFREQUEST is not valid in another thread context?
Is this correct, before i rearchitect my solution i wanted to check this?
> Im writing a bus driver. A WDFREQUEST gets sent into my queue from a lower level device driver. I
get the memory address of the WDFREQUEST and send the address out of the kernel in a TCP/IP
Not allowed at all.
KMDF objects cannot cross the driver boundary. So, lower driver must never ever use WDFREQUEST of the upper driver.
Actually, when the IRP enters the lower driver, KMDF allocates a new WDFREQUEST for it.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
technically this can work, but i question if it is a good design or not. Do you complete the rqeuest in the interim where you pass it back as a value to the app and it resends the value back down? Regardless, you have no way to validate that the WDFREQUEST value that the app passes back to you is a valid WDFREQUEST handle value. withouth validation, this is an open ended attack on your driver and can be leveraged by anyone to make your driver do lots of nasty things that it was not intended for. Since you are going to have to validate the value the app passes back, make it something you can validate … for instnace, something like a ULONG. You can then use that value to index an array or linked list, first making sure it is within range and what you expect.
d