I can’t seem to cause this kernel driver to fail, but it seems like it should.
This particular driver is an old software-only component that is quite old, but had been ported to KMDF before I became responsible for it. It has a couple METHOD_NEITHER IOCTLS that I need to preserve to maintain compatibility with older user mode software. Currently the driver is built with KMDF 1.9 to cover the OS versions it needs to be compatible with.
One of these IOCTLs passes in a user mode buffer containing a structure with an embedded pointer. Inspection of the EvtIoInCallerContext callback shows that the input buffer is being retrieved by WdfRequestRetrieveUnsafeUserInputBuffer() and locked down using WdfRequestProbeAndLockUserBufferForRead(), but no such processing is being performed for the structure pointed to by the embedded pointer (which is actually the head of a singly-linked list that gets traversed in the IOCTL’s handler, so there may be more than one buffer that needs locking).
It seems like this should be very fragile, since the IOCTL handler will only be able to read data from the embedded pointer if it’s running in the address context of the user process — which it must be doing. In my testing of this IOCTL, I have not seen any problems, even with multiple user processes calling into it.
This IOCTL is always being used synchronously, so there’s no overlapped I/O in play.
Any insight about why this IOCTL is getting lucky, and how its luck might possibly run out? Ideally I’d like to find a way to demonstrate the code has a practical issue before fixing it.
Thanks,
Dave