[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LNX.2.20.13.1701091347350.5146@monopod.intra.ispras.ru>
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.
