Mateusz Guzik <mjguzik@gmail.com> wrote:

> On Sun, Mar 2, 2025 at 10:31 PM Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> > Well, you're right that there is a potential race between threads
> > here.  Although that can only happen if you write your own version of
> > ld.so that creates threads before pinning down the syscalls using
> > pinsyscalls(2).
> >
> [snip]
> > But at the same time, this is a solution for a problem that doesn't
> > really exist in reality.  If someone really writes an ld.so
> > replacement that starts threads beforing calling pinsyscalls(2) they
> > deserve what they get.
> >
> 
> I'm not claiming legitimate userspace will do this.
> 
> I am claiming the stock code has a race here which has to be evaluated
> (for example if it can be used to panic the kernel).

How?  Please explain how.

Look in syscall_mi.h

        if (plibcpin->pn_pins &&
            addr >= plibcpin->pn_start && addr < plibcpin->pn_end)
                pin = plibcpin;

These 3 variables in pr->ps_libcpin start as 0 and NULL and NULL.

At some point they are made non-0, non-NULL, and non-NULL.

All 3 of them have to become set, of no libc pin has been found.  There
is no such thing as a 0 length pin table, and a >0 length pintable needs
to have a start and end.  If that isn't true, no pin has been found.

It no pin is found, the process is killed with an uncatchable SIGABRT.

Where do you see the panic?  Show your work.

> I implied this is something which will have to be looked at every time
> there are any changes to pinsyscalls.
> 
> Finally I claim this is a potential attack vector which does not need
> to be there.

What is the attack vector?  Please explain it.