Linux USB
 help / color / mirror / Atom feed
From: "M. Vefa Bicakci" <m.v.b@runbox.com>
To: Bastien Nocera <hadess@hadess.net>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Andrey Konovalov <andreyknvl@google.com>
Cc: Alan Stern <stern@rowland.harvard.edu>,
	syzkaller <syzkaller@googlegroups.com>,
	USB list <linux-usb@vger.kernel.org>,
	Dmitry Vyukov <dvyukov@google.com>
Subject: Re: USB driver ID matching broken
Date: Wed, 16 Sep 2020 18:58:38 +0300	[thread overview]
Message-ID: <359d080c-5cbb-250a-0ebd-aaba5f5c530d@runbox.com> (raw)
In-Reply-To: <9d329243e4ed6b09afade2659e09b847e9c780fc.camel@hadess.net>

On 16/09/2020 17.39, Bastien Nocera wrote:
> On Wed, 2020-09-16 at 16:15 +0200, Greg Kroah-Hartman wrote:
>> On Wed, Sep 16, 2020 at 03:33:25PM +0200, Andrey Konovalov wrote:
>>> Hi Bastien, Greg, Alan,
>>>
>>> Looks like commit adb6e6ac20ee ("USB: Also match device drivers
>>> using
>>> the ->match vfunc") broke the USB driver ID matching process. This,
>>> in
>>> turn, led to a complete breakage of the USB fuzzing instance.
>>>
>>> This is how an attempt to connect a USB device looks now:
>>>
>>> [   39.781642][   T12] usb 1-1: new high-speed USB device number 2
>>> using dummy_hcd
>>> [   40.299955][   T12] usb 1-1: New USB device found,
>>> idVendor=0cf3,
>>> idProduct=9271, bcdDevice= 1.08
>>> [   40.303072][   T12] usb 1-1: New USB device strings: Mfr=1,
>>> Product=2, SerialNumber=3
>>> [   40.305678][   T12] usb 1-1: Product: syz
>>> [   40.307041][   T12] usb 1-1: Manufacturer: syz
>>> [   40.308556][   T12] usb 1-1: SerialNumber: syz
>>> [   40.314825][   T12] usbip-host 1-1: 1-1 is not in match_busid
>>> table... skip!
>>> [   42.500114][   T51] usb 1-1: USB disconnect, device number 2
>>>
>>> It seems that when going through the list of registered IDs the
>>> code
>>> tries to match against USB/IP and succeeds as usbip_match() always
>>> returns true.
>>>
>>> I'm not sure what's the best fix for this is.
>>
>> I thought that is what the patch from Bastien was supposed to fix?
>>
>> If it didn't, we can revert it.
> 
> It wasn't. Are you thinking of "usbip: Implement a match function to
> fix usbip" by M. Vefa Bicakci (CC:ed)?
> 
> Seems to me that usbip wants to match *every* device. Wouldn't that be
> a bug in usbip?

Hello all,

I agree with Bastien; it looks like the match function that I had prepared
for the "USB-IP no longer works starting with v5.7.y" bug at [1] is not
appropriate due to the fact that the match function always returns true.

My understanding of how USB-IP works is that the user-space provides the
USB bus identifier of the device to be published via USB-IP to the kernel
via /sys/bus/usb/drivers/usbip-host/match_busid. Given that the bus
identifiers written to match_busid are stored in a table, perhaps this
table can be queried in the usbip_match function to avoid the issue
reported by Andrey while preserving USB-IP's functionality?

If needed, I can prepare a patch implementing this proposal, perhaps after
commit 7a2f2974 ("usbip: Implement a match function to fix usbip") is
reverted. The only catch is that my bandwidth is a bit limited, hence it
may take some time for me to publish a patch.

Sorry for this unexpected bug,

Vefa

[1] https://bugzilla.kernel.org/show_bug.cgi?id=208267

  reply	other threads:[~2020-09-16 20:24 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-16 13:33 USB driver ID matching broken Andrey Konovalov
2020-09-16 14:15 ` Greg Kroah-Hartman
2020-09-16 14:39   ` Bastien Nocera
2020-09-16 15:58     ` M. Vefa Bicakci [this message]
2020-09-17  9:59       ` [PATCH 1/2] usbcore/driver: Fix specific driver selection M. Vefa Bicakci
2020-09-17  9:59         ` [PATCH 2/2] usbip: Make the driver's match function specific M. Vefa Bicakci
2020-09-17 10:23         ` [PATCH 1/2] usbcore/driver: Fix specific driver selection Bastien Nocera
2020-09-17 10:39           ` M. Vefa Bicakci
2020-09-17 10:49             ` Bastien Nocera
2020-09-17 14:41               ` [PATCH 1/3] " M. Vefa Bicakci
2020-09-17 14:41                 ` [PATCH 2/3] usbcore/driver: Fix incorrect downcast M. Vefa Bicakci
2020-09-17 15:01                   ` Alan Stern
2020-09-18  9:26                     ` M. Vefa Bicakci
2020-09-17 14:41                 ` [PATCH 3/3] usbip: Make the driver's match function specific M. Vefa Bicakci
2020-09-17 15:21                   ` Shuah Khan
2020-09-18  9:26                     ` M. Vefa Bicakci
2020-09-18 14:31                       ` M. Vefa Bicakci
2020-09-18 15:49                         ` Shuah Khan
2020-09-19 13:54                           ` M. Vefa Bicakci
2020-09-21 17:03                             ` M. Vefa Bicakci
2020-09-18 14:31                 ` [PATCH 1/3] usbcore/driver: Fix specific driver selection M. Vefa Bicakci
2020-09-18 14:52                   ` Alan Stern
2020-09-19 13:52                     ` M. Vefa Bicakci

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=359d080c-5cbb-250a-0ebd-aaba5f5c530d@runbox.com \
    --to=m.v.b@runbox.com \
    --cc=andreyknvl@google.com \
    --cc=dvyukov@google.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hadess@hadess.net \
    --cc=linux-usb@vger.kernel.org \
    --cc=stern@rowland.harvard.edu \
    --cc=syzkaller@googlegroups.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox