Two different FCBs for same file leading to BSOD

Sanjeev-2 · August 4, 2024, 10:18am

Hello Guys. I have a few crash dumps where the BSOD is happening in our Section Sync Pre call. This is a pre-existing implementation where first we are calling FltQueryInformationFile() like so:

FltQueryInformationFile(FltObjects->Instance, FltObjects->FileObject, &fbi, sizeof(fbi), FileBasicInformation, NULL);

This works fine.

We then go onto create another FileObject on the same file using FltCreateFileEx (passing instance as NULL for some reason which will send the request to the top of the FS stack)

We pass the above obtained FileObject to a routine findFileLength which internally again calls FltQueryInformationFile() but this time with this fileobject and this leads to the crash.

!analyze -v output:

PAGE_FAULT_IN_NONPAGED_AREA (50)
Invalid system memory was referenced. This cannot be protected by try-except.
Typically the address is just plain bad or it is pointing at freed memory.
Arguments:
Arg1: ffffe58c7bba8030, memory referenced.
Arg2: 0000000000000000, value 0 = read operation, 1 = write operation.
Arg3: fffff80473769730, If non-zero, the instruction address which referenced the bad memory
address.
Arg4: 0000000000000000, (reserved)

TRAP_FRAME: ffffce81cddce690 -- (.trap 0xffffce81cddce690)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000000 rbx=0000000000000000 rcx=ffffbe83be3c73f8
rdx=ffffbe83c071b1e0 rsi=0000000000000000 rdi=0000000000000000
rip=fffff80473769730 rsp=ffffce81cddce820 rbp=ffffbe83be3c7010
r8=0000000000000005 r9=ffffe58c7bba7f80 r10=0000000000000000
r11=ffffce81cddce9b8 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei ng nz ac pe cy
Ntfs!NtfsInitializeIrpContextInternal+0x90:
fffff80473769730 4d39b1b0000000 cmp qword ptr [r9+0B0h],r14 ds:ffffe58c7bba8030=????????????????

