Message ID | d82e55abd532bb4034de9cd519a96332f75be1fb.1527099360.git.joseph.salisbury@canonical.com |
---|---|
State | New |
Headers | show |
Series | fsnotify: Fix fsnotify_mark_connector race | expand |
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@canonical.com> wrote: > From: Robert Kolchmeyer <rkolchmeyer@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@vger.kernel.org > Signed-off-by: Robert Kolchmeyer <rkolchmeyer@google.com> > Signed-off-by: Jan Kara <jack@suse.cz> > (cherry picked from commit d90a10e2444ba5a351fa695917258ff4c5709fa5) > Signed-off-by: Joseph Salisbury <joseph.salisbury@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@lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/kernel-team
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; }; /*