CVE-2026-58613: Use-After-Free in the Windows Cloud Files Mini Filter Driver (cldflt.sys)

Executive Summary

Cisco Talos researcher Marcin ‘Icewall’ Noga disclosed CVE-2026-58613, a kernel-mode use-after-free in cldflt.sys — the Windows Cloud Files Mini Filter Driver that powers cloud-storage integrations such as OneDrive Files On-Demand. The flaw carries a CVSSv3.1 score of 8.8 and is classified as CWE-416 (Use After Free). Because the entire attack runs from an ordinary local process (AV:L/PR:L/UI:N) and crosses a security scope boundary (S:C), a successful trigger gives a low-privileged attacker a path to full local privilege escalation. Microsoft confirmed the issue and shipped a fix on 14 July 2026.

The defect lives in CldiStreamCompleteRequest. A code path introduced in the May servicing update frees the request object and then dereferences a stream-context pointer that the very same free just released. By reporting incomplete hydration progress from a fake sync provider, terminating that provider process without cleaning up, eroding the stream context’s reference count with ordinary file deletes, and finally forcing the driver’s 60-second watchdog timer to walk its global list, an attacker drives the driver into freeing a pool block in the middle of a function that keeps using it. The result is a reliable use-after-free in non-paged pool — the kind of primitive that modern Windows kernel exploitation turns into arbitrary code execution.

Vulnerability at a Glance

The Cloud Files Mini-Filter Driver (cldflt.sys)

cldflt.sys is a Microsoft Windows kernel-mode file-system minifilter that enables cloud-storage integration features such as OneDrive Files On-Demand. It manages cloud-based placeholder files, synchronizes data between local storage and cloud services, and hydrates (downloads) files automatically when a user accesses them. Sitting inside the Windows file-system stack, the driver makes cloud files behave like ordinary local files — and, as with any driver that mediates between untrusted user-mode providers and privileged kernel state, its object lifetime management is a rich source of memory-safety bugs.

Background: The Global Countdown Timer List

The driver serves cloud placeholder files for sync engines (OneDrive, Dropbox, and so on) and handles on-demand hydration. To keep the file system from hanging when a sync provider stops responding, it maintains a system-wide global countdown timer list — a kernel linked list tracking every pending blocking request sent to a provider. Each entry on the list is given a 60-second deadline; this is the watchdog that guarantees forward progress if a provider goes silent.

The list is populated in several core scenarios — file hydration, directory population, notification acknowledgement, and, most importantly for this bug, provider progress reporting. When a provider calls CfReportProviderProgress / CfReportProviderProgress2 to report incomplete hydration (for example, “downloaded 297 KB of 1000 KB”), the driver creates an internal provider request on the timer list so the in-progress transfer can be tracked and cancelled if the provider disappears.

Once a request’s 60-second deadline expires, the driver’s timer DPC fires and a worker thread walks the global list, cancelling every expired request. Crucially, that same walk can also be forced on demand through the undocumented CfQueryProgress API — the call the Windows Shell uses to paint hydration progress bars in File Explorer. That on-demand trigger is what turns a race that would otherwise depend on a DPC into a deterministic exploit primitive.

Triggering the Vulnerability

Step 1 — Add a request to the global timer list

A cloud sync provider calls CfReportProviderProgress or CfReportProviderProgress2 to report incomplete progress on a placeholder file (say, completed=297 out of total=1000). Inside the kernel the call travels down the following chain:

User-mode: CfReportProviderProgress2(connKey, transferKey, reqKey, total=1000,    completed=297, sessionId=0)
  → cldapi!CfReportProviderProgress2 → FilterSendMessage
    → cldflt!CldiPortNotifyMessage
      → CldiPortProcessTransfer
        → CldiPortProcessReportProgress
          → CldSyncReportProgress
            → CldStreamReportProgress
              → CldiStreamBuildProviderRequest
                → CldiStreamInsertIntoGlobalRequestListNoLock  ← INSERT_GLOBAL

The request is created only when progressCompleted < progressTotal and no provider request is already pending on the stream. At this point the request holds a reference to the HSM_STREAM_CONTEXT via pRequest->pStreamHandleCtx->pStreamCtx. The stream context’s FltMgr reference count is greater than 1 — the on-disk file, the NTFS file object, and various FltMgr internals all contribute additional references.

Step 2 — Orphan the request by killing the provider

