[Cosmic][PATCH 1/1] fsnotify: Fix fsnotify_mark_connector race

[Joshua R. Poulson]

I referred to this same issue and fix in
https://bugs.launchpad.net/ubuntu/+source/linux-azure/+bug/1765564

On Wed, May 23, 2018 at 11:27 AM, Joseph Salisbury
<joseph.salisbury at canonical.com> wrote:
> From: Robert Kolchmeyer <rkolchmeyer at google.com>
>
> BugLink: http://bugs.launchpad.net/bugs/1771075
>
> 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.
>
> References: https://bugzilla.kernel.org/show_bug.cgi?id=199437
> Fixes: 08991e83b7286635167bab40927665a90fb00d81
> CC: stable at vger.kernel.org
> Signed-off-by: Robert Kolchmeyer <rkolchmeyer at google.com>
> Signed-off-by: Jan Kara <jack at suse.cz>
> (cherry picked from commit d90a10e2444ba5a351fa695917258ff4c5709fa5)
> Signed-off-by: Joseph Salisbury <joseph.salisbury at canonical.com>
> ---
>  include/linux/fsnotify_backend.h | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/include/linux/fsnotify_backend.h b/include/linux/fsnotify_backend.h
> index c6c6931..3504ac3 100644
> --- a/include/linux/fsnotify_backend.h
> +++ b/include/linux/fsnotify_backend.h
> @@ -216,12 +216,10 @@ struct fsnotify_mark_connector {
>         union { /* Object pointer [lock] */
>                 struct inode *inode;
>                 struct vfsmount *mnt;
> -       };
> -       union {
> -               struct hlist_head list;
>                 /* Used listing heads to free after srcu period expires */
>                 struct fsnotify_mark_connector *destroy_next;
>         };
> +       struct hlist_head list;
>  };
>
>  /*
> --
> 2.7.4
>
>
> --
> kernel-team mailing list
> kernel-team at lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/kernel-team