tree b12447b57e9d8ea9d0256988321aeef95a46d3f9
parent 649c0edc37773a0f5dcb099de52cfac35e11f652
author Robert Kolchmeyer <rkolchmeyer@google.com> 1524159873 -0700
committer ChromeOS Commit Bot <chromeos-commit-bot@chromium.org> 1524505607 +0000

FROMLIST: fsnotify: Fix fsnotify_mark_connector race

fsnotify() acquires a reference to a fsnotify_mark_connector through
the SRCU-protected pointer to_tell->i_fsnotify_marks. However, it
appears that no precautions are taken in fsnotify_put_mark() to
ensure that fsnotify() drops its reference to this
fsnotify_mark_connector before assigning a value to its 'destroy_next'
field. This can result in fsnotify_put_mark() assigning a value
to a connector's 'destroy_next' field right before fsnotify() tries to
traverse the linked list referenced by the connector's 'list' field.
Since these two fields are members of the same union, this behavior
results in a kernel panic.

This issue is resolved by moving the connector's 'destroy_next' field
into the object pointer union. This should work since the object pointer
access is protected by both a spinlock and the value of the 'flags'
field, and the 'flags' field is cleared while holding the spinlock in
fsnotify_put_mark() before 'destroy_next' is updated. It shouldn't be
possible for another thread to accidentally read from the object pointer
after the 'destroy_next' field is updated.

The offending behavior here is extremely unlikely; since
fsnotify_put_mark() removes references to a connector (specifically,
it ensures that the connector is unreachable from the inode it was
formerly attached to) before updating its 'destroy_next' field, a
sizeable chunk of code in fsnotify_put_mark() has to execute in the
short window between when fsnotify() acquires the connector reference
and saves the value of its 'list' field. On the HEAD kernel, I've only
been able to reproduce this by inserting a udelay(1) in fsnotify().
However, I've been able to reproduce this issue without inserting a
udelay(1) anywhere on older unmodified release kernels, so I believe
it's worth fixing at HEAD.

Fixes bug 199437: https://bugzilla.kernel.org/show_bug.cgi?id=199437

Fixes: 08991e83b7286635167bab40927665a90fb00d81
Signed-off-by: Robert Kolchmeyer <rkolchmeyer@google.com>

(am from https://patchwork.kernel.org/patch/10351417/)

BUG=b:77982952
TEST=tryjob, cannot repro issue on VM

Change-Id: Ie8a57feed915296919a2b1a57100aac26aca4011
Reviewed-on: https://chromium-review.googlesource.com/1020070
Commit-Ready: Robert Kolchmeyer <rkolchmeyer@google.com>
Tested-by: Robert Kolchmeyer <rkolchmeyer@google.com>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Reviewed-by: Pradeep Sawlani <sawlani@google.com>
(cherry picked from commit 548cbf3f9cfceac99d8713845bc90f4b8612f94f)
Reviewed-on: https://chromium-review.googlesource.com/1024330
Commit-Queue: Robert Kolchmeyer <rkolchmeyer@google.com>