The provider process now terminates without calling CfDisconnectSyncRoot or CfUnregisterSyncRoot. The request survives on the global timer list after the provider is gone: it becomes an orphan. No user-mode provider will ever complete it, and no disconnect logic will ever clean it up — the only thing that will ever touch it again is the 60-second timeout machinery. Had the process called CfUnregisterSyncRoot, the driver would have drained the request from the list with status STATUS_CLOUD_FILE_PROVIDER_TERMINATED (0xC000CF16); by exiting abruptly, the attacker deliberately bypasses that cleanup path.

Step 3 — Erode the stream-context reference count

Deleting the files and placeholders inside the sync-root directory (for example with rmdir /s /q) triggers NTFS file-close operations. Every close travels the NTFS → FltMgr cleanup path, which calls FltReleaseContext on cached stream-context references. Each release chips away at the HSM_STREAM_CONTEXT reference count until the orphaned timer-list request is the sole remaining reference (refcount == 1). This is the setup step that makes the imminent free fatal.

Step 4 — Force timer expiry and fire the walk

Roughly 60 seconds after Step 1, the request’s deadline expires. Rather than wait for the timer DPC, the attacker forces the list walk immediately by calling the undocumented CfQueryProgress API, which sends port command 0x4001 to \CLDMSGPORT. In the kernel this enters:

CfQueryProgress
  → FilterSendMessage (port cmd 0x4001)
    → CldiPortProcessFilterControl
      → CldiPortProcessQueryProgress
        → CldStreamQueryProgress
          → CldiStreamRestartCountdownTimer
            → CldiStreamStartCountdownTimer(bCancelAll=0)

CldiStreamStartCountdownTimer walks the global request list and cancels every expired request:

do {
AcquireResourceExclusive(&Resource);

if (ListEmpty) break;

pRequest = HEAD of list;
deadline = pRequest->DeadlineTimestamp;

if (deadline > currentTime)      // NOT expired
    break;                       // re-arm timer for remaining time

// EXPIRED:
RemoveFromGlobalList(pRequest);
pRequest->RemovedFromGlobalList = 1;

ReleaseResource(&Resource);

if (pRequest->MasterRequest)
    FltCancelIo(pRequest->MasterRequest->UserCbd);  // CVE-2023-29361 path (IRP-based)
else
    CldiStreamCancelSynchronousRequest(pRequest);    // OUR vulnerability path (no IRP)

} while (1);

Because the orphaned request was created by CfReportProviderProgress2 — a provider-initiated operation with no associated user I/O request — its MasterRequest field is NULL. That steers execution down the CldiStreamCancelSynchronousRequest branch (the path that has no IRP), which eventually calls CldiStreamCompleteRequest. The alternative branch, taken when MasterRequest is non-NULL, is the IRP-based route associated with the earlier CVE-2023-29361.

Step 5 — CldiStreamCompleteRequest and the UAF

When cldflt crashes, the debugger shows the following state:

6: kd> kb
 # RetAddr               : Args to Child                                                           : Call Site
