Another NT4 IopParseDevice bug.

NTDEV
1

Maybe this is a candidate for OSR bug list?

NT4 BUG

STATUS_REPARSE handling path in IopParseDevice calls
ExFreePool(CompleteName->Buffer) without
checking whether this is NULL.
Usually, CompleteName->Buffer is never NULL. But SRV calls IoCreateFile for
relative open
with NameFromObjectAttributes->Length == 0. In this case, the Obxxx routines
build a
CompleteName with NULL buffer.
SRV uses such opens to list files immediately under the share.
If the FSF uses STATUS_REPARSE - this causes BSOD under SRV.

WORKAROUND

OurParseDevice function (the hooked Parse method for Device object type)
must do the
following:

  • check CompleteName->Buffer to be non-NULL
  • if it is NULL - allocate a dummy buffer from paged pool with ‘IoNm’ tag of
    some dummy size
  • set CompleteName->MaximumLength to zero
  • remember the allocated pointer
  • if, on exit from real IopParseDevice, CompleteName->Buffer is equal to the
    saved pointer -
    then free it and zero the whole CompleteName back.
    The File type Parse method must be patched the same way.
    IoDeviceObjectType is not exported by the kernel. We will look in the
    undocumented header of
    any device object to find it. The type pointer is 4 ULONGs back from the
    object body.

Is there any such bug in w2k or XP?

Max

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

2

Max, I want to correct you a little …

  1. File object type Parse method doesn’t need to be patched
    because everything it does is:
  • check if the ParseContext is of type IO_OPEN_PACKET and has proper
    size
  • set the OpenPacket->RelatedFileObject to ParseObject
  • call IopParseDevice with all its arguments unchanged except
    ParseObject
    which is set to
    IoGetRelatedDeviceObject((PFILE_OBJECT)ParseObject);
    So I think there is no need to patch IopParseFile because everything
    needed
    will be done in path of Device object type Parse method.

  1. NT 4 NTOSKRNL exports IoDeviceObjectType so there is no need for
    touching
    the device object header itself to find out the Device object type
    pointer.

  2. Also I think there is no need for the check on exit. Simply check the
    buffer
    pointer on the entry and if it’s NULL allocate some short buffer (for
    eg. 8 bytes)
    and set the Buffer pointer to it and don’t forget to set
    MaximumLength to your length
    and Length to zero (because even if the buffer is allocated and has
    non-zero size it
    contains no valid data, so Length must be zero and MaximumLength
    should be set
    to real size of the buffer).

Please tell me what do you think about my notes.

Paul

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Maxim S. Shatskih
Sent: Monday, August 20, 2001 8:55 PM
To: NT Developers Interest List
Subject: [ntdev] Another NT4 IopParseDevice bug.

Maybe this is a candidate for OSR bug list?

NT4 BUG

STATUS_REPARSE handling path in IopParseDevice calls
ExFreePool(CompleteName->Buffer) without
checking whether this is NULL.
Usually, CompleteName->Buffer is never NULL. But SRV calls IoCreateFile
for
relative open
with NameFromObjectAttributes->Length == 0. In this case, the Obxxx
routines
build a
CompleteName with NULL buffer.
SRV uses such opens to list files immediately under the share.
If the FSF uses STATUS_REPARSE - this causes BSOD under SRV.

WORKAROUND

OurParseDevice function (the hooked Parse method for Device object type)
must do the
following:

  • check CompleteName->Buffer to be non-NULL
  • if it is NULL - allocate a dummy buffer from paged pool with ‘IoNm’
    tag of
    some dummy size
  • set CompleteName->MaximumLength to zero
  • remember the allocated pointer
  • if, on exit from real IopParseDevice, CompleteName->Buffer is equal to
    the
    saved pointer -
    then free it and zero the whole CompleteName back.
    The File type Parse method must be patched the same way.
    IoDeviceObjectType is not exported by the kernel. We will look in the
    undocumented header of
    any device object to find it. The type pointer is 4 ULONGs back from the
    object body.

Is there any such bug in w2k or XP?

Max

You are currently subscribed to ntdev as: xxxxx@compelson.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

3

> So I think there is no need to patch IopParseFile because everything

needed
will be done in path of Device object type Parse method.

Wrong, it calls IopParseDevice directly and not by means of the Device’s
VTBL.

  1. NT 4 NTOSKRNL exports IoDeviceObjectType so there is no need for
    touching the device object header itself to find out the Device object type
    pointer.

At least it is not in DDK, though thanks anyway, a good idea.

  1. Also I think there is no need for the check on exit. Simply check the
    buffer
    pointer on the entry and if it’s NULL allocate some short buffer (for

This can lead to a leak.
I don’t know how ObpLookupObjectName works - maybe it will not ExFreePool
our pointer, assuming that if it was zero before the Parse call, it must be
zero after Parse too.

Max

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

4

Max, I’m really sorry for my mistake.
Of course it’s not possible to force the IopParseFile to
call your routine - you must patch even IopParseFile to succeed.

The third question may be answered by someone at Microsoft
(but I don’t believe in such disclosure of Obejct Manager rules :-))

Paul

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Maxim S. Shatskih
Sent: Wednesday, August 22, 2001 7:17 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Another NT4 IopParseDevice bug.

So I think there is no need to patch IopParseFile because everything
needed
will be done in path of Device object type Parse method.

Wrong, it calls IopParseDevice directly and not by means of the Device’s
VTBL.

  1. NT 4 NTOSKRNL exports IoDeviceObjectType so there is no need for
    touching the device object header itself to find out the Device object
    type
    pointer.

At least it is not in DDK, though thanks anyway, a good idea.

  1. Also I think there is no need for the check on exit. Simply check
    the
    buffer
    pointer on the entry and if it’s NULL allocate some short buffer
    (for

This can lead to a leak.
I don’t know how ObpLookupObjectName works - maybe it will not
ExFreePool
our pointer, assuming that if it was zero before the Parse call, it must
be
zero after Parse too.

Max

You are currently subscribed to ntdev as: xxxxx@compelson.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com