Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 21 Jan 2021 11:27:34 -0500
From: Rich Felker <dalias@...c.org>
To: "Alex Xu (Hello71)" <alex_y_xu@...oo.ca>
Cc: musl@...ts.openwall.com
Subject: Re: [PATCH] don't set errno in free

On Thu, Jan 21, 2021 at 09:02:40AM -0500, Alex Xu (Hello71) wrote:
> busybox echo fails if free sets errno, which madvise does on old
> kernels.
> ---
>  src/malloc/mallocng/free.c | 14 ++++++++++++--
>  1 file changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git a/src/malloc/mallocng/free.c b/src/malloc/mallocng/free.c
> index 40745f97..82836815 100644
> --- a/src/malloc/mallocng/free.c
> +++ b/src/malloc/mallocng/free.c
> @@ -119,7 +119,13 @@ void free(void *p)
>  	if (((uintptr_t)(start-1) ^ (uintptr_t)end) >= 2*PGSZ && g->last_idx) {
>  		unsigned char *base = start + (-(uintptr_t)start & (PGSZ-1));
>  		size_t len = (end-base) & -PGSZ;
> -		if (len) madvise(base, len, MADV_FREE);
> +		if (len) {
> +			// madvise(..., MADV_FREE) returns -EINVAL on old kernels
> +			// POSIX.1-202x requires free() to not modify errno on success
> +			int e = errno;
> +			madvise(base, len, MADV_FREE);
> +			errno = e;
> +		}
>  	}

glue.h is already responsible for wiring up madvise appropriately
(namespace-safe), so we could just change it to make a raw syscall
instead of the function call to __madvise. This would be slightly less
costly at runtime, but is kinda non-obvious to the reader (especially
if the name is retained) and not as friendly to using mallocng
standalone outside musl.

>  	// atomic free without locking if this is neither first or last slot
> @@ -139,5 +145,9 @@ void free(void *p)
>  	wrlock();
>  	struct mapinfo mi = nontrivial_free(g, idx);
>  	unlock();
> -	if (mi.len) munmap(mi.base, mi.len);
> +	// POSIX.1-202x requires free() to not modify errno on success
> +	// munmap should succeed but no harm checking it again
> +	if (mi.len)
> +		if (munmap(mi.base, mi.len))
> +			a_crash();
>  }
> -- 
> 2.30.0

This is utterly wrong and will crash correct programs. Unmapping
memory can create 2 (temporarily 3) VMAs from one, thereby exceeding
the VMA limit and failing. In this case you have to just accept the
memory leak; you can't kill the valid program because the kernel is
incapable of handling its request in a way that doesn't waste memory.

You also can't do a raw syscall here, because munmap must wait for the
vmlock. So some additional work to save/restore errno is needed, or
else we need to expose a non-errno-using version of __munmap and use
it.

Rich

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.