linux-kernel - Re: [PATCH v2] pidfd: implement PIDFD_THREAD flag for pidfd

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: <20240131135232.GA2609@redhat.com>
Date: Wed, 31 Jan 2024 14:52:32 +0100
From: Oleg Nesterov <oleg@...hat.com>
To: Tycho Andersen <tycho@...ho.pizza>
Cc: Christian Brauner <brauner@...nel.org>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] pidfd: implement PIDFD_THREAD flag for pidfd_open()

On 01/30, Tycho Andersen wrote:
>
> On Tue, Jan 30, 2024 at 12:34:09PM +0100, Oleg Nesterov wrote:
> > Damn. Self-NACK.
> >
> > I forgot (we all ;) about mt-exec, and there are 2 problems.
> >
> > 1. The "if (!thread_group_leader(tsk))" block in de_thread() needs
> >    do_notify_pidfd() too, the execing non-leader thread looses its
> >    old pid, pidfd_poll(PIDFD_THREAD, pid-of-execing-sub-thread)
> >    should succeed. Must be fixed, I think.
>
> I think the `test_non_tgl_exec` from my tests exercises the scenario
> you're describing, and it works.

This means your test is racy, I guess.

Look. We have a leader L, its sub-thtread T with the pid TPID, and
another process X which sleeps in pidfd_poll(PIDFD_THREAD, TPID).

T starts de_thread and kills the leader L. The leader exits and wakes
X up.

Then T does de_thread() -> exchange_tids() so we have

	// BEFORE:
	// pid_task(TPID, PIDTYPE_PID) == T
	exchange_tids(tsk, leader);
	// AFTER:
	// pid_task(TPID, PIDTYPE_PID) == L

Now. If X calls pidfd_task_exited(TPID, true) "AFTER" then we are
fine, pidfd_task_exited() will return true. OK, this is not exactly
true, leader->exit_state == 0 right after exchange_tids(), but lets
ignore.

However. If X calls pidfd_task_exited(TPID, true) "BEFORE" it will
return false: pid_task(TPID) == T and T is not going to die. So
pidfd_poll() will block again forever, TPID is going to die.

See?

Fixed in v3.

> > 2. pidfd_poll(PIDFD_THREAD, pid-of-group-leader) should not succeed
> >    when its sub-thread execs, the execing thread inherits the leader's
> >    pid. Perhaps pidfd_task_exited() can check sig->group_exec_task,
>
> I didn't have an explicit test for this, but I hacked one up, and
> pidfd_poll(PIDFD_THREAD, pid-of-group-leader) doesn't return after
> exec.

See above, this depends on timing.

See also v3 I've sent, I tried to document the problems with mt-exec.

Oleg.