segmentation fault with glibc-2.34

Adhemerval Zanella adhemerval.zanella@linaro.org
Fri Dec 3 15:15:39 GMT 2021



On 03/12/2021 12:02, Florian Weimer wrote:
> * Adhemerval Zanella via Libc-help:
> 
>> On Fri, Dec 3, 2021 at 10:38 AM Andreas Fink via Libc-help
>> <libc-help@sourceware.org> wrote:
>>>
>>> Hello,
>>> I have observed a crash in firefox with glibc-2.34 and have found a
>>> small reproducer.
>>> Is the sigsys signal handler valid? If yes, then there is a bug in
>>> glibc-2.34.
>>> If it is invalid to set the result in the context, I think the firefox
>>> sandbox is doing dodgy things.
>>>
>>> gcc test.c -lseccomp
>>> strace ./a.out
>>
>> The seccomp filter *explicitly* blocks newfstatat, which might be used
>> by getpwuid.
> 
> It's used by the chroot detection.  NSS assumes that a chroot has
> happened and disables module loading.  This produces internal null
> pointers despite returning success from the lookup, and the callers do
> not handle that.  I'm not sure how the previous code handled that.
> 

Indeed this is what is happening on nss_database_check_reload_and_get.

> We should probably return EPERM due to that failing stat call and
> propagate the failure to the caller.  Returning ENOENT/a successful
> lookup that produces no data seems wrong.

Agreed.


More information about the Libc-help mailing list