00 fffff807`7d540e8c     : 00000000`00000000 00000000`00000000 ffffcb82`900f2a80 00000000`00000000 : cldflt!CldiStreamCompleteRequest+0x12f
01 fffff807`7d540a60     : 00000000`00000000 ffffcb82`900f2a80 ffffc80b`34feea68 ffffa685`a7a86f10 : cldflt!CldiStreamCompleteCanceledRequest+0x234
02 fffff807`7d534ec0     : 01dcec7b`5946f732 ffffcb82`900f2a80 00000000`00000002 00000000`00000100 : cldflt!CldiStreamCancelSynchronousRequest+0x68
03 fffff807`7d5376ee     : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : cldflt!CldiStreamStartCountdownTimer+0x150
04 fffff807`7d57cc0f     : 00000000`00000000 00000000`00000000 00000000`00000002 00000000`00000100 : cldflt!CldiStreamRestartCountdownTimer+0x66
05 fffff807`7d57b50c     : 00000000`00000001 0000000e`dabfdf90 00000000`00001c20 ffffc80b`34feed68 : cldflt!CldStreamQueryProgress+0x168b
06 fffff807`7d57b209     : 00000000`00004001 00000000`00000000 00000001`00001c20 ffffcb82`90f6cf20 : cldflt!CldiPortProcessQueryProgress+0x2b4
07 fffff807`7d54af49     : 00000000`00004001 00000000`00000000 00000000`00000000 00000000`00000000 : cldflt!CldiPortProcessFilterControl+0x4d
08 fffff801`4f233622     : ffffcb82`90ee6ee0 0000000e`dabfde30 00000000`000000e0 0000000e`dabfddb0 : cldflt!CldiPortNotifyMessage+0xcc9
09 fffff801`4f27f632     : ffffa685`af8dad60 0000000e`dabfde30 ffffa685`af8dae30 fffff801`be5259c0 : FLTMGR!FltpFilterMessage+0x162
0a fffff801`4f23b9c3     : ffffa685`af8dad60 ffffc80b`34fef0d0 ffffa685`a05a4bf0 00000000`00000000 : FLTMGR!FltpMsgDispatch+0xf2
0b fffff801`bd96ccfb     : ffffc80b`34fef008 00000000`00060000 ffffa685`b0624ac0 fffff801`bdf561b9 : FLTMGR!FltpDispatch+0x133
0c fffff801`bd96cc73     : ffffa685`b0624ac0 ffffa685`b0624ac0 00000020`00000000 00000000`00000000 : nt!IopfCallDriver+0x5b
0d fffff801`bdfdb3a5     : ffffa685`b0624ac0 ffffc80b`34fef0d0 ffffa685`a05a4bf0 00000000`00000000 : nt!IofCallDriver+0x13
0e fffff801`bdfda1ec     : 00000000`00000000 00000000`00000001 00000000`00000001 00000000`00000001 : nt!IopSynchronousServiceTail+0x1c5
0f fffff801`bdfd983e     : 00000000`00000000 fffff801`bda3ce9f 00000000`00000000 00000000`00000000 : nt!IopXxxControlFile+0x99c
10 fffff801`bddcc558     : 00000000`00000000 00000000`00000000 0000000e`da776000 00000000`00000000 : nt!NtDeviceIoControlFile+0x5e
11 00007ffd`b8de1d84     : 00007ffd`aa833bc2 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x28
12 00007ffd`aa833bc2     : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!NtDeviceIoControlFile+0x14
13 00007ffd`aa8331a1     : 00000000`00000000 0000000e`dabfdf80 00000000`00000000 00000000`00000000 : FLTLIB!FilterpDeviceIoControl+0x13e
14 00007ffd`a4503434     : 00000000`00000000 00000000`00000000 0000000e`dabfde70 00000000`00000000 : FLTLIB!FilterSendMessage+0x31
15 00007ff7`9cb147fc     : 00000000`00000000 00000000`00000000 ffffffff`ffffd8f0 00000000`00000000 : cldapi!CfQueryProgress+0x3f4
16 00000000`00000000     : 00000000`00000000 ffffffff`ffffd8f0 00000000`00000000 00000000`00000032 : poc+0x47fc

6: kd> r
rax=0000000000000036 rbx=0000000000000000 rcx=0000000000000000
rdx=0000000000000034 rsi=ffffcb82900f2a80 rdi=0000000000000000
rip=fffff8077d58435b rsp=ffffc80b34fee920 rbp=ffffcb8290ebaf80
 r8=0000000000000036  r9=0000000000000001 r10=fffff801bd91de80
r11=ffffa685abe1c430 r12=00000000c000cf1f r13=00270000000289b7
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei ng nz na po nc
cs=0010  ss=0018  ds=002b  es=002b  fs=0053  gs=002b             efl=00040282
cldflt!CldiStreamCompleteRequest+0x12f:
fffff807`7d58435b 488b4500        mov     rax,qword ptr [rbp]    ss:0018:ffffcb82`90ebaf80=????????????????

