Re: [PATCH 1/4] usbip: add sysfs_lock to synchronize sysfs code paths

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Apr 19, 2021 at 03:42:06PM -0600, Shuah Khan wrote:
> On 4/19/21 6:23 AM, Greg Kroah-Hartman wrote:
> > On Fri, Apr 16, 2021 at 03:43:45PM -0600, Shuah Khan wrote:
> > > On 4/16/21 2:53 PM, Tom Seewald wrote:
> > > > From: Shuah Khan <skhan@xxxxxxxxxxxxxxxxxxx>
> > > > 
> > > > commit 4e9c93af7279b059faf5bb1897ee90512b258a12 upstream.
> > > > 
> > > > Fuzzing uncovered race condition between sysfs code paths in usbip
> > > > drivers. Device connect/disconnect code paths initiated through
> > > > sysfs interface are prone to races if disconnect happens during
> > > > connect and vice versa.
> > > > 
> > > > This problem is common to all drivers while it can be reproduced easily
> > > > in vhci_hcd. Add a sysfs_lock to usbip_device struct to protect the paths.
> > > > 
> > > > Use this in vhci_hcd to protect sysfs paths. For a complete fix, usip_host
> > > > and usip-vudc drivers and the event handler will have to use this lock to
> > > > protect the paths. These changes will be done in subsequent patches.
> > > > 
> > > > Cc: stable@xxxxxxxxxxxxxxx # 4.9.x
> > > > Reported-and-tested-by: syzbot+a93fba6d384346a761e3@xxxxxxxxxxxxxxxxxxxxxxxxx
> > > > Signed-off-by: Shuah Khan <skhan@xxxxxxxxxxxxxxxxxxx>
> > > > Link: https://lore.kernel.org/r/b6568f7beae702bbc236a545d3c020106ca75eac.1616807117.git.skhan@xxxxxxxxxxxxxxxxxxx
> > > > Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
> > > > Signed-off-by: Tom Seewald <tseewald@xxxxxxxxx>
> > > > ---
> > > >    drivers/usb/usbip/usbip_common.h |  3 +++
> > > >    drivers/usb/usbip/vhci_hcd.c     |  1 +
> > > >    drivers/usb/usbip/vhci_sysfs.c   | 30 +++++++++++++++++++++++++-----
> > > >    3 files changed, 29 insertions(+), 5 deletions(-)
> > > > 
> > > 
> > > Thank you for the backport.
> > > 
> > > Reviewed-by: Shuah Khan <skhan@xxxxxxxxxxxxxxxxxxx>
> > > 
> > > Greg, please pick this up for 4.9.x
> > 
> > Also for 4.14.y, right?
> > 
> 
> It made it into 4.14 already. We are good with 4.14.y
> 
> 5f2a149564ee2b41ab09e90add21153bd5be64d3

Ugh, sorry, my fault, I hadn't updated my "what was released in what
stable version" on my laptop that I was working from yesterday.  They
are obviously all merged in 4.14 :(

Thanks for this.

greg k-h



[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux