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

[Thomas Gleixner <tglx@kernel.org>]

On Sun, Sep 06 2026 at 17:39, Eric W. Biederman wrote:
> Thomas Gleixner <tglx@kernel.org> writes:
>> @@ -1019,6 +1029,21 @@ static inline bool legacy_queue(struct s
>>  	return (sig < SIGRTMIN) && sigismember(&signals->signal, sig);
>>  }
>>  
>> +/*
>> + * When PF_EXITING is set the task is on the way out and has t::pending
>> + * flushed already. Prevent queueing of PIDTYPE_PID signals as they would
>> + * be leaked.
>> + */
>> +static inline bool task_can_queue_signal(struct task_struct *t, enum pid_type type)
>> +{
>> +	lockdep_assert_held(&t->sighand->siglock);
>> +
>> +	if (!(t->flags & PF_EXITING))
>> +		return true;
>> +
>
> I don't know if we care but I just noticed that this disallows
> using tkill(..., SIGKILL) or tgkill(..., SIGKILL) to stop coredumps.

The thread running the coredump does not have PF_EXITING set:

get_signal()
        ....
        vfs_coredump()
        ...
        do_group_exit()

The only interaction with coredumps of a task which reached do_exit() is
via:

        synchronize_group_exit()
           coredump_task_exit()
        ...
        exit_signals() ; // sets PF_EXITING.

coredump_task_exit() waits until the dumper thread finished, so even if
tkill() is directed at a non-dumper thread which is stuck there in
coredump_task_exit() the signal will be queued and complete_signal()
will set signal->flags = SIGNAL_GROUP_EXIT and wake everyone up
including the dumper thread.

So the only case where this matters is when a task sets PF_EXITING
_before_ the dumper starts:

T1			T2
                        do_exit()
vfs_coredump()
                          synchronize_group_exit()
                            lock(sighand)
                            tsk->flags |= PF_POSTCOREDUMP;
                            core_state = signal->core_state;
                            unlock(sighand);
                            // core_state == NULL

		          exit_signals() // Sets PF_EXITING
  zap_threads()
    lock(sighand)
    // Observes T2->flags PF_POSTCOREDUMP
    // and skips T2

Now in current mainline a tkill(T2, SIGKILL) will queue the SIGKILL in
T2->pending, but complete_signal() will not turn it into a group exit
either because it is a PIDTYPE_PID signal when PF_EXITING is set:

complete_signal()
  // wants_signal() returns false because PF_EXITING is set
  if (wants_signal(sig, p)) 
      t = p;
  else if ((type == PIDTYPE_PID) || thread_group_empty(p))
      return;  // path taken because type == PIDTYPE_PID

So it is queued for nothing and just sitting in T2->pending until
flush_sigqueue() mops it up.

That has been so since:

  5fcd835bf8c2 ("signals: use __group_complete_signal() for the specific signals too")

which was merged 18 years ago in the 2.6.26 merge window.

Which means not queueing it in the first place has exactly the same
outcome vs. SIGKILL.

The only difference is that current mainline still reaches
signalfd_notify() further down in __send_signal_locked(), while with the
early exit it will not. Does it actually matter?

If it matters we could simply force PIDTYPE_TGID for SIGKILL if type ==
PIDTYPE_PID because complete_signal() converts SIGKILL into a group exit
anyway.

Thanks,

        tglx