• Eli Billauer's avatar
    usb: core: Solve race condition in anchor cleanup functions · fbc29943
    Eli Billauer authored
    usb_kill_anchored_urbs() is commonly used to cancel all URBs on an
    anchor just before releasing resources which the URBs rely on. By doing
    so, users of this function rely on that no completer callbacks will take
    place from any URB on the anchor after it returns.
    
    However if this function is called in parallel with __usb_hcd_giveback_urb
    processing a URB on the anchor, the latter may call the completer
    callback after usb_kill_anchored_urbs() returns. This can lead to a
    kernel panic due to use after release of memory in interrupt context.
    
    The race condition is that __usb_hcd_giveback_urb() first unanchors the URB
    and then makes the completer callback. Such URB is hence invisible to
    usb_kill_anchored_urbs(), allowing it to return before the completer has
    been called, since the anchor's urb_list is empty.
    
    Even worse, if the racing completer callback resubmits the URB, it may
    remain in the system long after usb_kill_anchored_urbs() returns.
    
    Hence list_empty(&anchor->urb_list), which is used in the existing
    while-loop, doesn't reliably ensure that all URBs of the anchor are gone.
    
    A similar problem exists with usb_poison_anchored_urbs() and
    usb_scuttle_anchored_urbs().
    
    This patch adds an external do-while loop, which ensures that all URBs
    are indeed handled before these three functions return. This change has
    no effect at all unless the race condition occurs, in which case the
    loop will busy-wait until the racing completer callback has finished.
    This is a rare condition, so the CPU waste of this spinning is
    negligible.
    
    The additional do-while loop relies on usb_anchor_check_wakeup(), which
    returns true iff the anchor list is empty, and there is no
    __usb_hcd_giveback_urb() in the system that is in the middle of the
    unanchor-before-complete phase. The @suspend_wakeups member of
    struct usb_anchor is used for this purpose, which was introduced to solve
    another problem which the same race condition causes, in commit
    6ec4147e ("usb-anchor: Delay usb_wait_anchor_empty_timeout wake up
    till completion is done").
    
    The surely_empty variable is necessary, because usb_anchor_check_wakeup()
    must be called with the lock held to prevent races. However the spinlock
    must be released and reacquired if the outer loop spins with an empty
    URB list while waiting for the unanchor-before-complete passage to finish:
    The completer callback may very well attempt to take the very same lock.
    
    To summarize, using usb_anchor_check_wakeup() means that the patched
    functions can return only when the anchor's list is empty, and there is
    no invisible URB being processed. Since the inner while loop finishes on
    the empty list condition, the new do-while loop will terminate as well,
    except for when the said race condition occurs.
    Signed-off-by: default avatarEli Billauer <eli.billauer@gmail.com>
    Acked-by: default avatarOliver Neukum <oneukum@suse.com>
    Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
    Link: https://lore.kernel.org/r/20200731054650.30644-1-eli.billauer@gmail.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    fbc29943
urb.c 32.8 KB