Re: [patch 1/8] signal: Prevent exec() race

From: Thomas Gleixner

Date: Sat Sep 05 2026 - 07:25:07 EST


On Sat, Sep 05 2026 at 09:50, Frederic Weisbecker wrote:
> Le Sat, Sep 05, 2026 at 09:34:52AM +0200, Thomas Gleixner a écrit :
>> On Fri, Sep 04 2026 at 13:35, Oleg Nesterov wrote:
>> > Thomas, I can't read this series today, will try on Weekend.
>> >
>> > But you didn't reply to
>> > https://lore.kernel.org/all/apgHJj0qH7HlAXKO@xxxxxxxxxx/
>> > Let me quote that email here:
>> >
>> > OK... lets suppose the exiting task T passes exit_signals().
>> >
>> > Suppose we have an "ignored" timer tmr. Another sub-thread calls
>> > do_sigaction() -> posixtimer_sig_unignore() and finds that tmr
>> > in ->ignored_posix_timers list.
>> >
>> > But posixtimer_queue_sigqueue() doesn't check PF_EXITING, I guess
>> > it should check it too?
>>
>> From the patch:
>>
>> @@ -1990,6 +2004,9 @@ void posixtimer_send_sigqueue(struct k_i
>> if (!likely(lock_task_sighand(t, &flags)))
>> return;
>>
>> + if (unlikely(tmr->it_pid_type == PIDTYPE_PID && (t->flags & PF_EXITING)))
>> + goto unlock;
>> +
>
> But posixtimer_sig_unignore() calls directly posixtimer_queue_sigqueue(), not
> posixtimer_send_sigqueue().

I obviously can't read.

> However posixtimer_queue_sigqueue() -> complete_signal() -> wants_signal()
> checks PF_EXITING and complete_signal() then just drops it.
>
> Ah but doesn't that leak a refcount drop? Looks like the PF_EXITING check should
> indeed move to posixtimer_get_target().

Again. get_target() is not protected by sighand lock when called in
posxtimer_send_sigqueue().

Let me stare at it some more.