Non re-entrant call to IoCreateFileSpecifyDeviceObjectHint by sr.sys

Has anyone else seen evidence that SR is causing re-entracy? Back in 2003
Mathhew white posted a suggestive stack but the conversation was more about
IoCancelFileOpen.

Anyway, my filter is performing a IoCreateFileSpecifyDeviceObjectHint with a
fully formed file name (including a stream) and I am getting called again at
my create entry point. The filters are layered: my filter on top of SR on
top of NTFS.

This a segment of the callstack at the point of failure:

[…]
f828da28 80a21a41 myfiltr!FilterCreateDispatch+0x63e
f828da40 80cd4128 nt!IopfCallDriver+0x51
f828da64 80b36553 nt!IovCallDriver+0xa0
f828db48 80bb1e58 nt!IopParseDevice+0xba7
f828dbc0 80bac310 nt!ObpLookupObjectName+0x590
f828dc14 80b236fb nt!ObOpenObjectByName+0x140
f828dc90 80b242f0 nt!IopCreateFile+0x43b
f828dcd8 ba6bdea5 nt!IoCreateFileSpecifyDeviceObjectHint+0x52
f828de78 ba6be6d1 sr!SrpExpandPathOfFileName+0x111
f828de98 ba6be873 sr!SrpGetFileNameFromFileObject+0xe7
f828dffc ba6b98c2 sr!SrFileAlreadyExists+0x5f
f828e054 80a21a41 sr!SrCreate+0x19c
f828e06c 80cd4128 nt!IopfCallDriver+0x51
f828e090 80b36553 nt!IovCallDriver+0xa0
f828e174 80bb1e58 nt!IopParseDevice+0xba7
f828e1ec 80bac310 nt!ObpLookupObjectName+0x590
f828e240 80b236fb nt!ObOpenObjectByName+0x140
f828e2bc 80b242f0 nt!IopCreateFile+0x43b
f828e304 f4441ab7 nt!IoCreateFileSpecifyDeviceObjectHint+0x52
f828e34c f4441908 myfiltr!FilterForwardCreateIrp+0x47
[…]

Note that the call I have made to IoCreateFileSpecifyDeviceObjectHint has
gone to SR, but the call that SR made has come back to me.

Picking around with the debugger, the parameters I have called
IoCreateFileSpecifyDeviceObjectHint with are:

DesiredAccess : GENERIC_WRITE
ObjectAttributes:
RootDir : NULL
ObjectName : \Device\HarddiskVolume3:streamName
Attributes : OBJ_KERNEL_HANDLE
AllocationSize : NULL
FileAttributes : FILE_ATTRIBUTE_NORMAL
ShareAccess : 0
Disposition : FILE_CREATE
CreateOptions : FILE_NON_DIRECTORY_FILE
EaBuffer : NULL
EaLength : 0
CreateFileType : CreateFileTypeNone
ExtraCreateParameters: NULL
Options : IO_IGNORE_SHARE_ACCESS_CHECK
DeviceObject :

and the one SR has called:

DesiredAccess : SYNCHRONIZE
ObjectAttributes:
RootDir : NULL
ObjectName: \Device\HarddiskVolume3:streamName
Attributes: OBJ_KERNEL_HANDLE
AllocationSize : NULL
FileAttributes : FILE_ATTRIBUTE_NORMAL
ShareAccess : FILE_SHARE_READ | FILE_SHARE_WRITE
Disposition : FILE_OPEN
CreateOptions : FILE_OPEN_FOR_BACKUP_INTENT | FILE_SYNCHRONOUS_IO_NONALERT |
FILE_DIRECTORY_FILE
EaBuffer : 0
EaLength : 0
CreateFileType : 0
ExtraCreateParameters: 0
Options : IO_IGNORE_SHARE_ACCESS_CHECK
DeviceObject : NULL

Obviously the NULL parameter as DeviceObject stands out and I’m pretty
sure that I decoded the stack correctly. Options looks sensible but
CreateOptions looks strange.

Immediately before the call which causes this re-entrancy I have tried
to do a create with disposition FILE_OPEN and that has not caused any
re-entrancy.

This is WXP SP2, checked Kernel and HAL. The SR.SYS has a signature
for windbg of “sr.pdb\B2985B1EA5A340DCA067B59677B5CAAF1\sr.pdb”.

/rod

Rod,

If IoCreateFileSpecifyDeviceObjectHint is passed a
NULL device object it goes to the top of the stack, so
I think you are looking at that correctly.

There is a bigger point here though, and that is that
even though you are calling
IoCreateFileSpecifyDeviceObjectHint that does not
guarantee that you will not be reentered by another
filter below you. It seems broken to me but according
to Neal C., “that’s the way it is and you have to deal
with it.”

Try installing the latest version of a very popular AV
product and you will see all kinds of this type of
reentrancy.

— Rod Widdowson wrote:

