Null ptr dereference in FltReissueSynchronousIo when reissuing from NTFS to FAT

I have a fltmgr filter where in the post-MJ_DIRECTORY_CONTROL callback I
open another file object from a FAT volume and call FltReissueSynchronousIo
on it. The original operation is on an NTFS volume.

This has worked on ntfs->ntfs since the driver was first written, but I
only just tested on ntfs->fat, and it ends up dereferencing a NULL field
from a _FCB structure (I assume, from the FatF tag) as soon as it enters
NtfsCommonDirectoryControl.

The field in the _FCB is at offset 0x78 on a win7-x64. I haven’t figured
out yet how to display it in windbg, dt 0x… _FCB doesn’t find the
structure definition). The callstack is:

Ntfs!NtfsCommonDirectoryControl+0x35
Ntfs!NtfsFsdDirectoryControl
nt!IovCallDriver
fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted
fltmgr!FltReissueSynchronousIo

Besides the initial question (what’s the FCB field that I forget to fill
in), the second one is, why it ends up in ntfs, when the fs is fat. Is it
because the original operation was on ntfs and I reissue it ? Is doing a
cross-fstype reissue supported ?

Thanks.

You *are* setting the TargetInstance and TargetFileObject I guess.

I’d be inclined to look at the parameters passed to IoCallDriver. But your best bet is probably to just build your own CBD and populate the result accordingly.

“Bogdan Harjoc” wrote in message news:xxxxx@ntfsd…
I have a fltmgr filter where in the post-MJ_DIRECTORY_CONTROL callback I open another file object from a FAT volume and call FltReissueSynchronousIo on it. The original operation is on an NTFS volume.

This has worked on ntfs->ntfs since the driver was first written, but I only just tested on ntfs->fat, and it ends up dereferencing a NULL field from a _FCB structure (I assume, from the FatF tag) as soon as it enters NtfsCommonDirectoryControl.

The field in the _FCB is at offset 0x78 on a win7-x64. I haven’t figured out yet how to display it in windbg, dt 0x… _FCB doesn’t find the structure definition). The callstack is:

Ntfs!NtfsCommonDirectoryControl+0x35
Ntfs!NtfsFsdDirectoryControl
nt!IovCallDriver
fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted
fltmgr!FltReissueSynchronousIo

Besides the initial question (what’s the FCB field that I forget to fill in), the second one is, why it ends up in ntfs, when the fs is fat. Is it because the original operation was on ntfs and I reissue it ? Is doing a cross-fstype reissue supported ?

Thanks.

You *are* setting the TargetInstance and TargetFileObject I guess.

I’d be inclined to look at the parameters passed to IoCallDriver. But your best bet is probably to just build your own CBD and populate the result accordingly.

Rod
“Bogdan Harjoc” wrote in message news:xxxxx@ntfsd…
I have a fltmgr filter where in the post-MJ_DIRECTORY_CONTROL callback I open another file object from a FAT volume and call FltReissueSynchronousIo on it. The original operation is on an NTFS volume.

This has worked on ntfs->ntfs since the driver was first written, but I only just tested on ntfs->fat, and it ends up dereferencing a NULL field from a _FCB structure (I assume, from the FatF tag) as soon as it enters NtfsCommonDirectoryControl.

The field in the _FCB is at offset 0x78 on a win7-x64. I haven’t figured out yet how to display it in windbg, dt 0x… _FCB doesn’t find the structure definition). The callstack is:

Ntfs!NtfsCommonDirectoryControl+0x35
Ntfs!NtfsFsdDirectoryControl
nt!IovCallDriver
fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted
fltmgr!FltReissueSynchronousIo

Besides the initial question (what’s the FCB field that I forget to fill in), the second one is, why it ends up in ntfs, when the fs is fat. Is it because the original operation was on ntfs and I reissue it ? Is doing a cross-fstype reissue supported ?

Thanks.

I am setting TargetInstance and TargetFileObject and doing
FltSetCallbackDataDirty(). The null pointer that
NtfsCommonDirectoryControl+0x35
is dereferencing is data->Iopb->TargetFileObject->FsContext, which is
probably not null on ntfs->ntfs.

