[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <00bf063d-1047-41cd-9a74-7785f5f37eaa@codasip.com>
Date: Fri, 24 Apr 2026 18:13:15 +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 24/04/2026 16.30, Rich Felker wrote:
> 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?
sure, wfm.
- 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.
