TCache relative write

[D4R30]

I've come up with a tcache-based technique, and I did not find any House of ... or CTF that can achieve both of its objectives. Basically, it takes advantage of an out-of-bounds tcache metadata writing (both the pointer and counter) to achieve the following objectives:

• To write an arbitrary decimal value to an arbitrary location on heap, relative to the tcache_perthread_struct, which is allocated on heap. The most powerful use case would be a chunk overlapping attack.
• To write a freeing chunk's pointer to an arbitrary location on heap, again relative to tcache_perthread_struct. A powerful use case would be chunk edits (tcache poisoning, fastbin corruption, etc.)

And with these prerequisites:

• The ability to write a large value (anything higher than 64) on an arbitrary location
• Libc leak
• Being able to malloc/free with sizes higher than TCache maximum chunk size (0x408)

In the PoC, I demonstrated these two primitives to trigger a chunk overlapping, and a simple arbitrary pointer write.

I've thoroughly explained the technique in this blog post: https://d4r30.github.io/heap-exploit/2025/11/25/tcache-relative-write.html
Here's the summary:

The core concept of TCache relative writing is around the fact that when the allocator is recording a tcache chunk in tcache_perthread_struct, TCache mechanism does not enforce enough check and restraint on the computed tcachebin indice (tc_idx), thus WHERE the tcachebin count and head pointer can be written are not restricted by the allocator by any means. The allocator treats extended bin indices as valid in both tcache_put and tcache_get scenarios. If we’re somehow able to write a huge value on one of the fields of mp_ (tcache_bins from malloc_par), by requesting a chunk size higher than TCache range, we can control the place that a tcachebin pointer and counter is going to be written. Considering the fact that a tcache_perthread_struct is normally placed on heap, one can perform a TCache relative write on an arbitrary point located after the tcache metadata chunk (Even on tcache->entries list to poison tcache metadata). By writing the new freed tcache chunk’s pointer, we can combine this technique with other techniques like tcache poisoning or fastbin corruption and to trigger a heap leak. By writing the new counter, we can poison tcache->entries, and write arbitrary value into an arbitrary location of heap, with the right amount of mallocs and frees. With all these combined, one is able to create impactful chains of exploits, using this technique as their foundation.

This technique works on 2.30 and higher versions. The latest version tested is 2.41.

There's also another blog post that mainly discusses mp_ hijack, but does not discuss the arbitrary counter-writing capability. It is more beginner-friendly though, as it provides a more complete discussion of tcache basics: https://4xura.com/binex/pwn-mp_-exploiting-malloc_par-to-gain-tcache-bin-control/

One issue
As it is obvious in tcache_relative_write.c, when the PoC wants to compute &mp_.tcache_bins, a constant is used to compute the distance between unsortedbin and the tcache_bins field. This was the best possible option I had in my mind, because neither mp_ nor main_arena are exported. The difference between &main_arena and &mp_ are also different among glibc versions. If you had any idea on how to remove the constant and make the PoC more portable, please let me know. I've manually calculated and tested all the relative constants for 2.31-2.41, so I expect it will pass all the checks.

[Kyle-Kyle]

This is my understanding of this technique:

1. requires the ability to overwrite mp_.tcache_bins (so need to know its address)
2. then tcache will be tricked into thinking its metadata (tcache_perthread_struct) is larger than it actually is and read/write out of bound.
3. profit

If my understanding is correct, then this is very similar to a technique that was quite popular ~2019. Back then, it was overwriting the fastbin's limit (also in mp_) using the unsortedbin attack (provides the write-x-where primitive) and then allocating pointers out of bound.

I think we should include this.

Also, I have a question/suggestions:

• You mention that we need "The ability to write a large value (>64) on an arbitrary location". I haven't checked the source code, but I wonder what happens if we do an unaligned write? Do we still need to write a large value? (e.g., if we write 1 to &mp_.tcache_bins+1)
• I think you didn't explain the objective "To write an arbitrary value into an arbitrary location on heap" well. I have two interpretations of it: 1. free a pointer (A) that is large enough so that you can place it in a location you specify on the heap, the result is the value A is on the heap 2. free a pointer A, UAF overwrite its fwd pointer to B (actually arbitrary value), do allocation again, then B will be on heap. Which one do you mean here? And please clearly explain it in the files.
• please don't say arbitrary location on heap when you actually mean "outside the boundary of tcache_perthread_struct". (Let's say I want to write to heapbase+0x1000000, it'd be hard to allocate that huge amount to place the pointer there.
• It'd be great if you can explain that it is possible to obtain the write-x-where primitive using other techniques (e.g., large_bin_attack etc)

[D4R30]

Thanks for the comment.

So first of all, I think you've missed the most important objective of the attack. This technique is not just about writing a pointer out-of-bounds; it is also about the ability to write the counter out-of-bounds. I've demonstrated a chunk overlapping attack using this capability, in the how2heap PoCs and the blog post.

it was overwriting the fastbin's limit (also in mp_) using the unsortedbin attack (provides the write-x-where primitive) and then allocating pointers out of bound.

You should also note that global_max_fast is not a member of mp_. It is actually a separate global variable.

About the similarity to the fastbins relative write (which is used in the popular technique House of Husk), you're absolutely right. This technique is similar to the fastbins attack because it overwrites bins limit to achieve out-of-bounds write. But here are the facts that I believe make this technique unique and different from the already mentioned:

• It is not just about a pointer write. tcache_perthread_struct also stores the counter variable, which is used by TCache relative write to write a decimal value out-of-bounds. This was not present in the classic fastbins relative write. It also cannot be easily derived from the fastbins technique in my opinion. So the out-of-bounds counter-writing is the most important capability in this technique.

