| Message ID | 20200917144151.355848-3-m.v.b@runbox.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [1/3] usbcore/driver: Fix specific driver selection | expand |
On 9/17/20 8:41 AM, M. Vefa Bicakci wrote: > Prior to this commit, the USB-IP subsystem's USB device driver match > function used to match all USB devices (by returning true > unconditionally). Unfortunately, this is not correct behaviour and is > likely the root cause of the bug reported by Andrey Konovalov. > > USB-IP should only match USB devices that the user-space asked the kernel > to handle via USB-IP, by writing to the match_busid sysfs file, which is > what this commit aims to achieve. This is done by making the match > function check that the passed in USB device was indeed requested by the > user-space to be handled by USB-IP. > I see two patches 2/2 and 3/3 back to back. What is the difference between 2/2 and 3/3 versions? They look identical. Please include changes if any from version to version to make it easier for me to review. > Reported-by: Andrey Konovalov <andreyknvl@google.com> > Fixes: 7a2f2974f2 ("usbip: Implement a match function to fix usbip") > Link: https://lore.kernel.org/linux-usb/CAAeHK+zOrHnxjRFs=OE8T=O9208B9HP_oo8RZpyVOZ9AJ54pAA@mail.gmail.com/ > Cc: <stable@vger.kernel.org> # 5.8 > Cc: Bastien Nocera <hadess@hadess.net> > Cc: Valentina Manea <valentina.manea.m@gmail.com> > Cc: Shuah Khan <shuah@kernel.org> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > Cc: Alan Stern <stern@rowland.harvard.edu> > Cc: <syzkaller@googlegroups.com> > Signed-off-by: M. Vefa Bicakci <m.v.b@runbox.com> > --- > drivers/usb/usbip/stub_dev.c | 15 ++++++++++++++- > 1 file changed, 14 insertions(+), 1 deletion(-) > > diff --git a/drivers/usb/usbip/stub_dev.c b/drivers/usb/usbip/stub_dev.c > index 9d7d642022d1..3d9c8ff6762e 100644 > --- a/drivers/usb/usbip/stub_dev.c > +++ b/drivers/usb/usbip/stub_dev.c > @@ -463,7 +463,20 @@ static void stub_disconnect(struct usb_device *udev) > > static bool usbip_match(struct usb_device *udev) > { > - return true; > + bool match; > + struct bus_id_priv *busid_priv; > + const char *udev_busid = dev_name(&udev->dev); > + > + busid_priv = get_busid_priv(udev_busid); > + if (!busid_priv) > + return false; > + > + match = (busid_priv->status != STUB_BUSID_REMOV && > + busid_priv->status != STUB_BUSID_OTHER); > + > + put_busid_priv(busid_priv); > + > + return match; > } > > #ifdef CONFIG_PM > Did you happen to run the usbip test on this patch? If not, can you please run tools/testing/selftests/drivers/usb/usbip/usbip_test.sh and make sure there are no regressions. thanks, -- Shuah
On 17/09/2020 18.21, Shuah Khan wrote: > On 9/17/20 8:41 AM, M. Vefa Bicakci wrote: >> Prior to this commit, the USB-IP subsystem's USB device driver match >> function used to match all USB devices (by returning true >> unconditionally). Unfortunately, this is not correct behaviour and is >> likely the root cause of the bug reported by Andrey Konovalov. >> >> USB-IP should only match USB devices that the user-space asked the kernel >> to handle via USB-IP, by writing to the match_busid sysfs file, which is >> what this commit aims to achieve. This is done by making the match >> function check that the passed in USB device was indeed requested by the >> user-space to be handled by USB-IP. >> > > I see two patches 2/2 and 3/3 back to back. What is the difference > between 2/2 and 3/3 versions? They look identical. Please include > changes if any from version to version to make it easier for me to > review. Hello Shuah, Sorry for the delayed reply, and thank you for your interest! I realize that I did not add notes to the patch series regarding the changes between v1 and v2, and I forgot to label the second patch series as v2. Patches 2/2 and 3/3 are the same, as you have mentioned. I was addressing Bastien's code review comments for patch 1/2, and I split that patch into two separate patches, which is why the second patch series had 3 patches as opposed to 2. I realize that you are missing the context; here is a link to the thread: https://lore.kernel.org/linux-usb/359d080c-5cbb-250a-0ebd-aaba5f5c530d@runbox.com/T/ I can copy all patches to you as well, if you would be interested. All this to say, I am sorry about this small mess, and I will rectify this with patches I publish in the future. >> Reported-by: Andrey Konovalov <andreyknvl@google.com> >> Fixes: 7a2f2974f2 ("usbip: Implement a match function to fix usbip") >> Link: https://lore.kernel.org/linux-usb/CAAeHK+zOrHnxjRFs=OE8T=O9208B9HP_oo8RZpyVOZ9AJ54pAA@mail.gmail.com/ >> Cc: <stable@vger.kernel.org> # 5.8 >> Cc: Bastien Nocera <hadess@hadess.net> >> Cc: Valentina Manea <valentina.manea.m@gmail.com> >> Cc: Shuah Khan <shuah@kernel.org> >> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> >> Cc: Alan Stern <stern@rowland.harvard.edu> >> Cc: <syzkaller@googlegroups.com> >> Signed-off-by: M. Vefa Bicakci <m.v.b@runbox.com> >> --- >> drivers/usb/usbip/stub_dev.c | 15 ++++++++++++++- >> 1 file changed, 14 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/usb/usbip/stub_dev.c b/drivers/usb/usbip/stub_dev.c >> index 9d7d642022d1..3d9c8ff6762e 100644 >> --- a/drivers/usb/usbip/stub_dev.c >> +++ b/drivers/usb/usbip/stub_dev.c >> @@ -463,7 +463,20 @@ static void stub_disconnect(struct usb_device *udev) >> static bool usbip_match(struct usb_device *udev) >> { >> - return true; >> + bool match; >> + struct bus_id_priv *busid_priv; >> + const char *udev_busid = dev_name(&udev->dev); >> + >> + busid_priv = get_busid_priv(udev_busid); >> + if (!busid_priv) >> + return false; >> + >> + match = (busid_priv->status != STUB_BUSID_REMOV && >> + busid_priv->status != STUB_BUSID_OTHER); >> + >> + put_busid_priv(busid_priv); >> + >> + return match; >> } >> #ifdef CONFIG_PM >> > > Did you happen to run the usbip test on this patch? If not, can you > please run tools/testing/selftests/drivers/usb/usbip/usbip_test.sh > and make sure there are no regressions. Ah, this is a very good point! I have been testing the patches on Qubes OS, which uses usbip to forward USB devices between VMs. To be honest, I was not aware of the self-tests for usbip, and I will run the self-tests prior to publishing the next version of the patch series. > thanks, > -- Shuah Thank you! Vefa
On 18/09/2020 12.26, M. Vefa Bicakci wrote: > On 17/09/2020 18.21, Shuah Khan wrote: >> On 9/17/20 8:41 AM, M. Vefa Bicakci wrote: >>> Prior to this commit, the USB-IP subsystem's USB device driver match >>> function used to match all USB devices (by returning true >>> unconditionally). Unfortunately, this is not correct behaviour and is >>> likely the root cause of the bug reported by Andrey Konovalov. >>> >>> USB-IP should only match USB devices that the user-space asked the kernel >>> to handle via USB-IP, by writing to the match_busid sysfs file, which is >>> what this commit aims to achieve. This is done by making the match >>> function check that the passed in USB device was indeed requested by the >>> user-space to be handled by USB-IP. [snipped by Vefa] >>> Reported-by: Andrey Konovalov <andreyknvl@google.com> >>> Fixes: 7a2f2974f2 ("usbip: Implement a match function to fix usbip") >>> Link: https://lore.kernel.org/linux-usb/CAAeHK+zOrHnxjRFs=OE8T=O9208B9HP_oo8RZpyVOZ9AJ54pAA@mail.gmail.com/ >>> Cc: <stable@vger.kernel.org> # 5.8 >>> Cc: Bastien Nocera <hadess@hadess.net> >>> Cc: Valentina Manea <valentina.manea.m@gmail.com> >>> Cc: Shuah Khan <shuah@kernel.org> >>> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> >>> Cc: Alan Stern <stern@rowland.harvard.edu> >>> Cc: <syzkaller@googlegroups.com> >>> Signed-off-by: M. Vefa Bicakci <m.v.b@runbox.com> >>> --- >>> drivers/usb/usbip/stub_dev.c | 15 ++++++++++++++- >>> 1 file changed, 14 insertions(+), 1 deletion(-) >>> >>> diff --git a/drivers/usb/usbip/stub_dev.c b/drivers/usb/usbip/stub_dev.c >>> index 9d7d642022d1..3d9c8ff6762e 100644 >>> --- a/drivers/usb/usbip/stub_dev.c >>> +++ b/drivers/usb/usbip/stub_dev.c >>> @@ -463,7 +463,20 @@ static void stub_disconnect(struct usb_device *udev) >>> static bool usbip_match(struct usb_device *udev) >>> { >>> - return true; >>> + bool match; >>> + struct bus_id_priv *busid_priv; >>> + const char *udev_busid = dev_name(&udev->dev); >>> + >>> + busid_priv = get_busid_priv(udev_busid); >>> + if (!busid_priv) >>> + return false; >>> + >>> + match = (busid_priv->status != STUB_BUSID_REMOV && >>> + busid_priv->status != STUB_BUSID_OTHER); >>> + >>> + put_busid_priv(busid_priv); >>> + >>> + return match; >>> } >>> #ifdef CONFIG_PM >>> >> >> Did you happen to run the usbip test on this patch? If not, can you >> please run tools/testing/selftests/drivers/usb/usbip/usbip_test.sh >> and make sure there are no regressions. > > Ah, this is a very good point! I have been testing the patches on Qubes OS, > which uses usbip to forward USB devices between VMs. To be honest, I was not > aware of the self-tests for usbip, and I will run the self-tests prior to > publishing the next version of the patch series. Hello Shuah, I have just cleaned up the patches and run usbip_test.sh with a kernel without the patches in this series and with a kernel in this series. I noticed that there is a change in behaviour due to the fact that the new match function (usbip_match) does not always return true. This causes the stub device driver's probe() function to not get called at all, as the new more selective match function will prevent the stub device driver from being considered as a potential driver for the device under consideration. All of this results in the following difference in the logs of the usbip_test.sh, where the expected kernel log message "usbip-host 2-6: 2-6 is not in match_busid table... skip!" is not printed by a kernel that includes the patches in this series. --- unpatched_kernel_log.txt 2020-09-18 17:12:10.654000000 +0300 +++ patched_kernel_log.txt 2020-09-18 17:12:10.654000000 +0300 @@ -213,70 +213,69 @@ |__ Port 1: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 480M ============================================================== modprobe usbip_host - does it work? Should see -busid- is not in match_busid table... skip! dmesg ============================================================== -usbip-host 2-6: 2-6 is not in match_busid table... skip! ============================================================== Do you find this change in behaviour unacceptable? If no, I can remove this test case from usbip_test.sh with the same patch. If yes, then there is a need for a different solution to resolve the unexpected negative interaction between Bastien's work on generic/specific USB device driver selection and usbip functionality. Thank you, Vefa
On 9/18/20 8:31 AM, M. Vefa Bicakci wrote: > On 18/09/2020 12.26, M. Vefa Bicakci wrote: >> On 17/09/2020 18.21, Shuah Khan wrote: >>> On 9/17/20 8:41 AM, M. Vefa Bicakci wrote: >>>> Prior to this commit, the USB-IP subsystem's USB device driver match >>>> function used to match all USB devices (by returning true >>>> unconditionally). Unfortunately, this is not correct behaviour and is >>>> likely the root cause of the bug reported by Andrey Konovalov. >>>> >>>> USB-IP should only match USB devices that the user-space asked the >>>> kernel >>>> to handle via USB-IP, by writing to the match_busid sysfs file, >>>> which is >>>> what this commit aims to achieve. This is done by making the match >>>> function check that the passed in USB device was indeed requested by >>>> the >>>> user-space to be handled by USB-IP. > > [snipped by Vefa] > >>>> Reported-by: Andrey Konovalov <andreyknvl@google.com> >>>> Fixes: 7a2f2974f2 ("usbip: Implement a match function to fix usbip") >>>> Link: >>>> https://lore.kernel.org/linux-usb/CAAeHK+zOrHnxjRFs=OE8T=O9208B9HP_oo8RZpyVOZ9AJ54pAA@mail.gmail.com/ >>>> >>>> Cc: <stable@vger.kernel.org> # 5.8 >>>> Cc: Bastien Nocera <hadess@hadess.net> >>>> Cc: Valentina Manea <valentina.manea.m@gmail.com> >>>> Cc: Shuah Khan <shuah@kernel.org> >>>> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> >>>> Cc: Alan Stern <stern@rowland.harvard.edu> >>>> Cc: <syzkaller@googlegroups.com> >>>> Signed-off-by: M. Vefa Bicakci <m.v.b@runbox.com> >>>> --- >>>> drivers/usb/usbip/stub_dev.c | 15 ++++++++++++++- >>>> 1 file changed, 14 insertions(+), 1 deletion(-) >>>> >>>> diff --git a/drivers/usb/usbip/stub_dev.c >>>> b/drivers/usb/usbip/stub_dev.c >>>> index 9d7d642022d1..3d9c8ff6762e 100644 >>>> --- a/drivers/usb/usbip/stub_dev.c >>>> +++ b/drivers/usb/usbip/stub_dev.c >>>> @@ -463,7 +463,20 @@ static void stub_disconnect(struct usb_device >>>> *udev) >>>> static bool usbip_match(struct usb_device *udev) >>>> { >>>> - return true; >>>> + bool match; >>>> + struct bus_id_priv *busid_priv; >>>> + const char *udev_busid = dev_name(&udev->dev); >>>> + >>>> + busid_priv = get_busid_priv(udev_busid); >>>> + if (!busid_priv) >>>> + return false; >>>> + >>>> + match = (busid_priv->status != STUB_BUSID_REMOV && >>>> + busid_priv->status != STUB_BUSID_OTHER); >>>> + >>>> + put_busid_priv(busid_priv); >>>> + >>>> + return match; >>>> } >>>> #ifdef CONFIG_PM >>>> >>> >>> Did you happen to run the usbip test on this patch? If not, can you >>> please run tools/testing/selftests/drivers/usb/usbip/usbip_test.sh >>> and make sure there are no regressions. >> >> Ah, this is a very good point! I have been testing the patches on >> Qubes OS, >> which uses usbip to forward USB devices between VMs. To be honest, I >> was not >> aware of the self-tests for usbip, and I will run the self-tests prior to >> publishing the next version of the patch series. > > Hello Shuah, > > I have just cleaned up the patches and run usbip_test.sh with a kernel > without > the patches in this series and with a kernel in this series. > > I noticed that there is a change in behaviour due to the fact that the new > match function (usbip_match) does not always return true. This causes the > stub device driver's probe() function to not get called at all, as the new > more selective match function will prevent the stub device driver from > being > considered as a potential driver for the device under consideration. > Yes. This is the behavior I am concerned about and hence the reason to use the usbip test to verify this doesn't happen. With the patch you have the usbip match behavior becomes restrictive which isn't desirable. > All of this results in the following difference in the logs of the > usbip_test.sh, > where the expected kernel log message "usbip-host 2-6: 2-6 is not in > match_busid table... skip!" > is not printed by a kernel that includes the patches in this series. > > --- unpatched_kernel_log.txt 2020-09-18 17:12:10.654000000 +0300 > +++ patched_kernel_log.txt 2020-09-18 17:12:10.654000000 +0300 > @@ -213,70 +213,69 @@ > |__ Port 1: Dev 2, If 0, Class=Human Interface Device, > Driver=usbhid, 480M > ============================================================== > modprobe usbip_host - does it work? > Should see -busid- is not in match_busid table... skip! dmesg > ============================================================== > -usbip-host 2-6: 2-6 is not in match_busid table... skip! > ============================================================== > > Do you find this change in behaviour unacceptable? Yeah. This behavior isn't acceptable. If no, I can remove this > test case from usbip_test.sh with the same patch. If yes, then there is > a need > for a different solution to resolve the unexpected negative interaction > between > Bastien's work on generic/specific USB device driver selection and usbip > functionality. > I would recommend finding a different solution. Now that you have the usbip test handy, you can verify and test for regressions. thanks, -- Shuah
On 18/09/2020 18.49, Shuah Khan wrote: > On 9/18/20 8:31 AM, M. Vefa Bicakci wrote: >> Hello Shuah, >> >> I have just cleaned up the patches and run usbip_test.sh with a kernel without >> the patches in this series and with a kernel in this series. >> >> I noticed that there is a change in behaviour due to the fact that the new >> match function (usbip_match) does not always return true. This causes the >> stub device driver's probe() function to not get called at all, as the new >> more selective match function will prevent the stub device driver from being >> considered as a potential driver for the device under consideration. >> > > Yes. This is the behavior I am concerned about and hence the reason > to use the usbip test to verify this doesn't happen. > > With the patch you have the usbip match behavior becomes restrictive > which isn't desirable. > >> All of this results in the following difference in the logs of the usbip_test.sh, >> where the expected kernel log message "usbip-host 2-6: 2-6 is not in match_busid table... skip!" >> is not printed by a kernel that includes the patches in this series. >> >> --- unpatched_kernel_log.txt 2020-09-18 17:12:10.654000000 +0300 >> +++ patched_kernel_log.txt 2020-09-18 17:12:10.654000000 +0300 >> @@ -213,70 +213,69 @@ >> |__ Port 1: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 480M >> ============================================================== >> modprobe usbip_host - does it work? >> Should see -busid- is not in match_busid table... skip! dmesg >> ============================================================== >> -usbip-host 2-6: 2-6 is not in match_busid table... skip! >> ============================================================== >> >> Do you find this change in behaviour unacceptable? > > Yeah. This behavior isn't acceptable. > > If no, I can remove this >> test case from usbip_test.sh with the same patch. If yes, then there is a need >> for a different solution to resolve the unexpected negative interaction between >> Bastien's work on generic/specific USB device driver selection and usbip >> functionality. >> > > I would recommend finding a different solution. Now that you have the > usbip test handy, you can verify and test for regressions. > > thanks, > -- Shuah Thanks for the feedback, Shuah. I spent some time looking at and instrumenting the code in an attempt to find another solution, but have not found one. If the generic/specific USB driver selection functionality that Bastien Nocera introduced is desired to stay in the kernel, then making usbip_match more specific appears to be the only option for usbip to be functional without negatively affecting other device drivers. Should Bastien's work be reverted until a solution to this issue is found? Would you (or anyone) have any suggestions? I would be happy to work further on resolving this issue. I am including a summary of my findings below my signature. Thank you, Vefa === === === (1) If usbip_match stays as is, then the issue reported by Andrey Konovalov at https://lore.kernel.org/linux-usb/CAAeHK+zOrHnxjRFs=OE8T=O9208B9HP_oo8RZpyVOZ9AJ54pAA@mail.gmail.com/ will remain unresolved and will trickle down to Linux 5.9 due to the following commit's interaction with the return-true usbip_match function: USB: Simplify USB ID table match https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=master&id=0ed9498f9ecfde50c93f3f3dd64b4cd5414d9944 This commit was mis-classified as a simplification rather than a bug-fix and was not backported to linux-5.8.y. (I can explain my reasoning if beneficial.) After cherry-picking this commit onto 5.8.10, I can reproduce Andrey's issue with Andrey's "keyboard" program at: https://github.com/xairy/raw-gadget.git (2) If the following patches are also included in the kernel to fix two bugs in the USB driver selection logic, then a return-true usbip_match function will cause usbip's stub driver to be selected as the more specific device driver for all USB devices when the usbip_host module is loaded. (This makes all USB devices unavailable on my system, until I unload usbip_host and reload {x,e}hci-pci modules.) usbcore/driver: Fix specific driver selection https://marc.info/?l=linux-usb&m=160037262607960&q=mbox usbcore/driver: Fix incorrect downcast https://lore.kernel.org/linux-usb/20200917144151.355848-2-m.v.b@runbox.com/ I realize that this impact statement does not match my previous description at https://lore.kernel.org/linux-usb/363eab9a-c32a-4c60-4d6b-14ae8d873c52@runbox.com/ which was because I had forgotten to cherry pick 0ed9498f9e ("USB: Simplify USB ID table match"; i.e., the commit discussed in the previous bullet point) onto my v5.8.10-based test kernel.
On 19/09/2020 16.54, M. Vefa Bicakci wrote: > On 18/09/2020 18.49, Shuah Khan wrote: >> On 9/18/20 8:31 AM, M. Vefa Bicakci wrote: >>> Hello Shuah, >>> >>> I have just cleaned up the patches and run usbip_test.sh with a kernel without >>> the patches in this series and with a kernel in this series. >>> >>> I noticed that there is a change in behaviour due to the fact that the new >>> match function (usbip_match) does not always return true. This causes the >>> stub device driver's probe() function to not get called at all, as the new >>> more selective match function will prevent the stub device driver from being >>> considered as a potential driver for the device under consideration. >>> >> >> Yes. This is the behavior I am concerned about and hence the reason >> to use the usbip test to verify this doesn't happen. >> >> With the patch you have the usbip match behavior becomes restrictive >> which isn't desirable. >> >>> All of this results in the following difference in the logs of the usbip_test.sh, >>> where the expected kernel log message "usbip-host 2-6: 2-6 is not in match_busid table... skip!" >>> is not printed by a kernel that includes the patches in this series. >>> >>> --- unpatched_kernel_log.txt 2020-09-18 17:12:10.654000000 +0300 >>> +++ patched_kernel_log.txt 2020-09-18 17:12:10.654000000 +0300 >>> @@ -213,70 +213,69 @@ >>> |__ Port 1: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 480M >>> ============================================================== >>> modprobe usbip_host - does it work? >>> Should see -busid- is not in match_busid table... skip! dmesg >>> ============================================================== >>> -usbip-host 2-6: 2-6 is not in match_busid table... skip! >>> ============================================================== >>> >>> Do you find this change in behaviour unacceptable? >> >> Yeah. This behavior isn't acceptable. >> >> If no, I can remove this >>> test case from usbip_test.sh with the same patch. If yes, then there is a need >>> for a different solution to resolve the unexpected negative interaction between >>> Bastien's work on generic/specific USB device driver selection and usbip >>> functionality. >>> >> >> I would recommend finding a different solution. Now that you have the >> usbip test handy, you can verify and test for regressions. >> >> thanks, >> -- Shuah > > Thanks for the feedback, Shuah. I spent some time looking at and instrumenting > the code in an attempt to find another solution, but have not found one. > > If the generic/specific USB driver selection functionality that Bastien Nocera > introduced is desired to stay in the kernel, then making usbip_match more > specific appears to be the only option for usbip to be functional without > negatively affecting other device drivers. > > Should Bastien's work be reverted until a solution to this issue is found? > Would you (or anyone) have any suggestions? I would be happy to work further > on resolving this issue. Hello again, Status update: I found a solution that should be more acceptable. It involves some changes to the generic/specialized driver selection code and the removal of usbip_match altogether, while preserving proper behaviour of the usbip driver, apple-mfi-fastcharge and dummy_hcd. I intend to publish a new patch set by tomorrow. Vefa
diff --git a/drivers/usb/usbip/stub_dev.c b/drivers/usb/usbip/stub_dev.c index 9d7d642022d1..3d9c8ff6762e 100644 --- a/drivers/usb/usbip/stub_dev.c +++ b/drivers/usb/usbip/stub_dev.c @@ -463,7 +463,20 @@ static void stub_disconnect(struct usb_device *udev) static bool usbip_match(struct usb_device *udev) { - return true; + bool match; + struct bus_id_priv *busid_priv; + const char *udev_busid = dev_name(&udev->dev); + + busid_priv = get_busid_priv(udev_busid); + if (!busid_priv) + return false; + + match = (busid_priv->status != STUB_BUSID_REMOV && + busid_priv->status != STUB_BUSID_OTHER); + + put_busid_priv(busid_priv); + + return match; } #ifdef CONFIG_PM
Prior to this commit, the USB-IP subsystem's USB device driver match function used to match all USB devices (by returning true unconditionally). Unfortunately, this is not correct behaviour and is likely the root cause of the bug reported by Andrey Konovalov. USB-IP should only match USB devices that the user-space asked the kernel to handle via USB-IP, by writing to the match_busid sysfs file, which is what this commit aims to achieve. This is done by making the match function check that the passed in USB device was indeed requested by the user-space to be handled by USB-IP. Reported-by: Andrey Konovalov <andreyknvl@google.com> Fixes: 7a2f2974f2 ("usbip: Implement a match function to fix usbip") Link: https://lore.kernel.org/linux-usb/CAAeHK+zOrHnxjRFs=OE8T=O9208B9HP_oo8RZpyVOZ9AJ54pAA@mail.gmail.com/ Cc: <stable@vger.kernel.org> # 5.8 Cc: Bastien Nocera <hadess@hadess.net> Cc: Valentina Manea <valentina.manea.m@gmail.com> Cc: Shuah Khan <shuah@kernel.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Alan Stern <stern@rowland.harvard.edu> Cc: <syzkaller@googlegroups.com> Signed-off-by: M. Vefa Bicakci <m.v.b@runbox.com> --- drivers/usb/usbip/stub_dev.c | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-)