> Has anyone else seen evidence that SR is causing
> re-entracy? Back in 2003
> Mathhew white posted a suggestive stack but the
> conversation was more about
> IoCancelFileOpen.
>
> Anyway, my filter is performing a
> IoCreateFileSpecifyDeviceObjectHint with a
> fully formed file name (including a stream) and I am
> getting called again at
> my create entry point. The filters are layered: my
> filter on top of SR on
> top of NTFS.
>
> This a segment of the callstack at the point of
> failure:
>
> […]
> f828da28 80a21a41 myfiltr!FilterCreateDispatch+0x63e
> f828da40 80cd4128 nt!IopfCallDriver+0x51
> f828da64 80b36553 nt!IovCallDriver+0xa0
> f828db48 80bb1e58 nt!IopParseDevice+0xba7
> f828dbc0 80bac310 nt!ObpLookupObjectName+0x590
> f828dc14 80b236fb nt!ObOpenObjectByName+0x140
> f828dc90 80b242f0 nt!IopCreateFile+0x43b
> f828dcd8 ba6bdea5
> nt!IoCreateFileSpecifyDeviceObjectHint+0x52
> f828de78 ba6be6d1 sr!SrpExpandPathOfFileName+0x111
> f828de98 ba6be873
> sr!SrpGetFileNameFromFileObject+0xe7
> f828dffc ba6b98c2 sr!SrFileAlreadyExists+0x5f
> f828e054 80a21a41 sr!SrCreate+0x19c
> f828e06c 80cd4128 nt!IopfCallDriver+0x51
> f828e090 80b36553 nt!IovCallDriver+0xa0
> f828e174 80bb1e58 nt!IopParseDevice+0xba7
> f828e1ec 80bac310 nt!ObpLookupObjectName+0x590
> f828e240 80b236fb nt!ObOpenObjectByName+0x140
> f828e2bc 80b242f0 nt!IopCreateFile+0x43b
> f828e304 f4441ab7
> nt!IoCreateFileSpecifyDeviceObjectHint+0x52
> f828e34c f4441908
> myfiltr!FilterForwardCreateIrp+0x47
> […]
>
> Note that the call I have made to
> IoCreateFileSpecifyDeviceObjectHint has
> gone to SR, but the call that SR made has come back
> to me.
>
> Picking around with the debugger, the parameters I
> have called
> IoCreateFileSpecifyDeviceObjectHint with are:
>
> DesiredAccess : GENERIC_WRITE
> ObjectAttributes:
> RootDir : NULL
> ObjectName : \Device\HarddiskVolume3:streamName
> Attributes : OBJ_KERNEL_HANDLE
> AllocationSize : NULL
> FileAttributes : FILE_ATTRIBUTE_NORMAL
> ShareAccess : 0
> Disposition : FILE_CREATE
> CreateOptions : FILE_NON_DIRECTORY_FILE
> EaBuffer : NULL
> EaLength : 0
> CreateFileType : CreateFileTypeNone
> ExtraCreateParameters: NULL
> Options : IO_IGNORE_SHARE_ACCESS_CHECK
> DeviceObject :
>
> and the one SR has called:
>
> DesiredAccess : SYNCHRONIZE
> ObjectAttributes:
> RootDir : NULL
> ObjectName: \Device\HarddiskVolume3:streamName
> Attributes: OBJ_KERNEL_HANDLE
> AllocationSize : NULL
> FileAttributes : FILE_ATTRIBUTE_NORMAL
> ShareAccess : FILE_SHARE_READ | FILE_SHARE_WRITE
> Disposition : FILE_OPEN
> CreateOptions : FILE_OPEN_FOR_BACKUP_INTENT |
> FILE_SYNCHRONOUS_IO_NONALERT |
> FILE_DIRECTORY_FILE
> EaBuffer : 0
> EaLength : 0
> CreateFileType : 0
> ExtraCreateParameters: 0
> Options : IO_IGNORE_SHARE_ACCESS_CHECK
> DeviceObject : NULL
>
> Obviously the NULL parameter as DeviceObject stands
> out and I’m pretty
> sure that I decoded the stack correctly. Options
> looks sensible but
> CreateOptions looks strange.
>
> Immediately before the call which causes this
> re-entrancy I have tried
> to do a create with disposition FILE_OPEN and that
> has not caused any
> re-entrancy.
>
> This is WXP SP2, checked Kernel and HAL. The SR.SYS
> has a signature
> for windbg of
> “sr.pdb\B2985B1EA5A340DCA067B59677B5CAAF1\sr.pdb”.
>
> /rod
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as:
> xxxxx@yahoo.com
> To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>

Thanks Randy,

It seems broken to me but according
to Neal C., “that’s the way it is and you have to deal
with it.”

Oh yes, been there done that, bought the T shirt, I’ll “'just” handle it.
I was surpised to see Sr do this tho’.

Try installing the latest version of a very popular AV
product and you will see all kinds of this type of
reentrancy.

Don’t start me…

/r