Subject: Re: [PATCH 0/4] plugging some mmap() leaks

From: Ramsay Jones <[email-masked]>
Date: Fri, 6 Mar 2026 18:55:18 +0000

On 06/03/2026 6:37 pm, Junio C Hamano wrote:
> Ramsay Jones <[email-masked]> writes:
> 
>> When compiling with the NO_MMAP build variable set, the built-in
>> 'git_mmap()' and 'git_munmap()' compatability routines use simple
>> memory allocation and file I/O to emulate the required behaviour.
>> The current implementation is vunerable to the "double-delete" bug
>> (where the pointer returned by malloc() is passed to free() two or
>> more times), should the mapped memory block address be passed to
>> munmap() multiple times.
> 
> Sorry if I am missing something glaringly obvious, but quite
> honestly I am confused.  Wouldn't it be a bug to call munmap() again
> on the same region of memory obtained from mmap() and then already
> unmapped by calling munmap()?

Yes. The (second) call to munmap() with the (already unmapped) memory
region would return -1 with errno set to EINVAL.

The emulation layer does not detect this situation and simply calls
free() on the given pointer. Hence the 'double-delete' bug.

> Or can the emulation layer cause such a second free() even if the
> munmap() is done once and only once per memory region obtained from
> a single mmap()?

No. If you only git_munmap() once for a given memory region, everything
is fine.

Thanks.

ATB,
Ramsay Jones