hacktricks-tcache-bin-attack

Imported from Mriskiali/jb (skills/hacktricks_skills/binary-exploitation/tcache-bin-attack/SKILL.md). Install upstream with npx skills add Mriskiali/jb --skill tcache-bin-attack. Copyright stays with the author.

Hacktricks: Tcache Bin Attack

Source: Hacktricks Book — auto-converted by Cybermes.

Tcache Bin Attack

Basic Information

For more information about what a Tcache bin is, check this page:

{{#ref}} bins-and-memory-allocations.md {{#endref}}

The Tcache attack (also known as Tcache poisoning) is the tcache equivalent of a fast-bin attack: the attacker corrupts the next pointer stored in a freed tcache entry so that a later malloc() returns an attacker-chosen address.

This primitive is only useful if the attacker can first write into a freed chunk. Common ways of getting that primitive are explained here:

{{#ref}} overwriting-a-freed-chunk.md {{#endref}}

Historically, this was introduced together with tcache in glibc 2.26 and was initially very easy to exploit. Modern glibc added several checks, so the attack is still relevant, but it now depends a lot more on the target version and the primitive you start from.

Modern constraints

• glibc 2.29+ added stronger tcache double-free detection using the key field stored inside a freed tcache_entry. A plain free(A); free(B); free(A); usually aborts now unless the key check is bypassed or the chunk is reintroduced through another path.
• glibc 2.32+ added safe-linking to singly-linked allocator lists (tcache and fastbins). The stored next pointer is no longer raw, but mangled as:

stored_next = target ^ (address_of_next_field >> 12)

Therefore, a modern tcache poisoning usually needs either:

• A heap leak to compute the protected pointer correctly, or
• A different primitive that bypasses/abuses safe-linking instead of forging the pointer directly.[1]
• Alignment checks also became stricter, which is why a bad poisoned pointer now tends to crash with malloc(): unaligned tcache chunk detected.
• glibc 2.34+ removed the old malloc hooks from the active API, so classic end goals such as overwriting __malloc_hook / __free_hook should be treated as version-specific legacy targets, not as the default modern outcome.

In practice, the modern end goal is usually one of these:

• Return a chunk on top of another heap object to get arbitrary read/write.
• Return a chunk on a writable global / application structure and corrupt a code pointer later used by the program.
• Return a chunk on top of a structure later abused for FSOP, ROP, or another post-write primitive.

What a poisoned tcache entry looks like

A freed tcache chunk is reused as a tcache_entry:

struct tcache_entry {
    struct tcache_entry *next;
    uintptr_t key;
};

So, after freeing a chunk, the first qword of its user data becomes the singly-linked-list pointer and the next qword is used for the double-free check. If the vulnerability lets you overwrite either of them, you can often turn it into:

• Arbitrary allocation by corrupting next
• Double-free bypass by corrupting key

Basic modern poisoning flow

1. Obtain a primitive that lets you edit a freed chunk.
2. Free a chunk of the target tcache size.
3. Leak or infer the freed chunk address if safe-linking is enabled.
4. Overwrite its next pointer with the mangled version of the target address.
5. Allocate once to consume the corrupted entry.
6. Allocate again to get a chunk returned at the chosen target.

For glibc 2.32+ the forged value is typically:

fake_next = target ^ (address_of_victim_next_field >> 12)

If the returned pointer is not aligned to the allocator expectations, malloc() will usually abort before you get control.

Practical version notes

• Modern PoCs usually keep at least two freed entries in the target tcache bin before poisoning it (free(a); free(b); overwrite b->next) instead of corrupting a single-element list. This matches current glibc behaviour better and avoids brittle one-chunk demos.
• On glibc 2.42+, tcache can optionally cache much larger chunks if the environment raises glibc.malloc.tcache_max. Therefore, assumptions such as "larger than 0x410 reaches unsorted/small/large bins" are no longer universally valid on tuned targets.[3]
• If a local lab unexpectedly keeps large chunks inside tcache, either fill that tcache bin first or temporarily force the classic allocator paths while debugging:

GLIBC_TUNABLES=glibc.malloc.tcache_count=0 ./binary
GLIBC_TUNABLES=glibc.malloc.tcache_max=1032 ./binary

Tcache indexes attack

Usually it's possible to find at the beginning of the heap a chunk containing the amount of chunks per index inside the tcache and the address to the head chunk of each tcache index. If for some reason it's possible to modify this information, it would be possible to make the head chunk of some index point to a desired address so then allocating a chunk of the corresponding size returns that controlled address.

This is powerful because it doesn't just poison one freed entry: it corrupts the per-thread tcache metadata itself, which can let you pivot several size classes at once.

Metadata-centric tcache attacks

If you can reach the tcache_perthread_struct itself, poisoning the metadata is usually stronger than corrupting a single freed chunk: a write into entries[idx] can retarget future allocations of that size class, and a write into counts[idx] can make glibc believe cached chunks exist when they should not.

Useful modern variants to recognise:

• House of Water: turns a UAF/overflow into control of tcache_perthread_struct and is a good modern answer when safe-linking makes direct freelist poisoning awkward.
• Safe-link double protect: selected allocator paths can protect an already protected value again. The technique arranges the pointer positions so the relevant XOR masks cancel or transform into the required value; it is not enough to XOR any protected pointer twice, because PROTECT_PTR derives its mask from the storage address.[2]
• Tcache relative write: if you can first corrupt allocator parameters such as mp_.tcache_bins, glibc may compute oversized tc_idx values and write tcache metadata out of bounds into later heap memory.
• glibc 2.42 metadata hijacking: recent how2heap notes show that tcache_perthread_struct may be initialized later and not necessarily be the first heap allocation anymore, so an overflow/UAF on a large earlier chunk can directly overwrite entries[] and make the next small malloc() return an attacker-chosen address.[2]

Modern variants worth knowing

House of Botcake

This is the standard modern answer when the old tcache double-free no longer works. The idea is to use overlap/consolidation with the unsorted bin so the victim chunk ends up both reachable from tcache and part of a larger freed region. After regaining access to overlapping memory, you poison the tcache entry as usual.

This is especially useful on modern glibc when you have:

• A way to trigger consolidation
• A double-free-like primitive that is blocked by tcache checks
• Enough heap control to recover the victim chunk and rewrite its mangled next

Tcache stashing unlink attack

This is not a direct "overwrite next inside a freed tcache chunk" attack, but it is a very relevant tcache-focused arbitrary-allocation primitive. It abuses the path where glibc moves chunks from a small bin into tcache. If you can corrupt the small-bin metadata (typically bk) before that transfer, glibc can end up stashing a fake chunk into tcache, after which a normal malloc() returns it.

This is useful when a challenge gives you stronger control over small-bin metadata than over a freed tcache entry itself.

Safe-linking bypasses

On glibc 2.32+ the core problem is not "how do I overwrite next?" but "how do I produce a valid protected pointer?" Common answers are:

• Leak the heap by printing or reading a freed tcache chunk.
• Use an overlap/UAF to recover the heap base and then encode the poisoned pointer correctly.
• Abuse a primitive that effectively applies the protection logic twice or that corrupts the tcache metadata rather than a single entry.
• Read back mangled pointers from freed chunks and use helpers such as decrypt_safe_linking to recover the real pointer / heap base before forging the poisoned next.[4]

Examples

• CTF https://guyinatuxedo.github.io/29-tcache/dcquals19_babyheap/index.html[5]
  • Libc info leak: It's possible to fill the tcaches, add a chunk into the unsorted list, empty the tcache and re-allocate the chunk from the unsorted bin only overwriting the first 8B, leaving the second address to libc from the chunk intact so we can read it.
  • Tcache attack: The binary is vulnerable a 1B heap overflow. This will be abuse to change the size header of an allocated chunk making it bigger. Then, this chunk will be freed, adding it to the tcache of chunks of the fake size. Then, we will allocate a chunk with the faked size, and the previous chunk will be returned knowing that this chunk was actually smaller and this grants up the opportunity to overwrite the next chunk in memory.
    We will abuse this to overwrite the next chunk's FD pointer to point to a sensitive target, so then later allocations return a controlled pointer and give an arbitrary write primitive.
• CTF https://guyinatuxedo.github.io/29-tcache/plaid19_cpp/index.html[6]
  • Libc info leak: There is a use-after-free and a double-free. The write-up leaks a libc address by reading the linkage of a chunk placed in a small bin, similarly to an unsorted-bin leak.
  • Tcache attack: A Tcache is performed via a double free. The same chunk is freed twice, so inside the Tcache the chunk will point to itself. Then, it's allocated, its FD pointer is modified to point to the free hook and then it's allocated again so the next chunk in the list is going to be in the free hook. Then, this is also allocated and it's possible to write a the address of system here so when a malloc containing "/bin/sh" is freed we get a shell.
  • This is still a good historical example, but remember that the easy version of this attack does not generalise to glibc 2.32+ / 2.34+ without accounting for safe-linking and hook removal.
• CTF https://guyinatuxedo.github.io/44-more_tcache/csaw19_popping_caps0/index.html[7]
  • The main vuln here is the capacity to free any address in the heap by indicating its offset
  • Tcache indexes attack: It's possible to allocate and free a chunk of a size that when stored inside the tcache chunk (the chunk with the info of the tcache bins) will generate an address with the value 0x100. This is because the tcache stores the amount of chunks on each bin in different bytes, therefore one chunk in one specific index generates the value 0x100.
  • Then, this value looks like there is a chunk of size 0x100, allowing the attacker to free this address.
  • Then, allocating a chunk of size 0x100, the previous address will be returned as a chunk, allowing to overwrite other tcache indexes.
• CTF https://guyinatuxedo.github.io/44-more_tcache/csaw19_popping_caps1/index.html[8]
  • Same vulnerability as before with one extra restriction
  • Tcache indexes attack: Similar attack to the previous one but using less steps by freeing the chunk that contains the tcache info so its address is added to the tcache index of its size. Then, allocating that size returns the tcache metadata chunk itself, which allows poisoning other indexes.
• Math Door. HTB Cyber Apocalypse CTF 2023[9]
  • Write After Free to add a number to the fd pointer.
  • A lot of heap feng-shui is needed in this challenge. The writeup shows how controlling the head of the Tcache free-list is pretty handy.
  • Glibc leak through stdout (FSOP).
  • Tcache poisoning to get an arbitrary write primitive.
• mailman. ImaginaryCTF 2023[10]
  • Modern glibc 2.35 challenge.
  • The exploit chain uses a heap leak to defeat safe-linking, then House of Botcake to create the overlap needed for a modern tcache poisoning.
  • Good example of using tcache poisoning as a step towards FSOP/ROP, not just a hook overwrite.
• catastrophe. DiceCTF 2022[11]
  • Modern glibc 2.35 challenge.
  • Leak a heap pointer by reading a freed tcache entry, encode the poisoned pointer correctly, then use House of Botcake to obtain the arbitrary write needed for the rest of the chain.
• high frequency troubles. picoCTF 2024[12]
  • Modern glibc 2.35 challenge with no direct free() primitive.
  • The exploit first manufactures a free-like primitive from the top chunk (House of Orange / House of Tangerine style) and then pivots into tcache poisoning and a modern post-write target that still works after hook removal.

References

• [1] Check Point Research - Safe-Linking: eliminating a 20-year-old malloc() exploit primitive
• [2] shellphish/how2heap (GitHub)
• [3] libc-alpha mailing list - tcache changes (July 2025)
• [4] corgi.rip - Leakless heap exploitation (part 1)
• [5] guyinatuxedo - dcquals19 babyheap
• [6] guyinatuxedo - plaid19 cpp
• [7] guyinatuxedo - csaw19 popping_caps0
• [8] guyinatuxedo - csaw19 popping_caps1
• [9] Math Door. HTB Cyber Apocalypse CTF 2023
• [10] mailman. ImaginaryCTF 2023
• [11] catastrophe. DiceCTF 2022
• [12] high frequency troubles. picoCTF 2024