[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20261103020359.GO23438@brightrain.aerifal.cx>
Date: Mon, 2 Nov 2026 21:03:59 -0500
From: Rich Felker <dalias@...c.org>
To: "Puranam, Ananta Srikar" <srikar.puranam@....edu>
Cc: "musl@...ts.openwall.com" <musl@...ts.openwall.com>,
"West, Emily" <emily.west1@....edu>,
"Priya, Swarn" <swarn.priya@....edu>, "Gao, Peng" <penggao@...edu>,
"Ammanaghatta Shivakumar, Basavesh" <basavesh.shivakumar@....edu>
Subject: Re: ldso: map_library does not validate e_phentsize
On Tue, Nov 03, 2026 at 01:53:13AM +0000, Puranam, Ananta Srikar wrote:
> Hi Rich,
>
> Thanks for explaining. That helps. I talked it over with my advisor Dr. Basavesh,
> and we agree it's your call how much validation the loader should do.
> We don't want to send you reports you consider out of scope, so we'll
> hold back the rest of our malformed-ELF findings: bad header fields,
> dynamic table pointers or sizes that point out of range, and so on.
If you have them, it wouldn't hurt to send. You don't need to spend
time on detailed write-ups if you haven't already, but at least a
quick list would always be useful in case we do want to pursue some
validation at some point (e.g. the ldd thing).
> A few of our findings aren't about corrupted files. They come from
> ordinary inputs:
>
> - A shared library with a __thread variable aligned to more than the
> page size (for example aligned(8192)) gets a TLS block that is
> misaligned by a multiple of the page size. The values are right,
> but the alignment the program asked for is silently lost. glibc
> lays out the same files correctly.
Ah, I guess this requires taking into account the TLS alignment when
mapping the thread stack.
It's *probably* already correct for dynamic TLS added to existing
threads.
> - dlopen of a library built with -ftls-model=initial-exec fails as it
> should, but the "initial-exec TLS resolves to dynamic definition"
> error formats a name that is never set for relocations with no
> symbol. On 1.2.5 this crashes inside dlopen. On master the message
> shows an empty or unrelated symbol name. golang/go#54805 looks like
> the same thing.
Thanks, this should be an easy fix and indeed this is something that
can easily happen in files that aren't outright "malformed" just built
with incorrect CFLAGS/LDFLAGS for the intended use.
> - When ldso is invoked directly (/lib/ld-musl-*.so.1 ./prog), the
> program starts with sp % 16 == 8. musl's own crt1 re-aligns the
> stack, so C programs are fine. An entry point that uses the stack
> before re-aligning takes an alignment fault on aarch64.
This is expected; I seem to recall someone bringing this up once
before. I don't think there's any way to avoid it without doing a
memmove of the entire argv/environ/auxv array to move everything down
one slot. If there's a reason that's needed it could be done, but as
you've noted our entry point does not assume alignment.
> Would reports like these be welcome? If so, I'll send them together
> in one email rather than as separate threads. If not, let us know and
> we'll leave it there.
Sure. One thread is probably best.
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.
