[PATCH] malloc: check tcache mem size in tcache_get_n to avoid arbitrary mem allocation

[Wilco Dijkstra]

Hi,

>> Thanks, having a test is always useful. This basically overwrites the freelist
>> with a correctly swizzled pointer to a fake block. Once an attacker can do that,
>> they can just as easily fake a correct chunk header and pass the extra check...
>
> Though attackers could fake a correct chunk header to bypass the check,
> it's harder for them to arb alloc address out of heap to hijack pc.
> At least an arb alloc on heap wouldn't cause too much threat.
> Considering the extra checking cost, that is the best we can do for now.

What do you mean with "arb alloc"? Never heard of the term...

>> Note that it should trigger a check in free() since the size is corrupted.
>> If it is feasible for an attacker to break the swizzling, it would be best to improve
>> that in some way.
>
> The corruption of freelist happens after free, you can also see that in my
> test, so check in free won't work.

If the malloc succeeds despite corruption, it will likely fail if that block is freed
again, or on the next malloc that uses the now corrupted freelist. Adding free(ptr[0])
at the end of your test causes "double free or corruption".

> And if you want to run `./build/glibc/benchtests/bench-malloc-thread
> 1`directly, you should make it static linked, otherwise, the program
> will use malloc from your system libaray.

You can statically link with GLIBC, but that's not needed here - "make bench" will generate
benchmarks which will always dynamically link with your local GLIBC build. 

> On my machine, this patch is about 4% slower for thread1 and thread32, and seems even
> faster for simple 16(maybe because I remove the fastbin checks in _int_malloc)?

There is a 3.8% difference between those runs. Which one is old, which one is new? 

> My cpu is 20 × 13th Gen Intel Core i7-13700H, which is x86_64 arch.
> I saw your commit said that you use Neoverse V2, could that be the
> difference?

Note those results seem slow given the i7-13700H is quite new. Are you running on
the fast cores? Does the generated code look well optimized?

The results will depend on the CPU you're testing, but the general trend should be
similar. My old x64 box shows a 14-16% slowdown on bench-malloc-thread 1 / 32,
and bench-malloc-simple 15 is ~0.4% slower.

Cheers,
Wilco