[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20261103012939.GN23438@brightrain.aerifal.cx>
Date: Mon, 2 Nov 2026 20:29:40 -0500
From: Rich Felker <dalias@...c.org>
To: "Puranam, Ananta Srikar" <a.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 Mon, Nov 02, 2026 at 11:48:32PM +0000, Puranam, Ananta Srikar wrote:
> Hi,
>
> I'm Ananta Srikar Puranam, a PhD student at Washington State
> University. I'm reporting this bug on behalf of my team: Emily West,
> Dr. Swarn Priya, Dr. Peng Gao and Dr. Basavesh Ammanaghatta
> Shivakumar.
>
> map_library in ldso/dynlink.c never checks e_phentsize against
> sizeof(Phdr). It sizes the header read with e_phentsize * e_phnum
> (line 711 at 7813e911) and steps through the table by e_phentsize
> (line 727, also 764 and 825), but reads every entry as a full Phdr.
>
> With e_phentsize set to 28 on x86_64, musl reads e_phnum records 28
> bytes apart: only the first half of the real table, interleaved with
> bogus records that start in the middle of real ones. If PT_TLS is in
> the unread half, dlopen succeeds without TLS, dlsym of a TLS symbol
> returns NULL without setting dlerror, and the library crashes when
> it touches its own TLS. If PT_LOAD or PT_DYNAMIC is in the unread
> half, dlopen fails with "Exec format error".
>
> glibc rejects the same file with "ELF file's phentsize not the
> expected size". Rejecting it with ENOEXEC when e_phentsize !=
> sizeof(Phdr) seems like the expected behavior here.
There is an unbounded surface of things that could be validated when
loading programs/libraries, but no clear benefit from doing so.
Whatever is being loaded is necessarily something you're trusting; its
ctors execute in the same privilege domain as the program. Thus, we
have generally not opted to do validation except in cases where the
tooling could produce something that might appear to work but have
subtle/silent breakage.
If there is going to be any further validation, it should be based on
a goal with a purpose -- for example, if we wanted to guarantee safety
of running ldd on untrusted files. This is tractable, but would be a
big project, and I don't really feel comfortable making such a promise
of safety, so I'd probably rather not create the illusion of it.
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.
