[PATCH] proc: Report SIGEV_NONE in /proc/pid/timers if target task has died

Andrei Vagin posted 1 patch 1 week ago
fs/proc/base.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
[PATCH] proc: Report SIGEV_NONE in /proc/pid/timers if target task has died
Posted by Andrei Vagin 1 week ago
When a posix timer is created targeting a specific thread (using
SIGEV_SIGNAL | SIGEV_THREAD_ID), it takes a reference to the target
struct pid in timer->it_pid. If the target thread subsequently
terminates, its numeric tid is freed and can be recycled for an
unrelated task. However, the timer holds its reference to the original
struct pid.

show_timer() in /proc/[pid]/timers previously called pid_nr_ns()
directly on timer->it_pid without checking whether any task remained
attached to that struct pid. As a result:
1. It reported the stale tid, which could mistakenly refer to a recycled
   pid.
2. In the kernel, expired signals for dead target threads are dropped by
   posixtimer_send_sigqueue() because posixtimer_get_target() returns
   NULL, so the timer functionally acts as SIGEV_NONE.
3. Checkpoint/restore tools (CRIU) parsing /proc/[pid]/timers would try
   to restore a timer with SIGEV_SIGNAL | SIGEV_THREAD_ID targeting a
   non-existent or unrelated thread.

Check pid_has_task(timer->it_pid, timer->it_pid_type) in show_timer().
If the target task has died, override notify to SIGEV_NONE and report
PID 0 (e.g., 'notify: none/pid.0').

Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Andrei Vagin <avagin@google.com>
---
 fs/proc/base.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/fs/proc/base.c b/fs/proc/base.c
index 780f81259052..e3a6ea4fffea 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -2519,17 +2519,23 @@ static int show_timer(struct seq_file *m, void *v)
 	struct k_itimer *timer = hlist_entry((struct hlist_node *)v, struct k_itimer, list);
 	struct timers_private *tp = m->private;
 	int notify = timer->it_sigev_notify;
+	pid_t nr = 0;
 
 	guard(spinlock_irq)(&timer->it_lock);
 	if (!posixtimer_valid(timer))
 		return 0;
 
+	if (timer->it_pid && pid_has_task(timer->it_pid, timer->it_pid_type))
+		nr = pid_nr_ns(timer->it_pid, tp->ns);
+	else
+		notify = SIGEV_NONE;
+
 	seq_printf(m, "ID: %d\n", timer->it_id);
 	seq_printf(m, "signal: %d/%px\n", timer->sigq.info.si_signo,
 		   timer->sigq.info.si_value.sival_ptr);
 	seq_printf(m, "notify: %s/%s.%d\n", nstr[notify & ~SIGEV_THREAD_ID],
 		   (notify & SIGEV_THREAD_ID) ? "tid" : "pid",
-		   pid_nr_ns(timer->it_pid, tp->ns));
+		   nr);
 	seq_printf(m, "ClockID: %d\n", timer->it_clock);
 
 	return 0;
-- 
2.55.0.691.gc56d675ccc-goog
Re: [PATCH] proc: Report SIGEV_NONE in /proc/pid/timers if target task has died
Posted by Pavel Tikhomirov 4 days, 17 hours ago

On 8/16/26 18:12, Andrei Vagin wrote:
> When a posix timer is created targeting a specific thread (using
> SIGEV_SIGNAL | SIGEV_THREAD_ID), it takes a reference to the target
> struct pid in timer->it_pid. If the target thread subsequently
> terminates, its numeric tid is freed and can be recycled for an
> unrelated task. However, the timer holds its reference to the original
> struct pid.
> 
> show_timer() in /proc/[pid]/timers previously called pid_nr_ns()
> directly on timer->it_pid without checking whether any task remained
> attached to that struct pid. As a result:
> 1. It reported the stale tid, which could mistakenly refer to a recycled
>    pid.
> 2. In the kernel, expired signals for dead target threads are dropped by
>    posixtimer_send_sigqueue() because posixtimer_get_target() returns
>    NULL, so the timer functionally acts as SIGEV_NONE.
> 3. Checkpoint/restore tools (CRIU) parsing /proc/[pid]/timers would try
>    to restore a timer with SIGEV_SIGNAL | SIGEV_THREAD_ID targeting a
>    non-existent or unrelated thread.
> 
> Check pid_has_task(timer->it_pid, timer->it_pid_type) in show_timer().
> If the target task has died, override notify to SIGEV_NONE and report
> PID 0 (e.g., 'notify: none/pid.0').
> 
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Signed-off-by: Andrei Vagin <avagin@google.com>

