[RFC] alloc_pid() breakage

[Al Viro <viro-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org>]

On Sun, Dec 01, 2013 at 06:13:29PM +0000, Al Viro wrote:
 
> AFAICS, pid_ns gets internal procfs instance and it pins the sucker down.
> Which would cause exact same problems, obviously.  The trick done there
> is more or less to introduce a "being shut down" state of pid_ns - from
> the moment when we don't have any pids in it to actual destruction.
> Entering that state schedules (yes, it is async and yes, it is ugly)
> dropping the internal procfs vfsmount.
> 
> Additional headache, AFAICS, comes from /proc/self/ns/pid - it can be
> opened, passed to somebody in ancestor pidns and then fed by it to
> setns(2).  After that fork() by that somebody will trigger alloc_pid() in
> that pid_ns.  What happens if it comes just before the (already scheduled)
> pid_ns_release_proc()?  AFAICS, nothing good - there's no protection
> against leaks, access to freed vfsmount, double-mntput, etc.  Eric, am
> I missing something subtle and relevant in that code?

Egads...  I think I see what's going on, but it's convoluted as hell -
you rely on 1 not getting returned more than once by alloc_pidmap(), even
after having been freed, so this
        if (unlikely(is_child_reaper(pid))) {
                if (pid_ns_prepare_proc(ns))
                        goto out_free;
        }
is essentially "on the first call of alloc_pid() for given pidns".  And
upper bit in ->nr_hashed acts as "it's not in rundown state".

OK, so... what happens if I do unshare(CLONE_NEWPID) and the first fork()
attempt fails (e.g. due to failure to allocate a map page when allocating
a number in parent pidns, or OOM-induced failure to mount procfs, whatever).
Sure, that fork() has failed.  No pid had been allocated, thus no free_pid()
calls made.  After a while the memory becomes less tight and the same process
tries to fork() again.  What happens then?  pidns with processes in it,
but no reaper and NULL ->proc_mnt?  sysctl(2) called in it won't be happy;
neither will exit(2), actually, since it'll hit proc_flush_task_mnt() and
oops on trying to evaluate ->proc_mnt->mnt_root...

Another question: can free_pid() end up scheduling ->proc_work for anything
other than the last level?  After all, reaper in parent pidns couldn't have
gotten through the zap_pid_ns_process() yet, let alone getting to its
free_pid(), right?
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html