The faulting instruction dereferences rbp, which points at ffffcb82`90ebaf80 — freed memory. To understand why, here are the most important parts of CldiStreamCompleteRequest (decompiled):

Line 1     void __fastcall CldiStreamCompleteRequest(
Line 2             HSM_STREAM_HANDLE_CONTEXT *pStreamHandleCtx,
Line 3             CLD_STREAM_REQUEST *pRequest,
Line 4             __int64 completionStatus,
Line 5             unsigned int cancelFlags)
Line 6     {
Line 7 
Line 8     (...)
Line 9       if ( (unsigned int)Feature_H2E_WPA3SAE__private_IsEnabledDeviceUsage_1() ) //Code introduced in May update
Line 10      { 
Line 11        CldiStreamDeleteRequest(pRequest); // <-- First FREE REQUEST ?!
Line 12        CldiStreamCdqRELEASE((PFLT_CALLBACK_DATA_QUEUE)(*((_QWORD *)pStreamHandleCtx->pStreamCtx + 1) + 144LL), v15);//  UAF!!!
Line 13      }
Line 14      else
Line 15      {                                             
Line 16        if ( !pRequest->TimeoutType )
Line 17          CldiStreamCdqRELEASE((PFLT_CALLBACK_DATA_QUEUE)(*((_QWORD *)pStreamHandleCtx->pStreamCtx + 1) + 144LL), v14);
Line 18        CldiStreamDeleteRequest(pRequest);
Line 19      }

On line 11 the request is freed. Remember that pRequest carries pRequest->pStreamHandleCtx, and that pStreamHandleCtx->pStreamCtx is the stream context. Inside CldiStreamDeleteRequest, FltReleaseContext drops the stream-context reference count. Because the orphaned request holds the last reference (refcount == 1 after Step 3), the count falls to zero, and FltMgr synchronously invokes the cleanup callback chain — on the same thread, in the same call stack:

CldiStreamDeleteRequest+0xC5: FltReleaseContext(pStreamCtx)
  → FltMgr: refcount → 0, invoke cleanup callback
  → HsmFltDeleteSTREAM_CONTEXT+0x1E
  → CldHsmDeleteStreamContext+0x1B
  → CldStreamClose+0x154: ExFreePoolWithTag(pCldStream, 'Clst')  ← POOL BLOCK FREED

When control returns to CldiStreamCompleteRequest (line 12), it calls CldiStreamCdqRELEASE, which dereferences pStreamHandleCtx->pStreamCtx — a pointer into the pool block that was just freed. The !verifier extension confirms that the address in rbp is a freed pool block:

6: kd> !verifier 0x80 ffffcb82`90ebaf80
======================================================================
Pool block ffffcb8290ebaf80, Size 0000000000000080, Thread ffffa685ad7e7080
fffff801bda59700 nt!ExpFreePoolChecks+0x40
fffff801be282eca nt!ExFreePoolWithTag+0x165a
fffff801bdd2b8cc nt!DifExFreePoolWithTagWrapper+0xdc
fffff8077d5737b0 cldflt!CldStreamClose+0x160
fffff8077d57362b cldflt!CldHsmDeleteStreamContext+0x1b
fffff8077d57400e cldflt!HsmFltDeleteSTREAM_CONTEXT+0x1e
fffff8014f223c57 FLTMGR!FltReleaseContext+0x437
fffff8077d534ce1 cldflt!CldiStreamDeleteRequest+0xc5
fffff8077d58435b cldflt!CldiStreamCompleteRequest+0x12f
fffff8077d540e8c cldflt!CldiStreamCompleteCanceledRequest+0x234
fffff8077d540a60 cldflt!CldiStreamCancelSynchronousRequest+0x68
fffff8077d534ec0 cldflt!CldiStreamStartCountdownTimer+0x150
fffff8077d5376ee cldflt!CldiStreamRestartCountdownTimer+0x66
fffff8077d57cc0f cldflt!CldStreamQueryProgress+0x168b
fffff8077d57b50c cldflt!CldiPortProcessQueryProgress+0x2b4
fffff8077d57b209 cldflt!CldiPortProcessFilterControl+0x4d
fffff8077d54af49 cldflt!CldiPortNotifyMessage+0xcc9
fffff8014f233622 FLTMGR!FltpFilterMessage+0x162
fffff8014f27f632 FLTMGR!FltpMsgDispatch+0xf2
fffff8014f23b9c3 FLTMGR!FltpDispatch+0x133
fffff801bd96ccfb nt!IopfCallDriver+0x5b
fffff801bd96cc73 nt!IofCallDriver+0x13
fffff801bdfdb3a5 nt!IopSynchronousServiceTail+0x1c5
fffff801bdfda1ec nt!IopXxxControlFile+0x99c
fffff801bdfd983e nt!NtDeviceIoControlFile+0x5e
fffff801bddcc558 nt!KiSystemServiceCopyEnd+0x28

In short: the free on line 11 and the dereference on line 12 operate on the same object, with the stream-context teardown wedged between them. This poor object-lifetime handling is a textbook use-after-free that can be leveraged toward local privilege escalation.

Root Cause: A May-Update Feature Flag

The decisive detail is the branch guarded by Feature_H2E_WPA3SAE__private_IsEnabledDeviceUsage_1() on line 9 — code introduced in the May servicing update. When that feature is enabled, the function frees the request before the final CldiStreamCdqRELEASE, whereas the legacy else branch performs the release first and frees the request last. The reordering is what opens the window: the free on line 11 can drop the last stream-context reference and synchronously destroy the object that line 12 is about to read. The provider-request path (MasterRequest == NULL) is what reaches this branch without an IRP, distinguishing it from the earlier, IRP-based CVE-2023-29361.

