[Bug malloc/23733] New: Check the count before calling tcache_get()

["amaris at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=23733

            Bug ID: 23733
           Summary: Check the count before calling tcache_get()
           Product: glibc
           Version: 2.27
            Status: NEW
          Severity: minor
          Priority: P2
         Component: malloc
          Assignee: unassigned at sourceware dot org
          Reporter: amaris at redhat dot com
  Target Milestone: ---

Created attachment 11287
  --> https://sourceware.org/bugzilla/attachment.cgi?id=11287&action=edit
tcache overflow

When calling tcache_get() in __libc_malloc(), it is checked (among other
things) that tcache->entries[tc_idx] isn't equal NULL which indicates the
corresponding tcache bin should be empty. However, when the last chunk in
tcache bin gets corrupted (e.g. by use after free or heap buffer overflow) and
pointer to next chunk which is NULL would be overwritten, malloc() will
continue to serve chunks from that tcache bin even if it's empty and
tcache->count[tc_idx] will overflow.

It would be better to check if tcache->count[tc_idx] > 0, either instead or
additionally (even better), which isn't as vulnerable to corruption as metadata
stored in chunks.

The problematic code is at
https://sourceware.org/git/?p=glibc.git;a=blob;f=malloc/malloc.c;h=67cdfd0ad2f003964cd0f7dfe3bcd85ca98528a7;hb=HEAD#l3034

Currently, tcache_get() is called also on two other places, but they should be
fine since they get called only if we put some chunk into corresponding tcache
bin first.

I'm attaching the PoC for demonstration. It was tested on Fedora 28 x86_64 with
glibc 2.27 (but this issue is in most recent glibc code as well if I'm reading
the source code right):

$ ./tcache_overflow
Address of p = 0x13e6260
Address of q = 0x13e6290
p and q were freed
p was corrupted, pointing to q
Addresses of further allocated chunks:
1. chunk: 0x13e6290
2. chunk: 0x13e6260
3. chunk: 0x13e6290
4. chunk: 0x13e6260
5. chunk: 0x13e6290
6. chunk: 0x13e6260

-- 
You are receiving this mail because:
You are on the CC list for the bug.