On Tue, 06 Nov 2007 21:13:56 -0800 (PST) David Miller <davem@xxxxxxxxxxxxx> wrote: > From: David Miller <davem@xxxxxxxxxxxxx> > Date: Tue, 06 Nov 2007 20:34:33 -0800 (PST) > > > [FUTEX]: Fix address computation in compat code. > > Sorry, I just noticed there is a second handle_futex_death() > call in compat_exit_robust_list() which has the same > address computation bug. > > Here is an updated patch: > > [FUTEX]: Fix address computation in compat code. > > 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. > I tagged this as needed-in-2.6.23.x. Please let me know if that is not appropriate. - To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html