linux-kernel - Re: [patch] PID namespace design bug, workaround

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: <1194024622.6271.108.camel@localhost>
Date:	Fri, 02 Nov 2007 10:30:22 -0700
From:	Dave Hansen <haveblue@...ibm.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Pavel Emelyanov <xemul@...nvz.org>,
	Ulrich Drepper <drepper@...hat.com>,
	Ingo Molnar <mingo@...e.hu>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org,
	"Dinakar Guniguntala [imap]" <dino@...ibm.com>,
	Sripathi Kodi <sripathik@...ibm.com>
Subject: Re: [patch] PID namespace design bug, workaround

On Fri, 2007-11-02 at 01:04 -0700, Andrew Morton wrote:
> > > That is the "fix" you were referring to?  I was hoping you have a sketch
> > > for a real solution.  If nobody can think of a way to fix this PID
> > 
> > Looks like we misunderstood each other. Can you please elaborate on 
> > what exactly is broken in pid namespaces?
> 
> Isn't it this?
> 
> http://lkml.org/lkml/2007/11/1/141

I think we're still a bit murky on exactly what the issues are.  Ingo,
Ulrich, is this the right track?  The kind of issues that you're
concerned about?

There are certainly more of these, but here is one In the futex
userspace address, we install the current pid's vnr into a userspace
address.  

static int futex_lock_pi(u32 __user *uaddr, struct rw_semaphore *fshared,
                         int detect, ktime_t *time, int trylock)
{
...
        newval = task_pid_vnr(current);
        curval = cmpxchg_futex_value_locked(uaddr, 0, newval);

We obviously don't have any restrictions on who else might be mapping
that address, so that pid can theoretically leak out to any other task.
In another pid namespace, the pid at that userspace address is certainly
nonsensical.

-- Dave

-
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/