This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Fix integer overflow in malloc when tcache is enabled [BZ #22375]
- From: DJ Delorie <dj at redhat dot com>
- To: Arjun Shankar <arjun dot is at lostca dot se>
- Cc: libc-alpha at sourceware dot org
- Date: Mon, 06 Nov 2017 12:51:56 -0500
- Subject: Re: [PATCH] Fix integer overflow in malloc when tcache is enabled [BZ #22375]
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx05.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx05.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=dj at redhat dot com
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 2368413AAC
Arjun Shankar <arjun.is@lostca.se> writes:
> When the per-thread cache is enabled, __libc_malloc uses request2size (which
> does not perform an overflow check) to calculate the chunk size from the
> requested allocation size. This leads to an integer overflow causing malloc
> to incorrectly return the last successfully allocated block when called with
> a very large size argument (close to SIZE_MAX) instead of returning NULL and
> setting errno to ENOMEM.
> [BZ #22375]
> * malloc/malloc.c (__libc_malloc): Use checked_request2size instead
> of request2size.
> * malloc/tst-malloc-too-large.c: New test.
> * malloc/Makefile: Add tst-malloc-too-large.
> + for (lsbs = FIFTY_ON_BITS; lsbs > FIFTY_ON_BITS - (1UL << 14); lsbs--)
> + for (msbs = FOURTEEN_ON_BITS; msbs >= 1; msbs--)
Is it intentional that you're doing 32,768 allocations when this runs?
While this shouldn't take time on modern 64-bit hardware, I wonder if
this level of overkill is justified (not that I'm ever against overkill
*in general* but these tests get run a lot)
The patch is otherwise OK.