Re: [PATCH] signal/x86: Don't send SIGSEGV twice on SEGV_PKUERR

[Borislav Petkov]

On Thu, Jun 03, 2021 at 04:31:46PM -0500, Eric W. Biederman wrote:
> There are two ways signals get delivered.  The old fashioned way in the
> signal bitmap, and the new fangled way by queuing sigqueue_info.

By that you mean that third arg siginfo_t to

SYSCALL_DEFINE3(rt_sigqueueinfo, pid_t, pid, int, sig,
                siginfo_t __user *, uinfo)

I presume?

Which, as sigqueue(3) says, is what is called on Linux.

> In the old fashioned way there is no information except that the
> signal itself was delivered, and if the signal is sent twice it
> is impossible to find out. In the new fangled way because the
> sigqueue_info can vary between different times a signal is sent you
> can both see that a signal was delivered twice (because there are two
> distinct entries in the queue), but also possibly tell those two times
> a signal was sent apart.
>
> The new real time signals can queue as many sigqueue_info's as their
> rlimit allows.  The old signals are limited to exactly one sigqueue_info
> per signal number.

Aha.

> In this case the legacy_queue check tests to see if the signal is
> already pending (present in the signal bitmap) and not a new real time
> signal (which means only one sigqueue_info entry is allowed in the
> signal queue).

Aha, that sigismember() call in legacy_queue().

> Or in short I think everything turns out ok because the first signal is
> delivered, and the second just happens to get dropped as a duplicate by
> __send_signal.

Right, it is a SIGSEGV in both cases. So it is a legacy signal, and
that'll get marked in that sigset->sig array. Which is per task... ok.

> That is fragile and confusing to depend on so we should just fix the
> code to not send the wrong signal.

Yap.

> I hope that clears things up.

Very much so, thanks for taking the time!

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette