From: Greg KH <gregkh@suse.de>
To: linux-kernel@vger.kernel.org, stable@kernel.org
Cc: Justin Forbes <jmforbes@linuxtx.org>,
Zwane Mwaikambo <zwane@arm.linux.org.uk>,
"Theodore Ts'o" <tytso@mit.edu>,
Randy Dunlap <rdunlap@xenotime.net>,
Dave Jones <davej@redhat.com>,
Chuck Wolber <chuckw@quantumlinux.com>,
Chris Wedgwood <reviews@ml.cw.f00f.org>,
Michael Krufky <mkrufky@linuxtv.org>,
Chuck Ebbert <cebbert@redhat.com>,
Domenico Andreoli <cavokz@gmail.com>,
torvalds@linux-foundation.org, akpm@linux-foundation.org,
alan@lxorguk.ukuu.org.uk, bunk@kernel.org,
"David S. Miller" <davem@davemloft.net>
Subject: [patch 11/13] Fix compat futex hangs.
Date: Wed, 14 Nov 2007 22:09:52 -0800 [thread overview]
Message-ID: <20071115060952.GL7602@kroah.com> (raw)
In-Reply-To: <20071115060544.GA7602@kroah.com>
[-- Attachment #1: fix-compat-futex-hangs.patch --]
[-- Type: text/plain, Size: 3259 bytes --]
-stable review patch. If anyone has any objections, please let us know.
------------------
From: David Miller <davem@davemloft.net>
[FUTEX]: Fix address computation in compat code.
[ Upstream commit: 3c5fd9c77d609b51c0bab682c9d40cbb496ec6f1 ]
compat_exit_robust_list() computes a pointer to the
futex entry in userspace as follows:
(void __user *)entry + futex_offset
'entry' is a 'struct robust_list __user *', and
'futex_offset' is a 'compat_long_t' (typically a 's32').
Things explode if the 32-bit sign bit is set in futex_offset.
Type promotion sign extends futex_offset to a 64-bit value before
adding it to 'entry'.
This triggered a problem on sparc64 running 32-bit applications which
would lock up a cpu looping forever in the fault handling for the
userspace load in handle_futex_death().
Compat userspace runs with address masking (wherein the cpu zeros out
the top 32-bits of every effective address given to a memory operation
instruction) so the sparc64 fault handler accounts for this by
zero'ing out the top 32-bits of the fault address too.
Since the kernel properly uses the compat_uptr interfaces, kernel side
accesses to compat userspace work too since they will only use
addresses with the top 32-bit clear.
Because of this compat futex layer bug we get into the following loop
when executing the get_user() load near the top of handle_futex_death():
1) load from address '0xfffffffff7f16bd8', FAULT
2) fault handler clears upper 32-bits, processes fault
for address '0xf7f16bd8' which succeeds
3) goto #1
I want to thank Bernd Zeimetz, Josip Rodin, and Fabio Massimo Di Nitto
for their tireless efforts helping me track down this bug.
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
kernel/futex_compat.c | 27 ++++++++++++++++++++-------
1 file changed, 20 insertions(+), 7 deletions(-)
--- a/kernel/futex_compat.c
+++ b/kernel/futex_compat.c
@@ -29,6 +29,15 @@ fetch_robust_entry(compat_uptr_t *uentry
return 0;
}
+static void __user *futex_uaddr(struct robust_list *entry,
+ compat_long_t futex_offset)
+{
+ compat_uptr_t base = ptr_to_compat(entry);
+ void __user *uaddr = compat_ptr(base + futex_offset);
+
+ return uaddr;
+}
+
/*
* Walk curr->robust_list (very carefully, it's a userspace list!)
* and mark any locks found there dead, and notify any waiters.
@@ -75,11 +84,13 @@ void compat_exit_robust_list(struct task
* A pending lock might already be on the list, so
* dont process it twice:
*/
- if (entry != pending)
- if (handle_futex_death((void __user *)entry + futex_offset,
- curr, pi))
- return;
+ if (entry != pending) {
+ void __user *uaddr = futex_uaddr(entry,
+ futex_offset);
+ if (handle_futex_death(uaddr, curr, pi))
+ return;
+ }
if (rc)
return;
uentry = next_uentry;
@@ -93,9 +104,11 @@ void compat_exit_robust_list(struct task
cond_resched();
}
- if (pending)
- handle_futex_death((void __user *)pending + futex_offset,
- curr, pip);
+ if (pending) {
+ void __user *uaddr = futex_uaddr(pending, futex_offset);
+
+ handle_futex_death(uaddr, curr, pip);
+ }
}
asmlinkage long
--
next prev parent reply other threads:[~2007-11-15 6:13 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20071115042610.731859958@mini.kroah.org>
2007-11-15 6:05 ` [patch 00/13] 2.6.23-stable review, core kernel changes Greg KH
2007-11-15 6:09 ` [patch 01/13] lockdep: fix mismatched lockdep_depth/curr_chain_hash Greg KH
2007-11-15 6:09 ` [patch 02/13] locks: fix possible infinite loop in posix deadlock detection Greg KH
2007-11-15 6:09 ` [patch 03/13] Remove broken ptrace() special-case code from file mapping Greg KH
2007-11-15 6:09 ` [patch 04/13] param_sysfs_builtin memchr argument fix Greg KH
2007-11-15 16:11 ` Chuck Ebbert
2007-11-15 17:58 ` Greg KH
2007-11-15 20:46 ` Chuck Ebbert
2007-11-15 21:20 ` Jan Kiszka
2007-11-15 23:58 ` Greg KH
2007-11-15 6:09 ` [patch 05/13] HOWTO: update ja_JP/HOWTO with latest changes Greg KH
2007-11-15 6:09 ` [patch 06/13] SLUB: Fix memory leak by not reusing cpu_slab Greg KH
2007-11-15 6:09 ` [patch 07/13] writeback: dont propagate AOP_WRITEPAGE_ACTIVATE Greg KH
2007-11-15 6:09 ` [patch 08/13] splice: fix double kunmap() in vmsplice copy path Greg KH
2007-11-15 6:09 ` [patch 09/13] fix the softlockup watchdog to actually work Greg KH
2007-11-15 6:09 ` [patch 10/13] sched: keep utime/stime monotonic Greg KH
2007-11-15 6:09 ` Greg KH [this message]
2007-11-15 6:09 ` [patch 12/13] fix tmpfs BUG and AOP_WRITEPAGE_ACTIVATE Greg KH
2007-11-15 6:09 ` [patch 13/13] BLOCK: Fix bad sharing of tag busy list on queues with shared tag maps Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20071115060952.GL7602@kroah.com \
--to=gregkh@suse.de \
--cc=akpm@linux-foundation.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=bunk@kernel.org \
--cc=cavokz@gmail.com \
--cc=cebbert@redhat.com \
--cc=chuckw@quantumlinux.com \
--cc=davej@redhat.com \
--cc=davem@davemloft.net \
--cc=jmforbes@linuxtx.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mkrufky@linuxtv.org \
--cc=rdunlap@xenotime.net \
--cc=reviews@ml.cw.f00f.org \
--cc=stable@kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=tytso@mit.edu \
--cc=zwane@arm.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.