Crash Information

Under Driver Verifier the trigger produces a PAGE_FAULT_IN_NONPAGED_AREA (0x50) bugcheck bucketed as AV_VRF_cldflt!CldiStreamCompleteRequest. The full !analyze -v output follows:

6: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

PAGE_FAULT_IN_NONPAGED_AREA (50)
Invalid system memory was referenced.  This cannot be protected by try-except.
Typically the address is just plain bad or it is pointing at freed memory.
Arguments:
Arg1: ffffcb8290ebaf80, memory referenced.
Arg2: 0000000000000000, X64: bit 0 set if the fault was due to a not-present PTE.
    bit 1 is set if the fault was due to a write, clear if a read.
    bit 3 is set if the processor decided the fault was due to a corrupted PTE.
    bit 4 is set if the fault was due to attempted execute of a no-execute PTE.
    - ARM64: bit 1 is set if the fault was due to a write, clear if a read.
    bit 3 is set if the fault was due to attempted execute of a no-execute PTE.
Arg3: fffff8077d58435b, If non-zero, the instruction address which referenced the bad memory
    address.
Arg4: 0000000000000000, (reserved)
 

Debugging Details:
------------------
    
*** WARNING: Unable to verify checksum for poc.exe
Unable to load image C:\repro_stream_uaf\poc.exe, Win32 error 0n2
*** WARNING: Unable to verify checksum for poc.exe
Unable to load image C:\repro_stream_uaf\poc.exe, Win32 error 0n2
*** WARNING: Unable to verify checksum for poc.exe
Unable to load image C:\repro_stream_uaf\poc.exe, Win32 error 0n2

KEY_VALUES_STRING: 1

Key  : AV.PTE
Value: Invalid

Key  : AV.Page.Virtual
Value: 0xffffcb8290eb0000

Key  : AV.Type
Value: Read

Key  : Analysis.CPU.mSec
Value: 3875

Key  : Analysis.Elapsed.mSec
Value: 7253

Key  : Analysis.IO.Other.Mb
Value: 2030

Key  : Analysis.IO.Read.Mb
Value: 45

Key  : Analysis.IO.Write.Mb
Value: 5291

Key  : Analysis.Init.CPU.mSec
Value: 1395312

Key  : Analysis.Memory.CommitPeak.Mb
Value: 633
    
Key  : Analysis.Version.DbgEng
Value: 10.0.29547.1002

Key  : Analysis.Version.Description
Value: 10.2602.27.2 amd64fre

Key  : Analysis.Version.Ext
Value: 1.2602.27.2

Key  : Bugcheck.Code.KiBugCheckData
Value: 0x50

Key  : Bugcheck.Code.LegacyAPI
Value: 0x50

Key  : Bugcheck.Code.TargetModel
Value: 0x50

Key  : Failure.Bucket
Value: AV_VRF_cldflt!CldiStreamCompleteRequest

Key  : Failure.Exception.IP.Address
Value: 0xfffff8077d58435b

Key  : Failure.Exception.IP.Module
Value: cldflt

Key  : Failure.Exception.IP.Offset
Value: 0x8435b

Key  : Failure.Hash
Value: {61f2862e-d255-0a0b-0f7e-ddec7a333e8f}

Key  : Faulting.IP.Type
Value: Paged

Key  : Hypervisor.Enlightenments.ValueHex
Value: 0x6090ebf4

Key  : Hypervisor.Flags.AnyHypervisorPresent
Value: 1

Key  : Hypervisor.Flags.ApicEnlightened
Value: 1

Key  : Hypervisor.Flags.ApicVirtualizationAvailable
Value: 0

Key  : Hypervisor.Flags.AsyncMemoryHint
Value: 0

Key  : Hypervisor.Flags.CoreSchedulerRequested
Value: 0

Key  : Hypervisor.Flags.CpuManager
Value: 0

Key  : Hypervisor.Flags.DeprecateAutoEoi
Value: 0

Key  : Hypervisor.Flags.DynamicCpuDisabled
Value: 1

Key  : Hypervisor.Flags.Epf
Value: 0

Key  : Hypervisor.Flags.ExtendedProcessorMasks
Value: 1

Key  : Hypervisor.Flags.HardwareMbecAvailable
Value: 1

Key  : Hypervisor.Flags.MaxBankNumber
Value: 0

