Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260424143002.GQ1827@brightrain.aerifal.cx>
Date: Fri, 24 Apr 2026 10:30:04 -0400
From: Rich Felker <dalias@...c.org>
To: Florian Schmaus <florian.schmaus@...asip.com>
Cc: musl@...ts.openwall.com
Subject: Re: [PATCH] dynlink: set errno in case mprotect() fails

On Fri, Apr 24, 2026 at 03:52:14PM +0200, Florian Schmaus wrote:
> On 21/04/2026 15.13, Rich Felker wrote:
> > On Tue, Apr 21, 2026 at 08:34:11AM -0400, Rich Felker wrote:
> > > On Tue, Apr 21, 2026 at 09:57:27AM +0200, Florian Schmaus wrote:
> > > > The format string of the error message uses %m to print the value of
> > > > errno in human-readable form. But the low-level __syscall() macro,
> > > > used to invoke mprotect(), will not implicitly set errno. Fix this by
> > > > setting errno explicitly before emitting the error message.
> > > > ---
> > > >   ldso/dynlink.c | 1 +
> > > >   1 file changed, 1 insertion(+)
> > > > 
> > > > diff --git a/ldso/dynlink.c b/ldso/dynlink.c
> > > > index 715948f4f8b3..db0f9f52461c 100644
> > > > --- a/ldso/dynlink.c
> > > > +++ b/ldso/dynlink.c
> > > > @@ -1424,6 +1424,7 @@ static void reloc_all(struct dso *p)
> > > >   			long ret = __syscall(SYS_mprotect, laddr(p, p->relro_start),
> > > >   				p->relro_end-p->relro_start, PROT_READ);
> > > >   			if (ret != 0 && ret != -ENOSYS) {
> > > > +				errno = -ret;
> > > >   				error("Error relocating %s: RELRO protection failed: %m",
> > > >   					p->name);
> > > >   				if (runtime) longjmp(*rtld_fail, 1);
> > > > -- 
> > > > 2.53.0
> > > 
> > > I think this requires further analysis. See commit
> > > 63c67053a3e42e9dff788de432f82ff07d4d772a. Avoiding accessing errno was
> > > intentional here, and the access buried in the error path is probably
> > > a bug. But we need to look back at the constraints to determine how to
> > > fix it right.
> > 
> > At the early stage where there is no errno, error points to error_noop
> > so there is no problem except for lack of message. This is only for
> > libc itself and probably only happens if it was mislinked or if
> > there's bad seccomp policy.
> > 
> > However the case you're looking at is for other libraries after stage
> > 2 has finished, and indeed there the message lacks a meaningful errno.
> > 
> > We could probably move the assignment into errno into the error()
> > function, by passing an error code to replace errno as the first
> > argument before the format string.
> 
> I assume inventing a new format specifier is not an option? Something like
> 
> error("Error relocating %s: RELRO protection failed: %M",
>        p->name, -ret);
> 
> Alternatively, just emitting the numeric value would be an improvement over
> what we currently have.
> 
> I can draft a patch for this, but I'd appreciate some guidance on the
> preferred approach first.

Does the attached work for you?

Rich

View attachment "early_errno.diff" of type "text/plain" (1327 bytes)

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.