Re: execlineb ELF executable stack on Linux

From: Xavier Stonestreet <>
Date: Fri, 9 Apr 2021 02:56:59 +0200

On Thu, Apr 8, 2021 at 9:57 PM Laurent Bercot <> wrote:
> My toolchain also creates E stack binaries by default, no matter
> whether they're static or dynamic. It may be that my build of musl is
> bad.

That's unexpected.

> I am not interested enough in the details of what happens at the ld
> level to try and figure out if there's *something* that causes it to
> mark E stack when it should not; it requires spending much more
> quality time with binutils than I am comfortable with. All I know is
> that none of the object files in my software needs E stack, and
> bullying ld into doing the right thing works, so I'm content with that
> solution.

Fair enough. That's totally fine for self-contained packages in which
you control the build parameters from end-to-end. This may become an
issue with skarnet libraries, such as utmps, that are used with other,
non-skarnet packages. Libutmps pulls in libskarnet and libskarnet
'pollutes' the other packages by making their stack executable.

I'm currently going through the process of linking some packages (e.g.
coreutils, util-linux, and the like) with libutmps, and now the
executables that call libutmps have their stack executable. I can deal
with it on my own by tweaking the LDFLAGS (-noexecstack) of those
packages, it's not too much of an issue for me.

But let's take Alpine Linux for example. I see that they now link
coreutils, and probably other packages I didn't check, with libutmps
and libskarnet. I don't know if they're affected by the same GNU_STACK
weirdness in skalibs, or if they scan their distribution binaries for
executable stacks, but they may be shipping a bunch of
innocuous-looking binaries that have an executable stack and may be
vulnerable as a result.

So IMHO it may be worthwhile spending some time at some point to
figure out what's going on and eventually make it not happen anymore.
Just my 2 cents.
Received on Fri Apr 09 2021 - 00:56:59 UTC

This archive was generated by hypermail 2.3.0 : Sun May 09 2021 - 19:38:49 UTC