Key  : Hypervisor.Flags.MemoryZeroingControl
Value: 0

Key  : Hypervisor.Flags.NoExtendedRangeFlush
Value: 0

Key  : Hypervisor.Flags.NoNonArchCoreSharing
Value: 0

Key  : Hypervisor.Flags.Phase0InitDone
Value: 1

Key  : Hypervisor.Flags.PowerSchedulerQos
Value: 0

Key  : Hypervisor.Flags.RootScheduler
Value: 0

Key  : Hypervisor.Flags.SynicAvailable
Value: 1

Key  : Hypervisor.Flags.UseQpcBias
Value: 0

Key  : Hypervisor.Flags.Value
Value: 659693

Key  : Hypervisor.Flags.ValueHex
Value: 0xa10ed

Key  : Hypervisor.Flags.VpAssistPage
Value: 1

Key  : Hypervisor.Flags.VsmAvailable
Value: 1

Key  : Hypervisor.RootFlags.AccessStats
Value: 0

Key  : Hypervisor.RootFlags.CrashdumpEnlightened
Value: 0

Key  : Hypervisor.RootFlags.CreateVirtualProcessor
Value: 0

Key  : Hypervisor.RootFlags.DisableHyperthreading
Value: 0

Key  : Hypervisor.RootFlags.HostTimelineSync
Value: 0

Key  : Hypervisor.RootFlags.HypervisorDebuggingEnabled
Value: 0

Key  : Hypervisor.RootFlags.IsHyperV
Value: 0

Key  : Hypervisor.RootFlags.LivedumpEnlightened
Value: 0

Key  : Hypervisor.RootFlags.MapDeviceInterrupt
Value: 0

Key  : Hypervisor.RootFlags.MceEnlightened
Value: 0

Key  : Hypervisor.RootFlags.Nested
Value: 0

Key  : Hypervisor.RootFlags.StartLogicalProcessor
Value: 0

Key  : Hypervisor.RootFlags.Value
Value: 0

Key  : Hypervisor.RootFlags.ValueHex
Value: 0x0

Key  : SecureKernel.HalpHvciEnabled
Value: 0

Key  : WER.OS.Branch
Value: ge_release

Key  : WER.OS.Version
Value: 10.0.26100.1

BUGCHECK_CODE:  50

BUGCHECK_P1: ffffcb8290ebaf80

BUGCHECK_P2: 0

BUGCHECK_P3: fffff8077d58435b

BUGCHECK_P4: 0

FAULTING_THREAD:  ffffa685ad7e7080

EXCEPTION_PARAMETER1:  0000000000000000

EXCEPTION_PARAMETER2:  ffffcb8290ebaf80

READ_ADDRESS:  ffffcb8290ebaf80 Special pool

PROCESS_NAME:  poc.exe

