CVE-2024-30085
Cloud Files Mini Filter -- missing size check before memcpy leads to heap overflow
Summary
| Field | Value |
|---|---|
| Driver | cldflt.sys |
| Vulnerability Class | Buffer Overflow / Bounds Check |
| Vulnerable Build | 10.0.22621.3672 (KB5037853) |
| Fixed Build | 10.0.22621.3733 (KB5039212) |
| Exploited ITW | No |
Affected Functions
HsmIBitmapNORMALOpen
Root Cause
The Cloud Files Mini Filter (cldflt.sys) manages the hydration and dehydration of cloud-backed files through NTFS reparse points. Each cloud file placeholder carries a reparse point structure containing metadata about the file's cloud state, including multiple length fields that describe different aspects of the embedded data.
The vulnerability is in HsmIBitmapNORMALOpen, which processes cloud file reparse buffers during a bitmap open operation. When this function allocates a kernel heap buffer for the reparse data, it uses one length field from the reparse structure to determine the allocation size. However, the subsequent memcpy that fills this buffer uses a different, potentially larger length field from the same structure. The allocation size and the copy size come from different fields, and neither is validated against the other.
Since reparse points are user-constructed (created by setting cloud file placeholder reparse points from user mode via FSCTL_SET_REPARSE_POINT), the attacker fully controls both length fields. By setting the allocation-size field to a small value and the copy-size field to a large value, the memcpy writes far more data than the allocated buffer can hold. This produces a heap overflow in the kernel's non-paged pool, with both the overflow length and the overflow content under attacker control.
AutoPiff categorizes this as bounds_check with detection rules:
added_len_check_before_memcpy
Exploitation
Star Labs published a detailed exploitation walkthrough that demonstrates the full chain from heap overflow to SYSTEM. The strategy follows a well-established pattern for kernel pool overflows:
The attacker first creates a file with a crafted cloud file placeholder reparse point, setting the two length fields to create the desired size mismatch. Before triggering the overflow, pool feng shui is performed: the attacker sprays the kernel pool with pipe attribute objects (allocated via NtFsControlFile) sized to land in the same pool bucket as the vulnerable cldflt.sys allocation. This fills the pool segment and creates a predictable layout where pipe attribute objects sit adjacent to the buffer that will overflow.
When the overflow fires, it corrupts the adjacent pipe attribute object's header or data fields. The corrupted pipe attribute then serves as a relative read/write primitive: the attacker reads and writes data through the pipe attribute API, but the corrupted metadata causes those operations to target memory outside the pipe attribute's actual allocation.
The relative read/write is escalated to arbitrary kernel read/write, and from there the attacker locates the current process's _EPROCESS, reads the SYSTEM process token, and overwrites the current process's token pointer. The entire chain is reachable from user mode by creating and manipulating cloud file placeholder reparse points.
Patch Analysis
The patch in KB5039212 (build 10.0.22621.3733) added a bounds check before the memcpy call. The vulnerable version used the reparse data length field directly as the copy size without comparing it to the allocated buffer size. The patched code validates that the reparse data length does not exceed the destination buffer size, returning an error status on failure.
AutoPiff detects this via the added_len_check_before_memcpy rule, which identifies patches that introduce a length comparison guard on a previously unchecked memory copy.
Detection
YARA Rule
rule CVE_2024_30085_cldflt_sys {
meta:
description = "Detects vulnerable version of cldflt.sys (pre-patch)"
cve = "CVE-2024-30085"
author = "KernelSight"
severity = "high"
strings:
$mz = { 4D 5A }
$driver_name = "cldflt.sys" wide ascii nocase
$version = "10.0.22621.3672" wide ascii
$bitmap_open = "HsmIBitmapNORMALOpen" ascii
$cloud_filter = "CldFlt" wide ascii
condition:
$mz at 0 and $driver_name and $version and ($bitmap_open or $cloud_filter)
}
ETW Indicators
| Provider | Event / Signal | Relevance |
|---|---|---|
| Microsoft-Windows-CloudFiles | Cloud file placeholder operations | Reparse point creation and hydration requests handled by cldflt.sys |
| Microsoft-Windows-Kernel-Audit | Pool allocation integrity events | Kernel pool corruption from the heap overflow |
| Microsoft-Windows-Security-Auditing | Event 4672 -- Special privileges assigned | SYSTEM privilege acquisition following pool corruption and token swap |
| Microsoft-Windows-Kernel-Process | Process token modification | Runtime token replacement after arbitrary R/W via corrupted pipe attributes |
| Microsoft-Windows-Kernel-IoTrace | File system minifilter I/O tracing | Reparse point manipulation IOCTLs (FSCTL_SET_REPARSE_POINT) targeting the vulnerable path in cldflt.sys |
Behavioral Indicators
- Cloud file placeholder reparse points created with data length field exceeding the allocation size field, triggering the size-mismatch heap overflow in
HsmIBitmapNORMALOpen - Pool spray via
NtFsControlFileallocating pipe attribute objects of the correct size class, positioning them adjacent to the vulnerable cldflt.sys buffer allocation - Overwritten pipe attribute headers or data fields immediately following the cldflt.sys allocation, giving a relative read/write primitive
- Process transitions from medium integrity to SYSTEM via token swap (copying SYSTEM EPROCESS token) using the arbitrary R/W escalated from pipe attribute corruption
- Failed attempts produce BAD_POOL_HEADER or PAGE_FAULT_IN_NONPAGED_AREA bugchecks with cldflt.sys on the faulting stack
Broader Significance
CVE-2024-30085 is the third heap overflow in cldflt.sys within a year (following CVE-2023-36036 and CVE-2024-30084). The root cause is always the same pattern: the reparse point processing code uses one length field for allocation and a different length field for the copy, without validating consistency between them. The Star Labs exploitation walkthrough serves as an excellent educational reference for modern Windows kernel pool exploitation, demonstrating pipe attribute spray, relative-to-arbitrary read/write escalation, and token swapping in a single, well-documented chain.