• Alan Stern's avatar
    usbfs: private mutex for open, release, and remove · 4a2a8a2c
    Alan Stern authored
    The usbfs code doesn't provide sufficient mutual exclusion among open,
    release, and remove.  Release vs. remove is okay because they both
    acquire the device lock, but open is not exclusive with either one.  All
    three routines modify the udev->filelist linked list, so they must not
    run concurrently.
    
    Apparently someone gave this a minimum amount of thought in the past by
    explicitly acquiring the BKL at the start of the usbdev_open routine.
    Oddly enough, there's a comment pointing out that locking is unnecessary
    because chrdev_open already has acquired the BKL.
    
    But this ignores the point that the files in /proc/bus/usb/* are not
    char device files; they are regular files and so they don't get any
    special locking.  Furthermore it's necessary to acquire the same lock in
    the release and remove routines, which the code does not do.
    
    Yet another problem arises because the same file_operations structure is
    accessible through both the /proc/bus/usb/* and /dev/usb/usbdev* file
    nodes.  Even when one of them has been removed, it's still possible for
    userspace to open the other.  So simple locking around the individual
    remove routines is insufficient; we need to lock the entire
    usb_notify_remove_device notifier chain.
    
    Rather than rely on the BKL, this patch (as723) introduces a new private
    mutex for the purpose.  Holding the BKL while invoking a notifier chain
    doesn't seem like a good idea.
    Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
    Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
    4a2a8a2c
notify.c 1.74 KB