Reviewed-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>

Hopefully a useful note:

Though the fixed interface is not full-proof by itself, e.g. there is
still window that task alive at the time of check can be already dead at
the time when userspace uses the reported pid.

That gap probably can be closed easily from userspace, e.g. with taking pidfd
on this reported pid and re reading the info (to make sure it's still the same
task), or in CRIU we just have container processes frozen/ptrace-stopped so the
reported pid task should not go away under us.

> ---
>  fs/proc/base.c | 8 +++++++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/proc/base.c b/fs/proc/base.c
> index 780f81259052..e3a6ea4fffea 100644
> --- a/fs/proc/base.c
> +++ b/fs/proc/base.c
> @@ -2519,17 +2519,23 @@ static int show_timer(struct seq_file *m, void *v)
>  	struct k_itimer *timer = hlist_entry((struct hlist_node *)v, struct k_itimer, list);
>  	struct timers_private *tp = m->private;
>  	int notify = timer->it_sigev_notify;
> +	pid_t nr = 0;
>  
>  	guard(spinlock_irq)(&timer->it_lock);
>  	if (!posixtimer_valid(timer))
>  		return 0;
>  
> +	if (timer->it_pid && pid_has_task(timer->it_pid, timer->it_pid_type))
> +		nr = pid_nr_ns(timer->it_pid, tp->ns);
> +	else
> +		notify = SIGEV_NONE;
> +
>  	seq_printf(m, "ID: %d\n", timer->it_id);
>  	seq_printf(m, "signal: %d/%px\n", timer->sigq.info.si_signo,
>  		   timer->sigq.info.si_value.sival_ptr);
>  	seq_printf(m, "notify: %s/%s.%d\n", nstr[notify & ~SIGEV_THREAD_ID],
>  		   (notify & SIGEV_THREAD_ID) ? "tid" : "pid",
> -		   pid_nr_ns(timer->it_pid, tp->ns));
> +		   nr);
>  	seq_printf(m, "ClockID: %d\n", timer->it_clock);
>  
>  	return 0;

-- 
Best regards, Pavel Tikhomirov
Senior Software Developer, Virtuozzo.
Re: [PATCH] proc: Report SIGEV_NONE in /proc/pid/timers if target task has died
Posted by Andrei Vagin 3 days, 9 hours ago
On Wed, Aug 19, 2026 at 2:30 AM Pavel Tikhomirov
<ptikhomirov@virtuozzo.com> wrote:
>
>
>
> On 8/16/26 18:12, Andrei Vagin wrote:
> > When a posix timer is created targeting a specific thread (using
> > SIGEV_SIGNAL | SIGEV_THREAD_ID), it takes a reference to the target
> > struct pid in timer->it_pid. If the target thread subsequently
> > terminates, its numeric tid is freed and can be recycled for an
> > unrelated task. However, the timer holds its reference to the original
> > struct pid.
> >
> > show_timer() in /proc/[pid]/timers previously called pid_nr_ns()
> > directly on timer->it_pid without checking whether any task remained
> > attached to that struct pid. As a result:
> > 1. It reported the stale tid, which could mistakenly refer to a recycled
> >    pid.
> > 2. In the kernel, expired signals for dead target threads are dropped by
> >    posixtimer_send_sigqueue() because posixtimer_get_target() returns
> >    NULL, so the timer functionally acts as SIGEV_NONE.
> > 3. Checkpoint/restore tools (CRIU) parsing /proc/[pid]/timers would try
> >    to restore a timer with SIGEV_SIGNAL | SIGEV_THREAD_ID targeting a
> >    non-existent or unrelated thread.
> >
> > Check pid_has_task(timer->it_pid, timer->it_pid_type) in show_timer().
> > If the target task has died, override notify to SIGEV_NONE and report
> > PID 0 (e.g., 'notify: none/pid.0').
> >
> > Cc: Thomas Gleixner <tglx@linutronix.de>
> > Signed-off-by: Andrei Vagin <avagin@google.com>
>
> Reviewed-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
>
> Hopefully a useful note:
>
> Though the fixed interface is not full-proof by itself, e.g. there is
> still window that task alive at the time of check can be already dead at
> the time when userspace uses the reported pid.

Pavel, this isn't a unique problem. We can say that about any pid reported
in /proc.

>
> That gap probably can be closed easily from userspace, e.g. with taking pidfd
> on this reported pid and re reading the info (to make sure it's still the same
> task), or in CRIU we just have container processes frozen/ptrace-stopped so the
> reported pid task should not go away under us.

I think you answered your question:)

Thanks,
Andrei