futex: setup writeable mapping for futex ops which modify user space data
commiteb52dd3fe61f1b0e51f48bd7785939167835210d
authorThomas Gleixner <tglx@linutronix.de>
Mon, 18 May 2009 19:20:10 +0000 (18 21:20 +0200)
committerGreg Kroah-Hartman <gregkh@suse.de>
Mon, 15 Jun 2009 16:39:59 +0000 (15 09:39 -0700)
tree9e86ef867f733fec082116ef48cd1b5e8015be73
parent63eef0d3d33a89540e62207742118a6567bd4795
futex: setup writeable mapping for futex ops which modify user space data

commit 64d1304a64477629cb16b75491a77bafe6f86963 upstream.

The futex code installs a read only mapping via get_user_pages_fast()
even if the futex op function has to modify user space data. The
eventual fault was fixed up by futex_handle_fault() which walked the
VMA with mmap_sem held.

After the cleanup patches which removed the mmap_sem dependency of the
futex code commit 4dc5b7a36a49eff97050894cf1b3a9a02523717 (futex:
clean up fault logic) removed the private VMA walk logic from the
futex code. This change results in a stale RO mapping which is not
fixed up.

Instead of reintroducing the previous fault logic we set up the
mapping in get_user_pages_fast() read/write for all operations which
modify user space data. Also handle private futexes in the same way
and make the current unconditional access_ok(VERIFY_WRITE) depend on
the futex op.

Reported-by: Andreas Schwab <schwab@linux-m68k.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
kernel/futex.c