timerfd: Protect the might cancel mechanism proper
authorThomas Gleixner <tglx@linutronix.de>
Tue, 31 Jan 2017 14:24:03 +0000 (15:24 +0100)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Mon, 8 May 2017 05:46:01 +0000 (07:46 +0200)
commit911bd54922cdcc259daf73cb1a3a9d0305b9061d
treefff3fa4ba7cf4c05c8db408474114c78c1869ef0
parent0c49a2c16ca93e2e4e68e21dbc95e9466a01bbdb
timerfd: Protect the might cancel mechanism proper

commit 1e38da300e1e395a15048b0af1e5305bd91402f6 upstream.

The handling of the might_cancel queueing is not properly protected, so
parallel operations on the file descriptor can race with each other and
lead to list corruptions or use after free.

Protect the context for these operations with a seperate lock.

The wait queue lock cannot be reused for this because that would create a
lock inversion scenario vs. the cancel lock. Replacing might_cancel with an
atomic (atomic_t or atomic bit) does not help either because it still can
race vs. the actual list operation.

Reported-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: "linux-fsdevel@vger.kernel.org"
Cc: syzkaller <syzkaller@googlegroups.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: linux-fsdevel@vger.kernel.org
Link: http://lkml.kernel.org/r/alpine.DEB.2.20.1701311521430.3457@nanos
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
fs/timerfd.c