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

From: Ramsay Jones <ramsay@ramsayjones.plus.com>
Date: Mar 6, 2026, 18:55 UTC
Message-ID: <c3e66e36-cba0-49d3-b2a6-d65367f4be0f@ramsayjones.plus.com>
In-Reply-To: <xmqq5x78249v.fsf@gitster.g>

On 06/03/2026 6:37 pm, Junio C Hamano wrote:

Show 14 quoted lines

> Ramsay Jones <ramsay@ramsayjones.plus.com> 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