Skip to content

CVE-2024-49114

cldflt.sys -- Windows Cloud Files Mini-Filter Driver elevation of privilege

Summary

Field Value
Driver cldflt.sys (Cloud Files Mini-Filter)
Vulnerability Class Buffer Overflow
Vulnerable Build 10.0.22621.4460 and earlier
Fixed Build 10.0.22621.4602 (KB5048685, December 2024)
Exploited ITW No

Affected Functions

  • HsmpRpReadBuffer
  • HsmpOpCacheReadDehydratedData
  • HsmpSetupCacheIoContext

Root Cause

By December 2024, cldflt.sys had become one of the most frequently patched drivers in the Windows kernel, with CVE-2023-36036 (ITW heap overflow), CVE-2024-30084 (TOCTOU race), and CVE-2024-30085 (heap overflow in HsmIBitmapNORMALOpen) all hitting the same driver within a year. CVE-2024-49114 continued the pattern with yet another heap overflow, this time in the cache read path.

When a dehydrated (cloud-only) file is read, cldflt.sys needs to serve the cached data from the file's reparse point. HsmpRpReadBuffer allocates a buffer based on the cached data length stored in the reparse point structure, then copies the data into it. The function trusts the declared length in the reparse point without validating that it matches the actual available data. A crafted reparse point can declare a length much larger than the actual data, causing the read operation to copy past the end of the allocated buffer.

The overflow occurs in the kernel's NonPagedPoolNx. Both the overflow size and content are controlled by the attacker through the crafted reparse point, making it a precise heap corruption primitive.

AutoPiff categorizes this as heap buffer overflow via reparse point length mismatch with detection rules:

  • added_len_check_before_memcpy -- identifies the new bounds check on the data length field
  • added_buffer_size_validation -- detects the reparse point data length validation
  • reparse_point_validation_added -- flags new validation of reparse point structure fields

Exploitation

The attack begins by creating a file with a crafted cloud files reparse point containing an inflated data length field. When any process reads the dehydrated file, the minifilter intercepts the read request and attempts to serve the cached data. The inflated length triggers the heap buffer overflow.

The exploitation chain mirrors CVE-2024-30085. The attacker performs pool spray with pipe attributes, positioning controlled objects adjacent to the overflow buffer. The overflow corrupts a pipe attribute entry, providing an arbitrary read primitive. This is combined with I/O Ring for arbitrary write, culminating in a token swap for SYSTEM privilege escalation.

The fact that the same exploitation chain works across multiple cldflt.sys vulnerabilities (CVE-2024-30085 and CVE-2024-49114) demonstrates how reusable modern kernel exploitation techniques are once the initial primitive is established. The vulnerability class is the same (reparse point length mismatch leading to heap overflow), just in a different code path within the same driver.

Patch Analysis

The December 2024 update adds validation in HsmpRpReadBuffer: the declared data length in the reparse point is checked against the actual cached data size before memcpy. HsmpSetupCacheIoContext also now validates the total I/O context size against the reparse point's declared extents.

AutoPiff detects this via the added_len_check_before_memcpy rule, the same pattern that flagged CVE-2024-30085.

Detection

YARA Rule

rule CVE_2024_49114_CloudFilter {
    meta:
        description = "Detects vulnerable version of cldflt.sys (pre-patch)"
        cve = "CVE-2024-49114"
        author = "KernelSight"
        severity = "high"
    strings:
        $mz = { 4D 5A }
        $driver_name = "cldflt.sys" wide ascii nocase
        $internal_name = "InternalName" wide
        $vuln_version = "10.0.22621.4460" wide ascii
        $func_read = "HsmpRpReadBuffer" ascii
        $func_cache = "HsmpOpCacheReadDehydratedData" ascii
    condition:
        $mz at 0 and $driver_name and $internal_name and $vuln_version
}

rule CVE_2024_49114_ReparsePoint_Artifact {
    meta:
        description = "Detects file with crafted cloud files reparse point with inflated length"
        cve = "CVE-2024-49114"
        author = "KernelSight"
        severity = "medium"
    strings:
        $reparse_tag = { 17 00 00 90 }
        $hsm_marker = "CldFlt" ascii wide
    condition:
        $reparse_tag and $hsm_marker
}

ETW Indicators

Provider Event / Signal Relevance
Microsoft-Windows-StorageSync Cloud file hydration events Hydration requests triggered by reading dehydrated files with crafted reparse points
Microsoft-Windows-Kernel-File Reparse point set/get operations Creation of files with manipulated cloud files reparse points
Microsoft-Windows-Kernel-Audit Privilege escalation events Token manipulation following heap overflow exploitation
Microsoft-Windows-Security-Auditing Event 4688 -- Process creation SYSTEM-level process creation after cldflt.sys exploitation
Microsoft-Windows-Kernel-Process Process token changes Token swap from standard user to SYSTEM

Behavioral Indicators

  • Files created with cloud files reparse points (tag 0x90000017) where the declared data length exceeds the actual cached data, setting up the overflow in HsmpRpReadBuffer
  • Heap buffer overflow in NonPagedPoolNx when the minifilter processes a read on a dehydrated file with a crafted reparse point, observable as pool corruption from cldflt.sys
  • Pool spray with pipe attribute objects immediately before triggering a read on the crafted file, grooming adjacent allocations
  • NtFsControlFile calls with FSCTL_PIPE_GET_ATTRIBUTE following the overflow, using the corrupted pipe attribute for an arbitrary read primitive
  • Privilege escalation from low-privilege to SYSTEM via I/O Ring arbitrary write and token swap, following reparse point manipulation and minifilter read operations

Broader Significance

CVE-2024-49114 is the fourth vulnerability in cldflt.sys within roughly a year, all rooted in the same fundamental issue: the reparse point processing code trusts length fields from on-disk data without cross-validating them against allocation sizes. Each patch fixed the specific code path reported, but the underlying pattern persisted across the driver's multiple data-handling functions. This repeated vulnerability pattern in a single driver raises the question of whether point fixes are sufficient for code that systematically lacks bounds validation, or whether a broader refactoring of the reparse point parsing logic is needed.

References