On Thu, Feb 5, 2015 at 10:59 AM, Rod Widdowson
wrote:

> You are setting the TargetInstance and TargetFileObject I guess.
>
> I’d be inclined to look at the parameters passed to IoCallDriver. But
> your best bet is probably to just build your own CBD and populate the
> result accordingly.
>
> Rod
> “Bogdan Harjoc” wrote in message news:xxxxx@ntfsd…
> I have a fltmgr filter where in the post-MJ_DIRECTORY_CONTROL callback I
> open another file object from a FAT volume and call FltReissueSynchronousIo
> on it. The original operation is on an NTFS volume.
>
> This has worked on ntfs->ntfs since the driver was first written, but I
> only just tested on ntfs->fat, and it ends up dereferencing a NULL field
> from a _FCB structure (I assume, from the FatF tag) as soon as it enters
> NtfsCommonDirectoryControl.
>
> The field in the _FCB is at offset 0x78 on a win7-x64. I haven’t figured
> out yet how to display it in windbg, dt 0x… _FCB doesn’t find the
> structure definition). The callstack is:
>
> Ntfs!NtfsCommonDirectoryControl+0x35
> Ntfs!NtfsFsdDirectoryControl
> nt!IovCallDriver
> fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted
> fltmgr!FltReissueSynchronousIo
>
> Besides the initial question (what’s the FCB field that I forget to fill
> in), the second one is, why it ends up in ntfs, when the fs is fat. Is it
> because the original operation was on ntfs and I reissue it ? Is doing a
> cross-fstype reissue supported ?
>
> Thanks.
>
>
> —
> NTFSD is sponsored by OSR
>
> OSR is hiring!! Info at http://www.osr.com/careers
>
> For our schedule of debugging and file system seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

I mean NtfsCommonDirectoryControl is accessing FsContext+0x78, and that is
a NULL. FsContext is not null. It looks like a fat FCB that ends up in the
NTFS code.

On Thu, Feb 5, 2015 at 12:09 PM, Bogdan Harjoc wrote:

> I am setting TargetInstance and TargetFileObject and doing
> FltSetCallbackDataDirty(). The null pointer that NtfsCommonDirectoryControl+0x35
> is dereferencing is data->Iopb->TargetFileObject->FsContext, which is
> probably not null on ntfs->ntfs.
>
> On Thu, Feb 5, 2015 at 10:59 AM, Rod Widdowson
> wrote:
>
>> You are setting the TargetInstance and TargetFileObject I guess.
>>
>> I’d be inclined to look at the parameters passed to IoCallDriver. But
>> your best bet is probably to just build your own CBD and populate the
>> result accordingly.
>>
>> Rod
>> “Bogdan Harjoc” wrote in message news:xxxxx@ntfsd…
>> I have a fltmgr filter where in the post-MJ_DIRECTORY_CONTROL callback
>> I open another file object from a FAT volume and call
>> FltReissueSynchronousIo on it. The original operation is on an NTFS volume.
>>
>> This has worked on ntfs->ntfs since the driver was first written, but I
>> only just tested on ntfs->fat, and it ends up dereferencing a NULL field
>> from a _FCB structure (I assume, from the FatF tag) as soon as it enters
>> NtfsCommonDirectoryControl.
>>
>> The field in the _FCB is at offset 0x78 on a win7-x64. I haven’t figured
>> out yet how to display it in windbg, dt 0x… _FCB doesn’t find the
>> structure definition). The callstack is:
>>
>> Ntfs!NtfsCommonDirectoryControl+0x35
>> Ntfs!NtfsFsdDirectoryControl
>> nt!IovCallDriver
>> fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted
>> fltmgr!FltReissueSynchronousIo
>>
>> Besides the initial question (what’s the FCB field that I forget to fill
>> in), the second one is, why it ends up in ntfs, when the fs is fat. Is it
>> because the original operation was on ntfs and I reissue it ? Is doing a
>> cross-fstype reissue supported ?
>>
>> Thanks.
>>
>>
>> —
>> NTFSD is sponsored by OSR
>>
>> OSR is hiring!! Info at http://www.osr.com/careers
>>
>> For our schedule of debugging and file system seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>
>