From: Johan Hovold <johan@kernel.org>
To: Takashi Iwai <tiwai@suse.de>
Cc: Johan Hovold <johan@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Alan Stern <stern@rowland.harvard.edu>,
Andrey Konovalov <andreyknvl@google.com>,
alsa-devel@alsa-project.org,
Arvind Yadav <arvind.yadav.cs@gmail.com>,
Jaroslav Kysela <perex@perex.cz>,
Takashi Sakamoto <o-takashi@sakamocchi.jp>,
LKML <linux-kernel@vger.kernel.org>,
Dmitry Vyukov <dvyukov@google.com>,
Kostya Serebryany <kcc@google.com>,
syzkaller <syzkaller@googlegroups.com>,
linux-usb@vger.kernel.org
Subject: Re: usb/sound/bcd2000: warning in bcd2000_init_device
Date: Wed, 4 Oct 2017 12:23:11 +0200 [thread overview]
Message-ID: <20171004102311.GG3404@localhost> (raw)
In-Reply-To: <s5ha8171b6x.wl-tiwai@suse.de>
On Wed, Oct 04, 2017 at 12:04:06PM +0200, Takashi Iwai wrote:
> On Wed, 04 Oct 2017 11:24:42 +0200, Johan Hovold wrote:
> > On Wed, Oct 04, 2017 at 08:10:59AM +0200, Takashi Iwai wrote:
> > > Well, what I had in my mind is just a snippet from usb_submit_urb(),
> > > something like:
> > >
> > > bool usb_sanity_check_urb_pipe(struct urb *urb)
> > > {
> > > struct usb_host_endpoint *ep;
> > > int xfertype;
> > > static const int pipetypes[4] = {
> > > PIPE_CONTROL, PIPE_ISOCHRONOUS, PIPE_BULK, PIPE_INTERRUPT
> > > };
> > >
> > > ep = usb_pipe_endpoint(urb->dev, urb->pipe);
> > > xfertype = usb_endpoint_type(&ep->desc);
> > > return usb_pipetype(urb->pipe) != pipetypes[xfertype];
> > > }
> > >
> > > And calling this before usb_submit_urb() in each place that assigns
> > > the fixed EP as device-specific quirks.
> > > Does it make sense?
> >
> > Not really. Your driver should not even bind to an interface which lacks
> > the expected endpoints (rather than check this at a potentially later
> > point in time when URBs are submitted).
>
> The endpoint may exist but it may be invalid, as the problem is
> triggered by a VM. It doesn't parse but tries a fixed EP as it's no
> compliant device.
Yes, that's why a driver should verify that the endpoints it expects are
indeed present (and of the right type) already at probe.
In Andrey's fuzzing it's triggered by in a VM using the dummy_hcd
driver, but this could just as well be a (malicious) physical device
with unexpected descriptors.
> > The new helper which Greg mentioned would allow this to implemented with
> > just a few lines of code. Just add it to bcd2000_init_midi() or similar.
>
> Could you give an example? Then I can ask Andrey whether such a call
> really addresses the issue.
If you grep for usb_find_common_endpoints you'll find a few examples
of how that function may be used (e.g. in drivers/usb/misc/usblcd.c).
The helper iterates of the endpoint descriptors of an interface
alt-setting and returns a descriptor for each requested type if found.
After a vetting of our current drivers I concluded that this would
cover the needs of the vast majority of drivers.
So for the driver in question you'd only need to add something like:
struct usb_endpoint_descriptor *int_in, *int_out;
int ret;
ret = usb_find_common_endpoints(interface->cur_altsetting,
NULL, NULL, &int_in, &int_out);
if (ret) {
dev_err(&interface->dev, "required endpoints not found\n");
return -ENODEV;
}
Then you can use int_in->bEndpointAddress etc. when initialising your
URBs.
Johan
next prev parent reply other threads:[~2017-10-04 10:23 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-25 12:39 usb/sound/bcd2000: warning in bcd2000_init_device Andrey Konovalov
2017-10-03 7:52 ` Takashi Iwai
2017-10-03 7:52 ` Takashi Iwai
2017-10-03 14:21 ` Alan Stern
2017-10-03 14:21 ` Alan Stern
2017-10-03 15:48 ` Takashi Iwai
2017-10-03 15:48 ` Takashi Iwai
2017-10-03 16:50 ` Alan Stern
2017-10-03 16:50 ` Alan Stern
2017-10-03 17:42 ` Greg Kroah-Hartman
2017-10-04 6:10 ` Takashi Iwai
2017-10-04 7:52 ` Greg Kroah-Hartman
2017-10-04 8:08 ` Takashi Iwai
2017-10-04 8:08 ` Takashi Iwai
[not found] ` <s5htvzftjwn.wl-tiwai-l3A5Bk7waGM@public.gmane.org>
2017-10-04 8:26 ` Greg Kroah-Hartman
2017-10-04 8:26 ` Greg Kroah-Hartman
2017-10-04 9:24 ` Johan Hovold
2017-10-04 10:04 ` Takashi Iwai
2017-10-04 10:04 ` Takashi Iwai
2017-10-04 10:23 ` Johan Hovold [this message]
2017-10-04 10:41 ` Takashi Iwai
2017-10-04 10:41 ` Takashi Iwai
2017-10-04 12:03 ` Johan Hovold
2017-10-04 13:02 ` Takashi Iwai
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=20171004102311.GG3404@localhost \
--to=johan@kernel.org \
--cc=alsa-devel@alsa-project.org \
--cc=andreyknvl@google.com \
--cc=arvind.yadav.cs@gmail.com \
--cc=dvyukov@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=kcc@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=o-takashi@sakamocchi.jp \
--cc=perex@perex.cz \
--cc=stern@rowland.harvard.edu \
--cc=syzkaller@googlegroups.com \
--cc=tiwai@suse.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.