IP_IN_PAGED_CODE: 
cldflt!CldiStreamCompleteRequest+12f
fffff807`7d58435b 488b4500        mov     rax,qword ptr [rbp]

STACK_TEXT:  
*** WARNING: Unable to verify checksum for poc.exe
Unable to load image C:\repro_stream_uaf\poc.exe, Win32 error 0n2
ffffc80b`34fedcf8 fffff801`bdcbfa92     : ffffc80b`34fedd78 00000000`00000001 00000000`00000080 fffff801`bddd2a01 : nt!DbgBreakPointWithStatus
ffffc80b`34fedd00 fffff801`bdcbefbe     : 00000000`00000003 ffffc80b`34fede60 fffff801`bddd2c90 ffffc80b`34fee420 : nt!KiBugCheckDebugBreak+0x12
ffffc80b`34fedd60 fffff801`bdc08557     : 00000000`00000000 fffff801`bda1caf2 00000000`00000003 00000000`00000003 : nt!KeBugCheck2+0xb2e
ffffc80b`34fee4f0 fffff801`bda1e89d     : 00000000`00000050 ffffcb82`90ebaf80 00000000`00000000 ffffc80b`34fee790 : nt!KeBugCheckEx+0x107
ffffc80b`34fee530 fffff801`bd953e96     : 00000000`00000000 ffff8000`00000000 ffffcb82`90ebaf80 0000007f`fffffff8 : nt!MiSystemFault+0x78d
ffffc80b`34fee620 fffff801`bddc80cb     : ffffcb82`90ebaf80 ffffcb82`90ebaf80 00000000`00000000 ffffa685`a3dad420 : nt!MmAccessFault+0x646
ffffc80b`34fee790 fffff807`7d58435b     : 00000000`00000000 ffffcb82`900f2a80 00000000`00000000 00004001`00000001 : nt!KiPageFault+0x38b
ffffc80b`34fee920 fffff807`7d540e8c     : 00000000`00000000 00000000`00000000 ffffcb82`900f2a80 00000000`00000000 : cldflt!CldiStreamCompleteRequest+0x12f
ffffc80b`34fee9a0 fffff807`7d540a60     : 00000000`00000000 ffffcb82`900f2a80 ffffc80b`34feea68 ffffa685`a7a86f10 : cldflt!CldiStreamCompleteCanceledRequest+0x234
ffffc80b`34feea40 fffff807`7d534ec0     : 01dcec7b`5946f732 ffffcb82`900f2a80 00000000`00000002 00000000`00000100 : cldflt!CldiStreamCancelSynchronousRequest+0x68
ffffc80b`34feea70 fffff807`7d5376ee     : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : cldflt!CldiStreamStartCountdownTimer+0x150
ffffc80b`34feeaa0 fffff807`7d57cc0f     : 00000000`00000000 00000000`00000000 00000000`00000002 00000000`00000100 : cldflt!CldiStreamRestartCountdownTimer+0x66
ffffc80b`34feeae0 fffff807`7d57b50c     : 00000000`00000001 0000000e`dabfdf90 00000000`00001c20 ffffc80b`34feed68 : cldflt!CldStreamQueryProgress+0x168b
ffffc80b`34feecc0 fffff807`7d57b209     : 00000000`00004001 00000000`00000000 00000001`00001c20 ffffcb82`90f6cf20 : cldflt!CldiPortProcessQueryProgress+0x2b4
ffffc80b`34feed30 fffff807`7d54af49     : 00000000`00004001 00000000`00000000 00000000`00000000 00000000`00000000 : cldflt!CldiPortProcessFilterControl+0x4d
ffffc80b`34feed60 fffff801`4f233622     : ffffcb82`90ee6ee0 0000000e`dabfde30 00000000`000000e0 0000000e`dabfddb0 : cldflt!CldiPortNotifyMessage+0xcc9
ffffc80b`34feee70 fffff801`4f27f632     : ffffa685`af8dad60 0000000e`dabfde30 ffffa685`af8dae30 fffff801`be5259c0 : FLTMGR!FltpFilterMessage+0x162
ffffc80b`34feeee0 fffff801`4f23b9c3     : ffffa685`af8dad60 ffffc80b`34fef0d0 ffffa685`a05a4bf0 00000000`00000000 : FLTMGR!FltpMsgDispatch+0xf2
ffffc80b`34feef50 fffff801`bd96ccfb     : ffffc80b`34fef008 00000000`00060000 ffffa685`b0624ac0 fffff801`bdf561b9 : FLTMGR!FltpDispatch+0x133
ffffc80b`34feeff0 fffff801`bd96cc73     : ffffa685`b0624ac0 ffffa685`b0624ac0 00000020`00000000 00000000`00000000 : nt!IopfCallDriver+0x5b
ffffc80b`34fef030 fffff801`bdfdb3a5     : ffffa685`b0624ac0 ffffc80b`34fef0d0 ffffa685`a05a4bf0 00000000`00000000 : nt!IofCallDriver+0x13
ffffc80b`34fef060 fffff801`bdfda1ec     : 00000000`00000000 00000000`00000001 00000000`00000001 00000000`00000001 : nt!IopSynchronousServiceTail+0x1c5
ffffc80b`34fef110 fffff801`bdfd983e     : 00000000`00000000 fffff801`bda3ce9f 00000000`00000000 00000000`00000000 : nt!IopXxxControlFile+0x99c
ffffc80b`34fef380 fffff801`bddcc558     : 00000000`00000000 00000000`00000000 0000000e`da776000 00000000`00000000 : nt!NtDeviceIoControlFile+0x5e
ffffc80b`34fef3f0 00007ffd`b8de1d84     : 00007ffd`aa833bc2 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x28
0000000e`dabfdca8 00007ffd`aa833bc2     : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!NtDeviceIoControlFile+0x14
0000000e`dabfdcb0 00007ffd`aa8331a1     : 00000000`00000000 0000000e`dabfdf80 00000000`00000000 00000000`00000000 : FLTLIB!FilterpDeviceIoControl+0x13e
0000000e`dabfdd20 00007ffd`a4503434     : 00000000`00000000 00000000`00000000 0000000e`dabfde70 00000000`00000000 : FLTLIB!FilterSendMessage+0x31
0000000e`dabfdd70 00007ff7`9cb147fc     : 00000000`00000000 00000000`00000000 ffffffff`ffffd8f0 00000000`00000000 : cldapi!CfQueryProgress+0x3f4
0000000e`dabfdf60 00000000`00000000     : 00000000`00000000 ffffffff`ffffd8f0 00000000`00000000 00000000`00000032 : poc+0x47fc


