Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20170112041020.GA1533@brightrain.aerifal.cx>
Date: Wed, 11 Jan 2017 23:10:20 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: [PATCH] malloc: always fail with ENOMEM

On Mon, Jan 09, 2017 at 12:13:52PM +0100, Szabolcs Nagy wrote:
> * Julien Ramseier <j.ramseier@...il.com> [2017-01-09 09:47:35 +0100]:
> > malloc may set errno to something else than ENOMEM indirectly
> > through mmap, though ENOMEM is the only error allowed by POSIX.
> > 
> > There are cases where mmap will return EPERM instead of ENOMEM,
> > as highlighted by libc-test[1]. This can happen when mmap tries to
> > map pages near `mmap_min_addr` [2][3], as a security measure.
> 
> i've seen this too and i think this should be fixed in mmap
> (i.e. never return EPERM for anonymous mmap(0,...), since
> posix specifies ENOMEM for that failure)

Yes, both places in the patch call __mmap, so it could just be fixed
in __mmap. Rather than return syscall(...) we should probably have
something like"

	long ret = __syscall(...);
	if (ret == -EPERM && ...) ret = -ENOMEM;
	return (void *)__syscall_ret(ret);

where the ... checks for something like MAP_ANON and not MAP_FIXED or
similar. Does that look correct?

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.