Tcache overlap across consolidation paths

A double-free defense may inspect membership in one freelist while the exploitable inconsistency arises between multiple allocator paths. The key question is whether one physical region can simultaneously be treated as available in two incompatible ways.

Research anchor and scope

how2heap’s glibc 2.35 House of Botcake example uses a full tcache, normal-bin consolidation, and a later repeated free to produce overlap. It then changes an encoded tcache next pointer through the overlapping allocation. The source uses the default capacity of seven and includes safe-linking encoding introduced in glibc 2.32. Those defaults and the exact checks must be verified against the challenge’s libc; this brief includes no copied exploit program.

Keep two state diagrams

One diagram describes physical heap regions: boundaries, neighboring chunks, and consolidation. The other describes logical freelists: which pointers are present in tcache or normal bins. A pointer may remain reachable from program data after its original chunk boundary has been absorbed into a larger free region.

An independent toy allocator illustrates the danger. Region [0,100) becomes part of a merged free region [0,200), but another freelist still contains pointer 0 as a separate entry. Allocating the merged region and then allocating pointer 0 returns overlapping ownership. One caller can overwrite the other’s contents despite both believing they own valid allocations.

Verify the allocator routing

Fill counts, request sizes, and free ordering decide whether a chunk enters tcache or reaches consolidation. Draining one tcache slot changes the next free’s route. A guard chunk can keep the merged region from coalescing with the top chunk. Record these effects after each operation instead of describing every repeated free as equivalent.

Once overlap is established, test it with a harmless marker before poisoning a freelist. Determine the offset from the new allocation’s user pointer to the old chunk’s next field. With safe-linking, encode the chosen next pointer using the storage location’s address as required by the allocator; merely knowing the destination address is insufficient. Alignment checks and sufficient list count remain independent conditions.

Primitive and version limits

A repeated free does not imply an immediate arbitrary allocation. This construction also requires the right size class, controllable sequence, consolidation, and later allocation through the overlapping region. Thread changes or allocator tuning can invalidate the state model.

An allocation returned at a chosen address is still subject to what the application writes, how much it writes, and whether it later frees that pointer. Modern target selection cannot assume historical malloc hooks exist. Keep overlap, freelist control, chosen allocation, and security impact as separate milestones, each with its own address and lifetime assumptions.