STACK_TEXT:
ffffce81cddce3e8 fffff8046ee4b203 ffffce81cddce3f0 fffff8046ec6e7b0 ffffce81cddce4f0 fffff8046ee0bad8 ffffce81cddce690 fffff80473769730 ffffce81cddce820 fffff8047384ce62 ffffce81cddce890 fffff8047384cda0 ffffce81cddce9c0 fffff8046ec11385 ffffce81cddcec60 fffff8046c7f710f ffffce81cddceca0 fffff8046c7f879d ffffce81cddced10 fffff8046c8293eb ffffce81cddcedc0 fffff80476b3e1a7 ffffce81cddcee00 fffff80476b3bae6 ffffce81cddcee70 fffff8046c7f64cc ffffce81cddcefe0 fffff8046c7f2844 ffffce81cddcf100 fffff8046eca00a7 ffffce81cddcf1b0 fffff8046f080861 ffffce81cddcf220 fffff8046f0804cb ffffce81cddcf510 fffff8046f0803a7 ffffce81cddcf590 fffff8046f0800ad ffffce81cddcf5d0 fffff8046f07f894 ffffce81cddcf6c0 fffff8046f07f677 ffffce81cddcf840 fffff8046f07f45c ffffce81cddcf920 fffff8046ee0f7f5 ffffce81cddcf990 00007fffa28cd9f4 000000f8c5df96b8 0000000000000000 : 0000000000000050 ffffe58c7bba8030 0000000000000000 ffffce81cddce690 : nt!KeBugCheckEx
: ffffe58c7d6d8510 0000000000000000 ffffce81cddce710 0000000000000000 : nt!MiSystemFault+0x1b2813
: 0000000000000000 ffffe58c63bcd170 ffffbe83af467928 fffff8046ec406cf : nt!MmAccessFault+0x400
: ffffbe83b7bed6d0 fffff8046ec20ceb ffffce81cddd0000 fffff8046ec20ceb : nt!KiPageFault+0x358
: ffffce81cddce9e0 0000000000000008 0000000000000000 fffff8046ec265c8 : Ntfs!NtfsInitializeIrpContextInternal+0x90
: ffffce81cddce9e0 ffffbe83be3c7010 ffffbe83be3c7010 ffffbe83b1b8f068 : Ntfs!NtfsFsdDispatchSwitch+0xa2
: 0000000000000000 ffffce81cddced18 0000000000000000 0000000000000000 : Ntfs!NtfsFsdDispatchWait+0x40
: ffffbe83af1d3010 ffffce81cddced30 0000000000000000 fffff8046c7f5f7a : nt!IofCallDriver+0x55
: ffffce81cddced30 ffffbe839c527a28 ffffbe83af1d30f8 ffffbe83af1d30f8 : FLTMGR!FltpLegacyProcessingAfterPreCallbacksCompleted+0x28f
: ffffbe83af1d3010 ffffbe83c071b100 0000000000000005 0000000000000000 : FLTMGR!FltPerformSynchronousIo+0x3dd
: ffffbe839c527a20 ffffce81cddcef70 ffffbe83c071b1e0 ffffce81cddceed0 : FLTMGR!FltQueryInformationFile+0x7b
: ffffbe83b26341f0 ffffce81cddcef70 ffffbe83b2634268 ffffce81cddcf078 : myminiflt!findFileLength+0xaf
: 0000000000000000 0000000000000000 0000000000000000 ffffbe83b3c406e0 : myminiflt!PreAcquireForSectionSync+0x336
: 0000000000000000 00000000000000ff ffffce81cddcf200 ffffce8100000000 : FLTMGR!FltpPerformPreCallbacksWorker+0x36c
: ffffce81cddd0000 0000000000000000 ffffce81cddc9000 ffffe58c6f4e4050 : FLTMGR!FltpPreFsFilterOperation+0x184
: fffff8046c7f8eb0 0000000000000001 ffffe58c6f4e4050 fffff8046c7f26c0 : nt!FsFilterPerformCallbacks+0xe7
: 0000000000000000 ffffbe83b3c407c8 be83c071be30ffff 0000000000120089 : nt!FsRtlAcquireFileExclusiveCommon+0x121
: ffffbe839c572da0 fffff8046ec9fa30 ffffbe83746c6644 ffffce81cddcf600 : nt!FsRtlAcquireToCreateMappedSection+0x5b
: ffffce8100000000 ffffbe8300000000 0000000000000000 0000000000000000 : nt!MiCallCreateSectionFilters+0x37
: 0000000000000000 0000000000000000 ffffbe83c071be60 0000000000000000 : nt!MiCreateImageOrDataSection+0x13d
: 0000000008000000 ffffce81cddcfa80 0000000000000001 0000000000000002 : nt!MiCreateSection+0xf4
: 000000f8c5df9710 00000000000f0005 000000f8c5df9728 ffffce81cddcfa80 : nt!MiCreateSectionCommon+0x207
: 0000000000001508 ffffbe83b7bed080 000000f8c5df96c8 ffffce8100000018 : nt!NtCreateSection+0x5c
: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : nt!KiSystemServiceCopyEnd+0x25
: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : 0x00007fff`a28cd9f4

My analysis lead me to finding that the crash is happening in NTFS trying to access FCB beyond it's size and the FCB addresses in FltObjects->FileObject and the FileObject created by us are different.

In the register dump above, r9 has the offending address which is the FCB address of the fileobject we created.

FCB for FltObjects->FileObject:

12: kd> dt _FSRTL_ADVANCED_FCB_HEADER 0xffffe58c63bcd170 FLTMGR!_FSRTL_ADVANCED_FCB_HEADER +0x000 NodeTypeCode : 0n1797 +0x002 NodeByteSize : 0n624 +0x004 Flags : 0x60 ''
+0x005 IsFastIoPossible : 0x2 ''
+0x006 Flags2 : 0x2 ''
+0x007 Reserved : 0y0000
+0x007 Version : 0y0011
+0x008 Resource : 0xffffbe83af467960 _ERESOURCE +0x010 PagingIoResource : 0xffffbe83af467a10 _ERESOURCE
+0x018 AllocationSize : _LARGE_INTEGER 0x71000
+0x020 FileSize : _LARGE_INTEGER 0x70580
+0x028 ValidDataLength : _LARGE_INTEGER 0x70580
+0x030 FastMutex : 0xffffbe83af467928 _FAST_MUTEX +0x038 FilterContexts : _LIST_ENTRY [ 0xffffbe83b3a570a8 - 0xffffbe83b3a570a8 ] +0x048 PushLock : 0 +0x050 FileContextSupportPointer : 0xffffe58c63bcd158 -> (null)
+0x058 Oplock : (null)
+0x058 ReservedForRemote : (null)
+0x060 ReservedContext : (null)

FCB for our created FileObject:

12: kd> dt _FSRTL_ADVANCED_FCB_HEADER 0xffffe58c7bba7f80 FLTMGR!_FSRTL_ADVANCED_FCB_HEADER +0x000 NodeTypeCode :0n25649 +0x002 NodeByteSize : 0n120 +0x004 Flags : 0x60 ''
+0x005 IsFastIoPossible : 0x2 ''
+0x006 Flags2 : 0x2 ''
+0x007 Reserved : 0y0000
+0x007 Version : 0y0011
+0x008 Resource : 0xffffbe83af467960 _ERESOURCE +0x010 PagingIoResource : 0xffffbe83af467a10 _ERESOURCE
+0x018 AllocationSize : _LARGE_INTEGER 0x71000
+0x020 FileSize : _LARGE_INTEGER 0x70580
+0x028 ValidDataLength : _LARGE_INTEGER 0x70580
+0x030 FastMutex : 0xffffbe83c18d7a80 _FAST_MUTEX +0x038 FilterContexts : _LIST_ENTRY [ 0xffffbe83b1b8f028 - 0xffffbe83`b1b8f028 ]
+0x048 PushLock : 0
+0x050 FileContextSupportPointer : (null)
+0x058 Oplock : (null)
+0x058 ReservedForRemote : (null)
+0x060 ReservedContext : (null)

