Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 5 Mar 2021 11:12:56 -0500
From: Rich Felker <>
To: Michael Forney <>
Subject: Re: ld-musl-* and empty .eh_frame

On Fri, Mar 05, 2021 at 10:07:32AM -0500, Rich Felker wrote:
> On Thu, Mar 04, 2021 at 07:18:11PM -0800, Michael Forney wrote:
> > Hi,
> > 
> > √Črico noticed that cproc (my C compiler) produced executables that
> > musl's dynamic linker fails to load when passed as an argument:
> > 
> >   /lib/ ./t: Not a valid dynamic program
> > 
> > However, running ./t directly works fine. It turns out that this
> > is because the executables have an empty .eh_frame section, which
> > causes musl to attempt an mmap with length 0 which fails with EINVAL.
> The section itself isn't the problem; rather the linker making a
> dedicated PROT_READ segment with no non-zero-length sections in it is.
> It really should have collapsed that out. (Also it would not happen
> without the separate-text option, which mcm disables because it makes
> lots of problems.)
> With that said, there's no good reason we should error out on this;
> it's syntactically and semantically valid just pointless for the
> linker to emit. I think adding if (!n) return p; at the top of
> mmap_fixed in dynlink.c fixes it.

In practice this probably does, but there's also something of a
question what to do if the zero-size segment is not page aligned. This
is not actually a mmap error since it will be automatically expanded
out to page boundaries in both directions, but if ld is capable of
emitting such segments they may be semantically wrong (mapping over
top of something else they're not intended to). Can you confirm that
ld isn't doing anything awful here?


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.