linux-kernel - [PATCH] futex: bugfix for robust futex deadlock when waking only one thread in handle_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>] [day] [month] [year] [list]

Message-ID: <OFC7A3D444.3EF36F3E-ON48257B47.002BA6AB-48257B47.002BC310@zte.com.cn>
Date:	Mon, 8 Apr 2013 15:57:38 +0800
From:	jiang.biao2@....com.cn
To:	linux-kernel@...r.kernel.org
Cc:	Zhang Yi <zhang.yi20@....com.cn>,
	Ma Chenggong <ma.chenggong@....com.cn>,
	Liu Dong <liu.dong3@....com.cn>,
	Cui Yunfeng <cui.yunfeng@....com.cn>,
	Lu Zhongjun <lu.zhongjun@....com.cn>,
	Jiang Biao <jiang.biao2@....com.cn>
Subject: [PATCH] futex: bugfix for robust futex deadlock when waking only one thread
 in handle_futex_death

From: Zhang Yi <zhang.yi20@....com.cn>

The function handle_futex_death just wakes one thread, which may be not 
enough 
when the owner process is dead. Think about this scene：
1. A robust futex is shared for two processes, each process has multi 
threads 
try to get the lock. 
2. One of the threads gets the lock, and the others are waiting and sorted 
in 
order of priority.
3. The process to which the lock owner thread belongs is dying，and 
handle_futex_death is called to wake the first waiter 
4. When the first waiter belongs to the same process，it has no chance to 
return 
to the userspace to get the lock and will not call handle_futex_death any 
more，
and then the rest threads of the other process will never be waked, and 
will block 
forever.

This patch wakes all the waiters when lock owner is in group-exit, letting 
all 
the waiters return to userspace and try to get the lock again.

Signed-off-by: Zhang Yi <zhang.yi20@....com.cn>
Tested-by: Ma Chenggong <ma.chenggong@....com.cn>
Reviewed-by: Liu Dong <liu.dong3@....com.cn>
Reviewed-by: Cui Yunfeng <cui.yunfeng@....com.cn>
Reviewed-by: Lu Zhongjun <lu.zhongjun@....com.cn>
Reviewed-by: Jiang Biao <jiang.biao2@....com.cn>

--- orig/linux-3.9-rc5/kernel/futex.c   2013-03-31 22:12:43.000000000 
+0000
+++ new/linux-3.9-rc5/kernel/futex.c    2013-04-03 12:33:27.735392000 
+0000
@@ -2545,8 +2545,10 @@ retry:
                 * Wake robust non-PI futexes here. The wakeup of
                 * PI futexes happens in exit_pi_state():
                 */
-               if (!pi && (uval & FUTEX_WAITERS))
-                       futex_wake(uaddr, 1, 1, FUTEX_BITSET_MATCH_ANY);
+               if (!pi && (uval & FUTEX_WAITERS)){
+                       int wake_nr = signal_group_exit(current->signal) ? 
INT_MAX : 1;
+                       futex_wake(uaddr, 1, wake_nr, 
FUTEX_BITSET_MATCH_ANY);
+               }
        }
        return 0;
 }
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.