Tcache and safe-linking: version-sensitive heap state

Mechanism

glibc tcache keeps small freed allocations in per-thread singly linked lists. Exploit reasoning must account for bin count, allocation size class, duplicate-free checks, and the encoded next pointers used by newer releases. Safe-linking protects link representation; it does not repair the underlying memory corruption or guarantee that all allocator metadata is inaccessible.

Practical method

Pin the loader and libc, then log allocation addresses and bin state after each operation. Verify whether an allocation comes from tcache, a fastbin, or another path. For encoded links, identify the storage address as well as the desired pointer. Keep count manipulation and pointer manipulation as separate steps.

protected_next = next XOR (address_of_link >> 12)
# This describes the common glibc safe-linking representation,
# not every allocator or all heap pointer fields.

Interpreting evidence

Use debugger observations to show which bin supplies the next allocation. A poisoned-looking memory word is insufficient if the relevant cache count is zero or integrity checks reject the entry.

Pitfalls and limits

Tcache appeared in glibc 2.26; safe-linking is associated with glibc 2.32 and later. Distributions backport changes, and per-thread behavior matters. Do not reuse an old payload solely because the technique name matches.