[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080416164410.GB24563@sergelap.austin.ibm.com>
Date: Wed, 16 Apr 2008 11:44:10 -0500
From: "Serge E. Hallyn" <serue@...ibm.com>
To: lkml <linux-kernel@...r.kernel.org>, Andrew Morton <akpm@...l.org>
Cc: Pavel Emelyanov <xemul@...nvz.org>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
Manfred Spraul <manfred@...orfullife.com>,
Michael Kerrisk <mtk.manpages@...glemail.com>,
Nadia Derbey <Nadia.Derbey@...l.net>
Subject: [PATCH 3/3] ipc: sysvsem: refuse clone(CLONE_SYSVSEM|CLONE_NEWIPC)
CLONE_NEWIPC|CLONE_SYSVSEM interaction isn't handled properly. This can
cause a kernel memory corruption. CLONE_NEWIPC must detach from the existing
undo lists.
Fix, part 3: refuse clone(CLONE_SYSVSEM|CLONE_NEWIPC).
With unshare, specifying CLONE_SYSVSEM means unshare the sysvsem. So
it seems reasonable that CLONE_NEWIPC without CLONE_SYSVSEM would just
imply CLONE_SYSVSEM.
However with clone, specifying CLONE_SYSVSEM means *share* the sysvsem.
So calling clone(CLONE_SYSVSEM|CLONE_NEWIPC) is explicitly asking for
something we can't allow. So return -EINVAL in that case.
Signed-off-by: Serge E. Hallyn <serue@...ibm.com>
---
kernel/nsproxy.c | 12 ++++++++++++
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/kernel/nsproxy.c b/kernel/nsproxy.c
index f5d332c..468ade3 100644
--- a/kernel/nsproxy.c
+++ b/kernel/nsproxy.c
@@ -139,6 +139,18 @@ int copy_namespaces(unsigned long flags, struct task_struct *tsk)
goto out;
}
+ /*
+ * CLONE_NEWIPC must detach from the undolist: after switching
+ * to a new ipc namespace, the semaphore arrays from the old
+ * namespace are unreachable. In clone parlance, CLONE_SYSVSEM
+ * means share undolist with parent, so we must forbid using
+ * it along with CLONE_NEWIPC.
+ */
+ if ((flags&CLONE_NEWIPC) && (flags&CLONE_SYSVSEM)) {
+ err = -EINVAL;
+ goto out;
+ }
+
new_ns = create_new_namespaces(flags, tsk, tsk->fs);
if (IS_ERR(new_ns)) {
err = PTR_ERR(new_ns);
--
1.5.1.1.GIT
--
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/
Powered by blists - more mailing lists