[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2850267c-935d-4782-9b44-c83fadad28d8@codasip.com>
Date: Fri, 24 Apr 2026 15:52:14 +0200
From: Florian Schmaus <florian.schmaus@...asip.com>
To: Rich Felker <dalias@...c.org>
Cc: musl@...ts.openwall.com
Subject: Re: [PATCH] dynlink: set errno in case mprotect() fails
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.
- Florian
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.
