From: Ramsay Jones Date: Fri, 06 Mar 2026 18:55:18 GMT Subject: Re: [PATCH 0/4] plugging some mmap() leaks Message-ID: In-Reply-To: On 06/03/2026 6:37 pm, Junio C Hamano wrote: > Ramsay Jones 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