sys_unshare(CLONE_NEWIPC) doesn't handle the undo lists properly, this can

cause a kernel memory corruption. CLONE_NEWIPC must detach from the existing

undo lists.

Fix, part 1: add support for sys_unshare(CLONE_SYSVSEM)
I'm not sure who's the right maintainer, Andrew, could you merge it?
Signed-off-by: Manfred Spraul <manfred@colorfullife.com>

---

 ipc/sem.c     |    1 +

 kernel/fork.c |   18 ++++++++++++++----

 2 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/ipc/sem.c b/ipc/sem.c

index 0b45a4d..35841bd 100644

--- a/ipc/sem.c

+++ b/ipc/sem.c

@@ -1298,6 +1298,7 @@ void exit_sem(struct task_struct *tsk)

 	undo_list = tsk->sysvsem.undo_list;

 	if (!undo_list)

 		return;

+	tsk->sysvsem.undo_list = NULL;
 	if (!atomic_dec_and_test(&undo_list->refcnt))

 		return;

diff --git a/kernel/fork.c b/kernel/fork.c

index 9c042f9..7f242b0 100644

--- a/kernel/fork.c

+++ b/kernel/fork.c

@@ -1675,13 +1675,17 @@ static int unshare_fd(unsigned long unshare_flags, struct files_struct **new_fdp

 }
 /*

- * Unsharing of semundo for tasks created with CLONE_SYSVSEM is not

- * supported yet

+ * Unsharing of semundo for tasks created with CLONE_SYSVSEM doesn't require

+ * any allocations: it means that the task leaves the existing undo lists,

+ * just like sys_exit(). The new undo lists are allocated on demand in the

+ * ipc syscalls.

+ * new_ulistp is set to a non-NULL value, the caller expects that on success.

  */

 static int unshare_semundo(unsigned long unshare_flags, struct sem_undo_list **new_ulistp)

 {

-	if (unshare_flags & CLONE_SYSVSEM)

-		return -EINVAL;

+	if (unshare_flags & CLONE_SYSVSEM) {

+		*new_ulistp = (void*)1;

+	}
 	return 0;

 }

@@ -1731,6 +1735,12 @@ asmlinkage long sys_unshare(unsigned long unshare_flags)

 		goto bad_unshare_cleanup_semundo;
 	if (new_fs ||  new_mm || new_fd || new_ulist || new_nsproxy) {

+		if (unshare_flags & CLONE_SYSVSEM) {

+			/*

+			 * CLONE_SYSVSEM is equivalent to sys_exit().

+			 *...
[ message continues ]

--

It adds a new feature - previously sys_unshare(CLONE_SYSVSEM) returned

Attached is an alternative. If you prefer it, I'll send another patch set.
--

    Manfred

FWIW I definately far far prefer this version  :)
As for 'maintainers', in the end wrt this code I'd defer to any two of

Pavel, Nadia, and Pierre, each of who I've seen do a great deal of

digging around this code.
(I think I saw some set of these go into -mm so I guess I'll just grab

mmotm and test with that a bit later today)
thanks,
--

Of course if we do go this route, then the unshare(2) manpage will need

an update (so Michael Kerrisk cc:d).
thanks,

-serge

--

On Mon, 14 Apr 2008 09:58:40 -0500
Oh, OK.
I guess I'll drop what I have.  Manfred, can we please have a new patchset?
We might end up slipping this back to 2.6.25.1.  Would that be a bad thing?

--

It'd be unfortunate, but as the existing patch doesn't completely fix

the problem it's probably best to wait anyway.
Manfred, I don't want to step on your toes, but please do let me know if

you don't have time to do the next version.  If you do have time, then

thank you again for spotting+fixing the problem.
thanks,

-serge

--

Well I suppose we can fiddle with this sort of thing later.  Right now the

major concern is the testedness and reviewedness of these changes?

--