An uninitalized “Fast Tracker” in the Window’s HTTP Protocol stack as used by IIS. Despite providing a bit of a crash analysis and a POC the post is missing information about the vulnerability as their primary focus was on building out the exploit.

We start in HTTP!UlFastSendHttpResponse which is used to send an HTTP Response. When the originating request includes the TE: trailers header the function will allocate a “Fast Tracker” with a call to UlpAllocateFastTracker. There is only an uninitialized use when the HTTP version is missing from the request line so presumably it was performing some conditional initialization there and when the version failed to match the usual suspects like HTTP/1.1 or HTTP/2 the value was just never initialized.

It is perhaps worth calling out that the TE: header is important because it indicates the transfer encodings the client will accept. In HTTP/1.1 there are several options for this, but in HTTP/2 the only acceptable value is trailers. So there is the chance that there is some sort of HTTP version confusion going on also.

With an uninitialized “Fast Tracker” and control over the contents through heap spraying with other requests they could gain control over the argument to a MmUnmapLockedPages call. Resulting in a page fault with a bad pointer and a denial of service attack. Which is perhaps a useful primitive for a more complex chain abusing this for a sort of use-after-free situation although I’m not familiar enough with the Windows Kernel to comment on the nuances of MmUnmapLockedPages for such a use.