And just to add to your information, I’ve seen it not only with stack
based events but also with other types of variables like an
IO_STATUS_BLOCK that is used for an asynchronous request. If the
variable is allocated on the stack and the routine returns back then
later the status is set you get similar types of results. But in the
end, any sort of stack based variable used in this way where the stack
is unwound then later the variable is modified can result in this
behavior.
Pete
–
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295
------ Original Message ------
From: “Scott Noone”
To: “Windows File Systems Devs Interest List”
Sent: 12/2/2016 8:29:17 AM
Subject: Re:[ntfsd] RE:Can filter manager APIs crash due to parallel
execution
>This crash is damn cool.
>
>All looks good except the CPU plucked a NULL pointer off the stack
>where a return address should be.
>
>I would really like to see the corrupted stack BEFORE the exception
>happened. Unfortunately the page fault handler ran and pushed all sorts
>of stuff onto the stack, losing the corrupted values:
>
>ffffd00184146a98 fffff801fea1330d fltmgr!FltpGetStreamListCtrl+0x4d
>ffffd00184146aa0 ffffe00101cba010
>ffffd00184146aa8 ffffe00101cba010
>ffffd00184146ab0 6d83bfc66d83bfc6
>ffffd00184146ab8 6d83bfc66d83bfc6
>ffffd00184146ac0 96177a9cb0036100
>ffffd00184146ac8 0000000000000167
>ffffd00184146ad0 0000000000000000
>ffffd00184146ad8 0000000000000080
>ffffd00184146ae0 0000000000000010
>ffffd00184146ae8 0000000000000000
>ffffd00184146af0 0000000000000010
>ffffd00184146af8 0000000000010282
>ffffd00184146b00 ffffd00184146b10
>ffffd00184146b08 0000000000000018 << Bad RIP was here!
>ffffd00184146b10 ffffe000fe70e010
>ffffd00184146b18 ffffe00101cba010
>ffffd00184146b20 0000000000000000
>ffffd00184146b28 ffffe00101cba018
>ffffd00184146b30 ffff28007b17530b
>ffffd00184146b38 0000000000000000
>ffffd00184146b40 ffffe000fde24040
>ffffd00184146b48 fffff801ff02d6a2
>HPEDpHsmX64!HpArcHsmDeferredReadWriteCompletion+0x112
>ffffd00184146b50 ffffe00101cba010
>ffffd00184146b58 ffffe000fe9b2040
>ffffd00184146b60 ffffe00101a92070
>
>The sort of thing that you expect to see if someone has a calling
>convention wrong, but that’s highly unlikely to be the case here. Do
>you ever use stack based events? I think someone already mentioned this
>but it’s a common way create a stack corruption bug (i.e. you put the
>event on the stack and then leave without waiting, at some point in the
>future someone sets the event).
>
>-scott
>OSR
>@OSRDrivers
>
>
>“Anatoly Mikhailov” wrote in message
>news:xxxxx@ntfsd…
>
>One my previous post is one separate patch.
>
>
>—
>NTFSD is sponsored by OSR
>
>
>MONTHLY seminars on crash dump analysis, WDF, Windows internals and
>software drivers!
>Details at http:
>
>To unsubscribe, visit the List Server section of OSR Online at
>http:</http:></http:>