linux-kernel - Re: [PATCH] namespaces: fix race at task 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <m14pqfysrq.fsf@ebiederm.dsl.xmission.com>
Date:	Thu, 25 Jan 2007 09:29:13 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	"Serge E. Hallyn" <serue@...ibm.com>
Cc:	linux-kernel@...r.kernel.org, Cedric Le Goater <clg@...ibm.com>,
	Oleg Nesterov <oleg@...sign.ru>,
	Daniel Hokka Zakrisson <daniel@...ac.com>,
	herbert@...hfloor.at, akpm@...l.org, trond.myklebust@....uio.no,
	Linux Containers <containers@...ts.osdl.org>
Subject: Re: [PATCH] namespaces: fix race at task exit

"Serge E. Hallyn" <serue@...ibm.com> writes:

> In do_exit(), the exit_task_namespaces() was placed after
> exit_notify() because exit_notify ends up using the pid
> namespace both to access the reaper, and for detaching the
> pid.  However, this placement allows an nfs server to reap
> the task before exit_task_namespaces() completes.
>
> This patch moves the exit_task_namespaces() into release_task,
> below release_thread() which puts the pids(), and just above
> the call_rcu(delayed_put_task_struct).  I believe this should
> solve both problems.

For the pid namespace this seems to be correct placement.
For the mount namespace this would seem to exacerbate the problem
because it now gets called after the task has been reaped!

I'd love to be convinced otherwise but I do not believe we
can safely exit both the mount and the pid namespace at the
same location in the code.

The NFS unmount currently wants a killable thread as it
uses interruptible sleeps.  How does starting that process
after the process in which it lives aid this?

But thanks for remembering this.  This is a real problem we
do need to solve.

Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/