The NodeTypeCode value in Fcb for our fileobject is very peculiar which I couldn't find anywhere. It's node size is 120 and NTFS is trying to access well beyond it causing the crash.
Also this FCB's pooltag is 'BFpc' which looks like a tag used by bindflt.sys. The pool tag for FCB in FltObjects->FileObject is 'Ntff' which is from NTFS.sys which makes sense.

The filename in both fileobjects is the same and it's a local ntfs volume.

All this lead to me suspect bindflt.sys and I used bindlink to configure bindflt.sys with a virtual path mapped to a remote path to reproduce the issue. I hooked up windbg to the setup.

Only once did I see the FCBs differ but that time too there wasn't any crash in the above call stack. Rest of the time FCB addresses were exactly the same for both FltObjects->FileObject and our created FileObject.

II am stumped about what could be causing two different FCBs and what file system is NodeTypeCode :0n25649 representing and what's the exact reason for this BSOD.

Will appreciate any help

Thank you

rod_widdowson · August 4, 2024, 12:03pm

If you are sending a create to the top of the stack and the file object downwards only you are going to hit problems. Either send the query to the top or the send the create down.

Ive not heard of bindflt managing file objects bit it is quite within its rights to.

In my experience NTFS is not great at accepting the wrong file object. Fat is much worse tho.

Sanjeev-2 · August 5, 2024, 12:08pm

Thanks for the reply Rod

If you are sending a create to the top of the stack and the file object downwards only you are going to hit problems. Either send the query to the top or the send the create down.

This is what I have in mind too. But I have been trying to reproduce the issue so as to be able test and confirm that the issue is gone.

Second approach is to use FltObjects->FileObject as preceding code already doing.

As I mentioned previously this is a preexisting code and it is not quite clear to me if there was a conscious decision to call FltQueryInformationFile() with FltObjects->FileObject and then go to create another fileobject by FtlCreateFileEx and again FltQueryInformationFile() but this time with our FileObject. To me it looks superfluous.

Christian_Allred · August 5, 2024, 11:34pm

bindflt uses shadow file objects. Therefore, the create sent to the top of the stack gave you one of bindflt's file objects, not one of NTFS's.

system · September 4, 2024, 11:35pm

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.