linux-kernel - Re: futexes: Still infinite loop in get_futex

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: <4A702AC2.2060003@gmail.com>
Date:	Wed, 29 Jul 2009 12:56:02 +0200
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Jens Rosenboom <jens@...one.net>
CC:	Peter Zijlstra <peterz@...radead.org>,
	Sonny Rao <sonnyrao@...ibm.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: futexes: Still infinite loop in get_futex_key() in 2.6.31-rc4

Eric Dumazet a écrit :
> Jens Rosenboom a écrit :
>> On Wed, 2009-07-29 at 08:22 +0200, Jens Rosenboom wrote:
>>> On Mon, 2009-07-27 at 15:36 +0200, Peter Zijlstra wrote:
>>> [...]
>>>> Bugger.. how easy it is to reproduce?
>>> Okay, my colleague found the right combination of scripts, take the two
>>> attached, run them both a couple of times in parallel for some hours,
>>> and get a stuck ps. This happens both on an old 2.6.29.1 I happened to
>>> still have on one machine as with 2.6.31-rc4. Both of them dual-core
>>> Opterons as the original one. If you want further tracebacks or other
>>> information, let me know.
>> Forget about null.pl even, just run pees.pl twice and a top to watch it,
>> has worked for me within less than an hour several times now.
>>
> 
> Ah that makes sense now...
> 
> maybe execve() forgets to clear clear_child_tid 
> 

Sorry , I hit 'Send' before completing the mail...

Could you please try following patch ?

[PATCH] exec: must clear clear_child_tid

"ps", while reading /proc/xxx files, has to raise mm_users count
(via a call to get_task_mm())

So when the exiting process (and spied by a ps) calls mm_release() we could go through :

        if (tsk->clear_child_tid
            && !(tsk->flags & PF_SIGNALED)
            && atomic_read(&mm->mm_users) > 1) {
                u32 __user * tidptr = tsk->clear_child_tid;
                tsk->clear_child_tid = NULL;

                /*
                 * We don't check the error code - if userspace has
                 * not set up a proper pointer then tough luck.
                 */
                put_user(0, tidptr);
                sys_futex(tidptr, FUTEX_WAKE, 1, NULL, NULL, 0);
        }

It can happen if execve() doesnt set clear_child_tid to NULL,
and we try to futex() to a tidptr that has no meaning (it had  a
meaning only in bash space, before its thread did the execve())

Furthermore, we can call put_user(0, tidptr), overwriting some integer
in our user space and corrupt user memory. (if the initial thread exits)


Reported-by: Jens Rosenboom <jens@...one.net>
Signed-off-by: Eric Dumazet <eric.dumazet@...il.com>
---
diff --git a/fs/exec.c b/fs/exec.c
index 4a8849e..e275652 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -1343,6 +1343,7 @@ int do_execve(char * filename,
 	mutex_unlock(&current->cred_guard_mutex);
 	acct_update_integrals(current);
 	free_bprm(bprm);
+	current->clear_child_tid = NULL;
 	if (displaced)
 		put_files_struct(displaced);
 	return retval;

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