Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 9 Jan 2017 13:53:50 +0300 (MSK)
From: Alexander Monakov <amonakov@...ras.ru>
To: musl@...ts.openwall.com
Subject: Re: [PATCH] malloc: always fail with ENOMEM

On Mon, 9 Jan 2017, Julien Ramseier wrote:

> malloc may set errno to something else than ENOMEM indirectly
> through mmap, though ENOMEM is the only error allowed by POSIX.

Pedantically speaking, no: POSIX explicitly allows implementations
to report errors other than specified, in case errors are allowed;
from 2.3 "Error Numbers":

    Implementations [...] may generate additional errors unless
    explicitly disallowed for a particular function.

But this is just FYI, of course reporting EPERM from malloc is not useful
(and Rich indicated that he'd like to avoid that).

> 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.
> 
> [1] http://www.openwall.com/lists/musl/2016/03/30/9
> [2] https://ghc.haskell.org/trac/ghc/ticket/7500
> [3] https://github.com/torvalds/linux/blob/master/security/min_addr.c

Thanks for digging out the cause.  I think you should wait for feedback
from Rich on the patch.

Alexander

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.