SYMBOL_NAME:  cldflt!CldiStreamCompleteRequest+12f

MODULE_NAME: cldflt

IMAGE_NAME:  cldflt.sys

STACK_COMMAND: .process /r /p 0xffffa685b001a080; .thread /r /p 0xffffa685ad7e7080 ; kb

BUCKET_ID_FUNC_OFFSET:  12f

FAILURE_BUCKET_ID:  AV_VRF_cldflt!CldiStreamCompleteRequest

OS_VERSION:  10.0.26100.1

BUILDLAB_STR:  ge_release

OSPLATFORM_TYPE:  x64

OSNAME:  Windows 10

FAILURE_ID_HASH:  {61f2862e-d255-0a0b-0f7e-ddec7a333e8f}

Followup:     MachineOwner
---------

Vendor Response & Timeline

Microsoft acknowledged the report and published a fix. Full details are in the vendor advisory: MSRC — CVE-2026-58613.

Key Takeaways

• CVE-2026-58613 is a CWE-416 use-after-free in cldflt.sys reachable entirely from a low-privileged local process, scoring CVSS 8.8 with a scope change to potential SYSTEM-level code execution.
• The root cause is a May-update code path in CldiStreamCompleteRequest that frees the request — and, through it, the last stream-context reference — before dereferencing that same stream context.
• The exploit weaponizes the driver’s own 60-second watchdog timer list: a provider-progress request is orphaned, its backing object’s refcount is driven to 1, and the timer walk performs the fatal free.
• Terminating the provider process abruptly deliberately bypasses the CfUnregisterSyncRoot cleanup that would otherwise drain the request with STATUS_CLOUD_FILE_PROVIDER_TERMINATED.
• The undocumented CfQueryProgress API turns a timeout race into a deterministic on-demand trigger, which is what makes the bug practical to exploit.
• This is the no-IRP (MasterRequest == NULL) sibling of the earlier IRP-based CVE-2023-29361 in the same request-cancellation machinery.

Defensive Recommendations

• Patch now. Apply the July 2026 Windows cumulative update that ships the fixed cldflt.sys; confirm the driver version is later than 10.0.26100.8457 on affected 24H2/build-26100 systems.
• Inventory exposure. Cloud Files is present on stock Windows 10/11 installs regardless of whether OneDrive is actively used — treat every endpoint as affected until patched, not just OneDrive machines.
• Hunt for the trigger pattern. Watch for processes that register a sync root, call CfReportProviderProgress/CfReportProviderProgress2 with completed < total, then exit without CfUnregisterSyncRoot, and shortly after issue CfQueryProgress.
• Monitor for 0x50 bugchecks bucketed as AV_VRF_cldflt!CldiStreamCompleteRequest; on production hosts an exploit attempt may crash the box rather than succeed, so unexplained cldflt stop codes deserve triage.
• Enable kernel exploit mitigations where supported — HVCI/VBS, kernel-mode Hardware-enforced Stack Protection, and Kernel Data Protection raise the cost of turning this UAF into code execution.
• Constrain low-privilege code with EDR rules and application control; the entire chain runs as a normal user, so behavioral detection at the user-mode API layer is the earliest catch point.
• Track the driver as a monitored attack surface going forward: two CVEs (this one and CVE-2023-29361) now sit in the same cancellation path, so treat future cldflt updates as security-relevant.

Conclusion

CVE-2026-58613 is a compact demonstration of how a single reordering of “free” and “release” in a busy kernel driver can hand a local user a powerful use-after-free primitive. By abusing the Cloud Files watchdog timer — orphaning a provider-progress request, starving the stream context down to its last reference, and forcing the list walk with CfQueryProgress — the researcher turned a benign progress-reporting feature into a deterministic path to freed-memory reuse in non-paged pool. The fix is straightforward once the ordering bug is understood; applying it promptly is the only real mitigation.

Original text: “Microsoft Windows Cloud Files Mini Filter Driver CldiStreamCompleteRequest use-after-free vulnerability” by Marcin ‘Icewall’ Noga at Cisco Talos.