This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] malloc: Always call memcpy in _int_realloc [BZ #24027]
- From: Niklas Hambüchen <mail at nh2 dot me>
- To: Florian Weimer <fw at deneb dot enyo dot de>, libc-alpha at sourceware dot org
- Date: Tue, 25 Dec 2018 21:55:40 +0100
- Subject: Re: [PATCH] malloc: Always call memcpy in _int_realloc [BZ #24027]
- References: <87sgyluz8t.fsf@mid.deneb.enyo.de>
Would it not make sense to first apply the patch I provided in
https://sourceware.org/bugzilla/show_bug.cgi?id=24027
that fixes the type, and then do the removal of the memcpy special case as a refactoring?
That would ensure that if somebody disagrees with the performance-critical bit in the future and reverts this, they don't revert back to the bugged version.
It would also make it possible for downstream distributions to cherry-pick a minimal patch from upstream.
Niklas
On 2018-12-25 21:29, Florian Weimer wrote:
> This patch removes the custom memcpy implementation from _int_realloc
> for small chunk sizes. ncopies has the wrong type and could thus
> result in too few elements being copied, so removing this code fixes
> bug 24027. I don't think the inlining is performance-critical because
> this code is used when the realloc results in an _int_malloc, copy,
> and _int_free, so even for small allocations there is quote some
> overhead beyond the copy itself.
>
> I'm not sure if this warrants tracking as a security bug. Looking at
> the code, the problem could be trigger in a default configuration if
> mremap fails and a subsequent mmap succeeds.