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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20250925162759.GA25838@redhat.com>
Date: Thu, 25 Sep 2025 18:28:00 +0200
From: Oleg Nesterov <oleg@...hat.com>
To: Mateusz Guzik <mjguzik@...il.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
	Demi Marie Obenour <demiobenour@...il.com>,
	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

Sorry for the late reply...

On 09/23, Mateusz Guzik wrote:
>
> On Tue, Sep 23, 2025 at 2:05 PM Oleg Nesterov <oleg@...hat.com> wrote:
> > As you correctly pointed out, forget_original_parent/prctl lack the necessary
> > barries. So lets add the barriers instead of abusing tasklist? As for sys_prctl(),
> > I think that ret-to-user-mode + enter-the-kernel-mode should act as a full
> > barrier, so it only needs WRITE_ONCE()...
> >
>
> So I looked over this and I think I see why you are not eager to fix
> the problem to begin with. ;)
>
> I agree with reluctance to take tasklist lock to handle
> PR_SET_PDEATHSIG, but I wonder if in practice this is used rarely
> enough that the lock trip would not be a problem? It avoids any
> modifications to the exit codepath.

Yes... I mostly dislike the fact that this patch adds another possibility
to easily abuse the global tasklist lock from userspace...

> By barriers I presume you meant smp_mb() between
> RCU_INIT_POINTER(t->real_parent, reaper) and
> READ_ONCE(t->pdeath_signal) in forget_original_parent.

Yes,

> That's very
> nasty as the full fence is quite expensive.

Well, the exit_notify() path is already heavy, not sure smp_mb() or
smp_store_mb(real_parent, reaper) can add a noticeable difference.

> > Or perhaps user-space can do something else to sync with the exiting parent
> > instead of using getppid() ?
> >
>
> I never put any thought concerning this mechanism, I do think it
> nicely showcases the prctl at hand is kind of crap. The non-crap
> version would pass the PID you think your parent is, so that you do
> this race-free.

Or PR_SET_PDEATHSIG_FOR_CHILDREN(pdeath_signal), or the new
CLONE_WITH_PDEATHSIG. Or something else, I agree that the current API is,
well, not perfect ;)

> I don't know if makes any sense to add this.

Neither me.

OK. I won't argue with this patch. At least the usage of tasklist_lock is well
documented.

Thanks!

Oleg.