linux-kernel - Re: [PATCH] kernel: Prevent prctl(PR_SET_PDEATHSIG) from racing with parent process exit

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAGudoHF4P-NVSCJGvy6BSeU10tNbbB_oKq=FhtrOzUAaJychig@mail.gmail.com>
Date: Sat, 27 Sep 2025 03:51:26 +0200
From: Mateusz Guzik <mjguzik@...il.com>
To: Demi Marie Obenour <demiobenour@...il.com>
Cc: Oleg Nesterov <oleg@...hat.com>, Andrew Morton <akpm@...ux-foundation.org>, 
	Christian Brauner <brauner@...nel.org>, 
	Linux kernel mailing list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] kernel: Prevent prctl(PR_SET_PDEATHSIG) from racing with
 parent process exit

On Sat, Sep 27, 2025 at 1:58 AM Demi Marie Obenour
<demiobenour@...il.com> wrote:
> My personal thought is that prctl(PR_SET_DEATHSIG) is rather rare,
> and also the lock is not held very long.  In particular, exit
> already takes tasklist_lock for writing, and that is much more
> common.  Therefore, I would be shocked if this added any significant
> contention outside of contrived benchmarks.
>

This is my suspicion as well, yes.

> What I _am_ concerned about is potential starvation,
> especially on PREEMPT_RT.  Per the documentation:
>
> > - Because an rwlock_t writer cannot grant its priority to multiple
> >   readers, a preempted low-priority reader will continue holding its lock,
> >   thus starving even high-priority writers.
>
> This allows any user to hammer tasklist_lock
> at will.  Is that going to be a problem?
>

I can't speak for Oleg, but he also expressed concern over free access
to readlock tasklist, presumably including in this context.

My take is that any thread can already freely abuse the lock in this
manner by spamming waitid or kill (and probably in some other ways).

The existing spots are not trivial to fix. Should someone do it, your
patch is comparatively a minor addition effort-wise.