Pool corruption through a primitive ladder

A kernel overflow’s usefulness depends on which object is adjacent and which metadata fields it can corrupt. Choosing an object with a length or pointer field can turn a short overwrite into a larger, more controllable capability.

Research anchor and scope

Cherie-Anne Lee’s CVE-2024-30085 analysis examines an unchecked copy into a 0x1000 paged-pool allocation in cldflt.sys. For Windows 10 22H2, the article identifies KB5039211 as the fix. Its chain uses WNF metadata corruption, ALPC objects, and PipeAttribute objects to build disclosure and access primitives. Structure offsets and user-memory assumptions are environment-specific; the source does not justify transferring its full chain to arbitrary Windows builds.

Start with overwrite geometry

Record allocation size, copy length, controllable overflow bytes, pool type, alignment, and object lifetime. A sixteen-byte overwrite cannot control every field of an adjacent large object. Map exactly which header or field lands within reach before choosing a spray object.

In an independent toy allocator, object A contains a fixed-size buffer and object B contains {length, data}. A small overflow into B’s length can make B’s normal read API disclose bytes beyond its allocation. That API supplies a new read capability; the original overflow does not itself become an arbitrary address read. A further pointer corruption may be needed to choose a destination or source.

Verify every rung

First demonstrate adjacency and a harmless length change. Next verify bounded out-of-bounds read with a marker in another allocation. Then establish whether a leak identifies a real kernel pointer rather than incidental bytes. Only after resolving address uncertainty should a test try to redirect a pointer to a controlled benign location.

Heap grooming needs more than large allocation counts. Match allocation classes, introduce holes, observe replacement, and account for per-process or per-CPU behavior. An object freed immediately after overflow may still leave durable corruption in its neighbor, but the reused hole changes subsequent layout. Track both the corrupted object’s lifetime and every object referenced by it.

Build boundaries and cleanup

Validate layouts from symbols or direct inspection for the tested build. Pointer tagging, encoded handles, pool hardening, page protections, and kernel access to user addresses can break a historical construction. A pointer leak does not grant write, and a bounded write does not prove token replacement or privilege escalation.

Leave a primitive ledger listing current reach, address knowledge, repeatability, and crash conditions. Do not port token offsets by name alone. Cleanup itself can dereference corrupted links and crash after the demonstration, so restoration and object teardown belong to reliability testing. A complete escalation requires a separate, validated security target after the memory primitives work.