CVE-2025-53149

ksthunk.sys -- heap overflow in HandleArrayProperty from unchecked BytesReturned

Summary

Field	Value
Driver	`ksthunk.sys` (Kernel Streaming WOW Thunk)
Vulnerability Class	Buffer Overflow (Heap)
CVSS	7.8
Exploited ITW	No
Patch Date	August 12, 2025

Affected Functions

CKSAutomationThunk::HandleArrayProperty
KsSynchronousIoControlDevice (called twice)

Root Cause

This vulnerability is a textbook example of a TOCTOU-adjacent flaw in buffer management. The vulnerable function, CKSAutomationThunk::HandleArrayProperty, makes two calls to KsSynchronousIoControlDevice. The first call is a sizing query: it asks the underlying device how many bytes the response will require, and the device returns this value in BytesReturned. The second call reads the actual array data into an allocated buffer.

The critical mistake is in what happens between these two calls. The code allocates a buffer based on OutputBufferLength rather than the actual BytesReturned from the sizing query. It checks whether OutputBufferLength is zero, but never verifies that it is large enough to hold the data the device will return. If the underlying device returns more data on the second call than the allocated buffer can hold, the write spills past the end of the non-paged heap allocation.

The vulnerable path is reachable through KSPROPSETID_VPConfig or KSPROPSETID_VPVBIConfig property sets. Crowdfense published a technical analysis showing the exact code flow and how the buffer mismatch leads to a controlled heap overflow.

Vulnerable Code Path

CKSAutomationThunk::HandleArrayProperty
  -> KsSynchronousIoControlDevice (first call: sizing query, gets BytesReturned)
  -> allocate buffer based on OutputBufferLength (ignoring BytesReturned)
  -> KsSynchronousIoControlDevice (second call: data read into undersized buffer)
  -> write exceeds allocation -> non-paged heap overflow

Exploitation

The attacker needs to set up a scenario where a kernel streaming device responds with more data than the pre-allocated buffer expects. This can be achieved by creating a crafted kernel streaming device that returns a large BytesReturned on the sizing query and then writes that full amount on the data query.

When the second KsSynchronousIoControlDevice call writes past the buffer boundary, it corrupts adjacent non-paged pool objects. By grooming the heap to place a controlled object adjacent to the vulnerable allocation, the attacker shapes the overflow to corrupt specific fields. The corrupted object provides an arbitrary write or read primitive, which is then used for SYSTEM privilege escalation.

Exploitation Primitive

Crafted KSPROPSETID_VPConfig request -> HandleArrayProperty
  -> OutputBufferLength < BytesReturned
  -> heap overflow into adjacent pool objects -> SYSTEM

Broader Significance

This vulnerability highlights a subtle class of bugs that arise from double-fetch patterns in kernel code. Even when a function correctly queries a size before allocating, using the wrong size variable for the allocation defeats the purpose of the check entirely. The pattern of "query size, allocate, read data" is common throughout Windows kernel drivers, and each instance is an opportunity for this exact mismatch to occur. The ksthunk.sys driver has appeared in multiple KernelSight entries (see also CVE-2025-49675), suggesting it deserves focused auditing attention.