tcpip.sys 10.0.19041.7548 → 10.0.19041.7663tcpip.sys parses IPv6 extension headers as it walks the receive path, and Ipv6pReceiveHopByHopOptions handles the Hop-by-Hop options header — the one extension header that is processed on every hop, including intermediate routers and the destination. The function reads the attacker-controlled Hdr Ext Len byte, computes a header length of 8 * ExtLen + 8, and then advances the NET_BUFFER cursor by that amount without verifying the buffer actually contains that many bytes. A packet that claims a larger extension length than it carries drives the parse offset beyond the real payload, so subsequent option processing reads and writes out of bounds. The patch adds a Feature_*-gated bounds check that compares the claimed length against the NET_BUFFER’s DataLength field before advancing, and, if the packet is short, sets the next-header type to 59 (No Next Header) and fails the parse with STATUS_INVALID_PARAMETER instead. The result is a remotely reachable, pre-authentication memory-corruption primitive rated CVSS 8.1.
IPv6 replaced IPv4’s fixed set of header options with a linked chain of extension headers. Each extension header begins with a Next Header byte (identifying the type of the following header) and, for most types, a Hdr Ext Len byte that encodes the header’s size. The Hop-by-Hop Options header (Next Header value 0) is special: RFC 8200 requires it to appear first, immediately after the fixed 40-byte IPv6 header, and it is the only extension header that every node along the delivery path is expected to examine rather than just the final destination.
Its length field follows the standard extension-header convention: the header is 8 * Hdr Ext Len + 8 bytes long — a base of 8 bytes plus 8 bytes for each unit in the length byte. Because Hdr Ext Len is a single byte, an attacker can legally claim a header anywhere from 8 bytes up to 8 * 255 + 8 = 2048 bytes, entirely independent of how large the packet on the wire actually is.
In the Windows networking stack, received packets are represented by NET_BUFFER structures chained under a NET_BUFFER_LIST. A NET_BUFFER tracks the current data pointer and, critically, a DataLength field (at offset 0x18) that records how many bytes of real payload remain. The stack walks the extension-header chain by repeatedly calling NetioAdvanceNetBufferList, which moves the data cursor forward by a caller-supplied count and decrements the remaining length. The invariant the whole parser depends on is simple: you never advance past DataLength. Ipv6pReceiveHopByHopOptions is the function that broke it.
Here is the relevant slice of the pre-patch function, decompiled:
if ((int)param_1[6] == 0x28) { // parse offset == 40 (just past fixed IPv6 header)
pbVar3 = (byte *)NdisGetDataBuffer(*(undefined8 *)(lVar2 + 8), 2, local_res8, 1, 0);
*(short *)((longlong)param_1 + 0x11a) = (short)param_1[6];
iVar4 = (uint)pbVar3[1] * 8 + 8; // 8 * Hdr Ext Len + 8
NetioAdvanceNetBufferList(lVar2, iVar4); // advance cursor unconditionally
*(int *)(param_1 + 6) = (int)param_1[6] + iVar4; // bump parse offset
*(uint *)((longlong)param_1 + 0x2c) = (uint)*pbVar3; // Next Header = first byte
}
The function pulls the first two bytes of the Hop-by-Hop header via NdisGetDataBuffer — pbVar3[0] is the Next Header value and pbVar3[1] is the Hdr Ext Len byte. It computes the claimed header length as iVar4 = pbVar3[1] * 8 + 8. Note that only two bytes were guaranteed to be present (the 2 argument to NdisGetDataBuffer); the length derived from the second of those bytes is trusted wholesale.
The very next statement is NetioAdvanceNetBufferList(lVar2, iVar4). There is no comparison against the NET_BUFFER’s DataLength. If the wire packet only carried, say, 16 bytes of Hop-by-Hop data but Hdr Ext Len was set to 255, iVar4 becomes 2048 and the cursor is advanced 2048 bytes forward — far past the end of the actual received data. The parse offset stored at param_1[6] is bumped by the same bogus amount, so the packet-processing state now believes it is sitting at byte 2088 of a packet that never had that many bytes.
Everything downstream inherits corrupted state. Individual TLV options inside the Hop-by-Hop header are walked using offsets and lengths derived from this now-desynchronized cursor, and the option handlers read (and in the router-alert / jumbogram paths, write) relative to a data pointer that no longer points inside the buffer. Because the option-parsing scratch state and the small fixed-size buffers used to marshal option contents live on the kernel stack — including the local_res8 storage seen in the decompilation — over-reading and over-copying against a cursor past the buffer end manifests as a stack-based buffer overflow, matching the MSRC classification.
The core defect is a classic length-field-versus-actual-length mismatch: the code trusts an attacker-supplied size field and mutates the buffer cursor by it without validating that the buffer is that large.
The fixed build (tcpip.sys 7663) changes exactly one function, Ipv6pReceiveHopByHopOptions, growing it from 286 to 324 bytes and adding a single new callee: Feature_3689662776__private_IsEnabledDeviceUsage. The rewritten inner block:
if ((int)param_1[6] == 0x28) {
pbVar4 = (byte *)NdisGetDataBuffer(*(undefined8 *)(lVar2 + 8), 2, local_res8, 1, 0);
*(short *)((longlong)param_1 + 0x11a) = (short)param_1[6];
uVar5 = (uint)pbVar4[1] * 8 + 8; // claimed header length
iVar3 = Feature_3689662776__private_IsEnabledDeviceUsage();
if ((iVar3 == 0) || (uVar5 <= *(uint *)(*(longlong *)(lVar2 + 8) + 0x18))) {
NetioAdvanceNetBufferList(lVar2, uVar5);
*(uint *)(param_1 + 6) = (int)param_1[6] + uVar5;
*(uint *)((longlong)param_1 + 0x2c) = (uint)*pbVar4;
}
else {
*(undefined4 *)((longlong)param_1 + 0x2c) = 0x3b; // Next Header = 59 (No Next Header)
*(undefined4 *)(lVar2 + 0x8c) = 0xc000021b; // STATUS_INVALID_PARAMETER
}
}
Walking the difference:
The new bounds check. The condition uVar5 <= *(uint *)(*(longlong *)(lVar2 + 8) + 0x18) is the fix. lVar2 + 8 dereferences to the NET_BUFFER, and + 0x18 is its DataLength field. The patch now requires that the claimed header length uVar5 be no larger than the bytes actually present before it will advance. Only when the buffer genuinely holds the header does control reach NetioAdvanceNetBufferList and the cursor/offset updates — the same three statements as before.
The failure path. When the packet is too short, the code does not advance. Instead it writes 0x3b (decimal 59, the “No Next Header” pseudo-value) into the next-header field at param_1 + 0x2c, which terminates the extension-header walk cleanly, and stores 0xc000021b — STATUS_INVALID_PARAMETER — into the per-packet status field at lVar2 + 0x8c. This mirrors the existing error handling already used in the sibling branch (the != 0x28 case, which likewise sets 0x3b and an error status and calls IppSendError). The malformed packet is dropped rather than parsed.
(One cosmetic note: the analyst’s post-patch listing shows the status constant as -1073741285 and the summary text mentions 0xC000005B; the diff against the reference build shows 0xc000021b. All are the standard STATUS_INVALID_PARAMETER-family failure code written to bail the parse — the point is that the short-packet path returns a failure and stops, it does not advance.)
Feature_* gating. The check is wrapped in Feature_3689662776__private_IsEnabledDeviceUsage(). When the feature is disabled (iVar3 == 0), the || short-circuits and the code takes the original, unchecked advance path. This is the standard Microsoft Velocity/Feature-flag pattern for shipping a fix dark and enabling it via staged rollout. Because a new Feature_* gate is being added around new validating logic here (not removed from around old logic), this is the genuine security fix — the added gate guards the added bounds check, exactly the signature of a gated remediation.
Functionally, the patch converts an unconditional, attacker-controlled cursor advance into a validated one, restoring the “never advance past DataLength” invariant at the single site that violated it.
The primitive is memory corruption on the kernel receive path, reachable remotely and without authentication. The trigger is a single crafted IPv6 packet: place a Hop-by-Hop Options header immediately after the fixed 40-byte IPv6 header (so the parse offset equals 0x28 and the vulnerable branch is entered), set the Hdr Ext Len byte to a value whose implied length 8 * ExtLen + 8 exceeds the bytes actually delivered in the NET_BUFFER, and truncate the packet accordingly. No handshake, no open socket, and no prior connection state are required, because Hop-by-Hop options are processed unconditionally during IPv6 reception — this is host-firewall-bypassing in the sense that it fires before higher-layer demultiplexing.
Once the cursor is advanced past the buffer, the subsequent Hop-by-Hop option TLV walk operates on out-of-bounds memory, and the option handlers marshal data through fixed-size stack storage — the source of the stack-based overflow. That gives an attacker influence over kernel stack contents adjacent to the parsing routine’s frame, the classic precondition for control-flow hijack via return-address or stack-cookie-adjacent corruption, subject to the usual mitigations (stack cookies, kernel CFG). The CVSS 8.1 with a higher attack complexity reflects that reliable code execution requires shaping the receive buffer layout and defeating those mitigations rather than the trigger being hard — the trigger itself is trivial and deterministic.
Reachability depends on IPv6 being enabled (it is, by default, on all supported Windows versions) and on the host actually processing Hop-by-Hop options for the packet — which includes the destination node and any Windows system acting in a routing/forwarding role. Any attacker who can deliver an IPv6 frame to the target — same link-local segment, or across a network that routes IPv6 to it — can attempt the trigger. The fix’s staged Feature_* gate means the mitigation is only active where that flag is enabled, so the effective exposure window on a given host tracks the rollout state of Feature_3689662776__private_IsEnabledDeviceUsage, not merely the presence of the patched binary.
Full decompilation of Ipv6pReceiveHopByHopOptions before the patch:
void Ipv6pReceiveHopByHopOptions(longlong *param_1)
{
longlong lVar1;
longlong lVar2;
byte *pbVar3;
int iVar4;
undefined2 local_res8 [4];
lVar1 = *(longlong *)(param_1[0x18] + 0x28);
local_res8[0] = 0;
do {
lVar2 = param_1[1];
if (((lVar2 != 0) && (-1 < *(int *)(lVar2 + 0x8c))) &&
(*(char *)(lVar1 + 0x220 + (ulonglong)*(uint *)((longlong)param_1 + 0x2c) * 0x48) != '\0')) {
if (*(uint *)((longlong)param_1 + 0x2c) != 0) {
return;
}
if ((int)param_1[6] == 0x28) {
pbVar3 = (byte *)NdisGetDataBuffer(*(undefined8 *)(lVar2 + 8),2,local_res8,1,0);
*(short *)((longlong)param_1 + 0x11a) = (short)param_1[6];
iVar4 = (uint)pbVar3[1] * 8 + 8;
NetioAdvanceNetBufferList(lVar2,iVar4);
*(int *)(param_1 + 6) = (int)param_1[6] + iVar4;
*(uint *)((longlong)param_1 + 0x2c) = (uint)*pbVar3;
}
else {
*(undefined4 *)((longlong)param_1 + 0x2c) = 0x3b;
*(undefined4 *)(lVar2 + 0x8c) = 0xc000021b;
IppSendError(0,&Ipv6Global,param_1,4,1,0x28000000,0);
}
}
param_1 = (longlong *)*param_1;
} while (param_1 != (longlong *)0x0);
return;
}
Full decompilation of Ipv6pReceiveHopByHopOptions after the patch:
void Ipv6pReceiveHopByHopOptions(longlong *param_1)
{
longlong lVar1;
longlong lVar2;
int iVar3;
byte *pbVar4;
uint uVar5;
undefined2 local_res8 [4];
lVar1 = *(longlong *)(param_1[0x18] + 0x28);
local_res8[0] = 0;
do {
lVar2 = param_1[1];
if (((lVar2 != 0) && (-1 < *(int *)(lVar2 + 0x8c))) &&
(*(char *)(lVar1 + 0x220 + (ulonglong)*(uint *)((longlong)param_1 + 0x2c) * 0x48) != '\0')) {
if (*(uint *)((longlong)param_1 + 0x2c) != 0) {
return;
}
if ((int)param_1[6] == 0x28) {
pbVar4 = (byte *)NdisGetDataBuffer(*(undefined8 *)(lVar2 + 8),2,local_res8,1,0);
*(short *)((longlong)param_1 + 0x11a) = (short)param_1[6];
uVar5 = (uint)pbVar4[1] * 8 + 8;
iVar3 = Feature_3689662776__private_IsEnabledDeviceUsage();
if ((iVar3 == 0) || (uVar5 <= *(uint *)(*(longlong *)(lVar2 + 8) + 0x18))) {
NetioAdvanceNetBufferList(lVar2,uVar5);
*(uint *)(param_1 + 6) = (int)param_1[6] + uVar5;
*(uint *)((longlong)param_1 + 0x2c) = (uint)*pbVar4;
}
else {
*(undefined4 *)((longlong)param_1 + 0x2c) = 0x3b;
*(undefined4 *)(lVar2 + 0x8c) = 0xc000021b;
}
}
else {
*(undefined4 *)((longlong)param_1 + 0x2c) = 0x3b;
*(undefined4 *)(lVar2 + 0x8c) = 0xc000021b;
IppSendError(0,&Ipv6Global,param_1,4,1,0x28000000,0);
}
}
param_1 = (longlong *)*param_1;
} while (param_1 != (longlong *)0x0);
return;
}
tcpip.sys 10.0.22621.7079 → 10.0.22621.7219tcpip.sys maintains a per-compartment forward-path cache — a scalable hash table of IppPath entries that caches next-hop routing decisions for received packets. In IppCreateForwardPath, a freshly allocated path entry was inserted into the live hash table (RtlInsertEntryHashTable) and only had its “valid” bit (+0x50 | 1) set after an intervening call to IppRestructureHashTableUnderLock. Although the write lock is held throughout, the restructure/prune machinery and concurrent readers key off that valid bit, and the ordering left a window where an entry visible in the table could be treated inconsistently — a classic publish-before-initialize error that leads to a use-after-free of the IppPath object. The patch, gated behind CFR feature 411806010, moves the valid-bit assignment to immediately after insertion (before pruning and restructuring), so the entry is never observable in an intermediate, not-yet-valid state.
When the IP layer receives a packet that needs to be forwarded or delivered, it must resolve a next hop. Rather than walk the route table on every packet, tcpip.sys caches resolved routes in a forward-path cache keyed by source/destination address. Each cache element is an IppPath structure allocated from a per-processor lookaside list (ExAllocateFromLookasideListEx) and linked into a scalable hash table — the RTL scalable hash table primitives (RtlInsertEntryHashTable, RtlAcquireScalableWriteLockAtDpcLevel) that Windows uses for high-contention, per-CPU-sharded lookups.
The relevant object layout, from the decompiled allocator, is a 0x58-byte header followed by inline copies of the destination and (optionally) source address keys:
+0x18 = 0x70667049 — the ASCII tag 'Ipfp', the structure’s type signature.+0x20 = pointer to the inline destination key (_Dst, at header+0x58).+0x28 = pointer to the inline source key (_Dst_01), or NULL.+0x3c = initial reference count, set to 1.+0x48 = a back-pointer to the associated next-hop/interface object (param_8), whose own refcount is bumped via CarAcquireCacheAwareReference (for tag 'Ipla') or a raw LOCK inc (for tag 'Ipne').+0x50 = the flags byte, whose bit 0 is the “path is valid / fully published” indicator.The hash is computed with RtlCompute37Hash over the destination key (and the source key, when present), seeded with g_37HashSeed, then OR’d with 0x80000000. Insertion, capacity-based pruning (IppPrunePathSetUnderLock), and table restructuring (IppRestructureHashTableUnderLock) all happen under a single scalable write lock acquired on param_1 + 0x4c0.
The lookup side — IppFindNextHopInFwdCacheOrRouteTable and friends, which call into this function — walks the same hash table to find an existing path before creating a new one. Reference counting on IppPath entries is what keeps them alive across that lookup/use window; when the count drops to zero the entry is freed back to the lookaside list. The valid bit at +0x50 governs whether an entry is eligible to be seen and referenced by those consumers.
Here is the tail of the pre-patch IppCreateForwardPath, from allocation-complete through publication:
*(undefined4 *)((longlong)_Dst_00 + 0x3c) = 1; // refcount = 1
*(undefined4 *)((longlong)_Dst_00 + 0x40) = *(undefined4 *)(param_1 + 0x14);
*(int **)((longlong)_Dst_00 + 0x48) = param_8;
if (*param_8 == 0x616c7049) { // 'Ipla'
CarAcquireCacheAwareReference(*(undefined8 *)(param_8 + 8),1);
}
else if (*param_8 == 0x656e7049) { // 'Ipne'
LOCK(); param_8[1] = param_8[1] + 1; UNLOCK();
}
...
lVar1 = param_1 + 0x4c0;
RtlAcquireScalableWriteLockAtDpcLevel(lVar1,&local_48);
RtlInsertEntryHashTable(param_1 + 0x640,_Dst_00,uVar3 | 0x80000000,0); // (1) PUBLISH
if ((uint)(*(int *)(param_1 + 0x604) * 2) <= *(uint *)(param_1 + 0x654)) {
IppPrunePathSetUnderLock(param_1,lVar1,2); // (2) PRUNE
}
IppRestructureHashTableUnderLock(param_1 + 0x640); // (3) RESTRUCTURE
*(byte *)((longlong)_Dst_00 + 0x50) = *(byte *)((longlong)_Dst_00 + 0x50) | 1; // (4) MARK VALID
KeReleaseInStackQueuedSpinLockFromDpcLevel(&local_48);
The defect is the ordering of steps (1) through (4). The entry _Dst_00 becomes a member of the live hash table at step (1), but its validity flag is not set until step (4) — after two operations that walk and mutate the table’s contents:
IppPrunePathSetUnderLock (2) is a garbage-collection pass triggered when the table’s occupancy (+0x654) reaches twice its target (+0x604 * 2). Pruning enumerates entries and evicts stale ones based on their state and reference counts.IppRestructureHashTableUnderLock (3) rebalances the scalable table’s per-bucket chains.Although the scalable write lock is held across the whole sequence, that lock is not the only synchronization boundary that matters here. The scalable hash table is designed for lockless / reader-optimistic traversal on its read paths, and the entry’s +0x50 valid bit is precisely the flag that tells a consumer “this entry is fully constructed and safe to reference.” By making the entry reachable at step (1) with +0x50 == 0, the code creates a window in which the pruning and restructuring logic — and any reader that reaches the entry through the sharded per-CPU structures without taking the full write lock — can encounter a path entry that is linked but not yet marked valid.
The consequence is a use-after-free: pruning/eviction logic can act on the not-yet-valid entry (or a racing consumer can grab and then release a reference on it) in a way that drives the freshly created IppPath — still owned by the refcount = 1 the constructor set at +0x3c — to premature teardown and return to the lookaside list, while IppCreateForwardPath continues to operate on _Dst_00 (it dereferences it again at step (4) and hands lVar1 to IppPathSetStartOrContinueTimer). The caller (IppDispatchReceivePacketHelper) then continues down the receive path holding a stale reference to freed lookaside memory that can be reallocated as another IppPath under attacker-influenced network load.
The post-patch function introduces exactly one behavioral change, gated by a Component Feature Rollout (CFR) flag, plus the addition of the enablement helper. The valid-bit write is hoisted to run immediately after insertion and before pruning/restructuring:
RtlInsertEntryHashTable(param_1 + 0x640,_Dst_00,uVar3 | 0x80000000,0);
iVar4 = Feature_411806010__private_IsEnabledDeviceUsage();
if (iVar4 != 0) { // NEW code path
*(byte *)((longlong)_Dst_00 + 0x50) = *(byte *)((longlong)_Dst_00 + 0x50) | 1;
}
if ((uint)(*(int *)(param_1 + 0x604) * 2) <= *(uint *)(param_1 + 0x654)) {
IppPrunePathSetUnderLock(param_1,lVar1,2);
}
IppRestructureHashTableUnderLock(param_1 + 0x640);
iVar4 = Feature_411806010__private_IsEnabledDeviceUsage();
if (iVar4 == 0) { // OLD (vulnerable) path
*(byte *)((longlong)_Dst_00 + 0x50) = *(byte *)((longlong)_Dst_00 + 0x50) | 1;
}
KeReleaseInStackQueuedSpinLockFromDpcLevel(&local_48);
The logic is a straight A/B fork on the feature state:
IsEnabledDeviceUsage() != 0): set +0x50 |= 1 right after RtlInsertEntryHashTable. The entry is now marked valid before IppPrunePathSetUnderLock and IppRestructureHashTableUnderLock ever touch the table. There is no observable window in which the entry is linked but not valid — publish and initialize-complete are now effectively atomic with respect to the prune/restructure machinery.The Feature_* gate is the standard Windows CFR pattern. The new helper:
ulonglong Feature_411806010__private_IsEnabledDeviceUsage(void)
{
ulonglong uVar1;
if ((Feature_411806010__private_featureState & 0x10) == 0) {
uVar1 = Feature_411806010__private_IsEnabledFallback(
Feature_411806010__private_featureState, 3);
}
else {
uVar1 = (ulonglong)(Feature_411806010__private_featureState & 1);
}
return uVar1;
}
reads the cached Feature_411806010__private_featureState: if bit 0x10 (the “state is decided/cached” bit) is set, it returns the low bit as the enable/disable answer; otherwise it consults Feature_411806010__private_IsEnabledFallback with default priority 3 to resolve the rollout decision. The remaining textual differences in the diff — iVar4/uVar5/lVar6 renames and the identical IppPathSetStartOrContinueTimer timer-interval arithmetic — are decompiler register-naming artifacts from the two inserted Feature_* calls, not semantic changes. The function’s length grew from 623 to 645 bytes, consistent with two small call/test/jz/or sequences replacing one unconditional or.
Note that once the flag reaches full deployment, the “disabled” branch is dead code; keeping it is purely the CFR safety valve.
The primitive is a use-after-free of a lookaside-backed IppPath object in non-paged pool, reachable from the packet receive path. IppCreateForwardPath is invoked from IppDispatchReceivePacketHelper / IppFindNextHopInFwdCacheOrRouteTable / IpIpsProviderFindNextHop — i.e., while processing inbound IP datagrams whose next hop is not already cached. No authentication and no local access are required, which is what earns the CVSS 9.8 / network attack vector: an attacker who can send packets to the target (crafted to miss the forward-path cache and force fresh entry creation) drives the vulnerable allocation path.
The trigger is a race, and the window is small — it exists only between RtlInsertEntryHashTable and the delayed +0x50 |= 1, spanning a prune and a restructure. Two conditions make it practical to hit despite the “high complexity” feel of a kernel race:
2 * target (+0x654 >= +0x604 * 2). By flooding the target with packets to many distinct destinations (or spoofed source/destination pairs, since the source key participates in the hash when present), an attacker inflates the cache toward that threshold on demand, guaranteeing that new insertions land in exactly the code path where pruning runs while the just-inserted entry is still invalid.refcount = 1, collapsing the reference to zero and freeing the object back to the per-processor lookaside list.Once the IppPath is freed, the lookaside list makes reallocation highly deterministic: the next IppCreateForwardPath on the same processor hands back the same block, letting an attacker groom the freed slot with a new, attacker-shaped path entry while the original caller still holds a pointer to it. Controlled fields at +0x48 (the interface/next-hop back-pointer, which is dereferenced and reference-counted) and +0x20/+0x28 (key pointers) provide the levers to convert the dangling reference into a controlled dereference and, ultimately, remote code execution in kernel context. Because the corrupted object is a routing-cache entry consulted on every subsequent forwarded packet, the attacker also gets repeated, low-noise opportunities to re-trigger and stabilize the exploit.
The fix eliminates the window entirely rather than merely narrowing it: with the feature enabled, no code between insertion and the valid-bit write can observe an entry that is linked-but-invalid, so neither the prune pass nor a concurrent reader can act on a partially constructed IppPath.
Reliable exploitation of this bug manifests as an unusual inbound traffic pattern: a burst of packets to a large number of distinct destination/source pairs from a single or small set of remote peers, engineered to churn the forward-path cache past its prune threshold. On unpatched hosts, failed race attempts tend to surface as tcpip.sys bugchecks in IppPrunePathSetUnderLock, IppRestructureHashTableUnderLock, or IppPathSetStartOrContinueTimer with a corrupted or freed IppPath (tag 'Ipfp' / 0x70667049) as the faulting object — a useful signature when triaging crash telemetry. On patched systems, confirm the mitigation is live by checking that CFR feature 411806010 is in the enabled state, since the vulnerable ordering remains reachable whenever the flag is off.
Full decompilation of IppCreateForwardPath before the patch:
/* WARNING: Globals starting with '_' overlap smaller symbols at the same address */
void IppCreateForwardPath
(longlong param_1,void *param_2,void *param_3,undefined4 param_4,undefined4 param_5,
undefined1 param_6,undefined4 param_7,int *param_8)
{
void *_Dst;
longlong lVar1;
undefined1 auVar2 [16];
uint uVar3;
undefined8 uVar4;
void *_Dst_00;
longlong lVar5;
ulonglong _Size;
void *_Dst_01;
undefined8 local_48;
undefined8 uStack_40;
undefined8 local_38;
local_48 = 0;
uStack_40 = 0;
local_38 = 0;
_Dst_01 = (void *)0x0;
_Size = (ulonglong)*(ushort *)(*(longlong *)(*(longlong *)(param_1 + 0x28) + 0x10) + 6);
uVar4 = PplpRetrieveListIndex(*(undefined8 *)(*(longlong *)(param_1 + 0x28) + 0x4ea8));
_Dst_00 = (void *)ExAllocateFromLookasideListEx(uVar4);
if (_Dst_00 == (void *)0x0) {
if (DAT_0 < '\0') {
McTemplateK0z_EtwWriteTransfer(&MICROSOFT_TCPIP_PROVIDER_Context,&TCPIP_MEMORY_FAILURES);
}
}
else {
memset(_Dst_00,0,0x58);
_Dst = (void *)((longlong)_Dst_00 + 0x58);
memmove(_Dst,param_3,_Size);
if (param_2 != (void *)0x0) {
_Dst_01 = (void *)(_Size + (longlong)_Dst);
memmove(_Dst_01,param_2,_Size);
}
*(undefined4 *)((longlong)_Dst_00 + 0x34) = param_5;
*(void **)((longlong)_Dst_00 + 0x28) = _Dst_01;
*(undefined1 *)((longlong)_Dst_00 + 0x38) = param_6;
*(undefined4 *)((longlong)_Dst_00 + 0x30) = param_7;
*(undefined4 *)((longlong)_Dst_00 + 0x18) = 0x70667049;
*(undefined4 *)((longlong)_Dst_00 + 0x1c) = param_4;
*(void **)((longlong)_Dst_00 + 0x20) = _Dst;
*(undefined4 *)((longlong)_Dst_00 + 0x3c) = 1;
*(undefined4 *)((longlong)_Dst_00 + 0x40) = *(undefined4 *)(param_1 + 0x14);
*(int **)((longlong)_Dst_00 + 0x48) = param_8;
if (*param_8 == 0x616c7049) {
CarAcquireCacheAwareReference(*(undefined8 *)(param_8 + 8),1);
}
else if (*param_8 == 0x656e7049) {
LOCK();
param_8[1] = param_8[1] + 1;
UNLOCK();
}
lVar1 = *(longlong *)((longlong)_Dst_00 + 0x28);
uVar3 = RtlCompute37Hash(g_37HashSeed,*(undefined8 *)((longlong)_Dst_00 + 0x20),
*(undefined2 *)
(*(longlong *)(*(longlong *)(param_1 + 0x28) + 0x10) + 6));
if (lVar1 != 0) {
uVar3 = RtlCompute37Hash(uVar3,lVar1,
*(undefined2 *)
(*(longlong *)(*(longlong *)(param_1 + 0x28) + 0x10) + 6));
}
lVar1 = param_1 + 0x4c0;
RtlAcquireScalableWriteLockAtDpcLevel(lVar1,&local_48);
RtlInsertEntryHashTable(param_1 + 0x640,_Dst_00,uVar3 | 0x80000000,0);
if ((uint)(*(int *)(param_1 + 0x604) * 2) <= *(uint *)(param_1 + 0x654)) {
IppPrunePathSetUnderLock(param_1,lVar1,2);
}
IppRestructureHashTableUnderLock(param_1 + 0x640);
*(byte *)((longlong)_Dst_00 + 0x50) = *(byte *)((longlong)_Dst_00 + 0x50) | 1;
KeReleaseInStackQueuedSpinLockFromDpcLevel(&local_48);
auVar2._8_8_ = 0;
auVar2._0_8_ = _DAT_1 / 10000;
lVar5 = SUB168(ZEXT816(0x624dd2f1a9fbe77) * auVar2,8);
IppPathSetStartOrContinueTimer
(lVar1,lVar5 + (_DAT_1 / 10000 - lVar5 >> 1) >> 8,1);
}
return;
}
Full decompilation of IppCreateForwardPath after the patch:
/* WARNING: Globals starting with '_' overlap smaller symbols at the same address */
void IppCreateForwardPath
(longlong param_1,void *param_2,void *param_3,undefined4 param_4,undefined4 param_5,
undefined1 param_6,undefined4 param_7,int *param_8)
{
void *_Dst;
longlong lVar1;
undefined1 auVar2 [16];
uint uVar3;
int iVar4;
undefined8 uVar5;
void *_Dst_00;
longlong lVar6;
ulonglong _Size;
void *_Dst_01;
undefined8 local_48;
undefined8 uStack_40;
undefined8 local_38;
local_48 = 0;
uStack_40 = 0;
local_38 = 0;
_Dst_01 = (void *)0x0;
_Size = (ulonglong)*(ushort *)(*(longlong *)(*(longlong *)(param_1 + 0x28) + 0x10) + 6);
uVar5 = PplpRetrieveListIndex(*(undefined8 *)(*(longlong *)(param_1 + 0x28) + 0x4ea8));
_Dst_00 = (void *)ExAllocateFromLookasideListEx(uVar5);
if (_Dst_00 == (void *)0x0) {
if (DAT_0 < '\0') {
McTemplateK0z_EtwWriteTransfer(&MICROSOFT_TCPIP_PROVIDER_Context,&TCPIP_MEMORY_FAILURES);
}
}
else {
memset(_Dst_00,0,0x58);
_Dst = (void *)((longlong)_Dst_00 + 0x58);
memmove(_Dst,param_3,_Size);
if (param_2 != (void *)0x0) {
_Dst_01 = (void *)(_Size + (longlong)_Dst);
memmove(_Dst_01,param_2,_Size);
}
*(undefined4 *)((longlong)_Dst_00 + 0x34) = param_5;
*(void **)((longlong)_Dst_00 + 0x28) = _Dst_01;
*(undefined1 *)((longlong)_Dst_00 + 0x38) = param_6;
*(undefined4 *)((longlong)_Dst_00 + 0x30) = param_7;
*(undefined4 *)((longlong)_Dst_00 + 0x18) = 0x70667049;
*(undefined4 *)((longlong)_Dst_00 + 0x1c) = param_4;
*(void **)((longlong)_Dst_00 + 0x20) = _Dst;
*(undefined4 *)((longlong)_Dst_00 + 0x3c) = 1;
*(undefined4 *)((longlong)_Dst_00 + 0x40) = *(undefined4 *)(param_1 + 0x14);
*(int **)((longlong)_Dst_00 + 0x48) = param_8;
if (*param_8 == 0x616c7049) {
CarAcquireCacheAwareReference(*(undefined8 *)(param_8 + 8),1);
}
else if (*param_8 == 0x656e7049) {
LOCK();
param_8[1] = param_8[1] + 1;
UNLOCK();
}
lVar1 = *(longlong *)((longlong)_Dst_00 + 0x28);
uVar3 = RtlCompute37Hash(g_37HashSeed,*(undefined8 *)((longlong)_Dst_00 + 0x20),
*(undefined2 *)
(*(longlong *)(*(longlong *)(param_1 + 0x28) + 0x10) + 6));
if (lVar1 != 0) {
uVar3 = RtlCompute37Hash(uVar3,lVar1,
*(undefined2 *)
(*(longlong *)(*(longlong *)(param_1 + 0x28) + 0x10) + 6));
}
lVar1 = param_1 + 0x4c0;
RtlAcquireScalableWriteLockAtDpcLevel(lVar1,&local_48);
RtlInsertEntryHashTable(param_1 + 0x640,_Dst_00,uVar3 | 0x80000000,0);
iVar4 = Feature_411806010__private_IsEnabledDeviceUsage();
if (iVar4 != 0) {
*(byte *)((longlong)_Dst_00 + 0x50) = *(byte *)((longlong)_Dst_00 + 0x50) | 1;
}
if ((uint)(*(int *)(param_1 + 0x604) * 2) <= *(uint *)(param_1 + 0x654)) {
IppPrunePathSetUnderLock(param_1,lVar1,2);
}
IppRestructureHashTableUnderLock(param_1 + 0x640);
iVar4 = Feature_411806010__private_IsEnabledDeviceUsage();
if (iVar4 == 0) {
*(byte *)((longlong)_Dst_00 + 0x50) = *(byte *)((longlong)_Dst_00 + 0x50) | 1;
}
KeReleaseInStackQueuedSpinLockFromDpcLevel(&local_48);
auVar2._8_8_ = 0;
auVar2._0_8_ = _DAT_1 / 10000;
lVar6 = SUB168(ZEXT816(0x624dd2f1a9fbe77) * auVar2,8);
IppPathSetStartOrContinueTimer
(lVar1,lVar6 + (_DAT_1 / 10000 - lVar6 >> 1) >> 8,1);
}
return;
}
Full decompilation of Feature_411806010__private_IsEnabledDeviceUsage after the patch:
ulonglong Feature_411806010__private_IsEnabledDeviceUsage(void)
{
ulonglong uVar1;
if ((Feature_411806010__private_featureState & 0x10) == 0) {
uVar1 = Feature_411806010__private_IsEnabledFallback(Feature_411806010__private_featureState,3);
}
else {
uVar1 = (ulonglong)(Feature_411806010__private_featureState & 1);
}
return uVar1;
}
tcpip.sys 10.0.19041.7291 → 10.0.19041.7417tcpip.sys reassembles length-prefixed FSE messages arriving on a kernel (WSK) receive path into a fixed 0x400-byte scratch buffer that lives inside a per-connection context. FseProcessIncomingMessages decides, on each incoming chunk, how many bytes to memmove into that buffer while it waits for a partial message to complete. In the pre-patch code the only sanity checks on the copy length were a lower bound (0x21) and a comparison against the declared message length — nothing ever verified that the number of bytes buffered stayed within the 0x400-byte buffer. An adjacent-network attacker who fragments a message so that the incoming payload is smaller than its declared length causes the whole incoming chunk to be copied in unbounded, producing a controlled heap overflow. The patch introduces RtlUIntAdd-checked accumulation and hard 0x400 caps on both the declared length and the copy size, and gates the new behavior behind Feature_98821435.
The Fse* family of routines in tcpip.sys implements a framed message layer on top of a kernel-mode socket. FseWskReceiveIrpCompletionRoutine fires when a WSK receive IRP completes, and hands the freshly received buffer to FseProcessIncomingMessages. Data on the wire is a stream of self-describing messages: the first uint of each message (*_Src) is its total length, and valid messages are constrained to the range [0x21, 0x400] — at least 0x21 (33) bytes of header, at most 0x400 (1024) bytes total.
Because TCP is a byte stream, a single receive can contain several whole messages, a whole message plus a fragment, or just a fragment of one message. To handle fragments straddling receive boundaries, each connection carries a reassembly context (reached via *(param_1 + 0x20) + 0xa8, aliased lVar1). Two fields matter:
lVar1 + 0x88 — a fixed 0x400-byte buffer holding the bytes of a partially-received message.lVar1 + 0x488 — a uint count of how many bytes are currently held in that buffer.The routine’s job on each call is to drain complete messages (dispatching each to FseProcessIncomingMessage) and to stash any trailing partial message into +0x88, updating the +0x488 count, so the next receive can continue where this one left off. When fewer than 4 bytes are buffered the length prefix itself is split across receives, so the code reconstructs a 0x20-byte header in a stack scratch buffer (local_68/local_60) to recover the declared length before deciding how much to copy.
The defect is the complete absence of an upper bound tying the amount copied into +0x88 to the buffer’s actual 0x400-byte size. Consider the “nothing buffered yet” path (*(lVar1 + 0x488) == 0, label LAB_0) in the pre-patch decompilation:
uVar5 = (uint)_Size;
while (uVar5 != 0) {
uVar5 = (uint)_Size;
if ((uVar5 < 0x21) || (uVar5 < *_Src)) {
memmove((void *)(lVar1 + 0x88), _Src, _Size); // <-- unbounded
*(uint *)(lVar1 + 0x488) = uVar5;
return 1;
}
FseProcessIncomingMessage(lVar1, _Src);
uVar4 = *_Src;
_Src = (uint *)((longlong)_Src + (ulonglong)uVar4);
uVar5 = uVar5 - uVar4;
_Size = (size_t)uVar5;
}
_Size/uVar5 here is the number of bytes remaining in the current receive. The loop dispatches complete messages, but the moment the remaining data is smaller than the declared message length (uVar5 < *_Src), it treats the remainder as a partial message and buffers all of it with memmove((void *)(lVar1 + 0x88), _Src, _Size). The guard is (uVar5 < 0x21) || (uVar5 < *_Src) — a lower bound and a “does this complete a message?” test. Neither caps _Size at 0x400.
An attacker controls both operands. *_Src is the first four bytes of the attacker’s data, so setting it to a large value (say 0xFFFFFFFF) forces the uVar5 < *_Src branch for any realistic receive. _Size is the size of the payload the attacker sent. Send a single chunk larger than 0x400 with an oversized length prefix and memmove writes _Size bytes into the 1024-byte buffer at +0x88, running straight off the end into whatever the heap allocation places after the reassembly context.
The same structural flaw exists in the “bytes already buffered” branches. When 4 or more bytes are buffered the declared length is read straight from the buffer (iVar6 = *(int *)(lVar1 + 0x88)) and validated only against the range [0x21, 0x400] via 0x3df < iVar6 - 0x21U. When the incoming chunk does not complete the message, the code again does:
memmove(pvVar2, _Src, _Size); // pvVar2 = lVar1 + 0x88 + uVar4
*(int *)(lVar1 + 0x488) = *(int *)(lVar1 + 0x488) + uVar5;
The destination is +0x88 + count, and the length is the full incoming _Size, with the count then advanced by uVar5. There is no check that count + _Size <= 0x400. The only near-bound in the whole function was uVar5 < 0x20 - uVar4 in the count < 4 sub-case — and note that constant is 0x20, the header reconstruction size, not 0x400, so it never protected the message body copy. Both the declared length validation and the running count are int/uint and are added without overflow checking, so even the range check on the declared length can be bypassed by arranging the accumulation to wrap.
The post-patch FseProcessIncomingMessages grows from 765 to 1158 bytes and pulls in two new callees: RtlUIntAdd for overflow-checked addition and Feature_98821435__private_IsEnabledDeviceUsage as the gate for the new logic. Every copy path now enforces the 0x400 ceiling.
The count == 0 drain loop (LAB_1). The unbounded buffer-the-remainder case is replaced with an explicit cap:
uVar8 = (uint)_Size_00;
if (uVar8 < 0x21) {
Feature_98821435__private_IsEnabledDeviceUsage();
}
else {
if (*_Src <= uVar8) { // message fully present -> dispatch
FseProcessIncomingMessage(lVar1, _Src);
uVar6 = *_Src;
_Src = (uint *)((longlong)_Src + (ulonglong)uVar6);
uVar8 = uVar8 - uVar6;
_Size_00 = (size_t)uVar8;
if (uVar8 == 0) goto LAB_2;
goto LAB_1;
}
iVar3 = Feature_98821435__private_IsEnabledDeviceUsage();
if (iVar3 == 0) goto LAB_3; // feature off: legacy copy
uVar6 = *_Src;
if ((0x400 < uVar6) || (0x400 < uVar8)) { // NEW: hard caps
/* WPP trace 0x30, then */ goto LAB_4; // LAB_4 -> return 0
}
}
LAB_3:
memmove((void *)(lVar1 + 0x88), _Src, _Size_00);
*(uint *)(lVar1 + 0x488) = uVar8;
When the feature is enabled and a partial message is about to be buffered, the code now rejects the input (return 0, after emitting a WPP trace with id 0x30) if either the declared length *_Src or the remaining size uVar8 exceeds 0x400. Since neither the buffer offset (0) plus a ≤0x400 copy can exceed the 0x400 buffer, the overflow is closed.
The count < 4 append path. Here the declared length isn’t yet known in full, so the running total is what must be bounded. The patch inserts an overflow-checked add before the copy:
if (uVar8 < uVar6) { // uVar6 = 0x20 - count
iVar3 = Feature_98821435__private_IsEnabledDeviceUsage();
uVar4 = (ulonglong)*(uint *)(lVar1 + 0x488);
if (iVar3 != 0) {
local_68[0] = 0;
iVar3 = RtlUIntAdd(uVar4, _Size_00, local_68); // count + incoming
if ((iVar3 < 0) || (0x400 < local_68[0])) { // overflow OR > 0x400
/* WPP trace 0x29 / 0x2d, then */ goto LAB_4; // return 0
}
}
memmove((void *)(lVar1 + 0x88 + uVar4), _Src, _Size_00);
*(int *)(lVar1 + 0x488) = *(int *)(lVar1 + 0x488) + uVar8;
...
}
RtlUIntAdd(count, incoming, &sum) returns a negative NTSTATUS on 32-bit wraparound, and the code additionally rejects sum > 0x400. Only if count + incoming both fits in a uint and stays inside the buffer does the memmove at +0x88 + count proceed. The same guarded pattern is duplicated in the reconstructed-header branch (after the two memmoves into the local_60 scratch header that recover local_60[0], the declared length) and in the count >= 4 branch, where the declared length is re-read from the buffer and again validated against [0x21, 0x400] (iVar3 - 0x21U < 0x3e0) before the completing copy at LAB_11/LAB_10.
Feature gating. Every new check is wrapped in Feature_98821435__private_IsEnabledDeviceUsage(). When it returns zero the function falls through to the legacy code paths (goto LAB_3, goto LAB_8, goto LAB_11) that retain only the old range check; when it returns non-zero the RtlUIntAdd / 0x400 logic runs. The co-patched gate helper itself is trivial:
ulonglong Feature_98821435__private_IsEnabledDeviceUsage(void)
{
if ((Feature_98821435__private_featureState & 0x10) == 0)
return Feature_98821435__private_IsEnabledFallback(
Feature_98821435__private_featureState, 3);
return (ulonglong)(Feature_98821435__private_featureState & 1);
}
This is the standard Velocity/CFR staged-rollout pattern: bit 0x10 of the cached feature state selects between a locally-cached decision (bit 0) and the IsEnabledFallback slow path. It is the switch that arms the entire overflow fix, which is why it is included in the same patch even though it contains no security logic of its own. Note that once fully rolled out (feature forced on) the iVar == 0 legacy branches become dead code.
The primitive is a classic linear heap buffer overflow. The overflowed object is the per-connection reassembly context; the write starts at +0x88 (or +0x88 + count) and runs past the buffer’s 0x400 boundary. Both the length and the contents of the overflow are attacker-controlled: the length is the size of the fragment the attacker chooses to send (bounded only by MTU/receive sizing pre-patch), and the contents are the raw bytes on the wire. That combination — controlled overflow length plus controlled overflow data adjacent to a kernel pool allocation — is a strong foundation for corrupting an adjacent object’s header or a neighboring pointer, the usual route from pool overflow to arbitrary write and ultimately kernel code execution.
Triggering is straightforward and requires no authentication: the attacker sends a fragment whose 4-byte length prefix advertises a message larger than the data actually delivered in that receive (uVar5 < *_Src), and whose payload exceeds 0x400 bytes. The count == 0 path takes the bait on the very first fragment — there is no race and no need to win a timing window, because the vulnerable memmove executes synchronously in the WSK receive completion. The count-nonzero paths give a second, incremental variant where the attacker dribbles bytes across several segments to push the running +0x488 count past 0x400, which is useful for shaping exactly where the write lands.
The CVSS 9.6 / “adjacent network” scoping reflects that the FSE message layer is reachable over the link-local network rather than the full Internet, and the “low complexity” despite the elaborate branching is accurate: the attacker never has to reason about the reassembly state machine’s happy path. They only need one mismatched length prefix and an oversized payload, both of which are unauthenticated bytes on the wire. The patch’s 0x400 caps and RtlUIntAdd guards neutralize every path that previously let the copy size or the accumulated count escape the buffer bound.
Full decompilation of FseProcessIncomingMessages before the patch:
/* WARNING: Function: __security_check_cookie replaced with injection: security_check_cookie */
undefined8 FseProcessIncomingMessages(longlong param_1,longlong param_2)
{
longlong lVar1;
void *pvVar2;
undefined8 uVar3;
uint uVar4;
uint *_Src;
uint uVar5;
size_t _Size;
int iVar6;
ulonglong _Size_00;
undefined1 auStack_a8 [32];
uint local_88;
undefined8 local_68;
undefined8 uStack_60;
ulonglong local_48;
local_48 = __security_cookie ^ (ulonglong)auStack_a8;
_Src = *(uint **)(param_1 + 0x30);
uVar5 = *(uint *)(param_2 + 0x38);
_Size = (size_t)uVar5;
lVar1 = *(longlong *)(*(longlong *)(param_1 + 0x20) + 0xa8);
if (((undefined **)WPP_GLOBAL_Control != &WPP_GLOBAL_Control) &&
(4 < (byte)WPP_GLOBAL_Control[0x29])) {
local_88 = uVar5;
WPP_SF__guid_d(*(undefined8 *)(WPP_GLOBAL_Control + 0x18),0x24,
&WPP_ac8b62d4254a334b4d08bba9079ab535_Traceguids,lVar1 + 0x18);
}
uVar4 = *(uint *)(lVar1 + 0x488);
if (uVar4 == 0) {
LAB_0:
uVar5 = (uint)_Size;
while (uVar5 != 0) {
uVar5 = (uint)_Size;
if ((uVar5 < 0x21) || (uVar5 < *_Src)) {
memmove((void *)(lVar1 + 0x88),_Src,_Size);
*(uint *)(lVar1 + 0x488) = uVar5;
return 1;
}
FseProcessIncomingMessage(lVar1,_Src);
uVar4 = *_Src;
_Src = (uint *)((longlong)_Src + (ulonglong)uVar4);
uVar5 = uVar5 - uVar4;
_Size = (size_t)uVar5;
}
}
else {
if (((undefined **)WPP_GLOBAL_Control != &WPP_GLOBAL_Control) &&
(4 < (byte)WPP_GLOBAL_Control[0x29])) {
WPP_SF__guid_(*(undefined8 *)(WPP_GLOBAL_Control + 0x18),0x25,
&WPP_ac8b62d4254a334b4d08bba9079ab535_Traceguids,lVar1 + 0x18);
uVar4 = *(uint *)(lVar1 + 0x488);
}
if (uVar4 < 4) {
_Size_00 = (ulonglong)uVar4;
if (uVar5 < 0x20 - uVar4) {
memmove((void *)(lVar1 + 0x88 + _Size_00),_Src,_Size);
*(int *)(lVar1 + 0x488) = *(int *)(lVar1 + 0x488) + uVar5;
if ((undefined **)WPP_GLOBAL_Control == &WPP_GLOBAL_Control) {
return 1;
}
if ((byte)WPP_GLOBAL_Control[0x29] < 5) {
return 1;
}
uVar3 = 0x28;
}
else {
local_68 = 0;
uStack_60 = 0;
memmove(&local_68,(void *)(lVar1 + 0x88),_Size_00);
memmove((void *)((longlong)&local_68 + _Size_00),_Src,(ulonglong)(0x20 - uVar4));
iVar6 = (int)local_68;
if (0x3df < (int)local_68 - 0x21U) {
if ((undefined **)WPP_GLOBAL_Control == &WPP_GLOBAL_Control) {
return 0;
}
if ((byte)WPP_GLOBAL_Control[0x29] < 2) {
return 0;
}
uVar3 = 0x29;
local_88 = (int)local_68;
goto LAB_1;
}
pvVar2 = (void *)(lVar1 + 0x88 + _Size_00);
if ((int)local_68 - uVar4 <= uVar5) {
memmove(pvVar2,_Src,(ulonglong)((int)local_68 - uVar4));
goto LAB_2;
}
memmove(pvVar2,_Src,_Size);
*(int *)(lVar1 + 0x488) = *(int *)(lVar1 + 0x488) + uVar5;
if ((undefined **)WPP_GLOBAL_Control == &WPP_GLOBAL_Control) {
return 1;
}
if ((byte)WPP_GLOBAL_Control[0x29] < 5) {
return 1;
}
uVar3 = 0x2a;
}
}
else {
iVar6 = *(int *)(lVar1 + 0x88);
if (0x3df < iVar6 - 0x21U) {
if ((undefined **)WPP_GLOBAL_Control == &WPP_GLOBAL_Control) {
return 0;
}
if ((byte)WPP_GLOBAL_Control[0x29] < 2) {
return 0;
}
uVar3 = 0x26;
local_88 = iVar6;
LAB_1:
WPP_SF__guid_DDD(*(undefined8 *)(WPP_GLOBAL_Control + 0x18),uVar3);
return 0;
}
pvVar2 = (void *)(lVar1 + 0x88 + (ulonglong)uVar4);
if (iVar6 - uVar4 <= uVar5) {
memmove(pvVar2,_Src,(ulonglong)(iVar6 - uVar4));
LAB_2:
_Src = (uint *)((longlong)_Src + (ulonglong)(uint)(iVar6 - *(int *)(lVar1 + 0x488)));
_Size = (size_t)(uVar5 + (*(int *)(lVar1 + 0x488) - iVar6));
FseProcessIncomingMessage(lVar1,lVar1 + 0x88,iVar6);
*(undefined4 *)(lVar1 + 0x488) = 0;
goto LAB_0;
}
memmove(pvVar2,_Src,_Size);
*(int *)(lVar1 + 0x488) = *(int *)(lVar1 + 0x488) + uVar5;
if ((undefined **)WPP_GLOBAL_Control == &WPP_GLOBAL_Control) {
return 1;
}
if ((byte)WPP_GLOBAL_Control[0x29] < 5) {
return 1;
}
uVar3 = 0x27;
}
WPP_SF_(*(undefined8 *)(WPP_GLOBAL_Control + 0x18),uVar3,
&WPP_ac8b62d4254a334b4d08bba9079ab535_Traceguids);
}
return 1;
}
Full decompilation of FseProcessIncomingMessages after the patch:
/* WARNING: Function: __security_check_cookie replaced with injection: security_check_cookie */
undefined8 FseProcessIncomingMessages(longlong param_1,longlong param_2)
{
longlong lVar1;
int iVar2;
int iVar3;
size_t _Size;
void *_Dst;
ulonglong uVar4;
undefined8 uVar5;
uint uVar6;
undefined8 uVar7;
uint uVar8;
size_t _Size_00;
undefined *puVar9;
uint *_Src;
undefined1 auStack_a8 [32];
uint local_88;
uint local_68 [2];
int local_60 [8];
ulonglong local_40;
local_40 = __security_cookie ^ (ulonglong)auStack_a8;
_Src = *(uint **)(param_1 + 0x30);
uVar8 = *(uint *)(param_2 + 0x38);
_Size_00 = (size_t)uVar8;
lVar1 = *(longlong *)(*(longlong *)(param_1 + 0x20) + 0xa8);
if (((undefined **)WPP_GLOBAL_Control != &WPP_GLOBAL_Control) &&
(4 < (byte)WPP_GLOBAL_Control[0x29])) {
local_88 = uVar8;
WPP_SF__guid_d(*(undefined8 *)(WPP_GLOBAL_Control + 0x18),0x24,
&WPP_bc8d3dbf0274335cb22dd3f8ccf775cf_Traceguids,lVar1 + 0x18);
}
_Size = (size_t)*(uint *)(lVar1 + 0x488);
if (*(uint *)(lVar1 + 0x488) == 0) {
LAB_0:
if ((int)_Size_00 != 0) {
LAB_1:
uVar8 = (uint)_Size_00;
if (uVar8 < 0x21) {
Feature_98821435__private_IsEnabledDeviceUsage();
}
else {
if (*_Src <= uVar8) {
FseProcessIncomingMessage(lVar1,_Src);
uVar6 = *_Src;
_Src = (uint *)((longlong)_Src + (ulonglong)uVar6);
uVar8 = uVar8 - uVar6;
_Size_00 = (size_t)uVar8;
if (uVar8 == 0) goto LAB_2;
goto LAB_1;
}
iVar3 = Feature_98821435__private_IsEnabledDeviceUsage();
if (iVar3 == 0) goto LAB_3;
uVar6 = *_Src;
if ((0x400 < uVar6) || (0x400 < uVar8)) {
if (((undefined **)WPP_GLOBAL_Control == &WPP_GLOBAL_Control) ||
((byte)WPP_GLOBAL_Control[0x29] < 2)) goto LAB_4;
uVar5 = *(undefined8 *)(WPP_GLOBAL_Control + 0x18);
uVar7 = 0x30;
puVar9 = (undefined *)(ulonglong)uVar6;
local_88 = uVar6;
goto LAB_5;
}
}
LAB_3:
memmove((void *)(lVar1 + 0x88),_Src,_Size_00);
*(uint *)(lVar1 + 0x488) = uVar8;
}
LAB_2:
uVar7 = 1;
}
else {
if (((undefined **)WPP_GLOBAL_Control != &WPP_GLOBAL_Control) &&
(4 < (byte)WPP_GLOBAL_Control[0x29])) {
WPP_SF__guid_(*(undefined8 *)(WPP_GLOBAL_Control + 0x18),0x25,
&WPP_bc8d3dbf0274335cb22dd3f8ccf775cf_Traceguids,lVar1 + 0x18);
_Size = (size_t)*(uint *)(lVar1 + 0x488);
}
if ((uint)_Size < 4) {
uVar6 = 0x20 - (uint)_Size;
if (uVar8 < uVar6) {
iVar3 = Feature_98821435__private_IsEnabledDeviceUsage();
uVar4 = (ulonglong)*(uint *)(lVar1 + 0x488);
if (iVar3 != 0) {
local_68[0] = 0;
iVar3 = RtlUIntAdd(uVar4,_Size_00,local_68);
if ((iVar3 < 0) || (0x400 < local_68[0])) {
if (((undefined **)WPP_GLOBAL_Control == &WPP_GLOBAL_Control) ||
((byte)WPP_GLOBAL_Control[0x29] < 2)) goto LAB_4;
uVar7 = 0x29;
LAB_6:
local_88 = (int)uVar4 + uVar8;
uVar5 = *(undefined8 *)(WPP_GLOBAL_Control + 0x18);
puVar9 = WPP_GLOBAL_Control;
LAB_5:
WPP_SF__guid_DD(uVar5,uVar7,puVar9,lVar1 + 0x18);
goto LAB_4;
}
}
memmove((void *)(lVar1 + 0x88 + uVar4),_Src,_Size_00);
*(int *)(lVar1 + 0x488) = *(int *)(lVar1 + 0x488) + uVar8;
if (((undefined **)WPP_GLOBAL_Control != &WPP_GLOBAL_Control) &&
(4 < (byte)WPP_GLOBAL_Control[0x29])) {
uVar7 = 0x2a;
LAB_7:
WPP_SF_(*(undefined8 *)(WPP_GLOBAL_Control + 0x18),uVar7,
&WPP_bc8d3dbf0274335cb22dd3f8ccf775cf_Traceguids);
}
goto LAB_2;
}
local_60[0] = 0;
local_60[1] = 0;
local_60[2] = 0;
local_60[3] = 0;
memmove(local_60,(void *)(lVar1 + 0x88),_Size);
memmove((void *)((longlong)local_60 + _Size),_Src,(ulonglong)uVar6);
iVar2 = Feature_98821435__private_IsEnabledDeviceUsage();
iVar3 = local_60[0];
if (iVar2 == 0) {
if (local_60[0] - 0x21U < 0x3e0) goto LAB_8;
if (((undefined **)WPP_GLOBAL_Control != &WPP_GLOBAL_Control) &&
(1 < (byte)WPP_GLOBAL_Control[0x29])) {
uVar7 = 0x2c;
local_88 = local_60[0];
goto LAB_9;
}
}
else {
if (local_60[0] - 0x21U < 0x3e0) {
LAB_8:
uVar6 = local_60[0] - *(uint *)(lVar1 + 0x488);
if (uVar8 < uVar6) {
iVar3 = Feature_98821435__private_IsEnabledDeviceUsage();
uVar4 = (ulonglong)*(uint *)(lVar1 + 0x488);
if (iVar3 != 0) {
local_68[0] = 0;
iVar3 = RtlUIntAdd(uVar4,_Size_00,local_68);
if ((iVar3 < 0) || (0x400 < local_68[0])) {
if (((undefined **)WPP_GLOBAL_Control != &WPP_GLOBAL_Control) &&
(1 < (byte)WPP_GLOBAL_Control[0x29])) {
uVar7 = 0x2d;
goto LAB_6;
}
goto LAB_4;
}
}
memmove((void *)(lVar1 + 0x88 + uVar4),_Src,_Size_00);
*(int *)(lVar1 + 0x488) = *(int *)(lVar1 + 0x488) + uVar8;
if (((undefined **)WPP_GLOBAL_Control != &WPP_GLOBAL_Control) &&
(4 < (byte)WPP_GLOBAL_Control[0x29])) {
uVar7 = 0x2e;
goto LAB_7;
}
goto LAB_2;
}
memmove((void *)(lVar1 + 0x88 + (ulonglong)*(uint *)(lVar1 + 0x488)),_Src,(ulonglong)uVar6
);
goto LAB_10;
}
if (((undefined **)WPP_GLOBAL_Control != &WPP_GLOBAL_Control) &&
(1 < (byte)WPP_GLOBAL_Control[0x29])) {
uVar7 = 0x2b;
local_88 = local_60[0];
goto LAB_9;
}
}
}
else {
iVar3 = *(int *)(lVar1 + 0x88);
iVar2 = Feature_98821435__private_IsEnabledDeviceUsage();
if (iVar2 == 0) {
if (iVar3 - 0x21U < 0x3e0) goto LAB_11;
if (((undefined **)WPP_GLOBAL_Control != &WPP_GLOBAL_Control) &&
(1 < (byte)WPP_GLOBAL_Control[0x29])) {
uVar7 = 0x27;
local_88 = iVar3;
goto LAB_9;
}
}
else {
if (iVar3 - 0x21U < 0x3e0) {
LAB_11:
_Dst = (void *)(lVar1 + 0x88 + (ulonglong)*(uint *)(lVar1 + 0x488));
uVar6 = iVar3 - *(uint *)(lVar1 + 0x488);
if (uVar6 <= uVar8) {
memmove(_Dst,_Src,(ulonglong)uVar6);
LAB_10:
_Src = (uint *)((longlong)_Src + (ulonglong)(uint)(iVar3 - *(int *)(lVar1 + 0x488)));
_Size_00 = (size_t)(uVar8 + (*(int *)(lVar1 + 0x488) - iVar3));
FseProcessIncomingMessage(lVar1,lVar1 + 0x88,iVar3);
*(undefined4 *)(lVar1 + 0x488) = 0;
goto LAB_0;
}
memmove(_Dst,_Src,_Size_00);
*(int *)(lVar1 + 0x488) = *(int *)(lVar1 + 0x488) + uVar8;
if (((undefined **)WPP_GLOBAL_Control != &WPP_GLOBAL_Control) &&
(4 < (byte)WPP_GLOBAL_Control[0x29])) {
uVar7 = 0x28;
goto LAB_7;
}
goto LAB_2;
}
if (((undefined **)WPP_GLOBAL_Control != &WPP_GLOBAL_Control) &&
(1 < (byte)WPP_GLOBAL_Control[0x29])) {
uVar7 = 0x26;
local_88 = iVar3;
LAB_9:
WPP_SF__guid_DDD(*(undefined8 *)(WPP_GLOBAL_Control + 0x18),uVar7);
}
}
}
LAB_4:
uVar7 = 0;
}
return uVar7;
}
Full decompilation of Feature_98821435__private_IsEnabledDeviceUsage after the patch:
ulonglong Feature_98821435__private_IsEnabledDeviceUsage(void)
{
ulonglong uVar1;
if ((Feature_98821435__private_featureState & 0x10) == 0) {
uVar1 = Feature_98821435__private_IsEnabledFallback(Feature_98821435__private_featureState,3);
}
else {
uVar1 = (ulonglong)(Feature_98821435__private_featureState & 1);
}
return uVar1;
}
tcpip.sys 10.0.19041.6926 → 10.0.19041.7181tcpip.sys processes the IPv4 Loose/Strict Source and Record Route (LSRR/SSRR) option inside Ipv4pReceiveRoutingHeader. When the host is configured to forward a source-routed datagram, the routine looks up an IPP_PATH to the next address in the route option, pulls the next hop out of it, and then clones and forwards the packet. In the vulnerable build the code dropped its reference on that path object — including calling IppCleanupPathPrimitive when the count reached zero — immediately after extracting the next hop, but then kept dereferencing the same path pointer (IppGetRouteFromPath, next-hop comparisons, clone construction) further down. That is a classic release-then-use, and because receive processing runs concurrently across RSS processors the last-reference drop races other holders, turning it into an exploitable use-after-free on a pool-backed network structure. The patch introduces a proper IppDereferencePath helper that performs the interlocked decrement plus teardown as one operation, and — gated behind Feature_221233465 — holds the path (and route) reference for the entire lifetime of the forwarding operation, releasing it only in a unified cleanup epilogue.
IPv4 source routing lets the sender embed a list of intermediate hops in an IP option (Loose Source and Record Route, type 131 / Strict Source and Record Route, type 137). A router that honors these options must, for each datagram, pick the next address from the option, resolve a route toward it, rewrite the option pointer, and forward the packet out toward that hop. Windows disables source-route forwarding by default, but the code path is still present and reachable when the relevant global/interface knobs are set — and the vulnerable logic is guarded by a global (DAT_2 == 2 short-circuits it) plus the per-interface forwarding flags checked at the top of the function.
The unit of work in Ipv4pReceiveRoutingHeader is a receive-batch element (param_1), a large structure that carries the current NBL (param_1[1]), parsed header offsets, the source/destination addresses, and status fields. The interesting object for this bug is the path, IPP_PATH, returned indirectly through IppRouteToDestinationInternal. In the decompilation the path is a pointer with:
+0x50,+0x54 (written from the global tick counter _DAT_5 / 10000),IppGetNextHopFromPath, andIppGetRouteFromPath.The next hop is a discriminated object identified by a 4-byte signature at offset 0: 0x616c7049 ("Ipla", a local address) or 0x656e7049 ("Ipne", a neighbor). The forwarding code takes a reference on whichever it is (CarAcquireCacheAwareReference for a local address, an interlocked increment for a neighbor) and later releases via IppDereferenceLocalAddress / IppDereferenceNeighbor. Paths are freed through IppCleanupPathPrimitive, which tears down the embedded route, next hop, and source address and returns the block to its FSB pool (FsbFree).
In the 6926 build, once a route to the next source-route hop is resolved, the function does this (edited for clarity):
iVar16 = IppRouteToDestinationInternal(local_80, piVar3, lVar15, lVar10);
if (iVar16 < 0) {
plVar11 = (longlong *)0x0;
}
else {
plVar11 = (longlong *)IppGetNextHopFromPath(local_a0); // cache next hop
// stamp path "last used" time at +0x54
*(int *)(local_a0 + 0x54) = /* current ticks */;
if (*(int *)(local_a0 + 0x50) == 0) {
KeBugCheck(0x1c); // refcount sanity
}
LOCK();
piVar1 = (int *)(local_a0 + 0x50);
iVar16 = *piVar1;
*piVar1 = *piVar1 + -1; // drop path reference
UNLOCK();
if (iVar16 == 1) {
IppCleanupPathPrimitive(local_a0); // ...and free it if last
}
}
if (plVar11 != (longlong *)0x0) {
if (((int)*plVar11 == 0x616c7049) && ((int)plVar11[3] != 1)) goto LAB_1;
if ((*(byte *)((longlong)param_1 + 0xb1) & 0x10) != 0) {
lVar10 = IppGetRouteFromPath(local_a0); // USE-AFTER-FREE
...
local_a0 is the path. The block above decrements its reference count at +0x50 and, when that count transitions 1 -> 0, calls IppCleanupPathPrimitive(local_a0), which frees the object back to its pool. Yet the very next if (plVar11 != NULL) branch keeps operating on local_a0: IppGetRouteFromPath(local_a0) reads the route pointer out of the path it may have just freed, and the broader forwarding path continues to depend on the route/next-hop state that belongs to that path.
Two things make this a real, exploitable defect rather than a theoretical one:
The reference being dropped is the working reference. The path here is the one produced by the route lookup on this code path; the KeBugCheck(0x1c) guard confirms the developers already knew hitting a zero count here is fatal. Nothing re-acquires the reference before the later uses.
Receive processing is concurrent. IPv4 receive runs on multiple RSS processors, and paths are shared, cached objects in the compartment’s path set. Another context validating, garbage-collecting (IppGarbageCollectPaths, IppFlushPaths), or otherwise dereferencing the same path can drive the count to zero in a window around this decrement. The MSRC classification — “concurrent execution using shared resource with improper synchronization” — is precisely this: the lifetime of the path spans a clone/forward sequence, but the code released it mid-sequence, so a racing releaser (or simply being the last holder) frees the block while IppGetRouteFromPath and the clone logic still read through it.
Because IppGetRouteFromPath returns *(path + 0x14) and the subsequent forwarding logic chases route/next-hop/interface pointers out of that freed allocation, an attacker who can reclaim the freed IPP_PATH pool block with controlled data steers those reads — and the reference-count manipulations on the “route” and “next hop” it hands back — into attacker-controlled memory.
The 7181 build restructures the whole tail of Ipv4pReceiveRoutingHeader around a new reference-counting helper and a feature gate. There are two code-changed functions plus a cluster of newly imported WIL/feature-staging helpers.
IppCleanupPathPrimitive → IppDereferencePathThe old IppCleanupPathPrimitive (which unconditionally tore down and freed a path) is joined by a new function, IppDereferencePath, that folds the interlocked decrement and the sanity KeBugCheck into the teardown:
int IppDereferencePath(longlong *param_1)
{
// stamp last-used time at +0x54
*(int *)((longlong)param_1 + 0x54) = /* current ticks */;
if ((int)param_1[10] == 0) { // count at +0x50
KeBugCheck(0x1c);
}
LOCK();
lVar4 = *(param_1 + 10);
*(int *)(param_1 + 10) = (int)lVar4 + -1;
UNLOCK();
iVar5 = (int)lVar4 + -1;
if (iVar5 == 0) {
// exact body of the old IppCleanupPathPrimitive:
// drop route, drop local-addr/neighbor next hop, ExFreePoolWithTag, FsbFree
}
return iVar5;
}
This is the key hygiene change: the “decrement, check, and free-if-last” dance that was open-coded inline (and misplaced) is now a single primitive that callers invoke when they are actually done with the path. The standalone IppCleanupPathPrimitive still exists for the paths that genuinely need unconditional teardown (its caller list loses only Ipv4pReceiveRoutingHeader), while every place that used to hand-roll the decrement now calls IppDereferencePath — note the new IppDereferencePath entries appearing in the caller lists of IppDereferenceRoute, IppDereferenceNeighbor, IppDereferenceLocalAddress, FsbFree, and ExFreePoolWithTag.
Ipv4pReceiveRoutingHeader: hold the reference to the endIn the patched routine, the early inline decrement/cleanup is gone. After IppRouteToDestinationInternal succeeds, the next hop is fetched and the path reference is retained:
pppppppiVar10 = (int *******)IppGetNextHopFromPath(local_b8);
iVar15 = Feature_221233465__private_IsEnabledDeviceUsage();
pppppppiVar20 = pppppppiVar18; // keep the path reference
if (iVar15 == 0) {
IppDereferencePath(pppppppiVar18); // legacy behavior only when feature OFF
}
When the feature is enabled, pppppppiVar20 keeps the live path reference and the code proceeds through the full forwarding sequence — IppGetRouteFromPath(pppppppiVar20), the next-hop signature checks, NetioAllocateAndReferenceCloneNetBufferList, RtlCopyMdlToMdl, option rewrite, IppCopyPacket, and IppForwardPackets — all while the path is still referenced. Only in the shared epilogue is everything released, in order:
// drop the next hop (local addr or neighbor)
if (pppppppiVar10 != 0) {
if (*(int *)pppppppiVar10 == 0x616c7049) IppDereferenceLocalAddress(pppppppiVar10);
else if (*(int *)pppppppiVar10 == 0x656e7049) IppDereferenceNeighbor(pppppppiVar10);
}
iVar15 = Feature_221233465__private_IsEnabledDeviceUsage();
if (iVar15 != 0) {
if (pppppppiVar20 != 0) { // now release the path
IppDereferencePath(pppppppiVar20);
local_b8 = 0;
}
if (local_a8 != 0) { // and the route, once
IppDereferenceRoute(local_a8);
local_a8 = 0;
}
}
The route obtained via IppGetRouteFromPath is likewise cached in local_a8 and released exactly once at the end, instead of the old pattern where the route was dereferenced inline (IppDereferenceRoute(lVar10)) in several branches while the path had already been dropped. The result is a single, well-defined ownership window: the path and its route are live from lookup through forward completion, and torn down together afterward — eliminating both the premature free and the double-handling of the route pointer.
Feature_221233465 gatingThe fix is wrapped in the WIL feature-staging machinery newly pulled into tcpip.sys: Feature_221233465__private_IsEnabledDeviceUsage (and its fallback → wil_details_IsEnabledFallback → wil_details_FeatureStateCache_ReevaluateCachedFeatureEnabledState → RtlQueryFeatureConfiguration / ZwQueryWnfStateData). Per the standard reading of these gates, adding a Feature_* check around new logic marks a newly staged fix: with the feature off, Ipv4pReceiveRoutingHeader still performs an early IppDereferencePath (the legacy-shaped behavior), and only with the feature on does the corrected “hold to the end” lifetime take effect. This lets Microsoft roll the corrected reference discipline out under Velocity/A-B control rather than flipping it unconditionally. The many added wil_details_* functions (StagingConfig_Load, StagingConfig_QueryFeatureState, FeatureReporting_*) are the supporting cache/telemetry plumbing for that gate, not part of the bug itself.
The primitive is a use-after-free of a pool-backed IPP_PATH driven entirely by a received IPv4 packet, giving CVSS 8.1 / “remote code execution.” Reachability:
Ipv4pReceiveRoutingHeader (correct option length, pbVar4[9] != 0x2b, header length equal to (*pbVar4 & 0xf) << 2, etc.). No credentials or local access are needed — the packet just has to reach a host that honors source-route forwarding.DAT_2 != 2, forwarding flags set on param_1). Default installs disable source-route forwarding, which is the main practical mitigation and why this is 8.1 rather than a wormable 9.8; routers, gateways, ICS/appliance images, and hosts with source routing explicitly enabled are the exposed population.1 -> 0 decrement itself frees the path and the immediately following IppGetRouteFromPath reads freed memory; or (b) win the concurrent race — a second receive/GC context on another RSS processor drops the path’s last reference during the window between the decrement and the later dereferences. Attackers can widen this window and improve reclamation odds by flooding source-routed packets across multiple queues (RSS spreads them by flow hash), keeping the compartment’s path set churning while grooming the FSB/pool with same-sized allocations to reclaim the freed IPP_PATH with controlled bytes.IppGetRouteFromPath yields path+0x14 (the route), the next-hop signature is read from offset 0 to decide between CarAcquireCacheAwareReference and an interlocked increment, and the clone path copies attacker-influenced option bytes. Controlling the reclaimed contents converts the UAF into a controlled fake-route / fake-next-hop dereference and reference-count manipulation on attacker memory — the standard on-ramp from a network-reachable kernel UAF to arbitrary write and code execution. The pre-patch KeBugCheck(0x1c) only catches an already-zero count before the decrement; it does nothing about the count reaching zero at the decrement or a racing releaser, which is exactly the exploited condition.The patch closes the window completely by never dropping the path (or its route) until the forwarding operation that depends on them has fully finished, and by centralizing the decrement-and-free in IppDereferencePath so the “free if last” transition can no longer be separated from the point where the caller relinquishes ownership.