Skip to content
  • Robert Kolchmeyer's avatar
    fsnotify: Fix fsnotify_mark_connector race · 75b98294
    Robert Kolchmeyer authored
    commit d90a10e2 upstream.
    
    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: 08991e83
    
    
    CC: stable@vger.kernel.org
    Signed-off-by: default avatarRobert Kolchmeyer <rkolchmeyer@google.com>
    Signed-off-by: default avatarJan Kara <jack@suse.cz>
    Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    75b98294