Null data pointer, pass through functions and platformorphic fault: pattern cooperation

We got a bugcheck when accessing a NULL data pointer:

1: kd> r
Last set context:
rax=0000000063537852 rbx=0000000000000000 rcx=0000000000000009
rdx=0000000000000000 rsi=0000000000000000 rdi=0000000000000000
rip=fffffadf262760da rsp=fffffadf15973968 rbp=0000000070537852
 r8=fffffadf31614b00  r9=fffffadffe9fa7b0 r10=000000000000000a
r11=fffffadf31614bf0 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl nz na po nc
cs=0010 ss=0018 ds=0000 es=0000 fs=0000 gs=0000 efl=00010206
rdbss!RxIsThisACscAgentOpen+0×30:
fffffadf`262760da f3a6 repe cmps byte ptr [rsi],byte ptr [rdi]

Default analysis via !analyze -v pointed to the first non-MS module DriverA (the identification process is explained here) located on the following stack trace (that also shows exception processing in file system kernel drivers):

1: kd> kc 100
Call Site
nt!KeBugCheckEx
rdbss!RxExceptionFilter+0x15e
rdbss!RxFsdCommonDispatch+0x6d5
nt!_C_specific_handler+0x9b
nt!RtlpExecuteHandlerForException+0xd
nt!RtlDispatchException+0x2c0
nt!KiDispatchException+0xd9
nt!KiExceptionExit
nt!KiPageFault+0x1e1
rdbss!RxIsThisACscAgentOpen+0x30
rdbss!RxInitializeVNetRootParameters+0x31d
rdbss!RxFindOrConstructVirtualNetRoot+0x180
rdbss!RxCanonicalizeNameAndObtainNetRoot+0x223
rdbss!RxCommonCreate+0x470
rdbss!RxFsdCommonDispatch+0x51c
mrxsmb!MRxSmbFsdDispatch+0x211
fltmgr!FltpCreate+0x353
DriverA!DispatchThrough+0×177
DriverB!PassThrough+0×12c
fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0×3f2
fltmgr!FltpCreate+0×3bd
Mup!DnrRedirectFileOpen+0×791
Mup!DnrNameResolve+0xb19
Mup!DnrStartNameResolution+0×478
Mup!DfsCommonCreate+0×3dc
Mup!DfsFsdCreate+0×10d
Mup!MupCreate+0×125
nt!IopParseDevice+0×1088
nt!ObpLookupObjectName+0×931
nt!ObOpenObjectByName+0×180
nt!IopCreateFile+0×630
nt!IoCreateFileSpecifyDeviceObjectHint+0xb4
fltmgr!FltpExpandFilePathWorker+0×23d
fltmgr!FltpExpandFilePath+0×5b
fltmgr!FltpGetOpenedDestinationFileName+0xd5
fltmgr!FltpGetNormalizedDestinationFileName+0×15
fltmgr!FltGetDestinationFileNameInformation+0×17d
DriverC+0×383e
fltmgr!FltpPerformPreCallbacks+0×3e2
fltmgr!FltpPassThroughInternal+0×40
fltmgr!FltpDispatch+0×102
Mup!DfsCommonSetInformation+0×165
Mup!DfsFsdSetInformation+0×67
nt!NtSetInformationFile+0×916
nt!KiSystemServiceCopyEnd+0×3

Although DriverA function on the stack trace looked like a pass through, DriverA.sys file was removed from the system. Nevertheless, the same pattern continued:

0: kd> kc 100
Call Site
nt!KeBugCheckEx
rdbss!RxExceptionFilter+0x15e
rdbss!RxFsdCommonDispatch+0x6d5
nt!_C_specific_handler+0x9b
nt!RtlpExecuteHandlerForException+0xd
nt!RtlDispatchException+0x2c0
nt!KiDispatchException+0xd9
nt!KiExceptionExit
nt!KiPageFault+0x1e1
rdbss!RxIsThisACscAgentOpen+0x30
rdbss!RxInitializeVNetRootParameters+0x31d
rdbss!RxFindOrConstructVirtualNetRoot+0x180
rdbss!RxCanonicalizeNameAndObtainNetRoot+0x223
rdbss!RxCommonCreate+0x470
rdbss!RxFsdCommonDispatch+0x51c
mrxsmb!MRxSmbFsdDispatch+0x211
fltmgr!FltpCreate+0x353
DriverB!PassThrough+0×12c
fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0×3f2
fltmgr!FltpCreate+0×3bd
Mup!DnrRedirectFileOpen+0×791
Mup!DnrNameResolve+0xb19
Mup!DnrStartNameResolution+0×478
Mup!DfsCommonCreate+0×3dc
Mup!DfsFsdCreate+0×10d
Mup!MupCreate+0×125
nt!IopParseDevice+0×1088
nt!ObpLookupObjectName+0×931
nt!ObOpenObjectByName+0×180
nt!IopCreateFile+0×630
nt!IoCreateFileSpecifyDeviceObjectHint+0xb4
fltmgr!FltpExpandFilePathWorker+0×23d
fltmgr!FltpExpandFilePath+0×5b
fltmgr!FltpGetOpenedDestinationFileName+0xd5
fltmgr!FltpGetNormalizedDestinationFileName+0×15
fltmgr!FltGetDestinationFileNameInformation+0×17d
DriverC+0×383e
fltmgr!FltpPerformPreCallbacks+0×3e2
fltmgr!FltpPassThroughInternal+0×40
fltmgr!FltpDispatch+0×102
Mup!DfsCommonSetInformation+0×165
Mup!DfsFsdSetInformation+0×67
nt!NtSetInformationFile+0×916
nt!KiSystemServiceCopyEnd+0×3

So it was concluded that the presence of DriverA was irrelevant to the problem. Now DriverB was pointed to by the default analysis as a possible culprit. However, the fault appeared platformorphic: Google search found another similar stack trace shape with the same faulted instruction but without DriverB and DriverC. Therefore the conclusion was that modules DriverA, DriverB and DriverC didn’t have the straightforward contribution to the abnormal system behaviour.

- Dmitry Vostokov @ DumpAnalysis.org -

Leave a Reply

You must be logged in to post a comment.