]> git.ipfire.org Git - thirdparty/kernel/stable.git/commit
arm64: futex: Fix FUTEX_WAKE_OP atomic ops with non-zero result value
authorWill Deacon <will.deacon@arm.com>
Mon, 8 Apr 2019 11:45:09 +0000 (12:45 +0100)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Wed, 17 Apr 2019 06:37:54 +0000 (08:37 +0200)
commitb8dba39c7a29f7651ad8e61fe0737d7c1ba42225
tree72867742218f53b8f64bbda2e78be62f162a00a0
parent377b54a6fb64e026ead623dbeb8c814b5bd934b0
arm64: futex: Fix FUTEX_WAKE_OP atomic ops with non-zero result value

commit 045afc24124d80c6998d9c770844c67912083506 upstream.

Rather embarrassingly, our futex() FUTEX_WAKE_OP implementation doesn't
explicitly set the return value on the non-faulting path and instead
leaves it holding the result of the underlying atomic operation. This
means that any FUTEX_WAKE_OP atomic operation which computes a non-zero
value will be reported as having failed. Regrettably, I wrote the buggy
code back in 2011 and it was upstreamed as part of the initial arm64
support in 2012.

The reasons we appear to get away with this are:

  1. FUTEX_WAKE_OP is rarely used and therefore doesn't appear to get
     exercised by futex() test applications

  2. If the result of the atomic operation is zero, the system call
     behaves correctly

  3. Prior to version 2.25, the only operation used by GLIBC set the
     futex to zero, and therefore worked as expected. From 2.25 onwards,
     FUTEX_WAKE_OP is not used by GLIBC at all.

Fix the implementation by ensuring that the return value is either 0
to indicate that the atomic operation completed successfully, or -EFAULT
if we encountered a fault when accessing the user mapping.

Cc: <stable@kernel.org>
Fixes: 6170a97460db ("arm64: Atomic operations")
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
arch/arm64/include/asm/futex.h