Validating parameters for IoDeviceControl in KMDF -> KMDF verifier error

When testing my driver to be crash safe for various user input, I came
across an issue in my driver that I don't know how to handle. To eliminate
my own driver, I tested the same thing with the original WDK (WDK 6000)
sample osrusbfx2 driver. By modifying the testapp to send erronous input to
the driver, I could get the error/break even there. The sample uses the
parameters\wdf\DbgBreakOnError = 1. Now I wonder how it should be handled by
the driver, as the KMDF says it's an error.

How to reproduce:
To have some common code to look at, I use the sample KMDF osrusbfx2.
Modify the testapp to call the driver with
IOCTL_OSRUSBFX2_GET_7_SEGMENT_DISPLAY and put erronous parameters in the
call:
if (!DeviceIoControl(deviceHandle,
IOCTL_OSRUSBFX2_GET_7_SEGMENT_DISPLAY,
&sevenSegment, // Ptr to InBuffer,
NULL in example
sizeof(UCHAR), // Length of
InBuffer, 0 in example
&sevenSegment, // Ptr to OutBuffer
0, // Length of
OutBuffer
&index, // BytesReturned
0)) { // Ptr to Overlapped
structure

I've only seen it when input buffer pointer and length is valid and the
output buffer pointer is correct but oputput buffer length is zero.

By turning on Parameters\Wdf\DbgBreakOnError, I get:
>KMDF detected potentially invalid operation by canusb.sys. Turn on
>framework verifier to break into the debugger.

Turning on the verifier gives me
>410: FxRequest::CompleteInternal - Caller of this WDFREQUEST 7A104170, Irp
>0x862BB398 is passing an OuputBuffer address even though the
>OutputBufferLength is zero
<yes, there is a spell error in the log: OuputBuffer>

So, here's my question: if this is a driver error, how can it be corrected?
If this is just invalid parameters, why does the KMDF verifier break to the
debugger?

Regards,
Carl-Magnus Segerlund

Doron
Tue Jan 29 14:58:42 CST 2008

this is a bit of an overactive check, you can selectively ignore it if you
know what to check for

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.


"Carl-Magnus" <news@deletethis.driverguru.se.deletethis> wrote in message
news:e9DghQoYIHA.4684@TK2MSFTNGP06.phx.gbl...
> When testing my driver to be crash safe for various user input, I came
> across an issue in my driver that I don't know how to handle. To eliminate
> my own driver, I tested the same thing with the original WDK (WDK 6000)
> sample osrusbfx2 driver. By modifying the testapp to send erronous input
> to the driver, I could get the error/break even there. The sample uses the
> parameters\wdf\DbgBreakOnError = 1. Now I wonder how it should be handled
> by the driver, as the KMDF says it's an error.
>
> How to reproduce:
> To have some common code to look at, I use the sample KMDF osrusbfx2.
> Modify the testapp to call the driver with
> IOCTL_OSRUSBFX2_GET_7_SEGMENT_DISPLAY and put erronous parameters in the
> call:
> if (!DeviceIoControl(deviceHandle,
> IOCTL_OSRUSBFX2_GET_7_SEGMENT_DISPLAY,
> &sevenSegment, // Ptr to InBuffer,
> NULL in example
> sizeof(UCHAR), // Length of
> InBuffer, 0 in example
> &sevenSegment, // Ptr to OutBuffer
> 0, // Length of
> OutBuffer
> &index, // BytesReturned
> 0)) { // Ptr to Overlapped
> structure
>
> I've only seen it when input buffer pointer and length is valid and the
> output buffer pointer is correct but oputput buffer length is zero.
>
> By turning on Parameters\Wdf\DbgBreakOnError, I get:
>>KMDF detected potentially invalid operation by canusb.sys. Turn on
>>framework verifier to break into the debugger.
>
> Turning on the verifier gives me
>>410: FxRequest::CompleteInternal - Caller of this WDFREQUEST 7A104170, Irp
>>0x862BB398 is passing an OuputBuffer address even though the
>>OutputBufferLength is zero
> <yes, there is a spell error in the log: OuputBuffer>
>
> So, here's my question: if this is a driver error, how can it be
> corrected? If this is just invalid parameters, why does the KMDF verifier
> break to the debugger?
>
> Regards,
> Carl-Magnus Segerlund
>

Carl-Magnus
Fri Feb 01 04:05:29 CST 2008

Ok, there's a way around in testing, but then I can't have DbgBreakOnError
set for my long time tests to catch those real errors. What I wonder is if
this really should be marked as an error when the driver does nothing wrong.
In this case, it's the user that sends bad indata. Am I right?

I see it as a security risk; if a driver uses the default inf from a driver
in the KMDF, it will have BreakOnError set and a user can send a faulty
IoDeviceControl that will crash the system (if the user can open the driver
i.e.). And a driver writer can't do anything (except make sure the registry
entry isn't there at release) to stop it from crashing. I suppose someone
more than I has forgotten to clean up the inf before release (at least my
internal testing found the error)...

Carl-Magnus

"Doron Holan [MSFT]" <doronh@online.microsoft.com> wrote in message
news:u4Cx7mrYIHA.4828@TK2MSFTNGP05.phx.gbl...
> this is a bit of an overactive check, you can selectively ignore it if you
> know what to check for
>
> d
>
> --
> Please do not send e-mail directly to this alias. this alias is for
> newsgroup purposes only.
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
>
>
> "Carl-Magnus" <news@deletethis.driverguru.se.deletethis> wrote in message
> news:e9DghQoYIHA.4684@TK2MSFTNGP06.phx.gbl...
>> When testing my driver to be crash safe for various user input, I came
>> across an issue in my driver that I don't know how to handle. To
>> eliminate my own driver, I tested the same thing with the original WDK
>> (WDK 6000) sample osrusbfx2 driver. By modifying the testapp to send
>> erronous input to the driver, I could get the error/break even there. The
>> sample uses the parameters\wdf\DbgBreakOnError = 1. Now I wonder how it
>> should be handled by the driver, as the KMDF says it's an error.
>>
>> How to reproduce:
>> To have some common code to look at, I use the sample KMDF osrusbfx2.
>> Modify the testapp to call the driver with
>> IOCTL_OSRUSBFX2_GET_7_SEGMENT_DISPLAY and put erronous parameters in the
>> call:
>> if (!DeviceIoControl(deviceHandle,
>> IOCTL_OSRUSBFX2_GET_7_SEGMENT_DISPLAY,
>> &sevenSegment, // Ptr to InBuffer,
>> NULL in example
>> sizeof(UCHAR), // Length of
>> InBuffer, 0 in example
>> &sevenSegment, // Ptr to OutBuffer
>> 0, // Length of
>> OutBuffer
>> &index, // BytesReturned
>> 0)) { // Ptr to
>> Overlapped structure
>>
>> I've only seen it when input buffer pointer and length is valid and the
>> output buffer pointer is correct but oputput buffer length is zero.
>>
>> By turning on Parameters\Wdf\DbgBreakOnError, I get:
>>>KMDF detected potentially invalid operation by canusb.sys. Turn on
>>>framework verifier to break into the debugger.
>>
>> Turning on the verifier gives me
>>>410: FxRequest::CompleteInternal - Caller of this WDFREQUEST 7A104170,
>>>Irp 0x862BB398 is passing an OuputBuffer address even though the
>>>OutputBufferLength is zero
>> <yes, there is a spell error in the log: OuputBuffer>
>>
>> So, here's my question: if this is a driver error, how can it be
>> corrected? If this is just invalid parameters, why does the KMDF verifier
>> break to the debugger?
>>
>> Regards,
>> Carl-Magnus Segerlund
>>
>

Doron
Mon Feb 04 14:42:57 CST 2008

you should never ship an INF which has BreakOnError set. if you did, this
is not an error in kmdf, rather an error made by the manfucaturer. this the
same shipping debug only code in a release driver.

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.


"Carl-Magnus" <news@deletethis.driverguru.se.deletethis> wrote in message
news:u8YU9nLZIHA.4324@TK2MSFTNGP03.phx.gbl...
> Ok, there's a way around in testing, but then I can't have DbgBreakOnError
> set for my long time tests to catch those real errors. What I wonder is if
> this really should be marked as an error when the driver does nothing
> wrong. In this case, it's the user that sends bad indata. Am I right?
>
> I see it as a security risk; if a driver uses the default inf from a
> driver in the KMDF, it will have BreakOnError set and a user can send a
> faulty IoDeviceControl that will crash the system (if the user can open
> the driver i.e.). And a driver writer can't do anything (except make sure
> the registry entry isn't there at release) to stop it from crashing. I
> suppose someone more than I has forgotten to clean up the inf before
> release (at least my internal testing found the error)...
>
> Carl-Magnus
>
> "Doron Holan [MSFT]" <doronh@online.microsoft.com> wrote in message
> news:u4Cx7mrYIHA.4828@TK2MSFTNGP05.phx.gbl...
>> this is a bit of an overactive check, you can selectively ignore it if
>> you know what to check for
>>
>> d
>>
>> --
>> Please do not send e-mail directly to this alias. this alias is for
>> newsgroup purposes only.
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>>
>>
>> "Carl-Magnus" <news@deletethis.driverguru.se.deletethis> wrote in message
>> news:e9DghQoYIHA.4684@TK2MSFTNGP06.phx.gbl...
>>> When testing my driver to be crash safe for various user input, I came
>>> across an issue in my driver that I don't know how to handle. To
>>> eliminate my own driver, I tested the same thing with the original WDK
>>> (WDK 6000) sample osrusbfx2 driver. By modifying the testapp to send
>>> erronous input to the driver, I could get the error/break even there.
>>> The sample uses the parameters\wdf\DbgBreakOnError = 1. Now I wonder how
>>> it should be handled by the driver, as the KMDF says it's an error.
>>>
>>> How to reproduce:
>>> To have some common code to look at, I use the sample KMDF osrusbfx2.
>>> Modify the testapp to call the driver with
>>> IOCTL_OSRUSBFX2_GET_7_SEGMENT_DISPLAY and put erronous parameters in the
>>> call:
>>> if (!DeviceIoControl(deviceHandle,
>>> IOCTL_OSRUSBFX2_GET_7_SEGMENT_DISPLAY,
>>> &sevenSegment, // Ptr to
>>> InBuffer, NULL in example
>>> sizeof(UCHAR), // Length of
>>> InBuffer, 0 in example
>>> &sevenSegment, // Ptr to
>>> OutBuffer
>>> 0, // Length of
>>> OutBuffer
>>> &index, // BytesReturned
>>> 0)) { // Ptr to
>>> Overlapped structure
>>>
>>> I've only seen it when input buffer pointer and length is valid and the
>>> output buffer pointer is correct but oputput buffer length is zero.
>>>
>>> By turning on Parameters\Wdf\DbgBreakOnError, I get:
>>>>KMDF detected potentially invalid operation by canusb.sys. Turn on
>>>>framework verifier to break into the debugger.
>>>
>>> Turning on the verifier gives me
>>>>410: FxRequest::CompleteInternal - Caller of this WDFREQUEST 7A104170,
>>>>Irp 0x862BB398 is passing an OuputBuffer address even though the
>>>>OutputBufferLength is zero
>>> <yes, there is a spell error in the log: OuputBuffer>
>>>
>>> So, here's my question: if this is a driver error, how can it be
>>> corrected? If this is just invalid parameters, why does the KMDF
>>> verifier break to the debugger?
>>>
>>> Regards,
>>> Carl-Magnus Segerlund
>>>
>>
>