• It is differently implemented, has different use cases and is stronger, because it is particularly used to overwrite metadata/data on heap. The House of Husk technique was restricted to the structures present after the fastbins array, and a printf call was required to actually trigger the exploit chain. TCache relative write is more fundamental and opens the doors to wide range of exploit chains, because you now have the ability to manipulate chunks metadata.

I didn't find the global_max_fast technique on this repository. Maybe we could add it to this PR and change the title to Relative write techniques, or we can just do it in the next PR.

For your questions/suggestions:

• No it doesn't necessarily have to be an aligned write. For example, If you can write a half-word, lets say, on the second most significant half-word, yes it still works. The goal is just to make mp_.tcache_bins a large value. So it doesn't necessarily have to an aligned write.

• By the "To write an arbitrary value into an arbitrary location on heap" I mean the out-of-bounds counter (decimal value) writing. There are actually two objectives: Out-of-bounds decimal writing and out-of-bounds pointer writing. Your first interpretation is true for the second one: Freeing chunk A that has the A->size large enough, so that A is written to the selected location. But for the out-of-bounds decimal writing: Freeing chunk A that has the A->size large enough, so that the counter is updated out-of-bounds. I've written all the calculations required to actually know what size you have to allocate and free to write the counter or the pointer to the target location.

• Yes it does make the request size huge, but it still is possible to make that chunk size with some heap grooming. So in theory and many practical cases it is still possible. Would you prefer that I revise this part, or should I add more explanation to make it clearer?

• I've pointed out many techniques - such as the largebin attack - that can be used to achieve a write-x-where primitive in the * VULNERABILITY * part.

[D4R30]

Sorry, I’m not sure whether you’re waiting for me to make changes. Based on my previous comment, please let me know if there’s anything you want me to update in the files.
@Kyle-Kyle

[Kyle-Kyle]

Hi,

Sorry for the late response. I was (still am) quite busy recently and forgot about this issue.
First of all, I'd like to clarify that I'd like to add this technique to this repo. I mentioned global_max_fast because this technique reminds me of that (and yes, I thought it was a member of mp_ but you are right, it is a global).

• I think it is quite clear that we both agree that one of the two primitives you can gain from this technique is writing a pointer out of bound. No need to discuss that part. But I'm still confused about the "write a decimal value out-of-bounds" part. I understand that the number of freed tcache chunks will be in tcache->counts[tc_idx], now that tc_idx can get out-of-bound, you can control where to write and potentially what to write (if you free enough chunks). But by default, the max you can write is 7, right? Unless we assume another primitive that we can overwrite mp_.tcache_count, this is not an arbitrary write, this is . Something doesn't add up here. What am I missing?

Yes it does make the request size huge, but it still is possible to make that chunk size with some heap grooming.

I don't think it is feasible in practice. When the allocation size is large enough, the allocator will use mmap instead, unless we assume we can overwrite mp_.mmap_threshold. By default, mp_.mmap_threshold is 0x20000, which means the max tc_idx you can get is ~0x2000, so the maximum out-of-bound write offset will be ~0x10000. So, I still think arbitrary location on heap is not a precise description for this.

I've pointed out many techniques - such as the largebin attack - that can be used to achieve a write-x-where primitive in the * VULNERABILITY * part.

you are right. I missed that part.

[D4R30]

Thanks for your time. I appreciate it.

You're right about the limited range of "out-of-bounds counter-writing", and it should be in fact called a semi-arbitrary writing, unless we can also make mp_.tcache_count a large value. The reason I generally called it an "arbitrary decimal value writing" primitive is because if one is able to trigger the write-x-where primitive for a second time (or just by the first time, if he can write to a larger range inside mp_), he can also make mp_.tcache_count large and actually achieve a fully arbitrary write. I did not cover an example for this one in the files (to avoid making them bloated), but I've provided an example here for a combination with tcache metadata poisoning.

To distinguish the "semi-arbitrary" and "fully arbitrary" cases, I changed the description for that primitive in the last commit. I hope it is more clear and precise now.

I don't think it is feasible in practice. When the allocation size is large enough, the allocator will use mmap instead, unless we assume we can overwrite mp_.mmap_threshold. By default, mp_.mmap_threshold is 0x20000, which means the max tc_idx you can get is ~0x2000, so the maximum out-of-bound write offset will be ~0x10000. So, I still think arbitrary location on heap is not a precise description for this.

Assume we have several contiguous freed chunks that, when consolidated, form a single unsorted/largebin chunk whose size is higher than mp_.mmap_threshold. Now if we malloc a chunk with that size (which is higher than mp_.mmap_threshold), the allocator first tries to satisfy the request by reallocating the binned chunk, rather than mmaping in the first place. Then we can free this large chunk, and trigger "tcache relative write". Here's an example:

int main(void)
{
        char *p1 = malloc(0x20000 - 0x10); // DEFAULT_MMAP_THRESHOLD_MIN - 0x10
        char *p2 = malloc(0x500);
        malloc(0x10);   // Avoid top consolidation

        free(p1);
        free(p2);

        char *p3 = malloc(0x20500); // Not mmap'd !
        assert(p3 == p1);

        free(p3); // Triggers tcache relative write (Assuming mp_.tcache_bins is a large value)

        return 0;
}

With some heap grooming, I believe this is totally possible to achieve in practice, thus I'd say the technique itself still gives us the arbitrary location capability, but to actually be a fully arbitrary location, it depends on the use case.