Re: A few questions about gadgetfs

[Andrey Konovalov]

Hi Alan,

Another question. According to the USB spec:

"""
The Data stage of a control transfer from an endpoint to the host is
complete when the endpoint does one of the following:
* Has transferred exactly the amount of data specified during the Setup stage
* Transfers a packet with a payload size less than wMaxPacketSize or
transfers a zero-length packet
"""

AFAIU, this means that a device only needs to send a zero-length
packet when the last data packet happened to be equal to
wMaxPacketSize to indicate that the data stage is over. Gadgetfs seems
to be doing something different, it sets the req->zero flag (for the
response passed to usb_ep_queue) when value < w_length, where value is
the length of the response being submitted and w_length is the value
of the wLength field of the control request. Is there something I
misunderstand?

Thanks!

Re: A few questions about gadgetfs

[Andrey Konovalov]

On Fri, Aug 31, 2018 at 4:34 PM, Alan Stern  wrote:
> On Fri, 31 Aug 2018, Andrey Konovalov wrote:

[...]

>> Yes, I understand this. The idea is to stall/wait until the userspace
>> provides a response. Like gadgetfs, but for every USB request.
>
> If all you want to do is wait, STALL is not the appropriate strategy.
> Instead the device should send NAK packets to the host.
>
> STALL means "I can't process that request, because it is erroneous or I
> don't understand it".  NAK means "I'm not yet ready to reply; try
> again later".

[...]

>> Is there a way to tell the UDC to not send the STALL packet, but to
>> just wait? Assuming the userspace will read the request and provide a
>> response within the timeout (50ms? [1]). Would this approach be
>> supported by more hosts than sending STALLs?
>>
>> [1] https://www.beyondlogic.org/usbnutshell/usb6.shtml
>
> Sure.  Just don't submit any response.  With no data in its FIFO, the
> UDC will respond with NAK packets.

Perfect, that's what I need, thanks a lot!

Re: A few questions about gadgetfs

[Andrey Konovalov]

On Thu, Aug 30, 2018 at 10:50 PM, Alan Stern  wrote:
> On Thu, 30 Aug 2018, Andrey Konovalov wrote:
>
>> Hi Alan,
>>
>> I have a few questions about gadgetfs.
>>
>> According to documentation usb_gadget_driver->setup "queues a response
>> to ep0, or returns negative to stall".
>>
>> Do I understand correctly, that "stall" in this case means "retry the
>> same request later" and it's unrelated to the STALL USB packet?
>
> No; it _is_ related to USB STALL packets.  In fact, it means "send a
> STALL packet back to the host".

OK, understood. I read the part of the USB spec about this (functional
and protocol stalls).

>
>> Is it OK to stall the initial control requests (the one that requests
>> the device descriptor for example)?
>
> Well, the USB spec allows a device to do this.  However, a device that
> always returns STALL for a Get-Device-Descriptor request will not be
> usable for anything, since the host will not be able to enumerate it.

Yes, I understand this. The idea is to stall/wait until the userspace
provides a response. Like gadgetfs, but for every USB request.

>
> The Linux USB stack will try such requests up to three times.  And
> there are retry loops at higher layers in the code too, so it can take
> quite a while before the stack finally gives up.
>
>> What exactly happens when we stall between the gadget and the host?
>> Does the UDC driver/hardware see that we don't have a response yet and
>> waits? Or does it somehow communicate that stall to the host?
>
> It sends a STALL packet to the host.

Is there a way to tell the UDC to not send the STALL packet, but to
just wait? Assuming the userspace will read the request and provide a
response within the timeout (50ms? [1]). Would this approach be
supported by more hosts than sending STALLs?

[1] https://www.beyondlogic.org/usbnutshell/usb6.shtml

>
>> Does it make any difference whether we stall or reply right away from
>> the host point of view?
>
> It depends on how the host-side code is written.  Some code will retry
> STALLed requests a few times, and some code will fail right away.

So the USB spec doesn't specify how the host should react to these
protocol STALL packets, but some USB hosts (e.g. Linux) just resend
the request? I assume that other popular hosts (Windows, MacOS, etc.)
do that as well, otherwise gadgetfs wouldn't be usable to emulate USB
devices for them.

Although while searching info about this I found an article [2], which
states: "The EFM8 HID device sends a STALL handshake in response to
the get DEVICE_QUALIFIER descriptor request because the EFM8 HID
device does not support the certain request. After that, the USB host
will issue the next SETUP transaction". So the host skips the request
and goes to the next one instead of rerequesting.

[2] 
https://www.silabs.com/community/mcu/8-bit/knowledge-base.entry.html/2017/06/18/the_role_of_stallha-pQTe

Do you know of any particular hosts that fail right away when they
receive a protocol STALL?

>
>> The questions arose when I started implementing a gadgetfs like
>> interface, that allows to respond to every USB packet (including the
>> initial control requests) from a userspace app.
>>
>> Thanks!
>
> You're welcome.
>
> Alan Stern
>

A few questions about gadgetfs

[Andrey Konovalov]

Hi Alan,

I have a few questions about gadgetfs.

According to documentation usb_gadget_driver->setup "queues a response
to ep0, or returns negative to stall".

Do I understand correctly, that "stall" in this case means "retry the
same request later" and it's unrelated to the STALL USB packet?

Is it OK to stall the initial control requests (the one that requests
the device descriptor for example)?

What exactly happens when we stall between the gadget and the host?
Does the UDC driver/hardware see that we don't have a response yet and
waits? Or does it somehow communicate that stall to the host?

Does it make any difference whether we stall or reply right away from
the host point of view?

The questions arose when I started implementing a gadgetfs like
interface, that allows to respond to every USB packet (including the
initial control requests) from a userspace app.

Thanks!

Re: External USB fuzzing

[Andrey Konovalov]

On Tue, Jun 5, 2018 at 10:06 PM, Alan Stern  wrote:
> On Tue, 5 Jun 2018, Andrey Konovalov wrote:

[...]

> What do you need that's different from what gadgetfs provides?

1. It does some sanity checks on the provided USB descriptors, which
we don't really want, since providing improper descriptors is a way to
find bugs.

2. Replies to some USB requests without asking the user. Same thing,
giving the user (== syzkaller) to reply something improper can trigger
some bugs.

3. File based interface is somewhat inconvenient for integration with syzkaller.

(4. Doesn't support SuperSpeed and doesn't support multiple UDC
devices. This can be fixed of course. )

Basically what (I think) I want is an ioctl-based GadgetFS-like
interface, that doesn't implement any USB protocol logic, but simply
passes all received requests to the user and asks for replies.

[...]

>> Could you elaborate on this? AFAIU the dummy device contains both a
>> virtual UDC and a virtual HCD that are connected to each other and
>> allow to plug a gadget device into usb core within the kernel. How do
>> you test a driver for an actual host controller? Is there a way to
>> connect a dummy UDC with an actual HCD?
>
> You can't connect a dummy UDC to an actual HCD.  But you can connect an
> actual UDC to an actual HCD -- people do it all the time.
>
> Normally the UDC and the HCD reside on separate computers.  For
> example, mobile devices typically have UDCs, and you can connect them
> to PCs.  But there is also UDC hardware available for Linux on Intel
> systems, so you can have the UDC and the HCD in the same computer if
> that's what you want.  Or two separate PCs, both running Linux.  Or
> even a Linux PC gadget connected to a Windows or OS X host!

I see, but that all requires real hardware, right? You can't just run
it in a VM (that's what I'm planning to do with dummy_hcd)?

[...]

> Right.  For example, usb-storage uses a work-queue routine for SCSI
> scanning when a new device is probed.  And in that routine, the SCSI
> layer often delegates some of the scanning work to async helper
> threads, depending on the how the system is configured.

Could you point me to the code that does that? I mean SCSI scanning.

[...]

>> 2. All the virtual UDCs get the same name "dummy_udc". And since the
>> process of UDC lookup to bind a gadget driver is based on the UDC name
>> (see usb_gadget_probe_driver()), we can't bind different gadget
>> drivers to different UDCs (and therefore connect to different hubs).
>
> That can be changed pretty easily.  For virtual UDCs beyond the first,
> we could append "-2", "-3", and so on to the "dummy_udc" name, for
> example.

I wrote a patch to implement this and then realized that it's actually
not needed. Even though all UDC devices have the same name
"dummy_udc", it seems they are actually renamed by someone and end up
getting names "dummy_udc.0", "dummy_udc.1" and so on (that'w what I
see when I add printk to usb_gadget_probe_driver()).

What initially confused me was that gadgetfs always binds to the same
UDC, but that's because it doesn't set the udc_name field of the
usb_gadget_driver struct (and also because it always expects the UDC
name to be the one returned by usb_get_gadget_udc_name(), but that
part I patched when I was trying to bind it to some other UDC).

Thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: External USB fuzzing

[Andrey Konovalov]

On Mon, Jun 4, 2018 at 9:37 PM, Alan Stern  wrote:
> On Mon, 4 Jun 2018, Andrey Konovalov wrote:

Hi, Alan!

[...]

>> The perfect solution would be to have something like /dev/tun for USB,
>> where you can write USB packets and the kernel would synchronously
>> process them. I'm not sure whether this is possible (highly
>> asynchronous USB core subsystem architecture + all communication is
>> initiated by the host).
>
> gadgetfs is a little like that already, except of course that the
> processing is not synchronous.

Yes, I started with GadgetFS initially, but actually ended up writing
my own interface that provides userspace interface to the gadget API
instead. Once I figure out what exactly I need from it, it might be a
good idea to merge it with GadgetFS as some special mode. Or not, not
sure yet.

>
> Another aspect of this would be fuzzing USB host controller drivers.
> In theory you could start doing this now, although you would have to
> use a real UDC instead of dummy-hcd.  However, this may create more
> complications that you want to deal with at the moment.

Could you elaborate on this? AFAIU the dummy device contains both a
virtual UDC and a virtual HCD that are connected to each other and
allow to plug a gadget device into usb core within the kernel. How do
you test a driver for an actual host controller? Is there a way to
connect a dummy UDC with an actual HCD?

>
>> Another thing we could do is to teach kcov to collect coverage from
>> arbitrary kernel threads. In this case we could collect coverage from
>> the thread that processes the USB events.
>
> That seems like a more general solution, something which could be
> applied to other settings too.  One difficulty you would face is
> telling the tool which threads to work on.  This is particularly tricky
> when dealing with work queues, since a single work-queue thread can run
> code for many different drivers and purposes.
>
> Perhaps it would be better to collect coverage information based on the
> location of the code being executed rather than the thread ID.

Yes, that is what I was thinking about. I have a prototype patch for
kcov that allows to annotate a block of the kernel code and collect
coverage from that block. I think this is the way I'll try to move
forward with.

>
>>  However we would still need
>> some signal to understand whether the device finished initialization,
>> etc. (with the first approach we could tell that some stage of device
>> initialization is finished by seeing that hub_event() returned).
>
> Why initialization particularly?  A device goes through a number of
> stages in its life cycle.
>
> I get the impression you would like to have a mechanism whereby you can
> send messages from arbitrary places in the kernel to your testing
> process.  A little like the function tracer or perf, perhaps.

Yes, we need to see all the stages, initialization was just an example.

The main question is: suppose we started a test program that emulates
a virtual USB device. How do we know that the test is over? Once all
the hub events are processed we can tell that the device is probably
either connected successfully or failed to connect. But then the
device driver can start it's own thread for example or register a
timer that does more work with the device. There are probably some
ways to tell what the device driver does at this moment for some
standard USB classes.

I guess I'll start with a timeout for now, until I figure out how to
properly collect coverage.

[...]

>> 2. A way to isolate independent test programs.
>>
>> Right now CONFIG_USB_DUMMY_HCD creates one global hub to which all
>> emulated USB devices connect. Would it be possible to create one
>> virtual hub per test (or at least one per test process) by say calling
>> some ioctl? What changes would that require?
>
> Are you planning to run multiple test processes concurrently?  If you
> aren't then this isn't an issue.

Yes, I believe that would increase fuzzing speed.

>
> In fact, dummy-hcd is capable of creating more than one virtual root
> hub (see the "num" module parameter), so in theory you could run
> multiple tests at the same time.  I don't think this capability has
> been tested very much.

OK, that's nice. I just tried it and it kind of works, but there are two issues:

1. There's a hardcoded limit on the maximum number of virtual UDCs
(#define MAX_NUM_UDC 2). Increasing this parameters seems to work just
fine.

2. All the virtual UDCs get the same name "dummy_udc". And since the
process of UDC lookup to bind a gadget driver is based on the UDC name
(see usb_gadget_probe_driver()), we can't bind different gadget
drivers to different UDCs (and therefore connect to different hubs).

>
>> Basically we need a way t

External USB fuzzing

[Andrey Konovalov]

Hi Greg and Alan!

As you might know I've been working on adding external USB fuzzing
support to syzkaller.

At this point a have a prototype, which is able to emulate USB devices
from userspace via a custom written userspace interface for the gadget
subsystem and CONFIG_USB_DUMMY_HCD. The patches and some details are
here [1].

This is just a prototype and there are a few things we need to support
USB fuzzing properly.

1. A way to collect coverage from USB code.

Syzkaller uses kcov (CONFIG_KCOV) to collect coverage from the kernel.
The issue is that kcov collects coverage in a process context (from
the kernel task that corresponds to the userspace process that created
the kcov device). But AFAIU USB uses a kernel worker to process USB
hub events.

The approach I tried to deal with this is to change hub_event() to put
events into a global queue and wait instead of processing them right
away. Then I added an ioctl to the hub device that takes an event from
the queue and processes it the same way hub_event() used to. This
results in USB events being processed in a process context. The patch
is here [2].

Is there a less hacky way to make processing USB events synchronously
(by an ioctl call from userspace for example), if that's feasible at
all?

The perfect solution would be to have something like /dev/tun for USB,
where you can write USB packets and the kernel would synchronously
process them. I'm not sure whether this is possible (highly
asynchronous USB core subsystem architecture + all communication is
initiated by the host).

Another thing we could do is to teach kcov to collect coverage from
arbitrary kernel threads. In this case we could collect coverage from
the thread that processes the USB events. However we would still need
some signal to understand whether the device finished initialization,
etc. (with the first approach we could tell that some stage of device
initialization is finished by seeing that hub_event() returned).

There's another issue with getting coverage after USB device has been
initialized. For example some device drivers create new threads that
communicate with that device. I don't see an easy way to collect
coverage from those threads.

2. A way to isolate independent test programs.

Right now CONFIG_USB_DUMMY_HCD creates one global hub to which all
emulated USB devices connect. Would it be possible to create one
virtual hub per test (or at least one per test process) by say calling
some ioctl? What changes would that require?

Basically we need a way to run a test program (that connects a USB
device and works with it from userspace for example) and then destroy
all the accumulated state before running the next test.

Thanks!

[1] 
https://github.com/google/syzkaller/blob/usb-fuzzer/docs/linux/external_fuzzing_usb.md

[2] 
https://github.com/google/syzkaller/blob/usb-fuzzer/tools/usb/0001-usb-fuzzer-add-hub-hijacking-ioctl.patch
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] USB: core: only clean up what we allocated

[Andrey Konovalov]

On Tue, Dec 12, 2017 at 5:12 PM, Alan Stern <st...@rowland.harvard.edu> wrote:
> On Tue, 12 Dec 2017, Andrey Konovalov wrote:
>
>> On Tue, Dec 12, 2017 at 4:41 PM, Alan Stern <st...@rowland.harvard.edu> 
>> wrote:
>> > On Mon, 11 Dec 2017, Greg KH wrote:
>> >
>> >> From: Andrey Konovalov <andreyk...@google.com>
>> >>
>> >> When cleaning up the configurations, make sure we only free the number
>> >> of configurations and interfaces that we could have allocated.
>> >>
>> >> Reported-by: Andrey Konovalov <andreyk...@google.com>
>> >> Cc: stable <sta...@vger.kernel.org>
>> >> Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
>> >>
>> >> diff --git a/drivers/usb/core/config.c b/drivers/usb/core/config.c
>> >> index 55b198ba629b..93b38471754e 100644
>> >> --- a/drivers/usb/core/config.c
>> >> +++ b/drivers/usb/core/config.c
>> >> @@ -764,18 +764,21 @@ void usb_destroy_configuration(struct usb_device 
>> >> *dev)
>> >>   return;
>> >>
>> >>   if (dev->rawdescriptors) {
>> >> - for (i = 0; i < dev->descriptor.bNumConfigurations; i++)
>> >> + for (i = 0; i < dev->descriptor.bNumConfigurations &&
>> >> + i < USB_MAXCONFIG; i++)
>> >>   kfree(dev->rawdescriptors[i]);
>> >>
>> >>   kfree(dev->rawdescriptors);
>> >>   dev->rawdescriptors = NULL;
>> >>   }
>> >>
>> >> - for (c = 0; c < dev->descriptor.bNumConfigurations; c++) {
>> >> + for (c = 0; c < dev->descriptor.bNumConfigurations &&
>> >> + c < USB_MAXCONFIG; c++) {
>> >>   struct usb_host_config *cf = >config[c];
>> >>
>> >>   kfree(cf->string);
>> >> - for (i = 0; i < cf->desc.bNumInterfaces; i++) {
>> >> + for (i = 0; i < cf->desc.bNumInterfaces &&
>> >> + i < USB_MAXINTERFACES; i++) {
>> >>   if (cf->intf_cache[i])
>> >>   kref_put(>intf_cache[i]->ref,
>> >> usb_release_interface_cache);
>> >
>> > None of these changes are necessary.  The code is careful to reduce
>> > dev->descriptor.bNumConfigurations and config->desc.bNumInterfaces when
>> > necessary.
>> >
>> > In usb_get_configuration() (line 806 on my system):
>> >
>> > if (ncfg > USB_MAXCONFIG) {
>> > dev_warn(ddev, "too many configurations: %d, "
>> > "using maximum allowed: %d\n", ncfg, USB_MAXCONFIG);
>> > dev->descriptor.bNumConfigurations = ncfg = USB_MAXCONFIG;
>> > }
>> >
>> > In usb_parse_configuration() (line 676 on my system):
>> >
>> > if (n != nintf)
>> > dev_warn(ddev, "config %d has %d interface%s, different 
>> > from "
>> > "the descriptor's value: %d\n",
>> > cfgno, n, plural(n), nintf_orig);
>> > else if (n == 0)
>> > dev_warn(ddev, "config %d has no interfaces?\n", cfgno);
>> > config->desc.bNumInterfaces = nintf = n;
>>
>> usb_parse_configuration() might return before reducing
>> config->desc.bNumInterfaces, and usb_destroy_configuration() is still
>> called in this case.
>
> True.  Okay, how about this patch instead?

Looks good to me.

>
> Index: usb-4.x/drivers/usb/core/config.c
> ===
> --- usb-4.x.orig/drivers/usb/core/config.c
> +++ usb-4.x/drivers/usb/core/config.c
> @@ -555,6 +555,9 @@ static int usb_parse_configuration(struc
> unsigned iad_num = 0;
>
> memcpy(>desc, buffer, USB_DT_CONFIG_SIZE);
> +   nintf = nintf_orig = config->desc.bNumInterfaces;
> +   config->desc.bNumInterfaces = 0;// Adjusted later
> +
> if (config->desc.bDescriptorType != USB_DT_CONFIG ||
> config->desc.bLength < USB_DT_CONFIG_SIZE ||
> config->desc.bLength > size) {
> @@ -568,7 +571,6 @@ static int usb_parse_configuration(struc
> buffer += config->desc.bLength;
> size -= config->desc.bLength;
>
> -   nintf = nintf_orig = config->desc.bNumInterfaces;
> if (nintf > USB_MAXINTERFACES) {
> dev_warn(ddev, "config %d has too many interfaces: %d, "
> "using maximum allowed: %d\n",
>
> Alan Stern
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] USB: core: only clean up what we allocated

[Andrey Konovalov]

On Tue, Dec 12, 2017 at 4:41 PM, Alan Stern <st...@rowland.harvard.edu> wrote:
> On Mon, 11 Dec 2017, Greg KH wrote:
>
>> From: Andrey Konovalov <andreyk...@google.com>
>>
>> When cleaning up the configurations, make sure we only free the number
>> of configurations and interfaces that we could have allocated.
>>
>> Reported-by: Andrey Konovalov <andreyk...@google.com>
>> Cc: stable <sta...@vger.kernel.org>
>> Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
>>
>> diff --git a/drivers/usb/core/config.c b/drivers/usb/core/config.c
>> index 55b198ba629b..93b38471754e 100644
>> --- a/drivers/usb/core/config.c
>> +++ b/drivers/usb/core/config.c
>> @@ -764,18 +764,21 @@ void usb_destroy_configuration(struct usb_device *dev)
>>   return;
>>
>>   if (dev->rawdescriptors) {
>> - for (i = 0; i < dev->descriptor.bNumConfigurations; i++)
>> + for (i = 0; i < dev->descriptor.bNumConfigurations &&
>> + i < USB_MAXCONFIG; i++)
>>   kfree(dev->rawdescriptors[i]);
>>
>>   kfree(dev->rawdescriptors);
>>   dev->rawdescriptors = NULL;
>>   }
>>
>> - for (c = 0; c < dev->descriptor.bNumConfigurations; c++) {
>> + for (c = 0; c < dev->descriptor.bNumConfigurations &&
>> + c < USB_MAXCONFIG; c++) {
>>   struct usb_host_config *cf = >config[c];
>>
>>   kfree(cf->string);
>> - for (i = 0; i < cf->desc.bNumInterfaces; i++) {
>> + for (i = 0; i < cf->desc.bNumInterfaces &&
>> + i < USB_MAXINTERFACES; i++) {
>>   if (cf->intf_cache[i])
>>   kref_put(>intf_cache[i]->ref,
>> usb_release_interface_cache);
>
> None of these changes are necessary.  The code is careful to reduce
> dev->descriptor.bNumConfigurations and config->desc.bNumInterfaces when
> necessary.
>
> In usb_get_configuration() (line 806 on my system):
>
> if (ncfg > USB_MAXCONFIG) {
> dev_warn(ddev, "too many configurations: %d, "
> "using maximum allowed: %d\n", ncfg, USB_MAXCONFIG);
> dev->descriptor.bNumConfigurations = ncfg = USB_MAXCONFIG;
> }
>
> In usb_parse_configuration() (line 676 on my system):
>
> if (n != nintf)
> dev_warn(ddev, "config %d has %d interface%s, different from "
> "the descriptor's value: %d\n",
> cfgno, n, plural(n), nintf_orig);
> else if (n == 0)
> dev_warn(ddev, "config %d has no interfaces?\n", cfgno);
> config->desc.bNumInterfaces = nintf = n;

usb_parse_configuration() might return before reducing
config->desc.bNumInterfaces, and usb_destroy_configuration() is still
called in this case.

>
> Alan Stern
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: WARNING in usb_submit_urb

[Andrey Konovalov]

On Tue, Nov 7, 2017 at 6:58 PM, Alan Stern  wrote:
> On Tue, 7 Nov 2017, Greg KH wrote:
>
>> On Tue, Nov 07, 2017 at 08:11:13AM -0800, syzbot wrote:
>> > Hello,
>> >
>> > syzkaller hit the following crash on
>> > 36ef71cae353f88fd6e095e2aaa3e5953af1685d
>> > git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
>> > compiler: gcc (GCC) 7.1.1 20170620
>> > .config is attached
>> > Raw console output is attached.
>> > C reproducer is attached
>> > syzkaller reproducer is attached. See https://goo.gl/kgGztJ
>> > for information about syzkaller reproducers
>>
>> This is not a crash, you are doing a panic-on-warning, and you send
>> invalid data to the kernel and it warned about it properly and kept on
>> working :)
>>
>> Perhaps maybe not a full WARN_ON() is to be done here?
>
> I don't understand how this could have happened.  The raw log explains
> the problem:
>
>> [   15.138822] usb usb1: BOGUS urb flags, 2 --> 0
>> [   15.139498] [ cut here ]
>> [   15.139955] WARNING: CPU: 3 PID: 2986 at drivers/usb/core/urb.c:498 
>> usb_submit_urb+0xeb9/0x10f0
> ...
>> [   15.150280] RIP: 0010:usb_submit_urb+0xeb9/0x10f0
> ...
>> [   15.155166]  proc_do_submiturb+0x1f53/0x3860
>
> The "2 --> 0" means that proc_do_submiturb() tried to submit a control
> URB (2 = PIPE_CONTROL) to an isochronous endpoint (0 = PIPE_ISOCHRONOUS).
> But right near the start of the routine we have:
>
> switch (uurb->type) {
> case USBDEVFS_URB_TYPE_CONTROL:
> if (!usb_endpoint_xfer_control(>desc))
> return -EINVAL;
>
> So how was the warning triggered?

This isn't the "BOGUS urb xfer" warning, this is "BOGUS urb flags". So
2 means the URB_ISO_ASAP flag, which is passed in urb->transfer_flags
but not allowed. And as far as I understand, it gets set because uurb
(which is passed from user space) has USBDEVFS_URB_ISO_ASAP flag set
when passed to proc_do_submiturb().

>
> Alan Stern
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] net: usb: asix: fill null-ptr-deref in asix_suspend

[Andrey Konovalov]

On Mon, Nov 6, 2017 at 4:20 PM, Oliver Neukum <oneu...@suse.com> wrote:
> Am Montag, den 06.11.2017, 13:30 +0100 schrieb Andrey Konovalov:
>> On Mon, Nov 6, 2017 at 10:49 AM, Oliver Neukum <oneu...@suse.com> wrote:
>> >
>> >
>> > 2. Will a device work after that? The appropriate fix may be to wait
>> > until the device is properly initialized.
>>
>> This shouldn't affect real devices as far as I understand. The crash
>> can be caused by a crafted malicious device.
>
> Hi!
>
> Hm. That seems strange as driver_priv is kmalloced. Do you
> still have a descriptor that causes this?
> Shouldn't we rather reject such a broken device?

I do have a way to reproduce this.

As far as I understand, for this particular device ax88172_bind() is
called, which doesn't assign anything to dev->driver_priv, so that's
why it is NULL in suspend() and resume().

>
> Regards
> Oliver
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: usb/net/qmi_wwan: divide error in qmi_wwan_probe/usbnet_probe

[Andrey Konovalov]

On Mon, Nov 6, 2017 at 3:06 PM, Bjørn Mork <bj...@mork.no> wrote:
> Andrey Konovalov <andreyk...@google.com> writes:
>
>> Hi!
>>
>> I've got the following report while fuzzing the kernel with syzkaller.
>
> Thanks.  It would have helped a lot of you said *what* you were fuzzing,
> though But based on where the bug is, I assume it is USB
> descriptors?

Yes, I was connecting USB devices with random descriptors. I though
it's obvious from the stack trace, but I'll include that in the
following reports. Thanks!

>
>
>> On commit 39dae59d66acd86d1de24294bd2f343fd5e7a625 (4.14-rc8).
>>
>> qmi_wwan 1-1:0.4: cdc-wdm0: USB WDM device
>> divide error:  [#1] PREEMPT SMP KASAN
>> Modules linked in:
>> CPU: 0 PID: 24 Comm: kworker/0:1 Not tainted 4.14.0-rc8-44453-g1fdc1a82c34f 
>> #56
>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>> Workqueue: usb_hub_wq hub_event
>> task: 88006bef5c00 task.stack: 88006bf6
>> RIP: 0010:usbnet_update_max_qlen+0x24d/0x390 drivers/net/usb/usbnet.c:355
>> RSP: 0018:88006bf67508 EFLAGS: 00010246
>> RAX: 000163c8 RBX: 8800621fce40 RCX: 8800621fcf34
>> RDX:  RSI: 837ecb7a RDI: 8800621fcf34
>> RBP: 88006bf67520 R08: 88006bef5c00 R09: ed000c43f881
>> R10: ed000c43f880 R11: 8800621fc406 R12: 0003
>> R13: 85c71de0 R14:  R15: 
>> FS:  () GS:88006ca0() knlGS:
>> CS:  0010 DS:  ES:  CR0: 80050033
>> CR2: 7ffe9c0d6dac CR3: 614f4000 CR4: 06f0
>> Call Trace:
>>  usbnet_probe+0x18b5/0x2790 drivers/net/usb/usbnet.c:1783
>>  qmi_wwan_probe+0x133/0x220 drivers/net/usb/qmi_wwan.c:1338
>
> So, looking over this again and again, the only obviously risky division
> I can see is the usbnet_update_max_qlen() call where we divide on both
> dev->rx_urb_size and dev->hard_mtu.
>
> I don't think dev->rx_urb_size can be 0 unless dev->hard_mtu is 0.  But
> the latter is possible, and this is a bug. In qmi_wwan_bind(), which is
> called by usbnet_probe() prior to the usbnet_update_max_qlen() call, we
> do
>
> if (cdc_ether) {
> dev->hard_mtu = le16_to_cpu(cdc_ether->wMaxSegmentSize);
> usbnet_get_ethernet_addr(dev, cdc_ether->iMACAddress);
> }
>
> which will be fatal if cdc_ether->wMaxSegmentSize is 0.  I assume that
> is what your fuzzer did?  Fix coming up RSN.  Thanks a lot for pointing
> this out.

I don't see the crash with your patches. Thanks for a quick fix!

>
>
> Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

usb/net/qmi_wwan: divide error in qmi_wwan_probe/usbnet_probe

[Andrey Konovalov]

Hi!

I've got the following report while fuzzing the kernel with syzkaller.

On commit 39dae59d66acd86d1de24294bd2f343fd5e7a625 (4.14-rc8).

qmi_wwan 1-1:0.4: cdc-wdm0: USB WDM device
divide error:  [#1] PREEMPT SMP KASAN
Modules linked in:
CPU: 0 PID: 24 Comm: kworker/0:1 Not tainted 4.14.0-rc8-44453-g1fdc1a82c34f #56
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: usb_hub_wq hub_event
task: 88006bef5c00 task.stack: 88006bf6
RIP: 0010:usbnet_update_max_qlen+0x24d/0x390 drivers/net/usb/usbnet.c:355
RSP: 0018:88006bf67508 EFLAGS: 00010246
RAX: 000163c8 RBX: 8800621fce40 RCX: 8800621fcf34
RDX:  RSI: 837ecb7a RDI: 8800621fcf34
RBP: 88006bf67520 R08: 88006bef5c00 R09: ed000c43f881
R10: ed000c43f880 R11: 8800621fc406 R12: 0003
R13: 85c71de0 R14:  R15: 
FS:  () GS:88006ca0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 7ffe9c0d6dac CR3: 614f4000 CR4: 06f0
Call Trace:
 usbnet_probe+0x18b5/0x2790 drivers/net/usb/usbnet.c:1783
 qmi_wwan_probe+0x133/0x220 drivers/net/usb/qmi_wwan.c:1338
 usb_probe_interface+0x324/0x940 drivers/usb/core/driver.c:361
 really_probe drivers/base/dd.c:413
 driver_probe_device+0x522/0x740 drivers/base/dd.c:557
 __device_attach_driver+0x25d/0x2d0 drivers/base/dd.c:653
 bus_for_each_drv+0xff/0x160 drivers/base/bus.c:463
 __device_attach+0x1a8/0x2a0 drivers/base/dd.c:710
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
 bus_probe_device+0x1fc/0x2a0 drivers/base/bus.c:523
 device_add+0xc27/0x15a0 drivers/base/core.c:1835
 usb_set_configuration+0xd4f/0x17a0 drivers/usb/core/message.c:1932
 generic_probe+0xbb/0x120 drivers/usb/core/generic.c:174
 usb_probe_device+0xab/0x100 drivers/usb/core/driver.c:266
 really_probe drivers/base/dd.c:413
 driver_probe_device+0x522/0x740 drivers/base/dd.c:557
 __device_attach_driver+0x25d/0x2d0 drivers/base/dd.c:653
 bus_for_each_drv+0xff/0x160 drivers/base/bus.c:463
 __device_attach+0x1a8/0x2a0 drivers/base/dd.c:710
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
 bus_probe_device+0x1fc/0x2a0 drivers/base/bus.c:523
 device_add+0xc27/0x15a0 drivers/base/core.c:1835
 usb_new_device+0x7fa/0x1090 drivers/usb/core/hub.c:2538
 hub_port_connect drivers/usb/core/hub.c:4987
 hub_port_connect_change drivers/usb/core/hub.c:5093
 port_event drivers/usb/core/hub.c:5199
 hub_event_impl+0x17b8/0x3440 drivers/usb/core/hub.c:5311
 hub_event+0x38/0x50 drivers/usb/core/hub.c:5209
 process_one_work+0x925/0x15d0 kernel/workqueue.c:2113
 worker_thread+0xef/0x10d0 kernel/workqueue.c:2247
 kthread+0x346/0x410 kernel/kthread.c:231
 ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:432
Code: b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f
85 46 01 00 00 48 8d bb f4 00 00 00 31 d2 b8 c8 63 01 00 48 89 f9 <48>
f7 b3 b0 01 00 00 48 ba 00 00 00 00 00 fc ff df 48 c1 e9 03
RIP: usbnet_update_max_qlen+0x24d/0x390 RSP: 88006bf67508
---[ end trace 834034903d6f2b37 ]---
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] net: usb: asix: fill null-ptr-deref in asix_suspend

[Andrey Konovalov]

On Mon, Nov 6, 2017 at 10:49 AM, Oliver Neukum <oneu...@suse.com> wrote:
> Am Donnerstag, den 02.11.2017, 21:26 +0100 schrieb Andrey Konovalov:
>> When asix_suspend() is called dev->driver_priv might not have been
>> assigned a value, so we need to check that it's not NULL.
>>
>> Found by syzkaller.
>
> Hi,

Hi Oliver,

>
> 1. if that happens on suspend, it will also happen on resume

Indeed, got crashes in asix_resume() tonight as well. Mailed v2.

> 2. Will a device work after that? The appropriate fix may be to wait
> until the device is properly initialized.

This shouldn't affect real devices as far as I understand. The crash
can be caused by a crafted malicious device.

Go ahead if you see a better way to fix this, my patch is more of a
hot fix trying to prevent the crashes.

Thanks!

>
> Regards
> Oliver
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2] net: usb: asix: fill null-ptr-deref in asix_suspend

[Andrey Konovalov]

When asix_suspend() is called dev->driver_priv might not have been
assigned a value, so we need to check that it's not NULL.

Similar issue is present in asix_resume(), this patch fixes it as well.

Found by syzkaller.

kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault:  [#1] PREEMPT SMP KASAN
Modules linked in:
CPU: 0 PID: 24 Comm: kworker/0:1 Not tainted 4.14.0-rc4-43422-geccacdd69a8c #400
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: usb_hub_wq hub_event
task: 88006bb36300 task.stack: 88006bba8000
RIP: 0010:asix_suspend+0x76/0xc0 drivers/net/usb/asix_devices.c:629
RSP: 0018:88006bbae718 EFLAGS: 00010202
RAX: dc00 RBX: 880061ba3b80 RCX: 11000c34d644
RDX: 0001 RSI: 0402 RDI: 0008
RBP: 88006bbae738 R08: 11000d775cad R09: 
R10:  R11:  R12: 8800630a8b40
R13:  R14: 0402 R15: 880061ba3b80
FS:  () GS:88006c60() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 7ff33cf89000 CR3: 61c0a000 CR4: 06f0
Call Trace:
 usb_suspend_interface drivers/usb/core/driver.c:1209
 usb_suspend_both+0x27f/0x7e0 drivers/usb/core/driver.c:1314
 usb_runtime_suspend+0x41/0x120 drivers/usb/core/driver.c:1852
 __rpm_callback+0x339/0xb60 drivers/base/power/runtime.c:334
 rpm_callback+0x106/0x220 drivers/base/power/runtime.c:461
 rpm_suspend+0x465/0x1980 drivers/base/power/runtime.c:596
 __pm_runtime_suspend+0x11e/0x230 drivers/base/power/runtime.c:1009
 pm_runtime_put_sync_autosuspend ./include/linux/pm_runtime.h:251
 usb_new_device+0xa37/0x1020 drivers/usb/core/hub.c:2487
 hub_port_connect drivers/usb/core/hub.c:4903
 hub_port_connect_change drivers/usb/core/hub.c:5009
 port_event drivers/usb/core/hub.c:5115
 hub_event+0x194d/0x3740 drivers/usb/core/hub.c:5195
 process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119
 worker_thread+0x221/0x1850 kernel/workqueue.c:2253
 kthread+0x3a1/0x470 kernel/kthread.c:231
 ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431
Code: 8d 7c 24 20 48 89 fa 48 c1 ea 03 80 3c 02 00 75 5b 48 b8 00 00
00 00 00 fc ff df 4d 8b 6c 24 20 49 8d 7d 08 48 89 fa 48 c1 ea 03 <80>
3c 02 00 75 34 4d 8b 6d 08 4d 85 ed 74 0b e8 26 2b 51 fd 4c
RIP: asix_suspend+0x76/0xc0 RSP: 88006bbae718
---[ end trace dfc4f5649284342c ]---

Signed-off-by: Andrey Konovalov <andreyk...@google.com>
---

Changes in v2:
- added asix_resume() fix

---
 drivers/net/usb/asix_devices.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/usb/asix_devices.c b/drivers/net/usb/asix_devices.c
index b2ff88e69a81..3d4f7959dabb 100644
--- a/drivers/net/usb/asix_devices.c
+++ b/drivers/net/usb/asix_devices.c
@@ -626,7 +626,7 @@ static int asix_suspend(struct usb_interface *intf, 
pm_message_t message)
struct usbnet *dev = usb_get_intfdata(intf);
struct asix_common_private *priv = dev->driver_priv;
 
-   if (priv->suspend)
+   if (priv && priv->suspend)
priv->suspend(dev);
 
return usbnet_suspend(intf, message);
@@ -678,7 +678,7 @@ static int asix_resume(struct usb_interface *intf)
struct usbnet *dev = usb_get_intfdata(intf);
struct asix_common_private *priv = dev->driver_priv;
 
-   if (priv->resume)
+   if (priv && priv->resume)
priv->resume(dev);
 
return usbnet_resume(intf);
-- 
2.15.0.403.gc27cc4dac6-goog

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] net: usb: asix: fill null-ptr-deref in asix_suspend

[Andrey Konovalov]

When asix_suspend() is called dev->driver_priv might not have been
assigned a value, so we need to check that it's not NULL.

Found by syzkaller.

kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault:  [#1] PREEMPT SMP KASAN
Modules linked in:
CPU: 0 PID: 24 Comm: kworker/0:1 Not tainted 4.14.0-rc4-43422-geccacdd69a8c #400
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: usb_hub_wq hub_event
task: 88006bb36300 task.stack: 88006bba8000
RIP: 0010:asix_suspend+0x76/0xc0 drivers/net/usb/asix_devices.c:629
RSP: 0018:88006bbae718 EFLAGS: 00010202
RAX: dc00 RBX: 880061ba3b80 RCX: 11000c34d644
RDX: 0001 RSI: 0402 RDI: 0008
RBP: 88006bbae738 R08: 11000d775cad R09: 
R10:  R11:  R12: 8800630a8b40
R13:  R14: 0402 R15: 880061ba3b80
FS:  () GS:88006c60() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 7ff33cf89000 CR3: 61c0a000 CR4: 06f0
Call Trace:
 usb_suspend_interface drivers/usb/core/driver.c:1209
 usb_suspend_both+0x27f/0x7e0 drivers/usb/core/driver.c:1314
 usb_runtime_suspend+0x41/0x120 drivers/usb/core/driver.c:1852
 __rpm_callback+0x339/0xb60 drivers/base/power/runtime.c:334
 rpm_callback+0x106/0x220 drivers/base/power/runtime.c:461
 rpm_suspend+0x465/0x1980 drivers/base/power/runtime.c:596
 __pm_runtime_suspend+0x11e/0x230 drivers/base/power/runtime.c:1009
 pm_runtime_put_sync_autosuspend ./include/linux/pm_runtime.h:251
 usb_new_device+0xa37/0x1020 drivers/usb/core/hub.c:2487
 hub_port_connect drivers/usb/core/hub.c:4903
 hub_port_connect_change drivers/usb/core/hub.c:5009
 port_event drivers/usb/core/hub.c:5115
 hub_event+0x194d/0x3740 drivers/usb/core/hub.c:5195
 process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119
 worker_thread+0x221/0x1850 kernel/workqueue.c:2253
 kthread+0x3a1/0x470 kernel/kthread.c:231
 ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431
Code: 8d 7c 24 20 48 89 fa 48 c1 ea 03 80 3c 02 00 75 5b 48 b8 00 00
00 00 00 fc ff df 4d 8b 6c 24 20 49 8d 7d 08 48 89 fa 48 c1 ea 03 <80>
3c 02 00 75 34 4d 8b 6d 08 4d 85 ed 74 0b e8 26 2b 51 fd 4c
RIP: asix_suspend+0x76/0xc0 RSP: 88006bbae718
---[ end trace dfc4f5649284342c ]---

Signed-off-by: Andrey Konovalov <andreyk...@google.com>
---
 drivers/net/usb/asix_devices.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/usb/asix_devices.c b/drivers/net/usb/asix_devices.c
index b2ff88e69a81..743416be84f3 100644
--- a/drivers/net/usb/asix_devices.c
+++ b/drivers/net/usb/asix_devices.c
@@ -626,7 +626,7 @@ static int asix_suspend(struct usb_interface *intf, 
pm_message_t message)
struct usbnet *dev = usb_get_intfdata(intf);
struct asix_common_private *priv = dev->driver_priv;
 
-   if (priv->suspend)
+   if (priv && priv->suspend)
priv->suspend(dev);
 
return usbnet_suspend(intf, message);
-- 
2.15.0.403.gc27cc4dac6-goog

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: usb/net/asix: kernel hang in asix_phy_reset

[Andrey Konovalov]

On Tue, Oct 24, 2017 at 4:59 PM, Andrey Konovalov <andreyk...@google.com> wrote:
> Hi!
>
> While fuzzing the kernel with syzkaller I've been getting kernel hangs
> within the asix driver.
>
> On commit 6cff0a118f23b98c604a3604ea9de11338e24fbe (4.14-rc6+).
>
> As far as I can tell the issue is that asix_phy_reset() doesn't
> enforce proper timeout.
>
> asix_phy_reset() calls asix_mdio_read() in a loop 5000 times with 100
> us delay, which gives 500 ms of sleeping time, but it doesn't account
> for the time while asix_mdio_read() executes. asix_mdio_read() in
> turns contains another loop for 30 iterations with a sleep for 1 ms
> (and does a bunch of stuff besides that). As a result asix_mdio_read()
> takes ~80 ms in my setup. This results in at least 5000 * 80 ms = 400
> seconds of delay in addition to those insignificant 500 ms.
>
> Hang stack trace:
>
> [] usb_start_wait_urb+0xfe/0x220 
> drivers/usb/core/message.c:61
> [< inline >] usb_internal_control_msg drivers/usb/core/message.c:100
> [] usb_control_msg+0x2c5/0x3a0 
> drivers/usb/core/message.c:151
> [] __usbnet_read_cmd+0xcd/0x180 
> drivers/net/usb/usbnet.c:1986
> [] usbnet_read_cmd+0x7f/0xe0 drivers/net/usb/usbnet.c:2044
> [] asix_read_cmd+0x75/0xe0 drivers/net/usb/asix_common.c:37
> [] asix_mdio_read+0xbb/0x150 
> drivers/net/usb/asix_common.c:471
> [] asix_phy_reset.isra.9+0xfa/0x1d0
> drivers/net/usb/asix_devices.c:227
> [] ax88172_bind+0x397/0x4e0 
> drivers/net/usb/asix_devices.c:284
> [] usbnet_probe+0xb06/0x2600 drivers/net/usb/usbnet.c:1726
> [] usb_probe_interface+0x358/0x880
> drivers/usb/core/driver.c:361
> [< inline >] really_probe drivers/base/dd.c:413
> [] driver_probe_device+0x490/0x800 drivers/base/dd.c:557
> [] __device_attach_driver+0x22b/0x290 drivers/base/dd.c:653
> [] bus_for_each_drv+0xfa/0x170 drivers/base/bus.c:463
> [] __device_attach+0x1ab/0x290 drivers/base/dd.c:710
> [] device_initial_probe+0x1a/0x20 drivers/base/dd.c:757
> [] bus_probe_device+0x1e6/0x290 drivers/base/bus.c:523
> [] device_add+0xb2f/0x1340 drivers/base/core.c:1835
> [] usb_set_configuration+0xe9d/0x1660
> drivers/usb/core/message.c:1932
> [] generic_probe+0x6e/0xe0 drivers/usb/core/generic.c:174
> [] usb_probe_device+0xaa/0xe0 drivers/usb/core/driver.c:266
> [< inline >] really_probe drivers/base/dd.c:413
> [] driver_probe_device+0x490/0x800 drivers/base/dd.c:557
> [] __device_attach_driver+0x22b/0x290 drivers/base/dd.c:653
> [] bus_for_each_drv+0xfa/0x170 drivers/base/bus.c:463
> [] __device_attach+0x1ab/0x290 drivers/base/dd.c:710
> [] device_initial_probe+0x1a/0x20 drivers/base/dd.c:757
> [] bus_probe_device+0x1e6/0x290 drivers/base/bus.c:523
> [] device_add+0xb2f/0x1340 drivers/base/core.c:1835
> [] usb_new_device+0x7b3/0xff0 drivers/usb/core/hub.c:2457
> [< inline >] hub_port_connect drivers/usb/core/hub.c:4906
> [< inline >] hub_port_connect_change drivers/usb/core/hub.c:5012
> [< inline >] port_event drivers/usb/core/hub.c:5118
> [] hub_event+0x133a/0x2d90 drivers/usb/core/hub.c:5198
> [] process_one_work+0x78b/0x1540 kernel/workqueue.c:2113
> [] worker_thread+0xe7/0xff0 kernel/workqueue.c:2247
> [] kthread+0x33c/0x410 kernel/kthread.c:231
> [] ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431
> [] 0x

And another hang stack, this time in mdiobus_scan():

[] usb_start_wait_urb+0xfe/0x220 drivers/usb/core/message.c:61
[< inline >] usb_internal_control_msg drivers/usb/core/message.c:100
[] usb_control_msg+0x2c5/0x3a0 drivers/usb/core/message.c:151
[] __usbnet_write_cmd+0xd4/0x170 drivers/net/usb/usbnet.c:2024
[] usbnet_write_cmd+0x7f/0xe0 drivers/net/usb/usbnet.c:2062
[] asix_write_cmd+0x75/0xe0 drivers/net/usb/asix_common.c:60
[] asix_set_sw_mii+0x29/0x90 drivers/net/usb/asix_common.c:288
[] asix_mdio_read+0x75/0x150 drivers/net/usb/asix_common.c:467
[] asix_mdio_bus_read+0x66/0x80 drivers/net/usb/ax88172a.c:43
[] mdiobus_read+0x6f/0x2f0 drivers/net/phy/mdio_bus.c:541
[< inline >] get_phy_id drivers/net/phy/phy_device.c:537
[] get_phy_device+0x74/0x2f0 drivers/net/phy/phy_device.c:569
[] mdiobus_scan+0x1f/0x60 drivers/net/phy/mdio_bus.c:475
[] __mdiobus_register+0x2c6/0x560
drivers/net/phy/mdio_bus.c:377
[< inline >] ax88172a_init_mdio drivers/net/usb/ax88172a.c:117
[] ax88172a_bind+0x515/0x8e0 drivers/net/usb/ax88172a.c:255
[] usbnet_probe+0xb06/0x2600 drivers/net/usb/usbnet.c:1726
[] usb_probe_interface+0x358/0x880
drivers/usb/core/driver.c:361
[< inline >] really_probe drivers/base/dd.c:413
[] driver_probe_device+0x490/0x800 drivers/base/dd.c:557
[] __device_attach_driver+0x22b/0x290 drivers/base/dd.c:653
[] bus_for_each_drv+0xfa/0x170 drivers/base/bus.c:463
[] __device_att

usb/net/asix: kernel hang in asix_phy_reset

[Andrey Konovalov]

Hi!

While fuzzing the kernel with syzkaller I've been getting kernel hangs
within the asix driver.

On commit 6cff0a118f23b98c604a3604ea9de11338e24fbe (4.14-rc6+).

As far as I can tell the issue is that asix_phy_reset() doesn't
enforce proper timeout.

asix_phy_reset() calls asix_mdio_read() in a loop 5000 times with 100
us delay, which gives 500 ms of sleeping time, but it doesn't account
for the time while asix_mdio_read() executes. asix_mdio_read() in
turns contains another loop for 30 iterations with a sleep for 1 ms
(and does a bunch of stuff besides that). As a result asix_mdio_read()
takes ~80 ms in my setup. This results in at least 5000 * 80 ms = 400
seconds of delay in addition to those insignificant 500 ms.

Hang stack trace:

[] usb_start_wait_urb+0xfe/0x220 drivers/usb/core/message.c:61
[< inline >] usb_internal_control_msg drivers/usb/core/message.c:100
[] usb_control_msg+0x2c5/0x3a0 drivers/usb/core/message.c:151
[] __usbnet_read_cmd+0xcd/0x180 drivers/net/usb/usbnet.c:1986
[] usbnet_read_cmd+0x7f/0xe0 drivers/net/usb/usbnet.c:2044
[] asix_read_cmd+0x75/0xe0 drivers/net/usb/asix_common.c:37
[] asix_mdio_read+0xbb/0x150 drivers/net/usb/asix_common.c:471
[] asix_phy_reset.isra.9+0xfa/0x1d0
drivers/net/usb/asix_devices.c:227
[] ax88172_bind+0x397/0x4e0 drivers/net/usb/asix_devices.c:284
[] usbnet_probe+0xb06/0x2600 drivers/net/usb/usbnet.c:1726
[] usb_probe_interface+0x358/0x880
drivers/usb/core/driver.c:361
[< inline >] really_probe drivers/base/dd.c:413
[] driver_probe_device+0x490/0x800 drivers/base/dd.c:557
[] __device_attach_driver+0x22b/0x290 drivers/base/dd.c:653
[] bus_for_each_drv+0xfa/0x170 drivers/base/bus.c:463
[] __device_attach+0x1ab/0x290 drivers/base/dd.c:710
[] device_initial_probe+0x1a/0x20 drivers/base/dd.c:757
[] bus_probe_device+0x1e6/0x290 drivers/base/bus.c:523
[] device_add+0xb2f/0x1340 drivers/base/core.c:1835
[] usb_set_configuration+0xe9d/0x1660
drivers/usb/core/message.c:1932
[] generic_probe+0x6e/0xe0 drivers/usb/core/generic.c:174
[] usb_probe_device+0xaa/0xe0 drivers/usb/core/driver.c:266
[< inline >] really_probe drivers/base/dd.c:413
[] driver_probe_device+0x490/0x800 drivers/base/dd.c:557
[] __device_attach_driver+0x22b/0x290 drivers/base/dd.c:653
[] bus_for_each_drv+0xfa/0x170 drivers/base/bus.c:463
[] __device_attach+0x1ab/0x290 drivers/base/dd.c:710
[] device_initial_probe+0x1a/0x20 drivers/base/dd.c:757
[] bus_probe_device+0x1e6/0x290 drivers/base/bus.c:523
[] device_add+0xb2f/0x1340 drivers/base/core.c:1835
[] usb_new_device+0x7b3/0xff0 drivers/usb/core/hub.c:2457
[< inline >] hub_port_connect drivers/usb/core/hub.c:4906
[< inline >] hub_port_connect_change drivers/usb/core/hub.c:5012
[< inline >] port_event drivers/usb/core/hub.c:5118
[] hub_event+0x133a/0x2d90 drivers/usb/core/hub.c:5198
[] process_one_work+0x78b/0x1540 kernel/workqueue.c:2113
[] worker_thread+0xe7/0xff0 kernel/workqueue.c:2247
[] kthread+0x33c/0x410 kernel/kthread.c:231
[] ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431
[] 0x

Messages printed to kernel log:

[  244.451821] asix 1-1:0.0 (unnamed net_device) (uninitialized):
Failed to enable software MII access
[  244.470152] asix 1-1:0.0 (unnamed net_device) (uninitialized):
Failed to read reg index 0x: -71
[  244.490199] asix 1-1:0.0 (unnamed net_device) (uninitialized):
Failed to read reg index 0x: -71
[  244.510193] asix 1-1:0.0 (unnamed net_device) (uninitialized):
Failed to write reg index 0x: -71
[  244.511992] asix 1-1:0.0 (unnamed net_device) (uninitialized):
Failed to enable hardware MII access
[  244.530191] asix 1-1:0.0 (unnamed net_device) (uninitialized):
Failed to write reg index 0x: -71
[  244.532024] asix 1-1:0.0 (unnamed net_device) (uninitialized):
Failed to enable software MII access
[  244.550197] asix 1-1:0.0 (unnamed net_device) (uninitialized):
Failed to read reg index 0x: -71
[  244.570198] asix 1-1:0.0 (unnamed net_device) (uninitialized):
Failed to read reg index 0x: -71
[  244.590194] asix 1-1:0.0 (unnamed net_device) (uninitialized):
Failed to write reg index 0x: -71
[  244.591960] asix 1-1:0.0 (unnamed net_device) (uninitialized):
Failed to enable hardware MII access
[  244.610193] asix 1-1:0.0 (unnamed net_device) (uninitialized):
Failed to write reg index 0x: -71
[  244.611978] asix 1-1:0.0 (unnamed net_device) (uninitialized):
Failed to enable software MII access
[  244.630224] asix 1-1:0.0 (unnamed net_device) (uninitialized):
Failed to read reg index 0x: -71
[  244.650197] asix 1-1:0.0 (unnamed net_device) (uninitialized):
Failed to read reg index 0x: -71
[  244.670193] asix 1-1:0.0 (unnamed net_device) (uninitialized):
Failed to write reg index 0x: -71
[  244.671991] asix 1-1:0.0 (unnamed net_device) (uninitialized):
Failed to enable hardware MII access
[  244.690170] asix 1-1:0.0 (unnamed net_device) (uninitialized):
Failed to write reg index 0x: -71
[  244.691907] asix 1-1:0.0 

Re: usb/serial/visor: slab-out-of-bounds in palm_os_3_probe

[Andrey Konovalov]

On Wed, Oct 4, 2017 at 4:40 PM, Greg Kroah-Hartman
<gre...@linuxfoundation.org> wrote:
> On Tue, Oct 03, 2017 at 11:29:40AM +0200, Johan Hovold wrote:
>> On Fri, Sep 29, 2017 at 10:37:55AM +0200, Greg Kroah-Hartman wrote:
>> > On Thu, Sep 28, 2017 at 07:57:46PM +0200, Andrey Konovalov wrote:
>> > > Hi!
>> > >
>> > > I've got the following report while fuzzing the kernel with syzkaller.
>> > >
>> > > On commit dc972a67cc54585bd83ad811c4e9b6ab3dcd427e (4.14-rc2+).
>> > >
>> > > There's no check on the connection_info->num_ports value when
>> > > iterating over ports.
>> > >
>> > > usb 1-1: Handspring Visor / Palm OS: port 162, is for unknown use
>> > > usb 1-1: Handspring Visor / Palm OS: port 81, is for unknown use
>> > > ==
>> > > BUG: KASAN: slab-out-of-bounds in palm_os_3_probe+0x4e4/0x570
>> > > Read of size 1 at addr 8800686daa26 by task kworker/0:1/24
>>
>> Thanks for the report, Andrey.
>>
>> > Ah, nice catch, this bug is _old_, sorry about that.
>> >
>> > The patch below should resolve this.  It looks bigger than it really is,
>> > as I'm just moving the error checking higher up in the function, and
>> > loosing an indentation for when there is invalid data.
>> >
>> > Can you let me know if this solves the issue?
>>
>> And thanks for fixing this up, Greg. Will you send a proper patch that I
>> can apply?
>
> Yes, let me redo it based on your comments, and will send it out
> "correctly" in a few days.

Hi Greg,

I was going through the bugs I've reported, and it seems that you
didn't mail the patch for this one. Reminding in case you've
accidentally forgotten about it.

Thanks!

>
> thanks for the review,
>
> greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: usb/core: slab-out-of-bounds in usb_get_bos_descriptor

[Andrey Konovalov]

On Wed, Oct 18, 2017 at 5:25 PM, Alan Stern <st...@rowland.harvard.edu> wrote:
> On Wed, 18 Oct 2017, Andrey Konovalov wrote:
>
>> Hi!
>>
>> I've got the following report while fuzzing the kernel with syzkaller.
>>
>> On commit 3e0cc09a3a2c40ec1ffb6b4e12da86e98feccb11 (4.14-rc5+).
>>
>> Looks like usb_get_bos_descriptor() doesn't check that buffer has
>> enough space for usb_dev_cap_header, which causes out-of-bounds
>> accesses.
>
> Please try the patch below.
>
> Alan Stern

Hi Alan,

This patch fixes the issue.

Thanks!

Tested-by: Andrey Konovalov <andreyk...@google.com>

>
>
>
> Index: usb-4.x/drivers/usb/core/config.c
> ===
> --- usb-4.x.orig/drivers/usb/core/config.c
> +++ usb-4.x/drivers/usb/core/config.c
> @@ -952,10 +952,12 @@ int usb_get_bos_descriptor(struct usb_de
> for (i = 0; i < num; i++) {
> buffer += length;
> cap = (struct usb_dev_cap_header *)buffer;
> -   length = cap->bLength;
>
> -   if (total_len < length)
> +   if (total_len < sizeof(*cap) || total_len < cap->bLength) {
> +   dev->bos->desc->bNumDeviceCaps = i;
> break;
> +   }
> +   length = cap->bLength;
> total_len -= length;
>
> if (cap->bDescriptorType != USB_DT_DEVICE_CAPABILITY) {
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

usb/core: slab-out-of-bounds in usb_get_bos_descriptor

[Andrey Konovalov]

Hi!

I've got the following report while fuzzing the kernel with syzkaller.

On commit 3e0cc09a3a2c40ec1ffb6b4e12da86e98feccb11 (4.14-rc5+).

Looks like usb_get_bos_descriptor() doesn't check that buffer has
enough space for usb_dev_cap_header, which causes out-of-bounds
accesses.

==
BUG: KASAN: slab-out-of-bounds in usb_get_bos_descriptor+0x621/0x670
Read of size 1 at addr 88006b21625a by task kworker/0:2/1254

CPU: 0 PID: 1254 Comm: kworker/0:2 Not tainted
4.14.0-rc5-43687-g49c387c9bdf6 #468
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: usb_hub_wq hub_event
Call Trace:
 __dump_stack lib/dump_stack.c:16
 dump_stack+0x292/0x395 lib/dump_stack.c:52
 print_address_description+0x78/0x280 mm/kasan/report.c:252
 kasan_report_error mm/kasan/report.c:351
 kasan_report+0x23d/0x350 mm/kasan/report.c:409
 __asan_report_load1_noabort+0x19/0x20 mm/kasan/report.c:427
 usb_get_bos_descriptor+0x621/0x670 drivers/usb/core/config.c:963
 hub_port_init+0x18e5/0x2860 drivers/usb/core/hub.c:4642
 hub_port_connect drivers/usb/core/hub.c:4835
 hub_port_connect_change drivers/usb/core/hub.c:5009
 port_event drivers/usb/core/hub.c:5115
 hub_event+0x17b3/0x3740 drivers/usb/core/hub.c:5195
 process_one_work+0xc73/0x1d90 kernel/workqueue.c:2119
 worker_thread+0x221/0x1850 kernel/workqueue.c:2253
 kthread+0x363/0x440 kernel/kthread.c:231
 ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431

Allocated by task 1254:
 save_stack_trace+0x1b/0x20 arch/x86/kernel/stacktrace.c:59
 save_stack+0x43/0xd0 mm/kasan/kasan.c:447
 set_track mm/kasan/kasan.c:459
 kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551
 __kmalloc+0x14e/0x310 mm/slub.c:3782
 kmalloc ./include/linux/slab.h:498
 kzalloc ./include/linux/slab.h:666
 usb_get_bos_descriptor+0x1cb/0x670 drivers/usb/core/config.c:944
 hub_port_init+0x18e5/0x2860 drivers/usb/core/hub.c:4642
 hub_port_connect drivers/usb/core/hub.c:4835
 hub_port_connect_change drivers/usb/core/hub.c:5009
 port_event drivers/usb/core/hub.c:5115
 hub_event+0x17b3/0x3740 drivers/usb/core/hub.c:5195
 process_one_work+0xc73/0x1d90 kernel/workqueue.c:2119
 worker_thread+0x221/0x1850 kernel/workqueue.c:2253
 kthread+0x363/0x440 kernel/kthread.c:231
 ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431

Freed by task 2853:
 save_stack_trace+0x1b/0x20 arch/x86/kernel/stacktrace.c:59
 save_stack+0x43/0xd0 mm/kasan/kasan.c:447
 set_track mm/kasan/kasan.c:459
 kasan_slab_free+0x72/0xc0 mm/kasan/kasan.c:524
 slab_free_hook mm/slub.c:1390
 slab_free_freelist_hook mm/slub.c:1412
 slab_free mm/slub.c:2988
 kfree+0xf6/0x2f0 mm/slub.c:3919
 load_elf_binary+0x39af/0x4f90 fs/binfmt_elf.c:1087
 search_binary_handler+0x146/0x480 fs/exec.c:1634
 exec_binprm fs/exec.c:1676
 do_execveat_common.isra.31+0x16d2/0x2200 fs/exec.c:1798
 do_execve fs/exec.c:1842
 SYSC_execve fs/exec.c:1923
 SyS_execve+0x3e/0x50 fs/exec.c:1918
 do_syscall_64+0x2c5/0x850 arch/x86/entry/common.c:287
 return_from_SYSCALL_64+0x0/0x7a arch/x86/entry/entry_64.S:245

The buggy address belongs to the object at 88006b216240
 which belongs to the cache kmalloc-32 of size 32
The buggy address is located 26 bytes inside of
 32-byte region [88006b216240, 88006b216260)
The buggy address belongs to the page:
page:ea0001ac8580 count:1 mapcount:0 mapping:  (null) index:0x0
flags: 0x1000100(slab)
raw: 01000100   000180550055
raw: ea0001b16640 000b000b 88006c403980 
page dumped because: kasan: bad access detected

Memory state around the buggy address:
 88006b216100: fb fb fc fc fb fb fb fb fc fc 00 00 00 00 fc fc
 88006b216180: fb fb fb fb fc fc fb fb fb fb fc fc fb fb fb fb
>88006b216200: fc fc fb fb fb fb fc fc 00 00 00 02 fc fc fb fb
^
 88006b216280: fb fb fc fc fb fb fb fb fc fc fb fb fb fb fc fc
 88006b216300: fb fb fb fb fc fc fb fb fb fb fc fc fb fb fb fb
==
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/9] ALSA: bcd2000: Add a sanity check for invalid EPs

[Andrey Konovalov]

On Tue, Oct 10, 2017 at 4:33 PM, Takashi Iwai <ti...@suse.de> wrote:
> On Tue, 10 Oct 2017 16:00:25 +0200,
> Andrey Konovalov wrote:
>>
>> On Tue, Oct 10, 2017 at 3:38 PM, Takashi Iwai <ti...@suse.de> wrote:
>> > As syzkaller spotted, currently bcd2000 driver submits a URB with the
>> > fixed EP without checking whether it's actually available, which may
>> > result in a kernel warning like:
>> >   usb 1-1: BOGUS urb xfer, pipe 1 != type 3
>> >   [ cut here ]
>> >   WARNING: CPU: 0 PID: 1846 at drivers/usb/core/urb.c:449
>> >   usb_submit_urb+0xf8a/0x11d0
>> >   Modules linked in:
>> >   CPU: 0 PID: 1846 Comm: kworker/0:2 Not tainted
>> >   4.14.0-rc2-42613-g1488251d1a98 #238
>> >   Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 
>> > 01/01/2011
>> >   Workqueue: usb_hub_wq hub_event
>> >   Call Trace:
>> >bcd2000_init_device sound/usb/bcd2000/bcd2000.c:289
>> >bcd2000_init_midi sound/usb/bcd2000/bcd2000.c:345
>> >bcd2000_probe+0xe64/0x19e0 sound/usb/bcd2000/bcd2000.c:406
>> >usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361
>> >
>> >
>> > This patch adds a sanity check of validity of EPs at the device
>> > initialization phase for avoiding the call with an invalid EP.
>> >
>> > Reported-by: Andrey Konovalov <andreyk...@google.com>
>> > Signed-off-by: Takashi Iwai <ti...@suse.de>
>>
>> Hi Takashi,
>>
>> I've applied patches #1 and #2 and for some reason get this when I try
>> to build the kernel:
>>
>>   LD  vmlinux.o
>>   MODPOST vmlinux.o
>> sound/usb/bcd2000/bcd2000.o: In function `bcd2000_init_midi':
>> .../sound/usb/bcd2000/bcd2000.c:346: undefined reference to
>> `usb_urb_ep_type_check'
>> .../sound/usb/bcd2000/bcd2000.c:347: undefined reference to
>> `usb_urb_ep_type_check'
>> make: *** [vmlinux] Error 1
>>
>> What could be wrong?
>
> Mea culpa, I generated patches from the wrong branch.
> Luckily only the first patch was wrong, the function name was
> misspelled.

Ah, I thought so and even intentionally checked for a typo in the
function name, but somehow still missed that :)

I've run my reproducers with your patches applied, all the warnings are gone.

Thanks!

Tested-by: Andrey Konovalov <andreyk...@google.com>

>
> Below is the right patch for patch 1, which already includes Greg's
> suggestions.  I'm going to send a v2 series in anyway later, so just
> putting this one below.
>
> Sorry for the inconvenience!
>
>
> Takashi
>
> -- 8< --
> From: Takashi Iwai <ti...@suse.de>
> Subject: [PATCH 1/9] usb: core: Add a helper function to check the validity 
> of EP type in URB
>
> This patch adds a new helper function to perform a sanity check of the
> given URB to see whether it contains a valid endpoint.  It's a light-
> weight version of what usb_submit_urb() does, but without the kernel
> warning followed by the stack trace, just returns an error code.
>
> Especially for a driver that doesn't parse the descriptor but fills
> the URB with the fixed endpoint (e.g. some quirks for non-compliant
> devices), this kind of check is preferable at the probe phase before
> actually submitting the urb.
>
> Signed-off-by: Takashi Iwai <ti...@suse.de>
> ---
>  drivers/usb/core/urb.c | 30 ++
>  include/linux/usb.h|  2 ++
>  2 files changed, 28 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/usb/core/urb.c b/drivers/usb/core/urb.c
> index 47903d510955..8b800e34407b 100644
> --- a/drivers/usb/core/urb.c
> +++ b/drivers/usb/core/urb.c
> @@ -187,6 +187,31 @@ EXPORT_SYMBOL_GPL(usb_unanchor_urb);
>
>  /*---*/
>
> +static const int pipetypes[4] = {
> +   PIPE_CONTROL, PIPE_ISOCHRONOUS, PIPE_BULK, PIPE_INTERRUPT
> +};
> +
> +/**
> + * usb_urb_ep_type_check - sanity check of endpoint in the given urb
> + * @urb: urb to be checked
> + *
> + * This performs a light-weight sanity check for the endpoint in the
> + * given urb.  It returns 0 if the urb contains a valid endpoint, otherwise
> + * a negative error code.
> + */
> +int usb_urb_ep_type_check(const struct urb *urb)
> +{
> +   const struct usb_host_endpoint *ep;
> +
> +   ep = usb_pipe_endpoint(urb->dev, urb->pipe);
> +   if (!ep)
> +   return -EINVAL;
> +   if (usb_pipetype(urb->pipe) != 
> pipetypes[usb_endpoint_type(>desc)])
> +   return -EINVAL;

Re: [PATCH 2/9] ALSA: bcd2000: Add a sanity check for invalid EPs

[Andrey Konovalov]

On Tue, Oct 10, 2017 at 3:38 PM, Takashi Iwai <ti...@suse.de> wrote:
> As syzkaller spotted, currently bcd2000 driver submits a URB with the
> fixed EP without checking whether it's actually available, which may
> result in a kernel warning like:
>   usb 1-1: BOGUS urb xfer, pipe 1 != type 3
>   [ cut here ]
>   WARNING: CPU: 0 PID: 1846 at drivers/usb/core/urb.c:449
>   usb_submit_urb+0xf8a/0x11d0
>   Modules linked in:
>   CPU: 0 PID: 1846 Comm: kworker/0:2 Not tainted
>   4.14.0-rc2-42613-g1488251d1a98 #238
>   Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>   Workqueue: usb_hub_wq hub_event
>   Call Trace:
>bcd2000_init_device sound/usb/bcd2000/bcd2000.c:289
>bcd2000_init_midi sound/usb/bcd2000/bcd2000.c:345
>bcd2000_probe+0xe64/0x19e0 sound/usb/bcd2000/bcd2000.c:406
>usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361
>
>
> This patch adds a sanity check of validity of EPs at the device
> initialization phase for avoiding the call with an invalid EP.
>
> Reported-by: Andrey Konovalov <andreyk...@google.com>
> Signed-off-by: Takashi Iwai <ti...@suse.de>

Hi Takashi,

I've applied patches #1 and #2 and for some reason get this when I try
to build the kernel:

  LD  vmlinux.o
  MODPOST vmlinux.o
sound/usb/bcd2000/bcd2000.o: In function `bcd2000_init_midi':
.../sound/usb/bcd2000/bcd2000.c:346: undefined reference to
`usb_urb_ep_type_check'
.../sound/usb/bcd2000/bcd2000.c:347: undefined reference to
`usb_urb_ep_type_check'
make: *** [vmlinux] Error 1

What could be wrong?

Thanks!

> ---
>  sound/usb/bcd2000/bcd2000.c | 7 +++
>  1 file changed, 7 insertions(+)
>
> diff --git a/sound/usb/bcd2000/bcd2000.c b/sound/usb/bcd2000/bcd2000.c
> index 7371e5b06035..a6408209d7f1 100644
> --- a/sound/usb/bcd2000/bcd2000.c
> +++ b/sound/usb/bcd2000/bcd2000.c
> @@ -342,6 +342,13 @@ static int bcd2000_init_midi(struct bcd2000 *bcd2k)
> bcd2k->midi_out_buf, BUFSIZE,
> bcd2000_output_complete, bcd2k, 1);
>
> +   /* sanity checks of EPs before actually submitting */
> +   if (usb_urb_ep_type_check(bcd2k->midi_in_urb) ||
> +   usb_urb_ep_type_check(bcd2k->midi_out_urb)) {
> +   dev_err(>dev->dev, "invalid MIDI EP\n");
> +   return -EINVAL;
> +   }
> +
> bcd2000_init_device(bcd2k);
>
> return 0;
> --
> 2.14.2
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

usb/net/asix: null-ptr-deref in asix_suspend

[Andrey Konovalov]

Hi!

I've got the following report while fuzzing the kernel with syzkaller.

On commit 8a5776a5f49812d29fe4b2d0a2d71675c3facf3f (4.14-rc4).

It seems that priv ends up being NULL.

usb 1-1: New USB device found, idVendor=0557, idProduct=2009
usb 1-1: New USB device strings: Mfr=204, Product=1, SerialNumber=0
usb 1-1: Product: a
usb 1-1: Manufacturer: a
gadgetfs: configuration #4
hub 1-1:4.2: bad descriptor, ignoring hub
hub: probe of 1-1:4.2 failed with error -5
asix 1-1:4.2 (unnamed net_device) (uninitialized): Failed to read reg
index 0x: -75
asix 1-1:4.2 eth1: register 'asix' at usb-dummy_hcd.0-1, ASIX AX8817x
USB 2.0 Ethernet, 08:d1:8e:63:00:88
asix 1-1:4.185 eth2: register 'asix' at usb-dummy_hcd.0-1, ASIX
AX8817x USB 2.0 Ethernet, 08:8f:0a:63:00:88
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault:  [#1] PREEMPT SMP KASAN
Modules linked in:
CPU: 0 PID: 24 Comm: kworker/0:1 Not tainted 4.14.0-rc4-43422-geccacdd69a8c #400
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: usb_hub_wq hub_event
task: 88006bb36300 task.stack: 88006bba8000
RIP: 0010:asix_suspend+0x76/0xc0 drivers/net/usb/asix_devices.c:629
RSP: 0018:88006bbae718 EFLAGS: 00010202
RAX: dc00 RBX: 880061ba3b80 RCX: 11000c34d644
RDX: 0001 RSI: 0402 RDI: 0008
RBP: 88006bbae738 R08: 11000d775cad R09: 
R10:  R11:  R12: 8800630a8b40
R13:  R14: 0402 R15: 880061ba3b80
FS:  () GS:88006c60() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 7ff33cf89000 CR3: 61c0a000 CR4: 06f0
Call Trace:
 usb_suspend_interface drivers/usb/core/driver.c:1209
 usb_suspend_both+0x27f/0x7e0 drivers/usb/core/driver.c:1314
 usb_runtime_suspend+0x41/0x120 drivers/usb/core/driver.c:1852
 __rpm_callback+0x339/0xb60 drivers/base/power/runtime.c:334
 rpm_callback+0x106/0x220 drivers/base/power/runtime.c:461
 rpm_suspend+0x465/0x1980 drivers/base/power/runtime.c:596
 __pm_runtime_suspend+0x11e/0x230 drivers/base/power/runtime.c:1009
 pm_runtime_put_sync_autosuspend ./include/linux/pm_runtime.h:251
 usb_new_device+0xa37/0x1020 drivers/usb/core/hub.c:2487
 hub_port_connect drivers/usb/core/hub.c:4903
 hub_port_connect_change drivers/usb/core/hub.c:5009
 port_event drivers/usb/core/hub.c:5115
 hub_event+0x194d/0x3740 drivers/usb/core/hub.c:5195
 process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119
 worker_thread+0x221/0x1850 kernel/workqueue.c:2253
 kthread+0x3a1/0x470 kernel/kthread.c:231
 ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431
Code: 8d 7c 24 20 48 89 fa 48 c1 ea 03 80 3c 02 00 75 5b 48 b8 00 00
00 00 00 fc ff df 4d 8b 6c 24 20 49 8d 7d 08 48 89 fa 48 c1 ea 03 <80>
3c 02 00 75 34 4d 8b 6d 08 4d 85 ed 74 0b e8 26 2b 51 fd 4c
RIP: asix_suspend+0x76/0xc0 RSP: 88006bbae718
---[ end trace dfc4f5649284342c ]---
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] HID: usbhid: fix out-of-bounds bug

[Andrey Konovalov]

On Tue, Oct 10, 2017 at 9:25 AM, Jaejoong Kim <climbbb@gmail.com> wrote:
> Hi,
>
> To. Jiri, Alan,
>
> Could you please review this patch?
>
> To. Andey,
>
> Could you please test with this patch for KASAN OOB error?

Hi!

Yes, your patch fixes the issue.

Thanks!

Tested-by: Andrey Konovalov <andreyk...@google.com>

>
> Thanks, jaejoong
>
> 2017-09-28 19:16 GMT+09:00 Jaejoong Kim <climbbb@gmail.com>:
>> The hid descriptor identifies the length and type of subordinate
>> descriptors for a device. If the received hid descriptor is smaller than
>> the size of the struct hid_descriptor, it is possible to cause
>> out-of-bounds.
>>
>> In addition, if bNumDescriptors of the hid descriptor have an incorrect
>> value, this can also cause out-of-bounds while approaching hdesc->desc[n].
>>
>> So check the size of hid descriptor and bNumDescriptors.
>>
>> BUG: KASAN: slab-out-of-bounds in usbhid_parse+0x9b1/0xa20
>> Read of size 1 at addr 88006c5f8edf by task kworker/1:2/1261
>>
>> CPU: 1 PID: 1261 Comm: kworker/1:2 Not tainted
>> 4.14.0-rc1-42251-gebb2c2437d80 #169
>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 
>> 01/01/2011
>> Workqueue: usb_hub_wq hub_event
>> Call Trace:
>> __dump_stack lib/dump_stack.c:16
>> dump_stack+0x292/0x395 lib/dump_stack.c:52
>> print_address_description+0x78/0x280 mm/kasan/report.c:252
>> kasan_report_error mm/kasan/report.c:351
>> kasan_report+0x22f/0x340 mm/kasan/report.c:409
>> __asan_report_load1_noabort+0x19/0x20 mm/kasan/report.c:427
>> usbhid_parse+0x9b1/0xa20 drivers/hid/usbhid/hid-core.c:1004
>> hid_add_device+0x16b/0xb30 drivers/hid/hid-core.c:2944
>> usbhid_probe+0xc28/0x1100 drivers/hid/usbhid/hid-core.c:1369
>> usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361
>> really_probe drivers/base/dd.c:413
>> driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
>> __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
>> bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
>> __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
>> device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
>> bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
>> device_add+0xd0b/0x1660 drivers/base/core.c:1835
>> usb_set_configuration+0x104e/0x1870 drivers/usb/core/message.c:1932
>> generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174
>> usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266
>> really_probe drivers/base/dd.c:413
>> driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
>> __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
>> bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
>> __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
>> device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
>> bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
>> device_add+0xd0b/0x1660 drivers/base/core.c:1835
>> usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2457
>> hub_port_connect drivers/usb/core/hub.c:4903
>> hub_port_connect_change drivers/usb/core/hub.c:5009
>>     port_event drivers/usb/core/hub.c:5115
>> hub_event+0x194d/0x3740 drivers/usb/core/hub.c:5195
>> process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119
>> worker_thread+0x221/0x1850 kernel/workqueue.c:2253
>> kthread+0x3a1/0x470 kernel/kthread.c:231
>> ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431
>>
>> Reported-by: Andrey Konovalov <andreyk...@google.com>
>> Signed-off-by: Jaejoong Kim <climbbb@gmail.com>
>> ---
>>
>> Changes in v2:
>> - write a new commit message because orginal version is wrong approach
>> - add check hid descriptor size
>> - get proper value for bNumDescriptors as suggested by Alan Stern
>> - fix the Reported-by
>>
>>  drivers/hid/usbhid/hid-core.c | 12 +++-
>>  1 file changed, 11 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
>> index 089bad8..045b5da 100644
>> --- a/drivers/hid/usbhid/hid-core.c
>> +++ b/drivers/hid/usbhid/hid-core.c
>> @@ -975,6 +975,8 @@ static int usbhid_parse(struct hid_device *hid)
>> unsigned int rsize = 0;
>> char *rdesc;
>>  

Re: [PATCH 1/2] USB: serial: console: fix use-after-free on disconnect

[Andrey Konovalov]

On Wed, Oct 4, 2017 at 11:01 AM, Johan Hovold <jo...@kernel.org> wrote:
> A clean-up patch removing removing two redundant NULL-checks from the
> console disconnect handler inadvertently also removed a third check.
> This could lead to the struct usb_serial being prematurely freed by the
> console code when a driver accepts but does not register any ports for
> an interface which also lacks endpoint descriptors.
>
> Fixes: 0e517c93dc02 ("USB: serial: console: clean up sanity checks")
> Cc: stable <sta...@vger.kernel.org> # 4.11
> Reported-by: Andrey Konovalov <andreyk...@google.com>

Tested-by: Andrey Konovalov <andreyk...@google.com>

This fixes the crash.

Thanks!

> Signed-off-by: Johan Hovold <jo...@kernel.org>
> ---
>  drivers/usb/serial/console.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/usb/serial/console.c b/drivers/usb/serial/console.c
> index fdf89800ebc3..ed8ba3ef5c79 100644
> --- a/drivers/usb/serial/console.c
> +++ b/drivers/usb/serial/console.c
> @@ -265,7 +265,7 @@ static struct console usbcons = {
>
>  void usb_serial_console_disconnect(struct usb_serial *serial)
>  {
> -   if (serial->port[0] == usbcons_info.port) {
> +   if (serial->port[0] && serial->port[0] == usbcons_info.port) {
> usb_serial_console_exit();
> usb_serial_put(serial);
> }
> --
> 2.14.2
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: usb/misc/usbtest: null-ptr-deref in usbtest_probe/get_endpoints

[Andrey Konovalov]

On Thu, Sep 28, 2017 at 7:01 PM, Alan Stern <st...@rowland.harvard.edu> wrote:
> On Thu, 28 Sep 2017, Andrey Konovalov wrote:
>
>> Hi!
>>
>> I've got the following report while fuzzing the kernel with syzkaller.
>>
>> On commit dc972a67cc54585bd83ad811c4e9b6ab3dcd427e (4.14-rc2+).
>>
>> It seems that out pointer ends up being NULL and kernel crashes on
>> access to out->desc.bEndpointAddress.
>>
>> gadgetfs: bound to dummy_udc driver
>> usb 1-1: new full-speed USB device number 2 using dummy_hcd
>> gadgetfs: connected
>> gadgetfs: disconnected
>> gadgetfs: connected
>> usb 1-1: config 2 interface 0 altsetting 206 endpoint 0x81 has invalid
>> maxpacket 2040, setting to 64
>> usb 1-1: config 2 interface 0 altsetting 206 has an invalid endpoint
>> with address 0xFF, skipping
>> usb 1-1: config 2 interface 0 altsetting 206 endpoint 0x5 has an
>> invalid bInterval 255, changing to 4
>> usb 1-1: config 2 interface 0 has no altsetting 0
>> usb 1-1: New USB device found, idVendor=0525, idProduct=a4a0
>> usb 1-1: New USB device strings: Mfr=0, Product=185, SerialNumber=1
>> usb 1-1: Product: a
>> usb 1-1: SerialNumber: a
>> gadgetfs: configuration #2
>> kasan: CONFIG_KASAN_INLINE enabled
>> kasan: GPF could be caused by NULL-ptr deref or user memory access
>> general protection fault:  [#1] PREEMPT SMP KASAN
>> Modules linked in:
>> CPU: 1 PID: 1845 Comm: kworker/1:2 Not tainted
>> 4.14.0-rc2-42664-gaf7d1481b3cb #297
>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>> Workqueue: usb_hub_wq hub_event
>> task: 880064328000 task.stack: 880064398000
>> RIP: 0010:get_endpoints drivers/usb/misc/usbtest.c:208
>> RIP: 0010:usbtest_probe+0x114f/0x1ef0 drivers/usb/misc/usbtest.c:2706
>
> This looks like a simple logic error.
>
> Alan Stern

Hi Alan,

This fixes it.

Tested-by: Andrey Konovalov <andreyk...@google.com>

Thanks!

>
>
>
> Index: usb-4.x/drivers/usb/misc/usbtest.c
> ===
> --- usb-4.x.orig/drivers/usb/misc/usbtest.c
> +++ usb-4.x/drivers/usb/misc/usbtest.c
> @@ -202,12 +202,13 @@ found:
> return tmp;
> }
>
> -   if (in) {
> +   if (in)
> dev->in_pipe = usb_rcvbulkpipe(udev,
> in->desc.bEndpointAddress & USB_ENDPOINT_NUMBER_MASK);
> +   if (out)
> dev->out_pipe = usb_sndbulkpipe(udev,
> out->desc.bEndpointAddress & 
> USB_ENDPOINT_NUMBER_MASK);
> -   }
> +
> if (iso_in) {
> dev->iso_in = _in->desc;
> dev->in_iso_pipe = usb_rcvisocpipe(udev,
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: usb/serial/visor: slab-out-of-bounds in palm_os_3_probe

[Andrey Konovalov]

On Fri, Sep 29, 2017 at 10:37 AM, Greg Kroah-Hartman
<gre...@linuxfoundation.org> wrote:
> On Thu, Sep 28, 2017 at 07:57:46PM +0200, Andrey Konovalov wrote:
>> Hi!
>>
>> I've got the following report while fuzzing the kernel with syzkaller.
>>
>> On commit dc972a67cc54585bd83ad811c4e9b6ab3dcd427e (4.14-rc2+).
>>
>> There's no check on the connection_info->num_ports value when
>> iterating over ports.
>>
>> usb 1-1: Handspring Visor / Palm OS: port 162, is for unknown use
>> usb 1-1: Handspring Visor / Palm OS: port 81, is for unknown use
>> ==
>> BUG: KASAN: slab-out-of-bounds in palm_os_3_probe+0x4e4/0x570
>> Read of size 1 at addr 8800686daa26 by task kworker/0:1/24
>>
>> CPU: 0 PID: 24 Comm: kworker/0:1 Not tainted 4.14.0-rc2-42748-gcd3da2fe6c25 
>> #324
>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>> Workqueue: usb_hub_wq hub_event
>> Call Trace:
>>  __dump_stack lib/dump_stack.c:16
>>  dump_stack+0x292/0x395 lib/dump_stack.c:52
>>  print_address_description+0x78/0x280 mm/kasan/report.c:252
>>  kasan_report_error mm/kasan/report.c:351
>>  kasan_report+0x23d/0x350 mm/kasan/report.c:409
>>  __asan_report_load1_noabort+0x19/0x20 mm/kasan/report.c:427
>>  palm_os_3_probe+0x4e4/0x570 drivers/usb/serial/visor.c:348
>>  visor_probe+0x11c/0x1e0 drivers/usb/serial/visor.c:463
>>  usb_serial_probe+0x540/0x4090 drivers/usb/serial/usb-serial.c:903
>>  usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361
>>  really_probe drivers/base/dd.c:413
>>  driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
>>  __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
>>  bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
>>  __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
>>  device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
>>  bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
>>  device_add+0xd0b/0x1660 drivers/base/core.c:1835
>>  usb_set_configuration+0x104e/0x1870 drivers/usb/core/message.c:1932
>>  generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174
>>  usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266
>>  really_probe drivers/base/dd.c:413
>>  driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
>>  __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
>>  bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
>>  __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
>>  device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
>>  bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
>>  device_add+0xd0b/0x1660 drivers/base/core.c:1835
>>  usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2538
>>  hub_port_connect drivers/usb/core/hub.c:4984
>>  hub_port_connect_change drivers/usb/core/hub.c:5090
>>  port_event drivers/usb/core/hub.c:5196
>>  hub_event_impl+0x1971/0x3760 drivers/usb/core/hub.c:5310
>>  hub_event+0x11b/0x3f0 drivers/usb/core/hub.c:5206
>>  process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119
>>  worker_thread+0x221/0x1850 kernel/workqueue.c:2253
>>  kthread+0x3a1/0x470 kernel/kthread.c:231
>>  ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431
>>
>> Allocated by task 24:
>>  save_stack_trace+0x1b/0x20 arch/x86/kernel/stacktrace.c:59
>>  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
>>  set_track mm/kasan/kasan.c:459
>>  kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551
>>  kmem_cache_alloc_trace+0x11e/0x2d0 mm/slub.c:2772
>>  kmalloc ./include/linux/slab.h:493
>>  palm_os_3_probe+0x7c/0x570 drivers/usb/serial/visor.c:325
>>  visor_probe+0x11c/0x1e0 drivers/usb/serial/visor.c:463
>>  usb_serial_probe+0x540/0x4090 drivers/usb/serial/usb-serial.c:903
>>  usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361
>>  really_probe drivers/base/dd.c:413
>>  driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
>>  __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
>>  bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
>>  __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
>>  device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
>>  bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
>>  device_add+0xd0b/0x1660 drivers/base/core.c:1835
>>  usb_set_configuration+0x104e/0x1870 drivers/usb/core/message.c:1932
>>  generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174
>>  usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266
>>  really_probe drivers/base/dd.c:413
>>  driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
>>  __device_attach_driver+0x230/0x290 drivers/b

usb/serial/visor: slab-out-of-bounds in palm_os_3_probe

[Andrey Konovalov]

Hi!

I've got the following report while fuzzing the kernel with syzkaller.

On commit dc972a67cc54585bd83ad811c4e9b6ab3dcd427e (4.14-rc2+).

There's no check on the connection_info->num_ports value when
iterating over ports.

usb 1-1: Handspring Visor / Palm OS: port 162, is for unknown use
usb 1-1: Handspring Visor / Palm OS: port 81, is for unknown use
==
BUG: KASAN: slab-out-of-bounds in palm_os_3_probe+0x4e4/0x570
Read of size 1 at addr 8800686daa26 by task kworker/0:1/24

CPU: 0 PID: 24 Comm: kworker/0:1 Not tainted 4.14.0-rc2-42748-gcd3da2fe6c25 #324
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: usb_hub_wq hub_event
Call Trace:
 __dump_stack lib/dump_stack.c:16
 dump_stack+0x292/0x395 lib/dump_stack.c:52
 print_address_description+0x78/0x280 mm/kasan/report.c:252
 kasan_report_error mm/kasan/report.c:351
 kasan_report+0x23d/0x350 mm/kasan/report.c:409
 __asan_report_load1_noabort+0x19/0x20 mm/kasan/report.c:427
 palm_os_3_probe+0x4e4/0x570 drivers/usb/serial/visor.c:348
 visor_probe+0x11c/0x1e0 drivers/usb/serial/visor.c:463
 usb_serial_probe+0x540/0x4090 drivers/usb/serial/usb-serial.c:903
 usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361
 really_probe drivers/base/dd.c:413
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
 bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
 __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
 bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
 device_add+0xd0b/0x1660 drivers/base/core.c:1835
 usb_set_configuration+0x104e/0x1870 drivers/usb/core/message.c:1932
 generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174
 usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266
 really_probe drivers/base/dd.c:413
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
 bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
 __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
 bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
 device_add+0xd0b/0x1660 drivers/base/core.c:1835
 usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2538
 hub_port_connect drivers/usb/core/hub.c:4984
 hub_port_connect_change drivers/usb/core/hub.c:5090
 port_event drivers/usb/core/hub.c:5196
 hub_event_impl+0x1971/0x3760 drivers/usb/core/hub.c:5310
 hub_event+0x11b/0x3f0 drivers/usb/core/hub.c:5206
 process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119
 worker_thread+0x221/0x1850 kernel/workqueue.c:2253
 kthread+0x3a1/0x470 kernel/kthread.c:231
 ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431

Allocated by task 24:
 save_stack_trace+0x1b/0x20 arch/x86/kernel/stacktrace.c:59
 save_stack+0x43/0xd0 mm/kasan/kasan.c:447
 set_track mm/kasan/kasan.c:459
 kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551
 kmem_cache_alloc_trace+0x11e/0x2d0 mm/slub.c:2772
 kmalloc ./include/linux/slab.h:493
 palm_os_3_probe+0x7c/0x570 drivers/usb/serial/visor.c:325
 visor_probe+0x11c/0x1e0 drivers/usb/serial/visor.c:463
 usb_serial_probe+0x540/0x4090 drivers/usb/serial/usb-serial.c:903
 usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361
 really_probe drivers/base/dd.c:413
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
 bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
 __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
 bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
 device_add+0xd0b/0x1660 drivers/base/core.c:1835
 usb_set_configuration+0x104e/0x1870 drivers/usb/core/message.c:1932
 generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174
 usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266
 really_probe drivers/base/dd.c:413
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
 bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
 __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
 bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
 device_add+0xd0b/0x1660 drivers/base/core.c:1835
 usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2538
 hub_port_connect drivers/usb/core/hub.c:4984
 hub_port_connect_change drivers/usb/core/hub.c:5090
 port_event drivers/usb/core/hub.c:5196
 hub_event_impl+0x1971/0x3760 drivers/usb/core/hub.c:5310
 hub_event+0x11b/0x3f0 drivers/usb/core/hub.c:5206
 process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119
 worker_thread+0x221/0x1850 kernel/workqueue.c:2253
 kthread+0x3a1/0x470 kernel/kthread.c:231
 ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431

Freed by task 2772:
 save_stack_trace+0x1b/0x20 arch/x86/kernel/stacktrace.c:59
 save_stack+0x43/0xd0 mm/kasan/kasan.c:447
 set_track 

usb/misc/usbtest: null-ptr-deref in usbtest_probe/get_endpoints

[Andrey Konovalov]

Hi!

I've got the following report while fuzzing the kernel with syzkaller.

On commit dc972a67cc54585bd83ad811c4e9b6ab3dcd427e (4.14-rc2+).

It seems that out pointer ends up being NULL and kernel crashes on
access to out->desc.bEndpointAddress.

gadgetfs: bound to dummy_udc driver
usb 1-1: new full-speed USB device number 2 using dummy_hcd
gadgetfs: connected
gadgetfs: disconnected
gadgetfs: connected
usb 1-1: config 2 interface 0 altsetting 206 endpoint 0x81 has invalid
maxpacket 2040, setting to 64
usb 1-1: config 2 interface 0 altsetting 206 has an invalid endpoint
with address 0xFF, skipping
usb 1-1: config 2 interface 0 altsetting 206 endpoint 0x5 has an
invalid bInterval 255, changing to 4
usb 1-1: config 2 interface 0 has no altsetting 0
usb 1-1: New USB device found, idVendor=0525, idProduct=a4a0
usb 1-1: New USB device strings: Mfr=0, Product=185, SerialNumber=1
usb 1-1: Product: a
usb 1-1: SerialNumber: a
gadgetfs: configuration #2
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault:  [#1] PREEMPT SMP KASAN
Modules linked in:
CPU: 1 PID: 1845 Comm: kworker/1:2 Not tainted
4.14.0-rc2-42664-gaf7d1481b3cb #297
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: usb_hub_wq hub_event
task: 880064328000 task.stack: 880064398000
RIP: 0010:get_endpoints drivers/usb/misc/usbtest.c:208
RIP: 0010:usbtest_probe+0x114f/0x1ef0 drivers/usb/misc/usbtest.c:2706
RSP: 0018:88006439e358 EFLAGS: 00010246
RAX: dc00 RBX:  RCX: 11000c873c33
RDX:  RSI: 0006 RDI: 0002
RBP: 88006439e5e8 R08: 88006439dd60 R09: 11000c873bc5
R10: 880064328000 R11: 0005 R12: 88006197e698
R13: 880067755d28 R14: 88006439e5c0 R15: 88006782ddc0
FS:  () GS:88006c90() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 20002e07 CR3: 639a9000 CR4: 06e0
Call Trace:
 usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361
 really_probe drivers/base/dd.c:413
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
 bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
 __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
 bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
 device_add+0xd0b/0x1660 drivers/base/core.c:1835
 usb_set_configuration+0x104e/0x1870 drivers/usb/core/message.c:1932
 generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174
 usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266
 really_probe drivers/base/dd.c:413
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
 bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
 __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
 bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
 device_add+0xd0b/0x1660 drivers/base/core.c:1835
 usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2457
 hub_port_connect drivers/usb/core/hub.c:4903
 hub_port_connect_change drivers/usb/core/hub.c:5009
 port_event drivers/usb/core/hub.c:5115
 hub_event+0x194d/0x3740 drivers/usb/core/hub.c:5195
 process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119
 worker_thread+0x221/0x1850 kernel/workqueue.c:2253
 kthread+0x3a1/0x470 kernel/kthread.c:231
 ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431
Code: 8b bd 30 fe ff ff e8 d1 60 05 fe 48 b8 00 00 00 00 00 fc ff df
41 89 5f 10 49 8b 9e c0 fe ff ff 48 8d 7b 02 48 89 fa 48 c1 ea 03 <0f>
b6 04 02 48 89 fa 83 e2 07 38 d0 7f 09 84 c0 74 05 e8 ba 5f
RIP: usbtest_probe+0x114f/0x1ef0 RSP: 88006439e358
---[ end trace 005817b8c41d50d0 ]---
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

usb/misc/rio500: double-free or invalid-free in disconnect_rio

[Andrey Konovalov]

Hi!

I've got the following report while fuzzing the kernel with syzkaller.

On commit e19b205be43d11bff638cad4487008c48d21c103 (4.14-rc2).

gadgetfs: bound to dummy_udc driver
usb 1-1: new full-speed USB device number 2 using dummy_hcd
gadgetfs: connected
gadgetfs: disconnected
gadgetfs: connected
usb 1-1: config 3 has an invalid interface number: 220 but max is 0
usb 1-1: config 3 has an invalid interface number: 199 but max is 0
usb 1-1: config 3 has 2 interfaces, different from the descriptor's value: 1
usb 1-1: config 3 has no interface number 0
usb 1-1: config 3 has no interface number 1
usb 1-1: too many endpoints for config 3 interface 199 altsetting 74:
151, using maximum allowed: 30
usb 1-1: config 3 interface 199 altsetting 74 has 0 endpoint
descriptors, different from the interface d
escriptor's value: 151
usb 1-1: config 3 interface 199 has no altsetting 0
usb 1-1: New USB device found, idVendor=0841, idProduct=0001
usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
gadgetfs: configuration #3
rio500 1-1:3.220: USB Rio found at address 2
rio500 1-1:3.199: USB Rio found at address 2
gadgetfs: disconnected
usb 1-1: USB disconnect, device number 2
rio500 1-1:3.220: USB Rio disconnected.
==
BUG: KASAN: double-free or invalid-free in disconnect_rio+0xef/0x200

CPU: 0 PID: 24 Comm: kworker/0:1 Not tainted 4.14.0-rc2-42660-g24b7bd59eec0 #277
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: usb_hub_wq hub_event
Call Trace:
 __dump_stack lib/dump_stack.c:16
 dump_stack+0x292/0x395 lib/dump_stack.c:52
 print_address_description+0x78/0x280 mm/kasan/report.c:252
 kasan_report_double_free+0x5a/0x80 mm/kasan/report.c:333
 kasan_slab_free+0xa4/0xc0 mm/kasan/kasan.c:514
 slab_free_hook mm/slub.c:1390
 slab_free_freelist_hook mm/slub.c:1412
 slab_free mm/slub.c:2988
 kfree+0xf6/0x2f0 mm/slub.c:3919
 disconnect_rio+0xef/0x200 drivers/usb/misc/rio500.c:519
 usb_unbind_interface+0x21c/0xa90 drivers/usb/core/driver.c:423
 __device_release_driver drivers/base/dd.c:861
 device_release_driver_internal+0x4f4/0x5c0 drivers/base/dd.c:893
 device_release_driver+0x1e/0x30 drivers/base/dd.c:918
 bus_remove_device+0x2f4/0x4b0 drivers/base/bus.c:565
 device_del+0x5c4/0xab0 drivers/base/core.c:1985
 usb_disable_device+0x1e9/0x680 drivers/usb/core/message.c:1170
 usb_disconnect+0x260/0x7a0 drivers/usb/core/hub.c:2124
 hub_port_connect drivers/usb/core/hub.c:4754
 hub_port_connect_change drivers/usb/core/hub.c:5009
 port_event drivers/usb/core/hub.c:5115
 hub_event+0x1318/0x3740 drivers/usb/core/hub.c:5195
 process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119
 worker_thread+0x221/0x1850 kernel/workqueue.c:2253
 kthread+0x3a1/0x470 kernel/kthread.c:231
 ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431

Allocated by task 24:
 save_stack_trace+0x1b/0x20 arch/x86/kernel/stacktrace.c:59
 save_stack+0x43/0xd0 mm/kasan/kasan.c:447
 set_track mm/kasan/kasan.c:459
 kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551
 kmem_cache_alloc_trace+0x11e/0x2d0 mm/slub.c:2772
 kmalloc ./include/linux/slab.h:493
 probe_rio+0x100/0x230 drivers/usb/misc/rio500.c:484
 usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361
 really_probe drivers/base/dd.c:413
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
 bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
 __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
 bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
 device_add+0xd0b/0x1660 drivers/base/core.c:1835
 usb_set_configuration+0x104e/0x1870 drivers/usb/core/message.c:1932
 generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174
 usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266
 really_probe drivers/base/dd.c:413
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
 bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
 __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
 bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
 device_add+0xd0b/0x1660 drivers/base/core.c:1835
 usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2457
 hub_port_connect drivers/usb/core/hub.c:4903
 hub_port_connect_change drivers/usb/core/hub.c:5009
 port_event drivers/usb/core/hub.c:5115
 hub_event+0x194d/0x3740 drivers/usb/core/hub.c:5195
 process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119
 worker_thread+0x221/0x1850 kernel/workqueue.c:2253
 kthread+0x3a1/0x470 kernel/kthread.c:231
 ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431

Freed by task 24:
 save_stack_trace+0x1b/0x20 arch/x86/kernel/stacktrace.c:59
 save_stack+0x43/0xd0 mm/kasan/kasan.c:447
 set_track mm/kasan/kasan.c:459
 kasan_slab_free+0x72/0xc0 mm/kasan/kasan.c:524
 slab_free_hook mm/slub.c:1390
 slab_free_freelist_hook mm/slub.c:1412
 slab_free 

usb/serial: use-after-free in usb_serial_disconnect/__lock_acquire

[Andrey Konovalov]

Hi!

I've got the following report while fuzzing the kernel with syzkaller.

On commit e19b205be43d11bff638cad4487008c48d21c103 (4.14-rc2).

gadgetfs: bound to dummy_udc driver
usb 1-1: new full-speed USB device number 2 using dummy_hcd
gadgetfs: connected
gadgetfs: disconnected
gadgetfs: connected
usb 1-1: config 4 has an invalid interface number: 1 but max is 0
usb 1-1: config 4 has an invalid interface number: 153 but max is 0
usb 1-1: config 4 has 2 interfaces, different from the descriptor's value: 1
usb 1-1: config 4 has no interface number 0
usb 1-1: config 4 interface 1 altsetting 255 has an invalid endpoint
with address 0x0, skipping
usb 1-1: config 4 interface 1 altsetting 255 has an invalid endpoint
with address 0xFF, skipping
usb 1-1: config 4 interface 1 altsetting 255 has an invalid endpoint
with address 0x56, skipping
usb 1-1: too many endpoints for config 4 interface 153 altsetting 67:
174, using maximum allowed: 30
usb 1-1: config 4 interface 153 altsetting 67 has 0 endpoint
descriptors, different from the interface d
escriptor's value: 174
usb 1-1: config 4 interface 1 has no altsetting 0
usb 1-1: config 4 interface 153 has no altsetting 0
usb 1-1: New USB device found, idVendor=1199, idProduct=6832
usb 1-1: New USB device strings: Mfr=4, Product=20, SerialNumber=3
usb 1-1: Product: a
usb 1-1: Manufacturer: a
usb 1-1: SerialNumber: a
gadgetfs: configuration #4
sierra 1-1:4.1: Sierra USB modem converter detected
usb 1-1: Sierra USB modem converter now attached to ttyUSB0
sierra 1-1:4.153: Sierra USB modem converter detected
gadgetfs: disconnected
usb 1-1: USB disconnect, device number 2
sierra ttyUSB0: Sierra USB modem converter now disconnected from ttyUSB0
sierra 1-1:4.1: device disconnected
==
BUG: KASAN: use-after-free in __lock_acquire+0x4504/0x4550
Read of size 8 at addr 8800674df790 by task kworker/1:2/1846

CPU: 1 PID: 1846 Comm: kworker/1:2 Not tainted
4.14.0-rc2-42660-g24b7bd59eec0 #277
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: usb_hub_wq hub_event
Call Trace:
 __dump_stack lib/dump_stack.c:16
 dump_stack+0x292/0x395 lib/dump_stack.c:52
 print_address_description+0x78/0x280 mm/kasan/report.c:252
 kasan_report_error mm/kasan/report.c:351
 kasan_report+0x23d/0x350 mm/kasan/report.c:409
 __asan_report_load8_noabort+0x19/0x20 mm/kasan/report.c:430
 __lock_acquire+0x4504/0x4550 kernel/locking/lockdep.c:3376
 lock_acquire+0x259/0x620 kernel/locking/lockdep.c:4002
 __mutex_lock_common kernel/locking/mutex.c:756
 __mutex_lock+0x18e/0x1a50 kernel/locking/mutex.c:893
 mutex_lock_nested+0x1b/0x20 kernel/locking/mutex.c:908
 usb_serial_disconnect+0x69/0x2e0 drivers/usb/serial/usb-serial.c:1084
 usb_unbind_interface+0x21c/0xa90 drivers/usb/core/driver.c:423
 __device_release_driver drivers/base/dd.c:861
 device_release_driver_internal+0x4f4/0x5c0 drivers/base/dd.c:893
 device_release_driver+0x1e/0x30 drivers/base/dd.c:918
 bus_remove_device+0x2f4/0x4b0 drivers/base/bus.c:565
 device_del+0x5c4/0xab0 drivers/base/core.c:1985
 usb_disable_device+0x1e9/0x680 drivers/usb/core/message.c:1170
 usb_disconnect+0x260/0x7a0 drivers/usb/core/hub.c:2124
 hub_port_connect drivers/usb/core/hub.c:4754
 hub_port_connect_change drivers/usb/core/hub.c:5009
 port_event drivers/usb/core/hub.c:5115
 hub_event+0x1318/0x3740 drivers/usb/core/hub.c:5195
 process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119
 worker_thread+0x221/0x1850 kernel/workqueue.c:2253
 kthread+0x3a1/0x470 kernel/kthread.c:231
 ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431

Allocated by task 1846:
 save_stack_trace+0x1b/0x20 arch/x86/kernel/stacktrace.c:59
 save_stack+0x43/0xd0 mm/kasan/kasan.c:447
 set_track mm/kasan/kasan.c:459
 kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551
 kmem_cache_alloc_trace+0x11e/0x2d0 mm/slub.c:2772
 kmalloc ./include/linux/slab.h:493
 kzalloc ./include/linux/slab.h:666
 create_serial drivers/usb/serial/usb-serial.c:605
 usb_serial_probe+0x36f/0x4090 drivers/usb/serial/usb-serial.c:892
 usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361
 really_probe drivers/base/dd.c:413
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
 bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
 __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
 bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
 device_add+0xd0b/0x1660 drivers/base/core.c:1835
 usb_set_configuration+0x104e/0x1870 drivers/usb/core/message.c:1932
 generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174
 usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266
 really_probe drivers/base/dd.c:413
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
 bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
 __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
 

Re: [RFT] lan78xx: FIX use-after-free in lan78xx_write_reg

[Andrey Konovalov]

On Wed, Sep 27, 2017 at 2:06 PM, Andrey Konovalov <andreyk...@google.com> wrote:
> On Wed, Sep 27, 2017 at 1:18 PM, Arvind Yadav <arvind.yadav...@gmail.com> 
> wrote:
>> We are not releasing 'buf' memory on failure or disconnect a device.
>>
>> Adding 'u8 *buf' as part of 'lan78xx_net' structure to make proper
>> handle for 'buf'.
>> Now releasing 'buf' memory on failure. It's allocate first in
>> lan78xx_probe() and it should be freed last in lan78xx_disconnect().
>>
>> Signed-off-by: Arvind Yadav <arvind.yadav...@gmail.com>
>
> Hi Arvind,
>
> I've tried your patch and still see a crash.
>
> Thanks!
>
> lan78xx 1-1:90.0 (unnamed net_device) (uninitialized): can't register MDIO bus
> lan78xx: probe of 1-1:90.0 failed with error -5
> usb 1-1: USB disconnect, device number 2
> ==
> BUG: KASAN: use-after-free in lan78xx_write_reg.isra.21+0x1a8/0x1b0
> Read of size 8 at addr 880063dfac40 by task kworker/1:1/1152

It seems that the bug is caused by the fact that the
lan78xx_deferred_multicast_write() work is not shut down on
lan78xx_probe() failure.

>
> CPU: 1 PID: 1152 Comm: kworker/1:1 Not tainted
> 4.14.0-rc2-42660-g24b7bd59eec0-dirty #274
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> Workqueue: events lan78xx_deferred_multicast_write
> Call Trace:
>  __dump_stack lib/dump_stack.c:16
>  dump_stack+0x292/0x395 lib/dump_stack.c:52
>  print_address_description+0x78/0x280 mm/kasan/report.c:252
>  kasan_report_error mm/kasan/report.c:351
>  kasan_report+0x23d/0x350 mm/kasan/report.c:409
>  __asan_report_load8_noabort+0x19/0x20 mm/kasan/report.c:430
>  lan78xx_write_reg.isra.21+0x1a8/0x1b0 drivers/net/usb/lan78xx.c:459
>  lan78xx_deferred_multicast_write+0x10d/0x1a0 drivers/net/usb/lan78xx.c:1043
>  process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119
>  worker_thread+0x221/0x1850 kernel/workqueue.c:2253
>  kthread+0x3a1/0x470 kernel/kthread.c:231
>  ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431
>
> Allocated by task 1848:
>  save_stack_trace+0x1b/0x20 arch/x86/kernel/stacktrace.c:59
>  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
>  set_track mm/kasan/kasan.c:459
>  kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551
>  __kmalloc_node+0x192/0x480 mm/slub.c:3827
>  kmalloc_node ./include/linux/slab.h:535
>  kvmalloc_node+0x69/0xd0 mm/util.c:397
>  kvmalloc ./include/linux/mm.h:529
>  kvzalloc ./include/linux/mm.h:537
>  alloc_netdev_mqs+0x173/0xea0 net/core/dev.c:8023
>  alloc_etherdev_mqs+0x38/0x40 net/ethernet/eth.c:391
>  lan78xx_probe+0x13a/0x3020 drivers/net/usb/lan78xx.c:3545
>  usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361
>  really_probe drivers/base/dd.c:413
>  driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
>  __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
>  bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
>  __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
>  device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
>  bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
>  device_add+0xd0b/0x1660 drivers/base/core.c:1835
>  usb_set_configuration+0x104e/0x1870 drivers/usb/core/message.c:1932
>  generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174
>  usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266
>  really_probe drivers/base/dd.c:413
>  driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
>  __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
>  bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
>  __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
>  device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
>  bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
>  device_add+0xd0b/0x1660 drivers/base/core.c:1835
>  usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2457
>  hub_port_connect drivers/usb/core/hub.c:4903
>  hub_port_connect_change drivers/usb/core/hub.c:5009
>  port_event drivers/usb/core/hub.c:5115
>  hub_event+0x194d/0x3740 drivers/usb/core/hub.c:5195
>  process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119
>  worker_thread+0x221/0x1850 kernel/workqueue.c:2253
>  kthread+0x3a1/0x470 kernel/kthread.c:231
>  ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431
>
> Freed by task 1848:
>  save_stack_trace+0x1b/0x20 arch/x86/kernel/stacktrace.c:59
>  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
>  set_track mm/kasan/kasan.c:459
>  kasan_slab_free+0x72/0xc0 mm/kasan/kasan.c:524
>  slab_free_hook mm/slub.c:1390
>  slab_free_freelist_hook mm/slub.c:1412
>  slab_free mm/slub.c:2988
>  kfree+0xf6/0x2f0 mm/slub.c:3919
>  kvfree+0x3b/0x60 mm/util.c:416
>  netdev_freemem net/core/dev.c:7975
>  free_netdev+0x304/0x3c0 net/core/dev.

Re: [RFT] lan78xx: FIX use-after-free in lan78xx_write_reg

[Andrey Konovalov]

On Wed, Sep 27, 2017 at 1:18 PM, Arvind Yadav  wrote:
> We are not releasing 'buf' memory on failure or disconnect a device.
>
> Adding 'u8 *buf' as part of 'lan78xx_net' structure to make proper
> handle for 'buf'.
> Now releasing 'buf' memory on failure. It's allocate first in
> lan78xx_probe() and it should be freed last in lan78xx_disconnect().
>
> Signed-off-by: Arvind Yadav 

Hi Arvind,

I've tried your patch and still see a crash.

Thanks!

lan78xx 1-1:90.0 (unnamed net_device) (uninitialized): can't register MDIO bus
lan78xx: probe of 1-1:90.0 failed with error -5
usb 1-1: USB disconnect, device number 2
==
BUG: KASAN: use-after-free in lan78xx_write_reg.isra.21+0x1a8/0x1b0
Read of size 8 at addr 880063dfac40 by task kworker/1:1/1152

CPU: 1 PID: 1152 Comm: kworker/1:1 Not tainted
4.14.0-rc2-42660-g24b7bd59eec0-dirty #274
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: events lan78xx_deferred_multicast_write
Call Trace:
 __dump_stack lib/dump_stack.c:16
 dump_stack+0x292/0x395 lib/dump_stack.c:52
 print_address_description+0x78/0x280 mm/kasan/report.c:252
 kasan_report_error mm/kasan/report.c:351
 kasan_report+0x23d/0x350 mm/kasan/report.c:409
 __asan_report_load8_noabort+0x19/0x20 mm/kasan/report.c:430
 lan78xx_write_reg.isra.21+0x1a8/0x1b0 drivers/net/usb/lan78xx.c:459
 lan78xx_deferred_multicast_write+0x10d/0x1a0 drivers/net/usb/lan78xx.c:1043
 process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119
 worker_thread+0x221/0x1850 kernel/workqueue.c:2253
 kthread+0x3a1/0x470 kernel/kthread.c:231
 ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431

Allocated by task 1848:
 save_stack_trace+0x1b/0x20 arch/x86/kernel/stacktrace.c:59
 save_stack+0x43/0xd0 mm/kasan/kasan.c:447
 set_track mm/kasan/kasan.c:459
 kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551
 __kmalloc_node+0x192/0x480 mm/slub.c:3827
 kmalloc_node ./include/linux/slab.h:535
 kvmalloc_node+0x69/0xd0 mm/util.c:397
 kvmalloc ./include/linux/mm.h:529
 kvzalloc ./include/linux/mm.h:537
 alloc_netdev_mqs+0x173/0xea0 net/core/dev.c:8023
 alloc_etherdev_mqs+0x38/0x40 net/ethernet/eth.c:391
 lan78xx_probe+0x13a/0x3020 drivers/net/usb/lan78xx.c:3545
 usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361
 really_probe drivers/base/dd.c:413
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
 bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
 __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
 bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
 device_add+0xd0b/0x1660 drivers/base/core.c:1835
 usb_set_configuration+0x104e/0x1870 drivers/usb/core/message.c:1932
 generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174
 usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266
 really_probe drivers/base/dd.c:413
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
 bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
 __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
 bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
 device_add+0xd0b/0x1660 drivers/base/core.c:1835
 usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2457
 hub_port_connect drivers/usb/core/hub.c:4903
 hub_port_connect_change drivers/usb/core/hub.c:5009
 port_event drivers/usb/core/hub.c:5115
 hub_event+0x194d/0x3740 drivers/usb/core/hub.c:5195
 process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119
 worker_thread+0x221/0x1850 kernel/workqueue.c:2253
 kthread+0x3a1/0x470 kernel/kthread.c:231
 ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431

Freed by task 1848:
 save_stack_trace+0x1b/0x20 arch/x86/kernel/stacktrace.c:59
 save_stack+0x43/0xd0 mm/kasan/kasan.c:447
 set_track mm/kasan/kasan.c:459
 kasan_slab_free+0x72/0xc0 mm/kasan/kasan.c:524
 slab_free_hook mm/slub.c:1390
 slab_free_freelist_hook mm/slub.c:1412
 slab_free mm/slub.c:2988
 kfree+0xf6/0x2f0 mm/slub.c:3919
 kvfree+0x3b/0x60 mm/util.c:416
 netdev_freemem net/core/dev.c:7975
 free_netdev+0x304/0x3c0 net/core/dev.c:8137
 lan78xx_probe+0x21a4/0x3020 drivers/net/usb/lan78xx.c:3649
 usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361
 really_probe drivers/base/dd.c:413
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
 bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
 __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
 bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
 device_add+0xd0b/0x1660 drivers/base/core.c:1835
 usb_set_configuration+0x104e/0x1870 drivers/usb/core/message.c:1932
 generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174
 usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266
 

usb/net/lan78xx: use-after-free in lan78xx_write_reg

[Andrey Konovalov]

Hi!

I've got the following report while fuzzing the kernel with syzkaller.

On commit e19b205be43d11bff638cad4487008c48d21c103 (4.14-rc2).

==
BUG: KASAN: use-after-free in lan78xx_write_reg.isra.21+0x1a8/0x1b0
Read of size 8 at addr 8800683e2c40 by task kworker/0:3/2551

CPU: 0 PID: 2551 Comm: kworker/0:3 Not tainted
4.14.0-rc2-42613-g1488251d1a98 #256
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: events lan78xx_deferred_multicast_write
Call Trace:
 __dump_stack lib/dump_stack.c:16
 dump_stack+0x292/0x395 lib/dump_stack.c:52
 print_address_description+0x78/0x280 mm/kasan/report.c:252
 kasan_report_error mm/kasan/report.c:351
 kasan_report+0x23d/0x350 mm/kasan/report.c:409
 __asan_report_load8_noabort+0x19/0x20 mm/kasan/report.c:430
 lan78xx_write_reg.isra.21+0x1a8/0x1b0 drivers/net/usb/lan78xx.c:458
 lan78xx_deferred_multicast_write+0x10d/0x1a0 drivers/net/usb/lan78xx.c:1042
 process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119
 worker_thread+0x221/0x1850 kernel/workqueue.c:2253
 kthread+0x3a1/0x470 kernel/kthread.c:231
 ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431

Allocated by task 24:
 save_stack_trace+0x1b/0x20 arch/x86/kernel/stacktrace.c:59
 save_stack+0x43/0xd0 mm/kasan/kasan.c:447
 set_track mm/kasan/kasan.c:459
 kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551
 __kmalloc_node+0x192/0x480 mm/slub.c:3827
 kmalloc_node ./include/linux/slab.h:535
 kvmalloc_node+0x69/0xd0 mm/util.c:397
 kvmalloc ./include/linux/mm.h:529
 kvzalloc ./include/linux/mm.h:537
 alloc_netdev_mqs+0x173/0xea0 net/core/dev.c:8023
 alloc_etherdev_mqs+0x38/0x40 net/ethernet/eth.c:391
 lan78xx_probe+0x13a/0x2f10 drivers/net/usb/lan78xx.c:3542
 usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361
 really_probe drivers/base/dd.c:413
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
 bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
 __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
 bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
 device_add+0xd0b/0x1660 drivers/base/core.c:1835
 usb_set_configuration+0x104e/0x1870 drivers/usb/core/message.c:1932
 generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174
 usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266
 really_probe drivers/base/dd.c:413
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
 bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
 __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
 bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
 device_add+0xd0b/0x1660 drivers/base/core.c:1835
 usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2457
 hub_port_connect drivers/usb/core/hub.c:4903
 hub_port_connect_change drivers/usb/core/hub.c:5009
 port_event drivers/usb/core/hub.c:5115
 hub_event+0x194d/0x3740 drivers/usb/core/hub.c:5195
 process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119
 worker_thread+0x221/0x1850 kernel/workqueue.c:2253
 kthread+0x3a1/0x470 kernel/kthread.c:231
 ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431

Freed by task 24:
 save_stack_trace+0x1b/0x20 arch/x86/kernel/stacktrace.c:59
 save_stack+0x43/0xd0 mm/kasan/kasan.c:447
 set_track mm/kasan/kasan.c:459
 kasan_slab_free+0x72/0xc0 mm/kasan/kasan.c:524
 slab_free_hook mm/slub.c:1390
 slab_free_freelist_hook mm/slub.c:1412
 slab_free mm/slub.c:2988
 kfree+0xf6/0x2f0 mm/slub.c:3919
 kvfree+0x3b/0x60 mm/util.c:416
 netdev_freemem net/core/dev.c:7975
 free_netdev+0x304/0x3c0 net/core/dev.c:8137
 lan78xx_probe+0x20cc/0x2f10 drivers/net/usb/lan78xx.c:3645
 usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361
 really_probe drivers/base/dd.c:413
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
 bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
 __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
 bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
 device_add+0xd0b/0x1660 drivers/base/core.c:1835
 usb_set_configuration+0x104e/0x1870 drivers/usb/core/message.c:1932
 generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174
 usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266
 really_probe drivers/base/dd.c:413
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
 bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
 __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
 bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
 device_add+0xd0b/0x1660 drivers/base/core.c:1835
 usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2457
 hub_port_connect drivers/usb/core/hub.c:4903
 hub_port_connect_change 

usb/media/zr364xx: GPF in zr364xx_vidioc_querycap/strlcpy

[Andrey Konovalov]

Hi!

I've got the following report while fuzzing the kernel with syzkaller.

On commit ebb2c2437d8008d46796902ff390653822af6cc4 (Sep 18).

usb 1-1: new full-speed USB device number 2 using dummy_hcd
gadgetfs: connected
gadgetfs: disconnected
gadgetfs: connected
usb 1-1: config 225 has an invalid interface number: 1 but max is 0
usb 1-1: config 225 has no interface number 0
usb 1-1: config 225 interface 1 altsetting 0 endpoint 0x5 has invalid
maxpacket 2047, setting to 64
usb 1-1: config 225 interface 1 altsetting 0 has an invalid endpoint
with address 0xF5, skipping
usb 1-1: config 225 interface 1 altsetting 0 endpoint 0x8A has invalid
maxpacket 2047, setting to 64
usb 1-1: config 225 interface 1 altsetting 0 endpoint 0x81 has an
invalid bInterval 0, changing to 10
usb 1-1: config 225 interface 1 altsetting 0 endpoint 0x81 has invalid
maxpacket 1025, setting to 64
usb 1-1: config 225 interface 1 altsetting 0 has an invalid endpoint
with address 0xF7, skipping
usb 1-1: config 225 interface 1 altsetting 0 has an invalid endpoint
with address 0xB8, skipping
usb 1-1: New USB device found, idVendor=041e, idProduct=4024
usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=1
usb 1-1: SerialNumber: a
gadgetfs: configuration #225
zr364xx 1-1:225.1: Zoran 364xx compatible webcam plugged
zr364xx 1-1:225.1: model 041e:4024 detected
usb 1-1: 320x240 mode selected
usb 1-1: Zoran 364xx controlling device video0
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault:  [#1] PREEMPT SMP KASAN
Modules linked in:
CPU: 0 PID: 4306 Comm: v4l_id Not tainted 4.14.0-rc1-42261-ga67ef73a6f27 #225
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
task: 88006a27e300 task.stack: 880067f7
RIP: 0010:strlcpy+0x21/0x120 lib/string.c:140
RSP: 0018:880067f777a0 EFLAGS: 00010286
RAX: dc00 RBX: 880067f77c00 RCX: 
RDX: 0020 RSI:  RDI: 880067f77c10
RBP: 880067f777c8 R08: ed000cfeef82 R09: ed000cfeef82
R10: 0002 R11: ed000cfeef81 R12: 880067f77c10
R13: 880063034400 R14: 8000 R15: 880063193180
FS:  7f5561fe8700() GS:88006c80() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 7f5561b16110 CR3: 6b00c000 CR4: 06f0
Call Trace:
 zr364xx_vidioc_querycap+0xb8/0x220 drivers/media/usb/zr364xx/zr364xx.c:709
 v4l_querycap+0x134/0x370 drivers/media/v4l2-core/v4l2-ioctl.c:1008
 __video_do_ioctl+0x9c6/0xa80 drivers/media/v4l2-core/v4l2-ioctl.c:2750
 video_usercopy+0x4ea/0x1580 drivers/media/v4l2-core/v4l2-ioctl.c:2926
 video_ioctl2+0x31/0x40 drivers/media/v4l2-core/v4l2-ioctl.c:2968
 v4l2_ioctl+0x1c5/0x310 drivers/media/v4l2-core/v4l2-dev.c:360
 vfs_ioctl fs/ioctl.c:45
 do_vfs_ioctl+0x1c4/0x15c0 fs/ioctl.c:685
 SYSC_ioctl fs/ioctl.c:700
 SyS_ioctl+0x94/0xc0 fs/ioctl.c:691
 entry_SYSCALL_64_fastpath+0x23/0xc2 arch/x86/entry/entry_64.S:202
RIP: 0033:0x7f5561b1b347
RSP: 002b:7ffd403d19a8 EFLAGS: 0202 ORIG_RAX: 0010
RAX: ffda RBX: 7ffd403d1b00 RCX: 7f5561b1b347
RDX: 7ffd403d19b0 RSI: 80685600 RDI: 0003
RBP: 00400884 R08:  R09: 
R10:  R11: 0202 R12: 0003
R13: 7ffd403d1b00 R14:  R15: 
Code: 8b 45 f0 e9 64 ff ff ff 66 90 48 b8 00 00 00 00 00 fc ff df 55
48 89 f1 48 89 e5 48 c1 e9 03 41 55 41 54 49 89 fc 53 48 83 ec 10 <0f>
b6 04 01 48 89 f1 83 e1 07 38 c8 7f 08 84 c0 0f 85 9d 00 00
RIP: strlcpy+0x21/0x120 RSP: 880067f777a0
---[ end trace 23c9876972269088 ]---
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: usb/storage/uas: slab-out-of-bounds in uas_probe

[Andrey Konovalov]

On Thu, Sep 21, 2017 at 9:04 PM, Alan Stern <st...@rowland.harvard.edu> wrote:
> On Thu, 21 Sep 2017, Andrey Konovalov wrote:
>
>> On Thu, Sep 21, 2017 at 6:10 PM, Greg Kroah-Hartman
>> <gre...@linuxfoundation.org> wrote:
>> > On Thu, Sep 21, 2017 at 05:39:05PM +0200, Andrey Konovalov wrote:
>> >> Hi!
>> >>
>> >> I've got the following report while fuzzing the kernel with syzkaller.
>> >>
>> >> On commit ebb2c2437d8008d46796902ff390653822af6cc4 (Sep 18).
>> >>
>> >> The issue occurs when we iterate over interface altsettings, but I
>> >> don't see the driver doing anything wrong. I might be missing
>> >> something, or this might be an issue in USB core altsettings parsing.
>> >
>> >
>> > Any chance you happen to have the descriptors that you were feeding into
>> > the kernel at this crash?  That might help in figuring out what "went
>> > wrong".
>>
>> Here's the data that I feed into dummy_udc:
>>
>> 00 00 00 00 09 02 12 00 01 34 05 80 07 09 04 6e
>> 09 00 08 06 62 00 12 01 05 00 cb f7 71 83 04 00
>> 05 00 ab f6 07 81 08 01
>>
>> Also attaching a C reproducer (requires dummy_hcd and gadgetfs) and my 
>> .config.
>
> Why do your reproducers use an mmap'ed array for their data instead of
> a plain old statically allocated array?

That's just the way syzkaller generates reproducers, it uses mmap() to
allocate memory to feed into syscalls.

>
> Anyway, this turns out to be a genuine (and subtle!) bug in the uas
> driver.  The uas_find_uas_alt_setting() routine in uas-detect.h returns
> a bAlternateSetting value, but then the uas_use_uas_driver() routine
> uses this value as an index to the altsetting array -- which it isn't.
>
> Normally this doesn't cause any problems because the the entries in the
> array have bAlternateSetting values 0, 1, etc., so the value is equal
> to the index.  But in your fuzzed case, that wasn't true.
>
> The patch below fixes this bug, by returning a pointer to the
> alt-setting entry instead of either the value or the index.  Pointers
> are less subject to misinterpretation.

The patch helps, thanks!

Tested-by: Andrey Konovalov <andreyk...@google.com>

>
> Alan Stern
>
>
>
> Index: usb-4.x/drivers/usb/storage/uas-detect.h
> ===
> --- usb-4.x.orig/drivers/usb/storage/uas-detect.h
> +++ usb-4.x/drivers/usb/storage/uas-detect.h
> @@ -9,7 +9,8 @@ static int uas_is_interface(struct usb_h
> intf->desc.bInterfaceProtocol == USB_PR_UAS);
>  }
>
> -static int uas_find_uas_alt_setting(struct usb_interface *intf)
> +static struct usb_host_interface *uas_find_uas_alt_setting(
> +   struct usb_interface *intf)
>  {
> int i;
>
> @@ -17,10 +18,10 @@ static int uas_find_uas_alt_setting(stru
> struct usb_host_interface *alt = >altsetting[i];
>
> if (uas_is_interface(alt))
> -   return alt->desc.bAlternateSetting;
> +   return alt;
> }
>
> -   return -ENODEV;
> +   return NULL;
>  }
>
>  static int uas_find_endpoints(struct usb_host_interface *alt,
> @@ -58,14 +59,14 @@ static int uas_use_uas_driver(struct usb
> struct usb_device *udev = interface_to_usbdev(intf);
> struct usb_hcd *hcd = bus_to_hcd(udev->bus);
> unsigned long flags = id->driver_info;
> -   int r, alt;
> -
> +   struct usb_host_interface *alt;
> +   int r;
>
> alt = uas_find_uas_alt_setting(intf);
> -   if (alt < 0)
> +   if (!alt)
> return 0;
>
> -   r = uas_find_endpoints(>altsetting[alt], eps);
> +   r = uas_find_endpoints(alt, eps);
> if (r < 0)
> return 0;
>
> Index: usb-4.x/drivers/usb/storage/uas.c
> ===
> --- usb-4.x.orig/drivers/usb/storage/uas.c
> +++ usb-4.x/drivers/usb/storage/uas.c
> @@ -873,14 +873,14 @@ MODULE_DEVICE_TABLE(usb, uas_usb_ids);
>  static int uas_switch_interface(struct usb_device *udev,
> struct usb_interface *intf)
>  {
> -   int alt;
> +   struct usb_host_interface *alt;
>
> alt = uas_find_uas_alt_setting(intf);
> -   if (alt < 0)
> -   return alt;
> +   if (!alt)
> +   return -ENODEV;
>
> -   return usb_set_interface(udev,
> -   intf->altsetting[0].desc.bInterfaceNumber, alt);
> +   return usb_set_interface(udev, alt->desc.bInterfaceNumber,
> +   alt->desc.bAlternateSetting);
>  }
>
>  static int uas_configure_endpoints(struct uas_dev_info *devinfo)
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: usb/gadget: copy_to_user called with spinlock held

[Andrey Konovalov]

On Thu, Sep 21, 2017 at 7:35 PM, Alan Stern <st...@rowland.harvard.edu> wrote:
> On Thu, 21 Sep 2017, Andrey Konovalov wrote:
>
>> Hi!
>>
>> I've got the following report while fuzzing the kernel with syzkaller.
>>
>> On commit ebb2c2437d8008d46796902ff390653822af6cc4 (Sep 18).
>>
>> Line numbers might be a little off, due to some local changes to
>> gadgetfs code but the issue is AFAIU with calling copy_to_user() with
>> spinlock held in ep0_read(). I see that there's a FIXME exactly about
>> that and I was wondering if there's any chance of getting this fixed?
>>
>> Thanks!
>
> The patch below, which goes on top of the gadgetfs patch from a few
> days ago, should eliminate this problem.

This patch seems to be fixing the crashes.

Tested-by: Andrey Konovalov <andreyk...@google.com>

Thanks once again!

>
> Alan Stern
>
>
>
> Index: usb-4.x/drivers/usb/gadget/legacy/inode.c
> ===
> --- usb-4.x.orig/drivers/usb/gadget/legacy/inode.c
> +++ usb-4.x/drivers/usb/gadget/legacy/inode.c
> @@ -986,11 +986,14 @@ ep0_read (struct file *fd, char __user *
> retval = -EIO;
> else {
> len = min (len, (size_t)dev->req->actual);
> -// FIXME don't call this with the spinlock held ...
> +   ++dev->udc_usage;
> +   spin_unlock_irq(>lock);
> if (copy_to_user (buf, dev->req->buf, len))
> retval = -EFAULT;
> else
> retval = len;
> +   spin_lock_irq(>lock);
> +   --dev->udc_usage;
> clean_req (dev->gadget->ep0, dev->req);
> /* NOTE userspace can't yet choose to stall */
> }
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: usb/storage/uas: slab-out-of-bounds in uas_probe

[Andrey Konovalov]

On Thu, Sep 21, 2017 at 6:50 PM, Alan Stern <st...@rowland.harvard.edu> wrote:
> On Thu, 21 Sep 2017, Andrey Konovalov wrote:
>
>> Hi!
>>
>> I've got the following report while fuzzing the kernel with syzkaller.
>>
>> On commit ebb2c2437d8008d46796902ff390653822af6cc4 (Sep 18).
>>
>> The issue occurs when we iterate over interface altsettings, but I
>> don't see the driver doing anything wrong. I might be missing
>> something, or this might be an issue in USB core altsettings parsing.
>
> My guess is the latter, although I can't see what is going wrong.  Can
> you provide the code that does this?

I did, see the previous email (replying in case you missed it).

>
> Alan Stern
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

usb/gadget: copy_to_user called with spinlock held

[Andrey Konovalov]

Hi!

I've got the following report while fuzzing the kernel with syzkaller.

On commit ebb2c2437d8008d46796902ff390653822af6cc4 (Sep 18).

Line numbers might be a little off, due to some local changes to
gadgetfs code but the issue is AFAIU with calling copy_to_user() with
spinlock held in ep0_read(). I see that there's a FIXME exactly about
that and I was wondering if there's any chance of getting this fixed?

Thanks!

BUG: sleeping function called from invalid context at lib/usercopy.c:24
in_atomic(): 1, irqs_disabled(): 1, pid: 5948, name: syz-executor0
2 locks held by syz-executor0/5948:
 #0:  (>f_pos_lock){+.+.}, at: []
__fdget_pos+0x149/0x1c0 fs/file.c:767
 #1:  (&(>lock)->rlock){..-.}, at: []
spin_lock_irq include/linux/spinlock.h:341 [inline]
 #1:  (&(>lock)->rlock){..-.}, at: []
ep0_read+0x580/0x1230 drivers/usb/gadget/legacy/inode.c:972
irq event stamp: 1220
hardirqs last  enabled at (1219): []
__raw_spin_unlock_irq include/linux/spinlock_api_smp.h:168 [inline]
hardirqs last  enabled at (1219): []
_raw_spin_unlock_irq+0x2c/0x60 kernel/locking/spinlock.c:199
hardirqs last disabled at (1220): []
__raw_spin_lock_irq include/linux/spinlock_api_smp.h:126 [inline]
hardirqs last disabled at (1220): []
_raw_spin_lock_irq+0x19/0x50 kernel/locking/spinlock.c:167
softirqs last  enabled at (1022): []
__do_softirq+0x5fd/0xc2d kernel/softirq.c:310
softirqs last disabled at (1013): [] invoke_softirq
kernel/softirq.c:364 [inline]
softirqs last disabled at (1013): []
irq_exit+0x171/0x1a0 kernel/softirq.c:405
Preemption disabled at:
[] spin_lock_irq include/linux/spinlock.h:341 [inline]
[] ep0_read+0x580/0x1230 drivers/usb/gadget/legacy/inode.c:972
CPU: 1 PID: 5948 Comm: syz-executor0 Not tainted
4.14.0-rc1-42259-g18ca1418efd9 #216
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:16 [inline]
 dump_stack+0x292/0x395 lib/dump_stack.c:52
 ___might_sleep+0x65c/0x720 kernel/sched/core.c:6015
 __might_sleep+0x9a/0x190 kernel/sched/core.c:5968
 __might_fault+0x15d/0x290 mm/memory.c:4499
 _copy_to_user+0x2c/0xc0 lib/usercopy.c:24
 copy_to_user include/linux/uaccess.h:154 [inline]
 ep0_read+0x739/0x1230 drivers/usb/gadget/legacy/inode.c:987
 __vfs_read+0x69d/0x890 fs/read_write.c:410
 vfs_read+0x129/0x360 fs/read_write.c:446
 SYSC_read fs/read_write.c:572 [inline]
 SyS_read+0x100/0x240 fs/read_write.c:565
 entry_SYSCALL_64_fastpath+0x23/0xc2
RIP: 0033:0x40cfb1
RSP: 002b:7ff9c6b38b20 EFLAGS: 0293 ORIG_RAX: 
RAX: ffda RBX: 0001 RCX: 0040cfb1
RDX: 003c RSI: 7ff9c6b38b70 RDI: 0005
RBP: 0005 R08:  R09: 
R10:  R11: 0293 R12: 00708000
R13:  R14: 7ff9c6b399c0 R15: 7ff9c6b39700

=
WARNING: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected
4.14.0-rc1-42259-g18ca1418efd9 #216 Tainted: GW
-
syz-executor0/5948 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
 (>mmap_sem){}, at: []
__might_fault+0x18d/0x290 mm/memory.c:4501

and this task is already holding:
 (&(>lock)->rlock){..-.}, at: [] spin_lock_irq
include/linux/spinlock.h:341 [inline]
 (&(>lock)->rlock){..-.}, at: []
ep0_read+0x580/0x1230 drivers/usb/gadget/legacy/inode.c:972
which would create a new lock dependency:
 (&(>lock)->rlock){..-.} -> (>mmap_sem){}

but this new dependency connects a SOFTIRQ-irq-safe lock:
 (&(>lock)->rlock){..-.}

... which became SOFTIRQ-irq-safe at:
  mark_irqflags kernel/locking/lockdep.c:3077 [inline]
  __lock_acquire+0x1d93/0x4550 kernel/locking/lockdep.c:3455
  lock_acquire+0x259/0x620 kernel/locking/lockdep.c:4002
  __raw_spin_lock include/linux/spinlock_api_smp.h:142 [inline]
  _raw_spin_lock+0x32/0x50 kernel/locking/spinlock.c:151
  spin_lock include/linux/spinlock.h:316 [inline]
  gadgetfs_setup+0x212/0x1ea0 drivers/usb/gadget/legacy/inode.c:1320
  dummy_timer+0x13bf/0x3970 drivers/usb/gadget/udc/dummy_hcd.c:1870
  call_timer_fn+0x2a2/0x940 kernel/time/timer.c:1281
  expire_timers kernel/time/timer.c:1320 [inline]
  __run_timers+0x87f/0xd40 kernel/time/timer.c:1620
  run_timer_softirq+0x83/0x140 kernel/time/timer.c:1646
  __do_softirq+0x305/0xc2d kernel/softirq.c:284
  invoke_softirq kernel/softirq.c:364 [inline]
  irq_exit+0x171/0x1a0 kernel/softirq.c:405
  exiting_irq arch/x86/include/asm/apic.h:638 [inline]
  smp_apic_timer_interrupt+0x2b9/0x8d0 arch/x86/kernel/apic/apic.c:1048
  apic_timer_interrupt+0x9d/0xb0 arch/x86/entry/entry_64.S:577
  native_safe_halt+0x6/0x10 arch/x86/include/asm/irqflags.h:53
  arch_safe_halt arch/x86/include/asm/paravirt.h:93 [inline]
  default_idle+0x127/0x690 arch/x86/kernel/process.c:341
  arch_cpu_idle+0xf/0x20 arch/x86/kernel/process.c:332
  default_idle_call+0x3b/0x60 kernel/sched/idle.c:98
  cpuidle_idle_call kernel/sched/idle.c:156 

usb/storage/uas: slab-out-of-bounds in uas_probe

[Andrey Konovalov]

Hi!

I've got the following report while fuzzing the kernel with syzkaller.

On commit ebb2c2437d8008d46796902ff390653822af6cc4 (Sep 18).

The issue occurs when we iterate over interface altsettings, but I
don't see the driver doing anything wrong. I might be missing
something, or this might be an issue in USB core altsettings parsing.

==
BUG: KASAN: slab-out-of-bounds in uas_probe+0x15de/0x1680
Read of size 1 at addr 880063ba9ad4 by task kworker/1:2/1845

CPU: 1 PID: 1845 Comm: kworker/1:2 Not tainted
4.14.0-rc1-42251-gebb2c2437d80 #215
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: usb_hub_wq hub_event
Call Trace:
 __dump_stack lib/dump_stack.c:16
 dump_stack+0x292/0x395 lib/dump_stack.c:52
 print_address_description+0x78/0x280 mm/kasan/report.c:252
 kasan_report_error mm/kasan/report.c:351
 kasan_report+0x22f/0x340 mm/kasan/report.c:409
 __asan_report_load1_noabort+0x19/0x20 mm/kasan/report.c:427
 uas_is_interface drivers/usb/storage/uas-detect.h:9
 uas_find_uas_alt_setting drivers/usb/storage/uas-detect.h:19
 uas_use_uas_driver drivers/usb/storage/uas-detect.h:64
 uas_probe+0x15de/0x1680 drivers/usb/storage/uas.c:938
 usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361
 really_probe drivers/base/dd.c:413
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
 bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
 __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
 bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
 device_add+0xd0b/0x1660 drivers/base/core.c:1835
 usb_set_configuration+0x104e/0x1870 drivers/usb/core/message.c:1932
 generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174
 usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266
 really_probe drivers/base/dd.c:413
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
 bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
 __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
 bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
 device_add+0xd0b/0x1660 drivers/base/core.c:1835
 usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2457
 hub_port_connect drivers/usb/core/hub.c:4903
 hub_port_connect_change drivers/usb/core/hub.c:5009
 port_event drivers/usb/core/hub.c:5115
 hub_event+0x194d/0x3740 drivers/usb/core/hub.c:5195
 process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119
 worker_thread+0x221/0x1850 kernel/workqueue.c:2253
 kthread+0x3a1/0x470 kernel/kthread.c:231
 ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431

Allocated by task 2641:
 save_stack_trace+0x1b/0x20 arch/x86/kernel/stacktrace.c:59
 save_stack+0x43/0xd0 mm/kasan/kasan.c:447
 set_track mm/kasan/kasan.c:459
 kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551
 kmem_cache_alloc_node_trace+0x15e/0x2d0 mm/slub.c:2800
 kmalloc_node ./include/linux/slab.h:531
 kzalloc_node ./include/linux/slab.h:677
 __get_vm_area_node+0x141/0x570 mm/vmalloc.c:1402
 __vmalloc_node_range+0xa8/0x730 mm/vmalloc.c:1760
 __vmalloc_node mm/vmalloc.c:1810
 __vmalloc_node_flags mm/vmalloc.c:1824
 vmalloc+0x4a/0x50 mm/vmalloc.c:1846
 n_tty_open+0x20/0x470 drivers/tty/n_tty.c:1883
 tty_ldisc_open.isra.1+0x78/0xc0 drivers/tty/tty_ldisc.c:466
 tty_ldisc_setup+0x8f/0x100 drivers/tty/tty_ldisc.c:780
 tty_init_dev+0x1a2/0x4a0 drivers/tty/tty_io.c:1332
 ptmx_open+0xfe/0x320 drivers/tty/pty.c:831
 chrdev_open+0x25c/0x710 fs/char_dev.c:416
 do_dentry_open+0x74e/0xd60 fs/open.c:752
 vfs_open+0x10c/0x230 fs/open.c:866
 do_last fs/namei.c:3387
 path_openat+0xf22/0x34d0 fs/namei.c:3527
 do_filp_open+0x2a1/0x460 fs/namei.c:3562
 do_sys_open+0x543/0x720 fs/open.c:1059
 SYSC_open fs/open.c:1077
 SyS_open+0x32/0x40 fs/open.c:1072
 entry_SYSCALL_64_fastpath+0x23/0xc2 arch/x86/entry/entry_64.S:202

Freed by task 2641:
 save_stack_trace+0x1b/0x20 arch/x86/kernel/stacktrace.c:59
 save_stack+0x43/0xd0 mm/kasan/kasan.c:447
 set_track mm/kasan/kasan.c:459
 kasan_slab_free+0x72/0xc0 mm/kasan/kasan.c:524
 slab_free_hook mm/slub.c:1390
 slab_free_freelist_hook mm/slub.c:1412
 slab_free mm/slub.c:2988
 kfree+0xf6/0x2f0 mm/slub.c:3919
 __vunmap+0x24c/0x2f0 mm/vmalloc.c:1545
 vfree+0x55/0xe0 mm/vmalloc.c:1606
 n_tty_close+0xb7/0x120 drivers/tty/n_tty.c:1864
 tty_ldisc_close.isra.0+0x9e/0xd0 drivers/tty/tty_ldisc.c:490
 tty_ldisc_kill+0x50/0xc0 drivers/tty/tty_ldisc.c:639
 tty_ldisc_hangup+0x2a6/0x5c0 drivers/tty/tty_ldisc.c:758
 __tty_hangup.part.22+0x2e6/0x690 drivers/tty/tty_io.c:612
 __tty_hangup drivers/tty/tty_io.c:570
 tty_vhangup+0x26/0x30 drivers/tty/tty_io.c:684
 pty_close+0x36a/0x4b0 drivers/tty/pty.c:77
 tty_release+0x44b/0x1520 drivers/tty/tty_io.c:1638
 __fput+0x33e/0x800 fs/file_table.c:210
 fput+0x1a/0x20 fs/file_table.c:244
 task_work_run+0x1af/0x280 kernel/task_work.c:112
 

usb/net/hso: global-out-of-bounds in hso_probe

[Andrey Konovalov]

Hi!

I've got the following report while fuzzing the kernel with syzkaller.

On commit ebb2c2437d8008d46796902ff390653822af6cc4 (Sep 18).

Is seems there's no check on the if_num value when it's used in ((u32
*)(id->driver_info))[if_num].

==
BUG: KASAN: global-out-of-bounds in hso_probe+0x1379/0x1b70
Read of size 4 at addr 85c582f8 by task kworker/1:2/1846

CPU: 1 PID: 1846 Comm: kworker/1:2 Not tainted
4.14.0-rc1-42251-gebb2c2437d80 #215
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: usb_hub_wq hub_event
Call Trace:
 __dump_stack lib/dump_stack.c:16
 dump_stack+0x292/0x395 lib/dump_stack.c:52
 print_address_description+0x1d9/0x280 mm/kasan/report.c:252
 kasan_report_error mm/kasan/report.c:351
 kasan_report+0x22f/0x340 mm/kasan/report.c:409
 __asan_report_load4_noabort+0x19/0x20 mm/kasan/report.c:429
 hso_probe+0x1379/0x1b70 drivers/net/usb/hso.c:2880
 usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361
 really_probe drivers/base/dd.c:413
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
 bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
 __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
 bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
 device_add+0xd0b/0x1660 drivers/base/core.c:1835
 usb_set_configuration+0x104e/0x1870 drivers/usb/core/message.c:1932
 generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174
 usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266
 really_probe drivers/base/dd.c:413
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
 bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
 __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
 bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
 device_add+0xd0b/0x1660 drivers/base/core.c:1835
 usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2457
 hub_port_connect drivers/usb/core/hub.c:4903
 hub_port_connect_change drivers/usb/core/hub.c:5009
 port_event drivers/usb/core/hub.c:5115
 hub_event+0x194d/0x3740 drivers/usb/core/hub.c:5195
 process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119
 worker_thread+0x221/0x1850 kernel/workqueue.c:2253
 kthread+0x3a1/0x470 kernel/kthread.c:231
 ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431

The buggy address belongs to the variable:
 driver_name+0xb8/0xee0

Memory state around the buggy address:
 85c58180: 00 00 04 fa fa fa fa fa 00 00 fa fa fa fa fa fa
 85c58200: 06 fa fa fa fa fa fa fa 04 fa fa fa fa fa fa fa
>85c58280: 00 fa fa fa fa fa fa fa 06 fa fa fa fa fa fa fa
^
 85c58300: 00 02 fa fa fa fa fa fa 00 00 00 00 00 07 fa fa
 85c58380: fa fa fa fa 00 07 fa fa fa fa fa fa 00 00 00 06
==
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

usb/net/hso: warning in hso_free_net_device

[Andrey Konovalov]

Hi!

I've got the following report while fuzzing the kernel with syzkaller.

On commit ebb2c2437d8008d46796902ff390653822af6cc4 (Sep 18).

Looks like hso_create_net_device() can do goto exit before registering
network device.

hso 1-1:4.0: Can't find BULK IN endpoint
[ cut here ]
WARNING: CPU: 0 PID: 24 at net/core/dev.c:7117
rollback_registered_many+0x235/0xd90
Modules linked in:
CPU: 0 PID: 24 Comm: kworker/0:1 Not tainted 4.14.0-rc1-42251-gebb2c2437d80 #215
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: usb_hub_wq hub_event
task: 88006befe300 task.stack: 88006bf8
RIP: 0010:rollback_registered_many+0x235/0xd90 net/core/dev.c:7117
RSP: 0018:88006bf86058 EFLAGS: 00010297
RAX: 88006befe300 RBX:  RCX: 11000d40644e
RDX:  RSI:  RDI: 88006a032778
RBP: 88006bf86210 R08: 88006befe300 R09: 849e79cc
R10: 88006bf86450 R11: 11000d7dfefb R12: 88006a032200
R13: 88006a032270 R14: 88006bf86258 R15: dc00
FS:  () GS:88006c80() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 7f1c4eebb000 CR3: 69b63000 CR4: 06f0
Call Trace:
 rollback_registered+0x1ac/0x3c0 net/core/dev.c:7192
 unregister_netdevice_queue+0x2f3/0x580 net/core/dev.c:8180
 unregister_netdevice ./include/linux/netdevice.h:2427
 unregister_netdev+0x21/0x30 net/core/dev.c:8221
 hso_free_net_device+0xf2/0x2e0 drivers/net/usb/hso.c:2379
 hso_create_net_device+0x3f9/0x9d0 drivers/net/usb/hso.c:2567
 hso_probe+0xaa7/0x1b70 drivers/net/usb/hso.c:2896
 usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361
 really_probe drivers/base/dd.c:413
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
 bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
 __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
 bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
 device_add+0xd0b/0x1660 drivers/base/core.c:1835
 usb_set_configuration+0x104e/0x1870 drivers/usb/core/message.c:1932
 generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174
 usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266
 really_probe drivers/base/dd.c:413
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
 bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
 __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
 bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
 device_add+0xd0b/0x1660 drivers/base/core.c:1835
 usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2457
 hub_port_connect drivers/usb/core/hub.c:4903
 hub_port_connect_change drivers/usb/core/hub.c:5009
 port_event drivers/usb/core/hub.c:5115
 hub_event+0x194d/0x3740 drivers/usb/core/hub.c:5195
 process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119
 worker_thread+0x221/0x1850 kernel/workqueue.c:2253
 kthread+0x3a1/0x470 kernel/kthread.c:231
 ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431
Code: 48 c1 e8 03 42 0f b6 04 38 84 c0 74 08 84 c0 0f 8e e7 09 00 00
41 0f b6 9c 24 78 05 00 00 84 db 0f 85 57 ff ff ff e8 0b 92 b0 fc <0f>
ff 4c 89 ef e8 21 15 b7 fd 84 c0 0f 84 e1 00 00 00 e8 f4 91
---[ end trace 94e5147be32b2d45 ]---
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: usb/core: slab-out-of-bounds read in cdc_parse_cdc_header

[Andrey Konovalov]

On Thu, Sep 21, 2017 at 4:07 PM, Greg Kroah-Hartman
<gre...@linuxfoundation.org> wrote:
> On Thu, Sep 21, 2017 at 03:51:44PM +0200, Andrey Konovalov wrote:
>> On Thu, Sep 21, 2017 at 10:04 AM, Greg Kroah-Hartman
>> <gre...@linuxfoundation.org> wrote:
>> > On Thu, Sep 21, 2017 at 09:31:54AM +0200, Greg Kroah-Hartman wrote:
>> >> On Wed, Sep 20, 2017 at 04:45:08PM +0200, Andrey Konovalov wrote:
>> >> > Hi!
>> >> >
>> >> > I've got the following crash while fuzzing the kernel with syzkaller.
>> >> >
>> >> > On commit ebb2c2437d8008d46796902ff390653822af6cc4 (Sep 18).
>> >> >
>> >> > It looks like cdc_parse_cdc_header() doesn't validate buflen before
>> >> > accessing buffer[1], buffer[2] and so on. The only check present is
>> >> > while (buflen > 0).
>> >>
>> >> Ugh, you are right, let me go work on a patch, thanks for the report...
>> >
>> > Here's a first cut at a fix for this.  I think this should solve it, but
>> > it's early and my coffee has not fully kicked in...
>> >
>> > thanks,
>> >
>> > greg k-h
>> > -
>> >
>> > diff --git a/drivers/usb/core/message.c b/drivers/usb/core/message.c
>> > index 4c38ea41ae96..028feaf01aa5 100644
>> > --- a/drivers/usb/core/message.c
>> > +++ b/drivers/usb/core/message.c
>> > @@ -2069,6 +2069,10 @@ int cdc_parse_cdc_header(struct 
>> > usb_cdc_parsed_header *hdr,
>> > elength = 1;
>> > goto next_desc;
>> > }
>> > +   if ((buflen < elength) || (elength < 2)) {
>>
>> Hi Greg,
>>
>> I think this should check (elength < 3), since we access both
>> buffer[1] and buffer[2] after this check.
>
> {sigh}  yes, you are right, counted this one wrong.
>
> With this patch, updated one below, does it fix your crash?

It does, thanks!

Tested-by: Andrey Konovalov <andreyk...@google.com>

>
> thanks,
>
> greg k-h
>
>
> diff --git a/drivers/usb/core/message.c b/drivers/usb/core/message.c
> index 4c38ea41ae96..028feaf01aa5 100644
> --- a/drivers/usb/core/message.c
> +++ b/drivers/usb/core/message.c
> @@ -2069,6 +2069,10 @@ int cdc_parse_cdc_header(struct usb_cdc_parsed_header 
> *hdr,
> elength = 1;
> goto next_desc;
> }
> +   if ((buflen < elength) || (elength < 3)) {
> +   dev_err(>dev, "invalid descriptor buffer 
> length\n");
> +   break;
> +   }
> if (buffer[1] != USB_DT_CS_INTERFACE) {
> dev_err(>dev, "skipping garbage\n");
> goto next_desc;
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: usb/core: slab-out-of-bounds read in cdc_parse_cdc_header

[Andrey Konovalov]

On Thu, Sep 21, 2017 at 10:04 AM, Greg Kroah-Hartman
<gre...@linuxfoundation.org> wrote:
> On Thu, Sep 21, 2017 at 09:31:54AM +0200, Greg Kroah-Hartman wrote:
>> On Wed, Sep 20, 2017 at 04:45:08PM +0200, Andrey Konovalov wrote:
>> > Hi!
>> >
>> > I've got the following crash while fuzzing the kernel with syzkaller.
>> >
>> > On commit ebb2c2437d8008d46796902ff390653822af6cc4 (Sep 18).
>> >
>> > It looks like cdc_parse_cdc_header() doesn't validate buflen before
>> > accessing buffer[1], buffer[2] and so on. The only check present is
>> > while (buflen > 0).
>>
>> Ugh, you are right, let me go work on a patch, thanks for the report...
>
> Here's a first cut at a fix for this.  I think this should solve it, but
> it's early and my coffee has not fully kicked in...
>
> thanks,
>
> greg k-h
> -
>
> diff --git a/drivers/usb/core/message.c b/drivers/usb/core/message.c
> index 4c38ea41ae96..028feaf01aa5 100644
> --- a/drivers/usb/core/message.c
> +++ b/drivers/usb/core/message.c
> @@ -2069,6 +2069,10 @@ int cdc_parse_cdc_header(struct usb_cdc_parsed_header 
> *hdr,
> elength = 1;
> goto next_desc;
> }
> +   if ((buflen < elength) || (elength < 2)) {

Hi Greg,

I think this should check (elength < 3), since we access both
buffer[1] and buffer[2] after this check.

Thanks!

> +   dev_err(>dev, "invalid descriptor buffer 
> length\n");
> +   break;
> +   }
> if (buffer[1] != USB_DT_CS_INTERFACE) {
> dev_err(>dev, "skipping garbage\n");
> goto next_desc;
>
> --
> You received this message because you are subscribed to the Google Groups 
> "syzkaller" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to syzkaller+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: usb/gadget: null-ptr-deref in dev_ioctl

[Andrey Konovalov]

On Wed, Sep 20, 2017 at 7:59 PM, Alan Stern <st...@rowland.harvard.edu> wrote:
> On Mon, 11 Sep 2017, Andrey Konovalov wrote:
>
>> Hi!
>>
>> It seems that gadget->ops can be NULL so it probably needs to be
>> checked as well as gadget->ops->ioctl in dev_ioctl() in
>> drivers/usb/gadget/legacy/inode.c.
>
> Actually, I suspect the problem is that gadget is NULL, not
> gadget->ops.

Yes, you are correct, checked it by adding printk. Attaching a simple
repro of the issue just for reference.

>
>> kasan: CONFIG_KASAN_INLINE enabled
>> kasan: GPF could be caused by NULL-ptr deref or user memory access
>> general protection fault:  [#1] SMP KASAN
>> Modules linked in:
>> CPU: 1 PID: 5214 Comm: syz-executor Not tainted 4.13.0+ #94
>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>> task: 88006ac0e800 task.stack: 88006af6
>> ! handling hub events now: start
>> RIP: 0010:dev_ioctl+0x117/0x280 drivers/usb/gadget/legacy/inode.c:1323
>
> Can you test the patch below?  I haven't tried it myself yet, but I
> think it will fix the problem you found.

This fixes the crash for me.

Tested-by: Andrey Konovalov <andreyk...@google.com>

Thanks!

>
> Alan Stern
>
>
>
> Index: usb-4.x/drivers/usb/gadget/legacy/inode.c
> ===
> --- usb-4.x.orig/drivers/usb/gadget/legacy/inode.c
> +++ usb-4.x/drivers/usb/gadget/legacy/inode.c
> @@ -28,7 +28,7 @@
>  #include 
>  #include 
>  #include 
> -
> +#include 
>  #include 
>  #include 
>
> @@ -116,6 +116,7 @@ enum ep0_state {
>  struct dev_data {
> spinlock_t  lock;
> refcount_t  count;
> +   int udc_usage;
> enum ep0_state  state;  /* P: lock */
> struct usb_gadgetfs_event   event [N_EVENT];
> unsignedev_next;
> @@ -513,9 +514,9 @@ static void ep_aio_complete(struct usb_e
> INIT_WORK(>work, ep_user_copy_worker);
> schedule_work(>work);
> }
> -   spin_unlock(>dev->lock);
>
> usb_ep_free_request(ep, req);
> +   spin_unlock(>dev->lock);
> put_ep(epdata);
>  }
>
> @@ -939,9 +940,11 @@ ep0_read (struct file *fd, char __user *
> struct usb_request  *req = dev->req;
>
> if ((retval = setup_req (ep, req, 0)) == 0) {
> +   ++dev->udc_usage;
> spin_unlock_irq (>lock);
> retval = usb_ep_queue (ep, req, GFP_KERNEL);
> spin_lock_irq (>lock);
> +   --dev->udc_usage;
> }
> dev->state = STATE_DEV_CONNECTED;
>
> @@ -1131,6 +1134,7 @@ ep0_write (struct file *fd, const char _
> retval = setup_req (dev->gadget->ep0, dev->req, len);
> if (retval == 0) {
> dev->state = STATE_DEV_CONNECTED;
> +   ++dev->udc_usage;
> spin_unlock_irq (>lock);
> if (copy_from_user (dev->req->buf, buf, len))
> retval = -EFAULT;
> @@ -1142,6 +1146,7 @@ ep0_write (struct file *fd, const char _
> GFP_KERNEL);
> }
> spin_lock_irq(>lock);
> +   --dev->udc_usage;
> if (retval < 0) {
> clean_req (dev->gadget->ep0, 
> dev->req);
> } else
> @@ -1243,9 +1248,21 @@ static long dev_ioctl (struct file *fd,
> struct usb_gadget   *gadget = dev->gadget;
> long ret = -ENOTTY;
>
> -   if (gadget->ops->ioctl)
> +   spin_lock_irq(>lock);
> +   if (dev->state == STATE_DEV_OPENED ||
> +   dev->state == STATE_DEV_UNBOUND) {
> +   /* Not bound to a UDC */
> +   } else if (gadget->ops->ioctl) {
> +   ++dev->udc_usage;
> +   spin_unlock_irq(>lock);
> +
> ret = gadget->ops->ioctl (gadget, code, value);
>
> +   spin_lock_irq(>lock);
> +   --dev->udc_usage;
> +   }
>

usb/core: slab-out-of-bounds read in cdc_parse_cdc_header

[Andrey Konovalov]

Hi!

I've got the following crash while fuzzing the kernel with syzkaller.

On commit ebb2c2437d8008d46796902ff390653822af6cc4 (Sep 18).

It looks like cdc_parse_cdc_header() doesn't validate buflen before
accessing buffer[1], buffer[2] and so on. The only check present is
while (buflen > 0).

==
BUG: KASAN: slab-out-of-bounds in cdc_parse_cdc_header+0x611/0x6b0
Read of size 1 at addr 88006b03e554 by task kworker/1:2/2573

CPU: 1 PID: 2573 Comm: kworker/1:2 Not tainted 4.14.0-rc1+ #191
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: usb_hub_wq hub_event
Call Trace:
 __dump_stack lib/dump_stack.c:16
 dump_stack+0x192/0x22c lib/dump_stack.c:52
 print_address_description+0x78/0x280 mm/kasan/report.c:252
 kasan_report_error mm/kasan/report.c:351
 kasan_report+0x230/0x340 mm/kasan/report.c:409
 __asan_report_load1_noabort+0x19/0x20 mm/kasan/report.c:427
 cdc_parse_cdc_header+0x611/0x6b0 drivers/usb/core/message.c:2077
 usbnet_generic_cdc_bind+0x284/0x1b10 drivers/net/usb/cdc_ether.c:158
 usbnet_ether_cdc_bind drivers/net/usb/cdc_ether.c:329
 usbnet_cdc_bind+0x2a/0x190 drivers/net/usb/cdc_ether.c:437
 usbnet_probe+0xcfd/0x2ba0 drivers/net/usb/usbnet.c:1726
 usb_probe_interface+0x351/0x8d0 drivers/usb/core/driver.c:361
 really_probe drivers/base/dd.c:413
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
 bus_for_each_drv+0x15e/0x210 drivers/base/bus.c:463
 __device_attach+0x269/0x3c0 drivers/base/dd.c:710
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
 bus_probe_device+0x1da/0x280 drivers/base/bus.c:523
 device_add+0xcf9/0x1640 drivers/base/core.c:1835
 usb_set_configuration+0x1064/0x1890 drivers/usb/core/message.c:1932
 generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174
 usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266
 really_probe drivers/base/dd.c:413
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
 bus_for_each_drv+0x15e/0x210 drivers/base/bus.c:463
 __device_attach+0x269/0x3c0 drivers/base/dd.c:710
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
 bus_probe_device+0x1da/0x280 drivers/base/bus.c:523
 device_add+0xcf9/0x1640 drivers/base/core.c:1835
 usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2457
 hub_port_connect drivers/usb/core/hub.c:4903
 hub_port_connect_change drivers/usb/core/hub.c:5009
 port_event drivers/usb/core/hub.c:5115
 hub_event+0x23c8/0x37c0 drivers/usb/core/hub.c:5195
 process_one_work+0x9fb/0x1570 kernel/workqueue.c:2119
 worker_thread+0x1e4/0x1350 kernel/workqueue.c:2253
 kthread+0x324/0x3f0 kernel/kthread.c:231
 ret_from_fork+0x25/0x30 arch/x86/entry/entry_64.S:431

Allocated by task 2573:
 save_stack_trace+0x1b/0x20 arch/x86/kernel/stacktrace.c:59
 save_stack+0x43/0xd0 mm/kasan/kasan.c:447
 set_track mm/kasan/kasan.c:459
 kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551
 __kmalloc+0x81/0x1d0 mm/slub.c:3782
 kmalloc ./include/linux/slab.h:498
 usb_get_configuration+0x372/0x2a70 drivers/usb/core/config.c:848
 usb_enumerate_device drivers/usb/core/hub.c:2290
 usb_new_device+0xaae/0x1020 drivers/usb/core/hub.c:2426
 hub_port_connect drivers/usb/core/hub.c:4903
 hub_port_connect_change drivers/usb/core/hub.c:5009
 port_event drivers/usb/core/hub.c:5115
 hub_event+0x23c8/0x37c0 drivers/usb/core/hub.c:5195
 process_one_work+0x9fb/0x1570 kernel/workqueue.c:2119
 worker_thread+0x1e4/0x1350 kernel/workqueue.c:2253
 kthread+0x324/0x3f0 kernel/kthread.c:231
 ret_from_fork+0x25/0x30 arch/x86/entry/entry_64.S:43

Freed by task 3637:
 save_stack_trace+0x1b/0x20 arch/x86/kernel/stacktrace.c:59
 save_stack+0x43/0xd0 mm/kasan/kasan.c:447
 set_track mm/kasan/kasan.c:459
 kasan_slab_free+0x72/0xc0 mm/kasan/kasan.c:524
 slab_free_hook mm/slub.c:1390
 slab_free_freelist_hook mm/slub.c:1412
 slab_free mm/slub.c:2988
 kfree+0x96/0x1a0 mm/slub.c:3919
 kvfree+0x3b/0x60 mm/util.c:416
 __vunmap+0x1de/0x270 mm/vmalloc.c:1542
 vfree+0x55/0xe0 mm/vmalloc.c:1606
 n_tty_close+0xb7/0x120 drivers/tty/n_tty.c:1864
 tty_ldisc_close.isra.0+0x9e/0xd0 drivers/tty/tty_ldisc.c:490
 tty_ldisc_kill+0x4a/0xc0 drivers/tty/tty_ldisc.c:639
 tty_ldisc_release+0x10b/0x220 drivers/tty/tty_ldisc.c:807
 tty_release_struct+0x1f/0x50 drivers/tty/tty_io.c:1571
 tty_release+0xe60/0x15f0 drivers/tty/tty_io.c:1744
 __fput+0x324/0x7e0 fs/file_table.c:210
 fput+0x1a/0x20 fs/file_table.c:244
 task_work_run+0x22e/0x2e0 kernel/task_work.c:112
 tracehook_notify_resume ./include/linux/tracehook.h:191
 exit_to_usermode_loop+0x1d7/0x210 arch/x86/entry/common.c:162
 prepare_exit_to_usermode arch/x86/entry/common.c:197
 syscall_return_slowpath+0x2a7/0x310 arch/x86/entry/common.c:266
 entry_SYSCALL_64_fastpath+0xa3/0xa5 arch/x86/entry/entry_64.S:238

The buggy address belongs to the object at 88006b03e540
 which belongs to the cache kmalloc-32 of size 32
The buggy address is located 20 

Re: usb/hid: slab-out-of-bounds read in usbhid_parse

[Andrey Konovalov]

On Wed, Sep 20, 2017 at 6:57 AM, Kim Jaejoong <climbbb@gmail.com> wrote:
> Hi Andrey
>
> 2017-09-19 21:38 GMT+09:00 Andrey Konovalov <andreyk...@google.com>:
>> Hi Kim,
>>
>> I'm not sure. Is there a check on the bLength field of a
>> hid_descriptor struct? Can it be less than sizeof(struct
>> hid_descriptor)? If so, we still do an out-of-bounds access to
>> hdesc->desc[0] (or some other fields).
>
> You are right. I add hid descriptr size from HID device with bLength field.
>
> Could you test and review below patch?

It seems that this patch fixes the issue. I'll keep fuzzing to make sure.

Tested-by: Andrey Konovalov <andreyk...@google.com>

Thanks!

>
> To. usb & input guys.
>
> While dig this report, i was wondering about bNumDescriptors in HID 
> descriptor.
> HID document from usb.org said, 'this number must be at least one (1)
> as a Report descriptor will always be present.'
>
> There is no mention of the order of class descriptors. Suppose you
> have a HID device with a report descriptor and a physical descriptor.
>
> If you have the following hid descriptor in this case,
> HID descriptor
>bLength: 12
>bDescriptor Type: HID
>.. skip
>bNumDescriptors: 2
>bDescriptorType: physical
>bDescriptorLength: any
>bDescriptorType: Report
>bDescriptorLength: any
>
> If the order of the report descriptor is the second as above,
> usbhid_parse () will fail because my patch is only check the first
> bDescriptor Type.
> But If the order of the report descriptor is always first, there is no
> problem. How do you think this?
>
> Thanks, jaejoong
>
> -
>
> diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
> index 089bad8..94c3805 100644
> --- a/drivers/hid/usbhid/hid-core.c
> +++ b/drivers/hid/usbhid/hid-core.c
> @@ -974,7 +974,7 @@ static int usbhid_parse(struct hid_device *hid)
> u32 quirks = 0;
> unsigned int rsize = 0;
> char *rdesc;
> -   int ret, n;
> +   int ret;
>
> quirks = usbhid_lookup_quirk(le16_to_cpu(dev->descriptor.idVendor),
> le16_to_cpu(dev->descriptor.idProduct));
> @@ -997,12 +997,16 @@ static int usbhid_parse(struct hid_device *hid)
> return -ENODEV;
> }
>
> +   if (hdesc->bLength < sizeof(*hdesc)) {
> +   dbg_hid("hid descriptor is too short\n");
> +   return -EINVAL;
> +   }
> +
> hid->version = le16_to_cpu(hdesc->bcdHID);
> hid->country = hdesc->bCountryCode;
>
> -   for (n = 0; n < hdesc->bNumDescriptors; n++)
> -   if (hdesc->desc[n].bDescriptorType == HID_DT_REPORT)
> -   rsize = le16_to_cpu(hdesc->desc[n].wDescriptorLength);
> +   if (hdesc->desc[0].bDescriptorType == HID_DT_REPORT)
> +   rsize = le16_to_cpu(hdesc->desc[0].wDescriptorLength);
>
> if (!rsize || rsize > HID_MAX_DESCRIPTOR_SIZE) {
> dbg_hid("weird size of report descriptor (%u)\n", rsize);
> ---
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: usb/gadget: stalls in dummy_timer

[Andrey Konovalov]

On Tue, Sep 19, 2017 at 7:17 PM, Alan Stern <st...@rowland.harvard.edu> wrote:
> On Tue, 19 Sep 2017, Andrey Konovalov wrote:
>
>> On Fri, Sep 15, 2017 at 8:57 PM, Alan Stern <st...@rowland.harvard.edu> 
>> wrote:
>> > On Thu, 14 Sep 2017, Andrey Konovalov wrote:
>> >
>> >> On Thu, Sep 14, 2017 at 7:49 PM, Alan Stern <st...@rowland.harvard.edu> 
>> >> wrote:
>> >> > On Thu, 14 Sep 2017, Andrey Konovalov wrote:
>> >> >
>> >> >> Looked at this a little more.
>> >> >>
>> >> >> dummy_timer() stucks in an infinite loop. It calls
>> >> >> usb_hcd_giveback_urb(), which in turn calls usbtouch_irq(), which
>> >> >> calls usb_submit_urb(), which calls dummy_urb_enqueue() and puts urb
>> >> >> back into dummy urb queue. dummy_timer() then does goto restart, finds
>> >> >> the urb and calls usb_hcd_giveback_urb() again. And this process goes
>> >> >> on again and again. It seems that something should either process the
>> >> >> urb and set urb->status or it should just expire.
>> >> >
>> >> > There is some throttling code, but it applies only to bulk transfers.
>> >> > Probably because the bandwidth limits for other types are slightly
>> >> > different.  However, I don't think we need to worry about this level of
>> >> > detail, since the driver makes a number of other approximations anyway.
>> >> >
>> >> > Try the patch below; it should fix the problem.
>> >>
>> >> Hi Alan,
>> >>
>> >> Just tried your patch, my reproducer still hangs the kernel until all
>> >> memory is exhausted.
>> >>
>> >> Thanks!
>> >
>> > Hmmm.  Your reproducer doesn't run on my system.  The mmap system call
>> > fails, perhaps because this laptop has a 32-bit kernel.  So I can't
>> > tell what's going on.
>> >
>> > Can you collect a usbmon trace that shows what happens while the
>> > reproducer runs?  If it turns out to be extremely large, just post an
>> > initial portion of it.
>>
>> I've attached the usbmon trace. It's actually quite short, probably
>> due to the fact that the kernel enters infinite loop.
>>
>> I've also attached a reproducer that should compile on a 32 bit
>> system, however I haven't tested whether it reproduces the issue.
>
> Got it, thanks.  Can you test the patch below in place of (or in
> addition to) the earlier patch?

With this patch (just this one, without the other one) the reproducer
no longer hangs the kernel :)

Tested-by: Andrey Konovalov <andreyk...@google.com>

Thanks!

>
> Alan Stern
>
>
>
> Index: usb-4.x/drivers/usb/gadget/udc/dummy_hcd.c
> ===
> --- usb-4.x.orig/drivers/usb/gadget/udc/dummy_hcd.c
> +++ usb-4.x/drivers/usb/gadget/udc/dummy_hcd.c
> @@ -237,6 +237,8 @@ struct dummy_hcd {
>
> struct usb_device   *udev;
> struct list_headurbp_list;
> +   struct urbp *next_frame_urbp;
> +
> u32 stream_en_ep;
> u8  num_stream[30 / 2];
>
> @@ -1252,6 +1254,8 @@ static int dummy_urb_enqueue(
>
> list_add_tail(>urbp_list, _hcd->urbp_list);
> urb->hcpriv = urbp;
> +   if (!dum_hcd->next_frame_urbp)
> +   dum_hcd->next_frame_urbp = urbp;
> if (usb_pipetype(urb->pipe) == PIPE_CONTROL)
> urb->error_count = 1;   /* mark as a new urb */
>
> @@ -1768,6 +1772,7 @@ static void dummy_timer(unsigned long _d
> spin_unlock_irqrestore(>lock, flags);
> return;
> }
> +   dum_hcd->next_frame_urbp = NULL;
>
> for (i = 0; i < DUMMY_ENDPOINTS; i++) {
> if (!ep_info[i].name)
> @@ -1784,6 +1789,10 @@ restart:
> int type;
> int status = -EINPROGRESS;
>
> +   /* stop when we reach URBs queued after the timer interrupt */
> +   if (urbp == dum_hcd->next_frame_urbp)
> +   break;
> +
> urb = urbp->urb;
> if (urb->unlinked)
> goto return_urb;
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: usb/gadget: stalls in dummy_timer

[Andrey Konovalov]

On Fri, Sep 15, 2017 at 8:57 PM, Alan Stern <st...@rowland.harvard.edu> wrote:
> On Thu, 14 Sep 2017, Andrey Konovalov wrote:
>
>> On Thu, Sep 14, 2017 at 7:49 PM, Alan Stern <st...@rowland.harvard.edu> 
>> wrote:
>> > On Thu, 14 Sep 2017, Andrey Konovalov wrote:
>> >
>> >> Looked at this a little more.
>> >>
>> >> dummy_timer() stucks in an infinite loop. It calls
>> >> usb_hcd_giveback_urb(), which in turn calls usbtouch_irq(), which
>> >> calls usb_submit_urb(), which calls dummy_urb_enqueue() and puts urb
>> >> back into dummy urb queue. dummy_timer() then does goto restart, finds
>> >> the urb and calls usb_hcd_giveback_urb() again. And this process goes
>> >> on again and again. It seems that something should either process the
>> >> urb and set urb->status or it should just expire.
>> >
>> > There is some throttling code, but it applies only to bulk transfers.
>> > Probably because the bandwidth limits for other types are slightly
>> > different.  However, I don't think we need to worry about this level of
>> > detail, since the driver makes a number of other approximations anyway.
>> >
>> > Try the patch below; it should fix the problem.
>>
>> Hi Alan,
>>
>> Just tried your patch, my reproducer still hangs the kernel until all
>> memory is exhausted.
>>
>> Thanks!
>
> Hmmm.  Your reproducer doesn't run on my system.  The mmap system call
> fails, perhaps because this laptop has a 32-bit kernel.  So I can't
> tell what's going on.
>
> Can you collect a usbmon trace that shows what happens while the
> reproducer runs?  If it turns out to be extremely large, just post an
> initial portion of it.

I've attached the usbmon trace. It's actually quite short, probably
due to the fact that the kernel enters infinite loop.

I've also attached a reproducer that should compile on a 32 bit
system, however I haven't tested whether it reproduces the issue.

>
> Alan Stern
>


dummy_timer-stall-usbmon
Description: Binary data
// autogenerated by syzkaller (http://github.com/google/syzkaller)

#define _GNU_SOURCE

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

void gadgetfs_mkdir()
{
mkdir("/dev/gadget", 0755) != 0;
}

void gadgetfs_mount()
{
while (mount("none", "/dev/gadget", "gadgetfs", 0, NULL) != 0) {
usleep(10 * 1000);
umount2("/dev/gadget", MNT_FORCE | MNT_DETACH);
}
}

static int
gfs_handle_event_setup_get_descriptor(int fd,
  struct usb_ctrlrequest* setup)
{
char buffer[128];
int rv;
switch (setup->wValue >> 8) {
case USB_DT_STRING:
buffer[0] = 4;
buffer[1] = USB_DT_STRING;
if ((setup->wValue & 0x0ff) == 0) {
buffer[2] = 0x09;
buffer[3] = 0x04;
} else {
buffer[2] = 0x61;
buffer[3] = 0x00;
}
rv = write(fd, [0], 4);
if (rv != 4) {
return -1;
}
break;
default:
break;
}
return 0;
}

static int
gfs_handle_event_setup_set_configuration(int fd,
 struct usb_ctrlrequest* setup)
{
int rv = read(fd, , 0);
if (rv != 0) {
return -1;
}
return 0;
}

static int gfs_handle_event_setup(int fd, struct usb_ctrlrequest* setup)
{
switch (setup->bRequest) {
case USB_REQ_GET_DESCRIPTOR:
gfs_handle_event_setup_get_descriptor(fd, setup);
break;
case USB_REQ_SET_CONFIGURATION:
gfs_handle_event_setup_set_configuration(fd, setup);
break;
case USB_REQ_GET_INTERFACE:
break;
case USB_REQ_SET_INTERFACE:
break;
default:
break;
}
return 0;
}

static int gfs_handle_event(int fd, struct usb_gadgetfs_event* event)
{
switch (event->type) {
case GADGETFS_NOP:
break;
case GADGETFS_CONNECT:
break;
case GADGETFS_SETUP:
gfs_handle_event_setup(fd, >u.setup);
break;
case GADGETFS_DISCONNECT:
break;
case GADGETFS_SUSPEND:
break;
default:
br

Re: usb/hid: slab-out-of-bounds read in usbhid_parse

[Andrey Konovalov]

On Tue, Sep 19, 2017 at 1:47 PM, Kim Jaejoong <climbbb@gmail.com> wrote:
> Hi, Andrey Konovalov
>
> Thanks for the report.
>
> 2017-09-19 2:33 GMT+09:00 Andrey Konovalov <andreyk...@google.com>:
>> Hi!
>>
>> I've got the following crash while fuzzing the kernel with syzkaller.
>>
>> On commit ebb2c2437d8008d46796902ff390653822af6cc4 (Sep 18).
>>
>> It seems that there's no proper check on the hdesc->bNumDescriptors
>> value in usbhid_parse(). it iterates over hdesc->desc and accesses
>> hdesc->desc[n] fields, which might be out-of-bounds.
>
> The bNumDescriptors in hid descriptor means 'numeric expression
> specifying the number of class descriptors'.
> The value bNumberDescriptors identifies the number of additional class
> specific descriptors present.
> (refer to the 6.1.2 HID Descriptor in hid documents :
> http://www.usb.org/developers/hidpage/HID1_11.pdf)
>
> So, it can be out-of-bounds in hdesc->desc[n] if there is an
> additional class descriptor.
>
> Does the patch below fix this?

Hi Kim,

I'm not sure. Is there a check on the bLength field of a
hid_descriptor struct? Can it be less than sizeof(struct
hid_descriptor)? If so, we still do an out-of-bounds access to
hdesc->desc[0] (or some other fields).

Thanks!

>
> Thanks, jaejoong
> --
>
> diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
> index 089bad8..7b6a0b6 100644
> --- a/drivers/hid/usbhid/hid-core.c
> +++ b/drivers/hid/usbhid/hid-core.c
> @@ -974,7 +974,7 @@ static int usbhid_parse(struct hid_device *hid)
> u32 quirks = 0;
> unsigned int rsize = 0;
> char *rdesc;
> -   int ret, n;
> +   int ret;
>
> quirks = usbhid_lookup_quirk(le16_to_cpu(dev->descriptor.idVendor),
> le16_to_cpu(dev->descriptor.idProduct));
> @@ -1000,9 +1000,8 @@ static int usbhid_parse(struct hid_device *hid)
> hid->version = le16_to_cpu(hdesc->bcdHID);
> hid->country = hdesc->bCountryCode;
>
> -   for (n = 0; n < hdesc->bNumDescriptors; n++)
> -   if (hdesc->desc[n].bDescriptorType == HID_DT_REPORT)
> -   rsize = le16_to_cpu(hdesc->desc[n].wDescriptorLength);
> +   if (hdesc->desc[0].bDescriptorType == HID_DT_REPORT)
> +   rsize = le16_to_cpu(hdesc->desc[0].wDescriptorLength);
>
> if (!rsize || rsize > HID_MAX_DESCRIPTOR_SIZE) {
> dbg_hid("weird size of report descriptor (%u)\n", rsize);
>
>
>>
>> ==
>> BUG: KASAN: slab-out-of-bounds in usbhid_parse+0x9b1/0xa20
>> Read of size 1 at addr 88006c5f8edf by task kworker/1:2/1261
>>
>> CPU: 1 PID: 1261 Comm: kworker/1:2 Not tainted
>> 4.14.0-rc1-42251-gebb2c2437d80 #169
>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>> Workqueue: usb_hub_wq hub_event
>> Call Trace:
>>  __dump_stack lib/dump_stack.c:16
>>  dump_stack+0x292/0x395 lib/dump_stack.c:52
>>  print_address_description+0x78/0x280 mm/kasan/report.c:252
>>  kasan_report_error mm/kasan/report.c:351
>>  kasan_report+0x22f/0x340 mm/kasan/report.c:409
>>  __asan_report_load1_noabort+0x19/0x20 mm/kasan/report.c:427
>>  usbhid_parse+0x9b1/0xa20 drivers/hid/usbhid/hid-core.c:1004
>>  hid_add_device+0x16b/0xb30 drivers/hid/hid-core.c:2944
>>  usbhid_probe+0xc28/0x1100 drivers/hid/usbhid/hid-core.c:1369
>>  usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361
>>  really_probe drivers/base/dd.c:413
>>  driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
>>  __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
>>  bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
>>  __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
>>  device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
>>  bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
>>  device_add+0xd0b/0x1660 drivers/base/core.c:1835
>>  usb_set_configuration+0x104e/0x1870 drivers/usb/core/message.c:1932
>>  generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174
>>  usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266
>>  really_probe drivers/base/dd.c:413
>>  driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
>>  __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
>>  bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
>>  __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
>>  device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
>>  bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
>>  device_add+0xd0b/0x1

Re: usb/core: slab-out-of-bounds in usb_set_configuration

[Andrey Konovalov]

On Mon, Sep 18, 2017 at 8:50 PM, Greg Kroah-Hartman
<gre...@linuxfoundation.org> wrote:
> On Mon, Sep 18, 2017 at 07:22:24PM +0200, Andrey Konovalov wrote:
>> Hi!
>>
>> I've got the following crash while fuzzing the kernel with syzkaller.
>>
>> On commit ebb2c2437d8008d46796902ff390653822af6cc4 (Sep 18).
>>
>> It seems there's no proper size check of a
>> USB_DT_INTERFACE_ASSOCIATION descriptor. It's only checked that the
>> size is >= 2 in usb_parse_configuration(), so find_iad() might do
>> out-of-bounds access to intf_assoc->bInterfaceCount.
>
> Ah, nice catch!
>
> Does the patch below fix this?

Hi Greg,

I believe it does and the bug is no longer triggered with the
reproducer that I have.

Tested-by: Andrey Konovalov <andreyk...@google.com>

Thanks!

>
> thanks,
>
> greg k-h
>
> ---
>
> diff --git a/drivers/usb/core/config.c b/drivers/usb/core/config.c
> index 4be52c602e9b..a3dbac1938ec 100644
> --- a/drivers/usb/core/config.c
> +++ b/drivers/usb/core/config.c
> @@ -643,15 +643,23 @@ static int usb_parse_configuration(struct usb_device 
> *dev, int cfgidx,
>
> } else if (header->bDescriptorType ==
> USB_DT_INTERFACE_ASSOCIATION) {
> +   struct usb_interface_assoc_descriptor *d;
> +
> +   d = (struct usb_interface_assoc_descriptor *)header;
> +   if (d->bLength < USB_DT_INTERFACE_ASSOCIATION_SIZE) {
> +   dev_warn(ddev,
> +"config %d has an invalid interface 
> association descriptor of length %d, skipping\n",
> +cfgno, d->bLength);
> +   continue;
> +   }
> +
> if (iad_num == USB_MAXIADS) {
> dev_warn(ddev, "found more Interface "
>"Association Descriptors "
>"than allocated for in "
>"configuration %d\n", cfgno);
> } else {
> -   config->intf_assoc[iad_num] =
> -   (struct usb_interface_assoc_descriptor
> -   *)header;
> +   config->intf_assoc[iad_num] = d;
> iad_num++;
> }
>
> diff --git a/include/uapi/linux/usb/ch9.h b/include/uapi/linux/usb/ch9.h
> index ce1169af39d7..2a5d63040a0b 100644
> --- a/include/uapi/linux/usb/ch9.h
> +++ b/include/uapi/linux/usb/ch9.h
> @@ -780,6 +780,7 @@ struct usb_interface_assoc_descriptor {
> __u8  iFunction;
>  } __attribute__ ((packed));
>
> +#define USB_DT_INTERFACE_ASSOCIATION_SIZE  8
>
>  /*-*/
>
>
> --
> You received this message because you are subscribed to the Google Groups 
> "syzkaller" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to syzkaller+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

usb/hid: slab-out-of-bounds read in usbhid_parse

[Andrey Konovalov]

Hi!

I've got the following crash while fuzzing the kernel with syzkaller.

On commit ebb2c2437d8008d46796902ff390653822af6cc4 (Sep 18).

It seems that there's no proper check on the hdesc->bNumDescriptors
value in usbhid_parse(). it iterates over hdesc->desc and accesses
hdesc->desc[n] fields, which might be out-of-bounds.

==
BUG: KASAN: slab-out-of-bounds in usbhid_parse+0x9b1/0xa20
Read of size 1 at addr 88006c5f8edf by task kworker/1:2/1261

CPU: 1 PID: 1261 Comm: kworker/1:2 Not tainted
4.14.0-rc1-42251-gebb2c2437d80 #169
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: usb_hub_wq hub_event
Call Trace:
 __dump_stack lib/dump_stack.c:16
 dump_stack+0x292/0x395 lib/dump_stack.c:52
 print_address_description+0x78/0x280 mm/kasan/report.c:252
 kasan_report_error mm/kasan/report.c:351
 kasan_report+0x22f/0x340 mm/kasan/report.c:409
 __asan_report_load1_noabort+0x19/0x20 mm/kasan/report.c:427
 usbhid_parse+0x9b1/0xa20 drivers/hid/usbhid/hid-core.c:1004
 hid_add_device+0x16b/0xb30 drivers/hid/hid-core.c:2944
 usbhid_probe+0xc28/0x1100 drivers/hid/usbhid/hid-core.c:1369
 usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361
 really_probe drivers/base/dd.c:413
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
 bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
 __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
 bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
 device_add+0xd0b/0x1660 drivers/base/core.c:1835
 usb_set_configuration+0x104e/0x1870 drivers/usb/core/message.c:1932
 generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174
 usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266
 really_probe drivers/base/dd.c:413
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
 bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
 __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
 bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
 device_add+0xd0b/0x1660 drivers/base/core.c:1835
 usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2457
 hub_port_connect drivers/usb/core/hub.c:4903
 hub_port_connect_change drivers/usb/core/hub.c:5009
 port_event drivers/usb/core/hub.c:5115
 hub_event+0x194d/0x3740 drivers/usb/core/hub.c:5195
 process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119
 worker_thread+0x221/0x1850 kernel/workqueue.c:2253
 kthread+0x3a1/0x470 kernel/kthread.c:231
 ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431

Allocated by task 1261:
 save_stack_trace+0x1b/0x20 arch/x86/kernel/stacktrace.c:59
 save_stack+0x43/0xd0 mm/kasan/kasan.c:447
 set_track mm/kasan/kasan.c:459
 kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551
 __kmalloc+0x14e/0x310 mm/slub.c:3782
 kmalloc ./include/linux/slab.h:498
 usb_get_configuration+0x372/0x2a60 drivers/usb/core/config.c:848
 usb_enumerate_device drivers/usb/core/hub.c:2290
 usb_new_device+0xaae/0x1020 drivers/usb/core/hub.c:2426
 hub_port_connect drivers/usb/core/hub.c:4903
 hub_port_connect_change drivers/usb/core/hub.c:5009
 port_event drivers/usb/core/hub.c:5115
 hub_event+0x194d/0x3740 drivers/usb/core/hub.c:5195
 process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119
 worker_thread+0x221/0x1850 kernel/workqueue.c:2253
 kthread+0x3a1/0x470 kernel/kthread.c:231
 ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431

Freed by task 2927:
 save_stack_trace+0x1b/0x20 arch/x86/kernel/stacktrace.c:59
 save_stack+0x43/0xd0 mm/kasan/kasan.c:447
 set_track mm/kasan/kasan.c:459
 kasan_slab_free+0x72/0xc0 mm/kasan/kasan.c:524
 slab_free_hook mm/slub.c:1390
 slab_free_freelist_hook mm/slub.c:1412
 slab_free mm/slub.c:2988
 kfree+0xf6/0x2f0 mm/slub.c:3919
 free_rb_tree_fname+0x8a/0xe0 fs/ext4/dir.c:402
 ext4_htree_free_dir_info fs/ext4/dir.c:424
 ext4_release_dir+0x49/0x70 fs/ext4/dir.c:622
 __fput+0x33e/0x800 fs/file_table.c:210
 fput+0x1a/0x20 fs/file_table.c:244
 task_work_run+0x1af/0x280 kernel/task_work.c:112
 tracehook_notify_resume ./include/linux/tracehook.h:191
 exit_to_usermode_loop+0x1e1/0x220 arch/x86/entry/common.c:162
 prepare_exit_to_usermode arch/x86/entry/common.c:197
 syscall_return_slowpath+0x414/0x480 arch/x86/entry/common.c:266
 entry_SYSCALL_64_fastpath+0xc0/0xc2 arch/x86/entry/entry_64.S:238

The buggy address belongs to the object at 88006c5f8ea0
 which belongs to the cache kmalloc-64 of size 64
The buggy address is located 63 bytes inside of
 64-byte region [88006c5f8ea0, 88006c5f8ee0)
The buggy address belongs to the page:
page:ea0001b17e00 count:1 mapcount:0 mapping:  (null) index:0x0
flags: 0x1000100(slab)
raw: 01000100   0001002a002a
raw: ea0001a83000 00150015 88006c403800 
page dumped because: kasan: 

usb/core: slab-out-of-bounds in usb_set_configuration

[Andrey Konovalov]

Hi!

I've got the following crash while fuzzing the kernel with syzkaller.

On commit ebb2c2437d8008d46796902ff390653822af6cc4 (Sep 18).

It seems there's no proper size check of a
USB_DT_INTERFACE_ASSOCIATION descriptor. It's only checked that the
size is >= 2 in usb_parse_configuration(), so find_iad() might do
out-of-bounds access to intf_assoc->bInterfaceCount.

gadgetfs: bound to dummy_udc driver
usb 1-1: new full-speed USB device number 2 using dummy_hcd
gadgetfs: connected
gadgetfs: disconnected
gadgetfs: connected
usb 1-1: config 1 interface 0 altsetting 0 has an invalid endpoint
with address 0x0, skipping
usb 1-1: New USB device found, idVendor=0020, idProduct=410e
usb 1-1: New USB device strings: Mfr=0, Product=8, SerialNumber=3
usb 1-1: Product: a
usb 1-1: SerialNumber: a
==
BUG: KASAN: slab-out-of-bounds in usb_set_configuration+0x1859/0x1870
Read of size 1 at addr 88006a9d00de by task kworker/0:2/1260

CPU: 0 PID: 1260 Comm: kworker/0:2 Not tainted
4.14.0-rc1-42251-gebb2c2437d80 #169
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: usb_hub_wq hub_event
Call Trace:
 __dump_stack lib/dump_stack.c:16
 dump_stack+0x292/0x395 lib/dump_stack.c:52
 print_address_description+0x78/0x280 mm/kasan/report.c:252
 kasan_report_error mm/kasan/report.c:351
 kasan_report+0x22f/0x340 mm/kasan/report.c:409
 __asan_report_load1_noabort+0x19/0x20 mm/kasan/report.c:427
 find_iad drivers/usb/core/message.c:1644
 usb_set_configuration+0x1859/0x1870 drivers/usb/core/message.c:1855
 generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174
 usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266
 really_probe drivers/base/dd.c:413
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
 bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
 __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
 bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
 device_add+0xd0b/0x1660 drivers/base/core.c:1835
 usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2457
 hub_port_connect drivers/usb/core/hub.c:4903
 hub_port_connect_change drivers/usb/core/hub.c:5009
 port_event drivers/usb/core/hub.c:5115
 hub_event+0x194d/0x3740 drivers/usb/core/hub.c:5195
 process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119
 worker_thread+0x221/0x1850 kernel/workqueue.c:2253
 kthread+0x3a1/0x470 kernel/kthread.c:231
 ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431

Allocated by task 1260:
 save_stack_trace+0x1b/0x20 arch/x86/kernel/stacktrace.c:59
 save_stack+0x43/0xd0 mm/kasan/kasan.c:447
 set_track mm/kasan/kasan.c:459
 kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551
 __kmalloc+0x14e/0x310 mm/slub.c:3782
 kmalloc ./include/linux/slab.h:498
 usb_get_configuration+0x372/0x2a60 drivers/usb/core/config.c:848
 usb_enumerate_device drivers/usb/core/hub.c:2290
 usb_new_device+0xaae/0x1020 drivers/usb/core/hub.c:2426
 hub_port_connect drivers/usb/core/hub.c:4903
 hub_port_connect_change drivers/usb/core/hub.c:5009
 port_event drivers/usb/core/hub.c:5115
 hub_event+0x194d/0x3740 drivers/usb/core/hub.c:5195
 process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119
 worker_thread+0x221/0x1850 kernel/workqueue.c:2253
 kthread+0x3a1/0x470 kernel/kthread.c:231
 ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431

Freed by task 2870:
 save_stack_trace+0x1b/0x20 arch/x86/kernel/stacktrace.c:59
 save_stack+0x43/0xd0 mm/kasan/kasan.c:447
 set_track mm/kasan/kasan.c:459
 kasan_slab_free+0x72/0xc0 mm/kasan/kasan.c:524
 slab_free_hook mm/slub.c:1390
 slab_free_freelist_hook mm/slub.c:1412
 slab_free mm/slub.c:2988
 kfree+0xf6/0x2f0 mm/slub.c:3919
 load_elf_binary+0x39c2/0x4fa0 fs/binfmt_elf.c:1087
 search_binary_handler+0x146/0x480 fs/exec.c:1634
 exec_binprm fs/exec.c:1676
 do_execveat_common.isra.31+0x16d2/0x2200 fs/exec.c:1798
 do_execve fs/exec.c:1842
 SYSC_execve fs/exec.c:1923
 SyS_execve+0x3e/0x50 fs/exec.c:1918
 do_syscall_64+0x2c5/0x830 arch/x86/entry/common.c:287
 return_from_SYSCALL_64+0x0/0x7a arch/x86/entry/entry_64.S:245

The buggy address belongs to the object at 88006a9d00c0
 which belongs to the cache kmalloc-32 of size 32
The buggy address is located 30 bytes inside of
 32-byte region [88006a9d00c0, 88006a9d00e0)
The buggy address belongs to the page:
page:ea0001aa7400 count:1 mapcount:0 mapping:  (null)
index:0x88006a9d05a0
flags: 0x1000100(slab)
raw: 01000100  88006a9d05a0 000180550054
raw: ea000193fa00 00140014 88006c403980 
page dumped because: kasan: bad access detected

Memory state around the buggy address:
 88006a9cff80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
 88006a9d: fb fb fb fb fc fc fb fb fb fb fc fc fb fb fb fb
>88006a9d0080: fc fc fb fb fb fb fc fc 00 00 00 05 fc fc fb fb
  

Re: usb/gadget: stalls in dummy_timer

[Andrey Konovalov]

On Thu, Sep 14, 2017 at 7:49 PM, Alan Stern <st...@rowland.harvard.edu> wrote:
> On Thu, 14 Sep 2017, Andrey Konovalov wrote:
>
>> Looked at this a little more.
>>
>> dummy_timer() stucks in an infinite loop. It calls
>> usb_hcd_giveback_urb(), which in turn calls usbtouch_irq(), which
>> calls usb_submit_urb(), which calls dummy_urb_enqueue() and puts urb
>> back into dummy urb queue. dummy_timer() then does goto restart, finds
>> the urb and calls usb_hcd_giveback_urb() again. And this process goes
>> on again and again. It seems that something should either process the
>> urb and set urb->status or it should just expire.
>
> There is some throttling code, but it applies only to bulk transfers.
> Probably because the bandwidth limits for other types are slightly
> different.  However, I don't think we need to worry about this level of
> detail, since the driver makes a number of other approximations anyway.
>
> Try the patch below; it should fix the problem.

Hi Alan,

Just tried your patch, my reproducer still hangs the kernel until all
memory is exhausted.

Thanks!

>
> Alan Stern
>
>
>
> Index: usb-4.x/drivers/usb/gadget/udc/dummy_hcd.c
> ===
> --- usb-4.x.orig/drivers/usb/gadget/udc/dummy_hcd.c
> +++ usb-4.x/drivers/usb/gadget/udc/dummy_hcd.c
> @@ -1781,7 +1781,6 @@ restart:
> struct dummy_request*req;
> u8  address;
> struct dummy_ep *ep = NULL;
> -   int type;
> int status = -EINPROGRESS;
>
> urb = urbp->urb;
> @@ -1789,14 +1788,10 @@ restart:
> goto return_urb;
> else if (dum_hcd->rh_state != DUMMY_RH_RUNNING)
> continue;
> -   type = usb_pipetype(urb->pipe);
>
> -   /* used up this frame's non-periodic bandwidth?
> -* FIXME there's infinite bandwidth for control and
> -* periodic transfers ... unrealistic.
> -*/
> -   if (total <= 0 && type == PIPE_BULK)
> -   continue;
> +   /* Used up this frame's bandwidth? */
> +   if (total <= 0)
> +   break;
>
> /* find the gadget's ep for this request (if configured) */
> address = usb_pipeendpoint (urb->pipe);
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: usb/gadget: stalls in dummy_timer

[Andrey Konovalov]

On Tue, Sep 12, 2017 at 7:44 PM, Andrey Konovalov <andreyk...@google.com> wrote:
> On Tue, Sep 12, 2017 at 7:06 PM, Dmitry Torokhov
> <dmitry.torok...@gmail.com> wrote:
>> On Tue, Sep 12, 2017 at 05:48:51PM +0200, Andrey Konovalov wrote:
>>> On Mon, Sep 11, 2017 at 8:54 PM, Dmitry Torokhov
>>> <dmitry.torok...@gmail.com> wrote:
>>> > On Mon, Sep 11, 2017 at 8:15 AM, Andrey Konovalov <andreyk...@google.com> 
>>> > wrote:
>>> >> On Mon, Sep 11, 2017 at 3:25 PM, Alan Stern <st...@rowland.harvard.edu> 
>>> >> wrote:
>>> >>> On Mon, 11 Sep 2017, Andrey Konovalov wrote:
>>> >>>
>>> >>>> Hi!
>>> >>>>
>>> >>>> I've been getting stall reports like this one while fuzzing the USB
>>> >>>> stack with gadgetfs. I'm wondering whether this is a bug in gadgetfs
>>> >>>> or is this report induced by the changes I've made to the USB core
>>> >>>> code. I didn't touch gadgetfs code though (except for adding a few
>>> >>>> printk's).
>>> >>>>
>>> >>>> I'm on commit 81a84ad3cb5711cec79f4dd53a4ce026b092c432
>>> >>>
>>> >>> It's possible that this was caused by commit f16443a034c7 ("USB:
>>> >>> gadgetfs, dummy-hcd, net2280: fix locking for callbacks").  I've been
>>> >>> meaning to repair the commit but haven't done it yet.
>>> >>>
>>> >>> Can you test with that commit reverted?  You may end up seeing other
>>> >>> problems instead -- the ones that commit was intended to solve -- but
>>> >>> perhaps the stalls won't occur.
>>> >>
>>> >> So I've reverted both: the changes I made to USB core and the commit
>>> >> you mentioned, still saw the stalls.
>>> >>
>>> >> I've manged to find a way to reproduce this and now I'm not sure the
>>> >> problem is actually in gadgetfs, it might be the usbtouchscreen
>>> >> driver.
>>> >>
>>> >> The crash log is below.
>>> >>
>>> >> Thanks!
>>> >>
>>> >> gadgetfs: bound to dummy_udc driver
>>> >> usb 1-1: new full-speed USB device number 2 using dummy_hcd
>>> >> gadgetfs: connected
>>> >> gadgetfs: disconnected
>>> >> gadgetfs: connected
>>> >> usb 1-1: config 8 interface 0 altsetting 9 endpoint 0x8F has an
>>> >> invalid bInterval 0, changing to 10
>>> >> usb 1-1: config 8 interface 0 altsetting 9 endpoint 0x8F has invalid
>>> >> maxpacket 839, setting to 64
>>> >> usb 1-1: config 8 interface 0 altsetting 9 endpoint 0x7 has invalid
>>> >> maxpacket 1839, setting to 64
>>> >> usb 1-1: config 8 interface 0 has no altsetting 0
>>> >> usb 1-1: New USB device found, idVendor=0403, idProduct=f9e9
>>> >> usb 1-1: New USB device strings: Mfr=4, Product=8, SerialNumber=255
>>> >> usb 1-1: Product: a
>>> >> usb 1-1: Manufacturer: a
>>> >> usb 1-1: SerialNumber: a
>>> >> gadgetfs: configuration #8
>>> >> input: a a as /devices/platform/dummy_hcd.0/usb1/1-1/1-1:8.0/input/input8
>>> >> evbug: Connected device: input8 (a a at usb-dummy_hcd.0-1/input0)
>>> >> kworker/0:0: page allocation failure: order:0,
>>> >> mode:0x1280020(GFP_ATOMIC|__GFP_NOTRACK), nodemask=(null)
>>> >> kworker/0:0 cpuset=/ mems_allowed=0
>>> >
>>> > It seems you are running out of memory.
>>> >
>>> >> Swap cache stats: add 0, delete 0, find 0/0
>>> >> Free swap  = 0kB
>>> >> Total swap = 0kB
>>> >
>>> > And no swap. I think you need to give the box a bit more memory (or
>>> > there might be a leak somewhere).
>>>
>>> Increasing the amount of memory doesn't help. It looks like
>>> usbtouch_irq() gets called in an infinite loop, and calls
>>> usb_submit_urb on each iteration, until the kernel runs out of memory.
>>
>> Yes, that is exactly how USB interrupt-driven devices work. Their URB
>> completion routine handles the data and immediately resubmits URB to get
>> more data. The device/HCD will signal interrupt once more data is
>> available and the process starts over again. The only time we stop
>> resubmitting URBs if we get one of the following er

Re: usb/uwb: WARNING in hwarc_neep_init/usb_submit_urb

[Andrey Konovalov]

On Wed, Sep 13, 2017 at 4:59 PM, Alan Stern <st...@rowland.harvard.edu> wrote:
> On Wed, 13 Sep 2017, Dmitry Vyukov wrote:
>
>> On Tue, Sep 12, 2017 at 9:57 PM, Greg Kroah-Hartman
>> <gre...@linuxfoundation.org> wrote:
>> > On Tue, Sep 12, 2017 at 08:53:11PM +0200, Andrey Konovalov wrote:
>> >> Hi!
>> >>
>> >> I've got the following crash while fuzzing the kernel with syzkaller.
>> >>
>> >> On commit 81a84ad3cb5711cec79f4dd53a4ce026b092c432 (Sep 3).
>> >>
>> >> gadgetfs: bound to dummy_udc driver
>> >> usb 1-1: new full-speed USB device number 2 using dummy_hcd
>> >> gadgetfs: connected
>> >> gadgetfs: disconnected
>> >> gadgetfs: connected
>> >> usb 1-1: New USB device found, idVendor=, idProduct=
>> >> usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=203
>> >> usb 1-1: SerialNumber: a
>> >> gadgetfs: configuration #7
>> >> usb 1-1: BOGUS urb xfer, pipe 1 != type 3
>> >> [ cut here ]
>> >> WARNING: CPU: 0 PID: 3 at drivers/usb/core/urb.c:449 
>> >> usb_submit_urb+0xf8a/0x11d0
>> >> Modules linked in:
>> >> CPU: 0 PID: 3 Comm: kworker/0:0 Not tainted 4.13.0+ #111
>> >> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 
>> >> 01/01/2011
>> >> Workqueue: usb_hub_wq hub_event
>> >> task: 88006bdc1a00 task.stack: 88006bde8000
>> >> RIP: 0010:usb_submit_urb+0xf8a/0x11d0 drivers/usb/core/urb.c:448
>> >> RSP: 0018:88006bdee3c0 EFLAGS: 00010282
>> >> RAX: 0029 RBX: 8800672a7200 RCX: 
>> >> RDX: 0029 RSI: 88006c815c78 RDI: ed000d7bdc6a
>> >> RBP: 88006bdee4c0 R08: fbfff0fe00ff R09: fbfff0fe00ff
>> >> R10: 0018 R11: fbfff0fe00fe R12: 11000d7bdc7f
>> >> R13: 0003 R14: 0001 R15: 88006b02cc90
>> >> FS:  () GS:88006c80() 
>> >> knlGS:
>> >> CS:  0010 DS:  ES:  CR0: 80050033
>> >> CR2: 7fe4daddf000 CR3: 6add6000 CR4: 06f0
>> >> Call Trace:
>> >>  hwarc_neep_init+0x4ce/0x9c0 drivers/uwb/hwa-rc.c:710
>> >>  uwb_rc_add+0x2fb/0x730 drivers/uwb/lc-rc.c:361
>> >>  hwarc_probe+0x34e/0x9b0 drivers/uwb/hwa-rc.c:858
>> >>  usb_probe_interface+0x351/0x8d0 drivers/usb/core/driver.c:361
>> >>  really_probe drivers/base/dd.c:385
>> >>  driver_probe_device+0x610/0xa00 drivers/base/dd.c:529
>> >>  __device_attach_driver+0x230/0x290 drivers/base/dd.c:625
>> >>  bus_for_each_drv+0x15e/0x210 drivers/base/bus.c:463
>> >>  __device_attach+0x269/0x3c0 drivers/base/dd.c:682
>> >>  device_initial_probe+0x1f/0x30 drivers/base/dd.c:729
>> >>  bus_probe_device+0x1da/0x280 drivers/base/bus.c:523
>> >>  device_add+0xcf9/0x1640 drivers/base/core.c:1703
>> >>  usb_set_configuration+0x1064/0x1890 drivers/usb/core/message.c:1932
>> >>  generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174
>> >>  usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266
>> >>  really_probe drivers/base/dd.c:385
>> >>  driver_probe_device+0x610/0xa00 drivers/base/dd.c:529
>> >>  __device_attach_driver+0x230/0x290 drivers/base/dd.c:625
>> >>  bus_for_each_drv+0x15e/0x210 drivers/base/bus.c:463
>> >>  __device_attach+0x269/0x3c0 drivers/base/dd.c:682
>> >>  device_initial_probe+0x1f/0x30 drivers/base/dd.c:729
>> >>  bus_probe_device+0x1da/0x280 drivers/base/bus.c:523
>> >>  device_add+0xcf9/0x1640 drivers/base/core.c:1703
>> >>  usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2457
>> >>  hub_port_connect drivers/usb/core/hub.c:4890
>> >>  hub_port_connect_change drivers/usb/core/hub.c:4996
>> >>  port_event drivers/usb/core/hub.c:5102
>> >>  hub_event+0x23c8/0x37c0 drivers/usb/core/hub.c:5182
>> >>  process_one_work+0x9fb/0x1570 kernel/workqueue.c:2097
>> >>  worker_thread+0x1e4/0x1350 kernel/workqueue.c:2231
>> >>  kthread+0x324/0x3f0 kernel/kthread.c:231
>> >>  ret_from_fork+0x25/0x30 arch/x86/entry/entry_64.S:425
>> >> Code: 48 8b 85 30 ff ff ff 48 8d b8 98 00 00 00 e8 8e 93 07 ff 45 89
>> >> e8 44 89 f1 4c 89 fa 48 89 c6 48 c7 c7 a0 e5 55 86 e8 20 08 8f fd <0f>
>> >> ff e9 9b f7 ff ff e8 4a 0

[PATCH] uwb: ensure that endpoint is interrupt

[Andrey Konovalov]

hwarc_neep_init() assumes that endpoint 0 is interrupt, but there's no
check for that, which results in a WARNING in USB core code, when a bad
USB descriptor is provided from a device:

usb 1-1: BOGUS urb xfer, pipe 1 != type 3
[ cut here ]
WARNING: CPU: 0 PID: 3 at drivers/usb/core/urb.c:449 usb_submit_urb+0xf8a/0x11d0
Modules linked in:
CPU: 0 PID: 3 Comm: kworker/0:0 Not tainted 4.13.0+ #111
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: usb_hub_wq hub_event
task: 88006bdc1a00 task.stack: 88006bde8000
RIP: 0010:usb_submit_urb+0xf8a/0x11d0 drivers/usb/core/urb.c:448
RSP: 0018:88006bdee3c0 EFLAGS: 00010282
RAX: 0029 RBX: 8800672a7200 RCX: 
RDX: 0029 RSI: 88006c815c78 RDI: ed000d7bdc6a
RBP: 88006bdee4c0 R08: fbfff0fe00ff R09: fbfff0fe00ff
R10: 0018 R11: fbfff0fe00fe R12: 11000d7bdc7f
R13: 0003 R14: 0001 R15: 88006b02cc90
FS:  () GS:88006c80() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 7fe4daddf000 CR3: 6add6000 CR4: 06f0
Call Trace:
 hwarc_neep_init+0x4ce/0x9c0 drivers/uwb/hwa-rc.c:710
 uwb_rc_add+0x2fb/0x730 drivers/uwb/lc-rc.c:361
 hwarc_probe+0x34e/0x9b0 drivers/uwb/hwa-rc.c:858
 usb_probe_interface+0x351/0x8d0 drivers/usb/core/driver.c:361
 really_probe drivers/base/dd.c:385
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:529
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:625
 bus_for_each_drv+0x15e/0x210 drivers/base/bus.c:463
 __device_attach+0x269/0x3c0 drivers/base/dd.c:682
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:729
 bus_probe_device+0x1da/0x280 drivers/base/bus.c:523
 device_add+0xcf9/0x1640 drivers/base/core.c:1703
 usb_set_configuration+0x1064/0x1890 drivers/usb/core/message.c:1932
 generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174
 usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266
 really_probe drivers/base/dd.c:385
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:529
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:625
 bus_for_each_drv+0x15e/0x210 drivers/base/bus.c:463
 __device_attach+0x269/0x3c0 drivers/base/dd.c:682
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:729
 bus_probe_device+0x1da/0x280 drivers/base/bus.c:523
 device_add+0xcf9/0x1640 drivers/base/core.c:1703
 usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2457
 hub_port_connect drivers/usb/core/hub.c:4890
 hub_port_connect_change drivers/usb/core/hub.c:4996
 port_event drivers/usb/core/hub.c:5102
 hub_event+0x23c8/0x37c0 drivers/usb/core/hub.c:5182
 process_one_work+0x9fb/0x1570 kernel/workqueue.c:2097
 worker_thread+0x1e4/0x1350 kernel/workqueue.c:2231
 kthread+0x324/0x3f0 kernel/kthread.c:231
 ret_from_fork+0x25/0x30 arch/x86/entry/entry_64.S:425
Code: 48 8b 85 30 ff ff ff 48 8d b8 98 00 00 00 e8 8e 93 07 ff 45 89
e8 44 89 f1 4c 89 fa 48 89 c6 48 c7 c7 a0 e5 55 86 e8 20 08 8f fd <0f>
ff e9 9b f7 ff ff e8 4a 04 d6 fd e9 80 f7 ff ff e8 60 11 a6
---[ end trace 55d741234124cfc3 ]---

Check that endpoint is interrupt.

Found by syzkaller.

Signed-off-by: Andrey Konovalov <andreyk...@google.com>
---
 drivers/uwb/hwa-rc.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/uwb/hwa-rc.c b/drivers/uwb/hwa-rc.c
index 35a1e777b449..9a53912bdfe9 100644
--- a/drivers/uwb/hwa-rc.c
+++ b/drivers/uwb/hwa-rc.c
@@ -825,6 +825,8 @@ static int hwarc_probe(struct usb_interface *iface,
 
if (iface->cur_altsetting->desc.bNumEndpoints < 1)
return -ENODEV;
+   if (!usb_endpoint_xfer_int(>cur_altsetting->endpoint[0].desc))
+   return -ENODEV;
 
result = -ENOMEM;
uwb_rc = uwb_rc_alloc();
-- 
2.14.1.690.gbb1197296e-goog

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] uwb: properly check kthread_run return value

[Andrey Konovalov]

On Wed, Sep 13, 2017 at 6:53 PM, Dmitry Vyukov <dvyu...@google.com> wrote:
> On Wed, Sep 13, 2017 at 6:06 PM, Andrey Konovalov <andreyk...@google.com> 
> wrote:
>> uwbd_start() calls kthread_run() and checks that the return value is
>> not NULL. But the return value is not NULL in case kthread_run() fails,
>> it takes the form of ERR_PTR(-EINTR).
>>
>> Use IS_ERR() instead.
>>
>> Also add a check to uwbd_stop().
>>
>> Signed-off-by: Andrey Konovalov <andreyk...@google.com>
>> ---
>>  drivers/uwb/uwbd.c | 5 +++--
>>  1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/uwb/uwbd.c b/drivers/uwb/uwbd.c
>> index 01c20a260a8b..2a3cc48d837c 100644
>> --- a/drivers/uwb/uwbd.c
>> +++ b/drivers/uwb/uwbd.c
>> @@ -303,7 +303,7 @@ static int uwbd(void *param)
>>  void uwbd_start(struct uwb_rc *rc)
>>  {
>> rc->uwbd.task = kthread_run(uwbd, rc, "uwbd");
>> -   if (rc->uwbd.task == NULL)
>> +   if (IS_ERR(rc->uwbd.task))
>> printk(KERN_ERR "UWB: Cannot start management daemon; "
>>"UWB won't work\n");
>> else
>> @@ -313,7 +313,8 @@ void uwbd_start(struct uwb_rc *rc)
>>  /* Stop the UWB daemon and free any unprocessed events */
>>  void uwbd_stop(struct uwb_rc *rc)
>>  {
>> -   kthread_stop(rc->uwbd.task);
>> +   if (!IS_ERR(rc->uwbd.task))
>> +   kthread_stop(rc->uwbd.task);
>
> It looks weird to assign an error to rc->uwbd.task and leave it there.
> I think it's better to not assign errors to rc->uwbd.task, i.e. it's
> either a valid task or NULL.

Sent v3.

>
>> uwbd_flush(rc);
>>  }
>>
>> --
>> 2.14.1.581.gf28d330327-goog
>>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3] uwb: properly check kthread_run return value

[Andrey Konovalov]

uwbd_start() calls kthread_run() and checks that the return value is
not NULL. But the return value is not NULL in case kthread_run() fails,
it takes the form of ERR_PTR(-EINTR).

Use IS_ERR() instead.

Also add a check to uwbd_stop().

Signed-off-by: Andrey Konovalov <andreyk...@google.com>
---

v2: don't assign error values to rc->uwbd.task.
v1: added a check to uwbd_stop().

---
 drivers/uwb/uwbd.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/uwb/uwbd.c b/drivers/uwb/uwbd.c
index 01c20a260a8b..39dd4ef53c77 100644
--- a/drivers/uwb/uwbd.c
+++ b/drivers/uwb/uwbd.c
@@ -302,18 +302,22 @@ static int uwbd(void *param)
 /** Start the UWB daemon */
 void uwbd_start(struct uwb_rc *rc)
 {
-   rc->uwbd.task = kthread_run(uwbd, rc, "uwbd");
-   if (rc->uwbd.task == NULL)
+   struct task_struct *task = kthread_run(uwbd, rc, "uwbd");
+   if (IS_ERR(task)) {
+   rc->uwbd.task = NULL;
printk(KERN_ERR "UWB: Cannot start management daemon; "
   "UWB won't work\n");
-   else
+   } else {
+   rc->uwbd.task = task;
rc->uwbd.pid = rc->uwbd.task->pid;
+   }
 }
 
 /* Stop the UWB daemon and free any unprocessed events */
 void uwbd_stop(struct uwb_rc *rc)
 {
-   kthread_stop(rc->uwbd.task);
+   if (rc->uwbd.task)
+   kthread_stop(rc->uwbd.task);
uwbd_flush(rc);
 }
 
-- 
2.14.1.690.gbb1197296e-goog

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2] uwb: properly check kthread_run return value

[Andrey Konovalov]

uwbd_start() calls kthread_run() and checks that the return value is
not NULL. But the return value is not NULL in case kthread_run() fails,
it takes the form of ERR_PTR(-EINTR).

Use IS_ERR() instead.

Also add a check to uwbd_stop().

Signed-off-by: Andrey Konovalov <andreyk...@google.com>
---
 drivers/uwb/uwbd.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/uwb/uwbd.c b/drivers/uwb/uwbd.c
index 01c20a260a8b..2a3cc48d837c 100644
--- a/drivers/uwb/uwbd.c
+++ b/drivers/uwb/uwbd.c
@@ -303,7 +303,7 @@ static int uwbd(void *param)
 void uwbd_start(struct uwb_rc *rc)
 {
rc->uwbd.task = kthread_run(uwbd, rc, "uwbd");
-   if (rc->uwbd.task == NULL)
+   if (IS_ERR(rc->uwbd.task))
printk(KERN_ERR "UWB: Cannot start management daemon; "
   "UWB won't work\n");
else
@@ -313,7 +313,8 @@ void uwbd_start(struct uwb_rc *rc)
 /* Stop the UWB daemon and free any unprocessed events */
 void uwbd_stop(struct uwb_rc *rc)
 {
-   kthread_stop(rc->uwbd.task);
+   if (!IS_ERR(rc->uwbd.task))
+   kthread_stop(rc->uwbd.task);
uwbd_flush(rc);
 }
 
-- 
2.14.1.581.gf28d330327-goog

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] uwb: properly check kthread_run return value

[Andrey Konovalov]

On Wed, Sep 13, 2017 at 5:06 PM, Andrey Konovalov <andreyk...@google.com> wrote:
> uwbd_start() calls kthread_run() and checks that the return value is
> not NULL. But the return value is not NULL in case kthread_run() fails,
> it takes the form of ERR_PTR(-EINTR).
>
> Use IS_ERR() instead.

This uncovers another issue, there's no check of rc->uwbd.task in
uwbd_stop(). Will mail v2.

>
> Signed-off-by: Andrey Konovalov <andreyk...@google.com>
> ---
>  drivers/uwb/uwbd.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/uwb/uwbd.c b/drivers/uwb/uwbd.c
> index 01c20a260a8b..9f615b303576 100644
> --- a/drivers/uwb/uwbd.c
> +++ b/drivers/uwb/uwbd.c
> @@ -303,7 +303,7 @@ static int uwbd(void *param)
>  void uwbd_start(struct uwb_rc *rc)
>  {
> rc->uwbd.task = kthread_run(uwbd, rc, "uwbd");
> -   if (rc->uwbd.task == NULL)
> +   if (IS_ERR(rc->uwbd.task))
> printk(KERN_ERR "UWB: Cannot start management daemon; "
>"UWB won't work\n");
> else
> --
> 2.14.1.581.gf28d330327-goog
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: usb/uwb: GPF in uwbd_start

[Andrey Konovalov]

On Tue, Sep 12, 2017 at 9:55 PM, Greg Kroah-Hartman
<gre...@linuxfoundation.org> wrote:
> On Tue, Sep 12, 2017 at 07:10:07PM +0200, Andrey Konovalov wrote:
>> Hi!
>>
>> I've got the following crashes while fuzzing the kernel with syzkaller.
>>
>> On commit 81a84ad3cb5711cec79f4dd53a4ce026b092c432 (Sep 3).
>>
>> uwbd_start() calls kthread_run() and checks that the return value in
>> not NULL. But the return value is not NULL in case kthread_run()
>> fails, it takes the form of ERR_PTR(-EINTR).
>
> Great, do you want to write a patch for this, or do you want me to?

Just mailed a patch.

>
> And I'm guessing you really don't have the real hardware for this
> device, right?

I don't have a hardware reproducer, but making it is just a question
of effort. There's the Facedancer21 board [1], which can be used to
emulate arbitrary USB devices. It's also possible to do this with with
something like Raspberry Pi Zero in USB gadget mode through gadgetfs.

[1] https://int3.cc/products/facedancer21

>
> thanks,
>
> greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] uwb: properly check kthread_run return value

[Andrey Konovalov]

uwbd_start() calls kthread_run() and checks that the return value is
not NULL. But the return value is not NULL in case kthread_run() fails,
it takes the form of ERR_PTR(-EINTR).

Use IS_ERR() instead.

Signed-off-by: Andrey Konovalov <andreyk...@google.com>
---
 drivers/uwb/uwbd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/uwb/uwbd.c b/drivers/uwb/uwbd.c
index 01c20a260a8b..9f615b303576 100644
--- a/drivers/uwb/uwbd.c
+++ b/drivers/uwb/uwbd.c
@@ -303,7 +303,7 @@ static int uwbd(void *param)
 void uwbd_start(struct uwb_rc *rc)
 {
rc->uwbd.task = kthread_run(uwbd, rc, "uwbd");
-   if (rc->uwbd.task == NULL)
+   if (IS_ERR(rc->uwbd.task))
printk(KERN_ERR "UWB: Cannot start management daemon; "
   "UWB won't work\n");
else
-- 
2.14.1.581.gf28d330327-goog

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

usb/uwb: WARNING in hwarc_neep_init/usb_submit_urb

[Andrey Konovalov]

Hi!

I've got the following crash while fuzzing the kernel with syzkaller.

On commit 81a84ad3cb5711cec79f4dd53a4ce026b092c432 (Sep 3).

gadgetfs: bound to dummy_udc driver
usb 1-1: new full-speed USB device number 2 using dummy_hcd
gadgetfs: connected
gadgetfs: disconnected
gadgetfs: connected
usb 1-1: New USB device found, idVendor=, idProduct=
usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=203
usb 1-1: SerialNumber: a
gadgetfs: configuration #7
usb 1-1: BOGUS urb xfer, pipe 1 != type 3
[ cut here ]
WARNING: CPU: 0 PID: 3 at drivers/usb/core/urb.c:449 usb_submit_urb+0xf8a/0x11d0
Modules linked in:
CPU: 0 PID: 3 Comm: kworker/0:0 Not tainted 4.13.0+ #111
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: usb_hub_wq hub_event
task: 88006bdc1a00 task.stack: 88006bde8000
RIP: 0010:usb_submit_urb+0xf8a/0x11d0 drivers/usb/core/urb.c:448
RSP: 0018:88006bdee3c0 EFLAGS: 00010282
RAX: 0029 RBX: 8800672a7200 RCX: 
RDX: 0029 RSI: 88006c815c78 RDI: ed000d7bdc6a
RBP: 88006bdee4c0 R08: fbfff0fe00ff R09: fbfff0fe00ff
R10: 0018 R11: fbfff0fe00fe R12: 11000d7bdc7f
R13: 0003 R14: 0001 R15: 88006b02cc90
FS:  () GS:88006c80() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 7fe4daddf000 CR3: 6add6000 CR4: 06f0
Call Trace:
 hwarc_neep_init+0x4ce/0x9c0 drivers/uwb/hwa-rc.c:710
 uwb_rc_add+0x2fb/0x730 drivers/uwb/lc-rc.c:361
 hwarc_probe+0x34e/0x9b0 drivers/uwb/hwa-rc.c:858
 usb_probe_interface+0x351/0x8d0 drivers/usb/core/driver.c:361
 really_probe drivers/base/dd.c:385
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:529
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:625
 bus_for_each_drv+0x15e/0x210 drivers/base/bus.c:463
 __device_attach+0x269/0x3c0 drivers/base/dd.c:682
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:729
 bus_probe_device+0x1da/0x280 drivers/base/bus.c:523
 device_add+0xcf9/0x1640 drivers/base/core.c:1703
 usb_set_configuration+0x1064/0x1890 drivers/usb/core/message.c:1932
 generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174
 usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266
 really_probe drivers/base/dd.c:385
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:529
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:625
 bus_for_each_drv+0x15e/0x210 drivers/base/bus.c:463
 __device_attach+0x269/0x3c0 drivers/base/dd.c:682
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:729
 bus_probe_device+0x1da/0x280 drivers/base/bus.c:523
 device_add+0xcf9/0x1640 drivers/base/core.c:1703
 usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2457
 hub_port_connect drivers/usb/core/hub.c:4890
 hub_port_connect_change drivers/usb/core/hub.c:4996
 port_event drivers/usb/core/hub.c:5102
 hub_event+0x23c8/0x37c0 drivers/usb/core/hub.c:5182
 process_one_work+0x9fb/0x1570 kernel/workqueue.c:2097
 worker_thread+0x1e4/0x1350 kernel/workqueue.c:2231
 kthread+0x324/0x3f0 kernel/kthread.c:231
 ret_from_fork+0x25/0x30 arch/x86/entry/entry_64.S:425
Code: 48 8b 85 30 ff ff ff 48 8d b8 98 00 00 00 e8 8e 93 07 ff 45 89
e8 44 89 f1 4c 89 fa 48 89 c6 48 c7 c7 a0 e5 55 86 e8 20 08 8f fd <0f>
ff e9 9b f7 ff ff e8 4a 04 d6 fd e9 80 f7 ff ff e8 60 11 a6
---[ end trace 55d741234124cfc3 ]---
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

usb/uwb: GPF in uwbd_start

[Andrey Konovalov]

Hi!

I've got the following crashes while fuzzing the kernel with syzkaller.

On commit 81a84ad3cb5711cec79f4dd53a4ce026b092c432 (Sep 3).

uwbd_start() calls kthread_run() and checks that the return value in
not NULL. But the return value is not NULL in case kthread_run()
fails, it takes the form of ERR_PTR(-EINTR).

kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault:  [#1] SMP KASAN
Modules linked in:
CPU: 0 PID: 5237 Comm: syz-executor Not tainted 4.13.0+ #106
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
task: 880069cc2700 task.stack: 8800607e8000
RIP: 0010:uwbd_start+0xcf/0x160 drivers/uwb/uwbd.c:311
RSP: 0018:8800607ee6d0 EFLAGS: 00010207
RAX: dc00 RBX: 8800606baa80 RCX: 
RDX: 009a RSI: 812b6153 RDI: 04d4
RBP: 8800607ee6e8 R08: fbfff0fe00fd R09: fbfff0fe00fd
R10: 8800607ee6f8 R11: fbfff0fe00fc R12: fffc
R13: 8800606baed8 R14: 8800606baab0 R15: 11000c0fdcf0
FS:  7f84c9aeb700() GS:88006c80() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 7f7829776000 CR3: 6a9b6000 CR4: 06f0
Call Trace:
 uwb_rc_add+0x2cd/0x730 drivers/uwb/lc-rc.c:359
 hwarc_probe+0x34e/0x9b0 drivers/uwb/hwa-rc.c:858
 usb_probe_interface+0x351/0x8d0 drivers/usb/core/driver.c:361
 really_probe drivers/base/dd.c:385
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:529
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:625
 bus_for_each_drv+0x15e/0x210 drivers/base/bus.c:463
 __device_attach+0x269/0x3c0 drivers/base/dd.c:682
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:729
 bus_probe_device+0x1da/0x280 drivers/base/bus.c:523
 device_add+0xcf9/0x1640 drivers/base/core.c:1703
 usb_set_configuration+0x1064/0x1890 drivers/usb/core/message.c:1932
 generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174
 usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266
 really_probe drivers/base/dd.c:385
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:529
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:625
 bus_for_each_drv+0x15e/0x210 drivers/base/bus.c:463
 __device_attach+0x269/0x3c0 drivers/base/dd.c:682
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:729
 bus_probe_device+0x1da/0x280 drivers/base/bus.c:523
 device_add+0xcf9/0x1640 drivers/base/core.c:1703
 usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2457
 hub_port_connect drivers/usb/core/hub.c:4890
 hub_port_connect_change drivers/usb/core/hub.c:4996
 port_event drivers/usb/core/hub.c:5102
 hub_event_impl+0x23ec/0x37e0 drivers/usb/core/hub.c:5224
 gfs_hub_events_handle+0x6f6/0x900 drivers/usb/gadget/legacy/inode.c:1291
 dev_ioctl+0x1c0/0x280 drivers/usb/gadget/legacy/inode.c:1319
 vfs_ioctl fs/ioctl.c:45
 do_vfs_ioctl+0x1d2/0x1560 fs/ioctl.c:685
 SYSC_ioctl fs/ioctl.c:700
 SyS_ioctl+0x94/0xc0 fs/ioctl.c:691
 entry_SYSCALL_64_fastpath+0x1a/0xa5 arch/x86/entry/entry_64.S:203
RIP: 0033:0x447727
RSP: 002b:7f84c9aeabd8 EFLAGS: 0206 ORIG_RAX: 0010
RAX: ffda RBX: 7f84c9aeb700 RCX: 00447727
RDX: 0064 RSI: 4242 RDI: 0005
RBP: 7ffe7f91eaa0 R08:  R09: 
R10: 7f84c9aeb9d0 R11: 0206 R12: 
R13:  R14: 7f84c9aeb9c0 R15: 7f84c9aeb700
Code: 03 80 3c 02 00 0f 85 96 00 00 00 4c 8b a3 58 04 00 00 48 b8 00
00 00 00 00 fc ff df 49 8d bc 24 d8 04 00 00 48 89 fa 48 c1 ea 03 <0f>
b6 04 02 84 c0 74 04 3c 03 7e 5c 48 8d bb 50 04 00 00 48 b8
RIP: uwbd_start+0xcf/0x160 RSP: 8800607ee6d0
---[ end trace 16d16649a2b03b2e ]---
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: usb/gadget: stalls in dummy_timer

[Andrey Konovalov]

On Mon, Sep 11, 2017 at 8:54 PM, Dmitry Torokhov
<dmitry.torok...@gmail.com> wrote:
> On Mon, Sep 11, 2017 at 8:15 AM, Andrey Konovalov <andreyk...@google.com> 
> wrote:
>> On Mon, Sep 11, 2017 at 3:25 PM, Alan Stern <st...@rowland.harvard.edu> 
>> wrote:
>>> On Mon, 11 Sep 2017, Andrey Konovalov wrote:
>>>
>>>> Hi!
>>>>
>>>> I've been getting stall reports like this one while fuzzing the USB
>>>> stack with gadgetfs. I'm wondering whether this is a bug in gadgetfs
>>>> or is this report induced by the changes I've made to the USB core
>>>> code. I didn't touch gadgetfs code though (except for adding a few
>>>> printk's).
>>>>
>>>> I'm on commit 81a84ad3cb5711cec79f4dd53a4ce026b092c432
>>>
>>> It's possible that this was caused by commit f16443a034c7 ("USB:
>>> gadgetfs, dummy-hcd, net2280: fix locking for callbacks").  I've been
>>> meaning to repair the commit but haven't done it yet.
>>>
>>> Can you test with that commit reverted?  You may end up seeing other
>>> problems instead -- the ones that commit was intended to solve -- but
>>> perhaps the stalls won't occur.
>>
>> So I've reverted both: the changes I made to USB core and the commit
>> you mentioned, still saw the stalls.
>>
>> I've manged to find a way to reproduce this and now I'm not sure the
>> problem is actually in gadgetfs, it might be the usbtouchscreen
>> driver.
>>
>> The crash log is below.
>>
>> Thanks!
>>
>> gadgetfs: bound to dummy_udc driver
>> usb 1-1: new full-speed USB device number 2 using dummy_hcd
>> gadgetfs: connected
>> gadgetfs: disconnected
>> gadgetfs: connected
>> usb 1-1: config 8 interface 0 altsetting 9 endpoint 0x8F has an
>> invalid bInterval 0, changing to 10
>> usb 1-1: config 8 interface 0 altsetting 9 endpoint 0x8F has invalid
>> maxpacket 839, setting to 64
>> usb 1-1: config 8 interface 0 altsetting 9 endpoint 0x7 has invalid
>> maxpacket 1839, setting to 64
>> usb 1-1: config 8 interface 0 has no altsetting 0
>> usb 1-1: New USB device found, idVendor=0403, idProduct=f9e9
>> usb 1-1: New USB device strings: Mfr=4, Product=8, SerialNumber=255
>> usb 1-1: Product: a
>> usb 1-1: Manufacturer: a
>> usb 1-1: SerialNumber: a
>> gadgetfs: configuration #8
>> input: a a as /devices/platform/dummy_hcd.0/usb1/1-1/1-1:8.0/input/input8
>> evbug: Connected device: input8 (a a at usb-dummy_hcd.0-1/input0)
>> kworker/0:0: page allocation failure: order:0,
>> mode:0x1280020(GFP_ATOMIC|__GFP_NOTRACK), nodemask=(null)
>> kworker/0:0 cpuset=/ mems_allowed=0
>
> It seems you are running out of memory.
>
>> Swap cache stats: add 0, delete 0, find 0/0
>> Free swap  = 0kB
>> Total swap = 0kB
>
> And no swap. I think you need to give the box a bit more memory (or
> there might be a leak somewhere).

Increasing the amount of memory doesn't help. It looks like
usbtouch_irq() gets called in an infinite loop, and calls
usb_submit_urb on each iteration, until the kernel runs out of memory.

(gdb) bt
#0  unwind_next_frame (state=0x8801f6806120) at
arch/x86/kernel/unwind_frame.c:277
#1  0x81109e33 in unwind_next_frame (state=0x8801f515bd98)
at arch/x86/kernel/unwind_frame.c:269
#2  0x8108fa13 in __save_stack_trace
(trace=0x8801f68061b8, task=0x8801f515b400, regs=0x0
, nosched=false) at arch/x86/kernel/stacktrace.c:44
#3  0x8108fa8b in save_stack_trace (trace=) at
arch/x86/kernel/stacktrace.c:59
#4  0x81723873 in save_stack (flags=17301536) at mm/kasan/kasan.c:447
#5  0x81723b3d in set_track (flags=,
track=) at mm/kasan/kasan.c:459
#6  kasan_kmalloc (cache=0x8801f515bd98, object=,
size=, flags=17301536) at mm/kasan/kasan.c:551
#7  0x81724102 in kasan_slab_alloc (cache=,
object=, flags=) at mm/kasan/kasan.c:489
#8  0x8171f836 in slab_post_alloc_hook (p=,
size=, flags=, s=) at
mm/slab.h:440
#9  slab_alloc_node (addr=, node=,
gfpflags=, s=) at mm/slub.c:2712
#10 slab_alloc (addr=, gfpflags=,
s=) at mm/slub.c:2720
#11 kmem_cache_alloc_trace (s=0x8801f6401640, gfpflags=17301536,
size=) at mm/slub.c:2737
#12 0x83dc4ce3 in kmalloc (flags=,
size=) at ./include/linux/slab.h:493
#13 dummy_urb_enqueue (hcd=0x8801f0e5d200, urb=0x8801eac10d00,
mem_flags=17301536) at drivers/usb/gadget/udc/dummy_hcd.c:1220
#14 0x839bf3d3 in usb_hcd_submit_urb (urb=0x8801eac10d00,
mem_flags=17301536) at drivers/usb/core/hcd.c:1664
#15 0x839c4327 in usb_submit_urb (urb=0x8801eac10d00,
mem_flags=) at drivers/usb/core/urb.c:542
#16 0x840bda26 in usbtouch_irq (ur

usb/gadget: null-ptr-deref in dev_ioctl

[Andrey Konovalov]

Hi!

It seems that gadget->ops can be NULL so it probably needs to be
checked as well as gadget->ops->ioctl in dev_ioctl() in
drivers/usb/gadget/legacy/inode.c.

kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault:  [#1] SMP KASAN
Modules linked in:
CPU: 1 PID: 5214 Comm: syz-executor Not tainted 4.13.0+ #94
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
task: 88006ac0e800 task.stack: 88006af6
! handling hub events now: start
RIP: 0010:dev_ioctl+0x117/0x280 drivers/usb/gadget/legacy/inode.c:1323
RSP: 0018:88006af67c30 EFLAGS: 00010206
RAX: dc00 RBX: 11000d5ecf86 RCX: c9ab5000
RDX: 0005 RSI: 83f1c482 RDI: 0028
RBP: 88006af67cf8 R08: ed000d5ecf80 R09: ed000d5ecf81
R10: 88006af67ed8 R11:  R12: 0414
R13:  R14: dc00 R15: 
FS:  7fd2fcbc1700() GS:88006c90() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 006e30a0 CR3: 6a3ef000 CR4: 06e0
Call Trace:
 vfs_ioctl fs/ioctl.c:45
 do_vfs_ioctl+0x1d2/0x1560 fs/ioctl.c:685
 SYSC_ioctl fs/ioctl.c:700
 SyS_ioctl+0x94/0xc0 fs/ioctl.c:691
 entry_SYSCALL_64_fastpath+0x1a/0xa5 arch/x86/entry/entry_64.S:203
RIP: 0033:0x447727
RSP: 002b:7fd2fcbc0bd8 EFLAGS: 0206 ORIG_RAX: 0010
RAX: ffda RBX: 00708000 RCX: 00447727
RDX:  RSI: 0414 RDI: 0005
RBP: 5da0 R08:  R09: 
R10:  R11: 0206 R12: 0005
R13:  R14: 004c R15: 20003000
Code: 80 96 50 fd 41 81 fc 42 42 00 00 0f 84 b3 00 00 00 e8 6e 96 50
fd 49 8d 7f 28 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80>
3c 02 00 0f 85 4e 01 00 00 4d 8b 77 28 48 b8 00 00 00 00 00
RIP: dev_ioctl+0x117/0x280 RSP: 88006af67c30
---[ end trace 2fb9696e75c067ba ]---
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: usb/gadget: stalls in dummy_timer

[Andrey Konovalov]

On Mon, Sep 11, 2017 at 3:25 PM, Alan Stern <st...@rowland.harvard.edu> wrote:
> On Mon, 11 Sep 2017, Andrey Konovalov wrote:
>
>> Hi!
>>
>> I've been getting stall reports like this one while fuzzing the USB
>> stack with gadgetfs. I'm wondering whether this is a bug in gadgetfs
>> or is this report induced by the changes I've made to the USB core
>> code. I didn't touch gadgetfs code though (except for adding a few
>> printk's).
>>
>> I'm on commit 81a84ad3cb5711cec79f4dd53a4ce026b092c432
>
> It's possible that this was caused by commit f16443a034c7 ("USB:
> gadgetfs, dummy-hcd, net2280: fix locking for callbacks").  I've been
> meaning to repair the commit but haven't done it yet.
>
> Can you test with that commit reverted?  You may end up seeing other
> problems instead -- the ones that commit was intended to solve -- but
> perhaps the stalls won't occur.

So I've reverted both: the changes I made to USB core and the commit
you mentioned, still saw the stalls.

I've manged to find a way to reproduce this and now I'm not sure the
problem is actually in gadgetfs, it might be the usbtouchscreen
driver.

The crash log is below.

Thanks!

gadgetfs: bound to dummy_udc driver
usb 1-1: new full-speed USB device number 2 using dummy_hcd
gadgetfs: connected
gadgetfs: disconnected
gadgetfs: connected
usb 1-1: config 8 interface 0 altsetting 9 endpoint 0x8F has an
invalid bInterval 0, changing to 10
usb 1-1: config 8 interface 0 altsetting 9 endpoint 0x8F has invalid
maxpacket 839, setting to 64
usb 1-1: config 8 interface 0 altsetting 9 endpoint 0x7 has invalid
maxpacket 1839, setting to 64
usb 1-1: config 8 interface 0 has no altsetting 0
usb 1-1: New USB device found, idVendor=0403, idProduct=f9e9
usb 1-1: New USB device strings: Mfr=4, Product=8, SerialNumber=255
usb 1-1: Product: a
usb 1-1: Manufacturer: a
usb 1-1: SerialNumber: a
gadgetfs: configuration #8
input: a a as /devices/platform/dummy_hcd.0/usb1/1-1/1-1:8.0/input/input8
evbug: Connected device: input8 (a a at usb-dummy_hcd.0-1/input0)
kworker/0:0: page allocation failure: order:0,
mode:0x1280020(GFP_ATOMIC|__GFP_NOTRACK), nodemask=(null)
kworker/0:0 cpuset=/ mems_allowed=0
CPU: 0 PID: 3 Comm: kworker/0:0 Not tainted 4.13.0+ #93
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: usb_hub_wq hub_event
Call Trace:
 
 __dump_stack lib/dump_stack.c:16
 dump_stack+0x192/0x22c lib/dump_stack.c:52
 warn_alloc+0x28e/0x430 mm/page_alloc.c:3242
 __alloc_pages_slowpath+0x1bbc/0x2250 mm/page_alloc.c:4043
 __alloc_pages_nodemask+0x914/0xea0 mm/page_alloc.c:4135
 alloc_pages_current+0xbb/0x1f0 mm/mempolicy.c:1974
 alloc_pages ./include/linux/gfp.h:507
 alloc_slab_page mm/slub.c:1408
 allocate_slab mm/slub.c:1559
 new_slab+0x384/0x410 mm/slub.c:1638
 new_slab_objects mm/slub.c:2423
 ___slab_alloc+0x35d/0x4c0 mm/slub.c:2575
 __slab_alloc+0x20/0x40 mm/slub.c:2615
 slab_alloc_node mm/slub.c:2678
 slab_alloc mm/slub.c:2720
 kmem_cache_alloc_trace+0x14e/0x170 mm/slub.c:2737
 kmalloc ./include/linux/slab.h:493
 dummy_urb_enqueue+0xf3/0x970 drivers/usb/gadget/udc/dummy_hcd.c:1220
 usb_hcd_submit_urb+0x2d3/0x1d50 drivers/usb/core/hcd.c:1664
 usb_submit_urb+0x937/0x11d0 drivers/usb/core/urb.c:542
 usbtouch_irq+0x216/0x2e0 drivers/input/touchscreen/usbtouchscreen.c:1441
 __usb_hcd_giveback_urb+0x2a1/0x5b0 drivers/usb/core/hcd.c:1779
 usb_hcd_giveback_urb+0x34f/0x4d0 drivers/usb/core/hcd.c:1845
 dummy_timer+0xbda/0x38c0 drivers/usb/gadget/udc/dummy_hcd.c:1924
 call_timer_fn+0xba/0x390 kernel/time/timer.c:1281
 expire_timers kernel/time/timer.c:1320
 __run_timers+0x9d0/0xda0 kernel/time/timer.c:1620
 run_timer_softirq+0x51/0xb0 kernel/time/timer.c:1646
 __do_softirq+0x258/0x7ac kernel/softirq.c:284
 invoke_softirq kernel/softirq.c:364
 irq_exit+0x14e/0x180 kernel/softirq.c:405
 exiting_irq ./arch/x86/include/asm/apic.h:638
 smp_apic_timer_interrupt+0x7b/0xa0 arch/x86/kernel/apic/apic.c:1044
 apic_timer_interrupt+0x89/0x90
RIP: 0010:arch_local_irq_restore ./arch/x86/include/asm/paravirt.h:814
RIP: 0010:console_unlock+0x814/0xcd0 kernel/printk/printk.c:2247
RSP: 0018:88006bdedd30 EFLAGS: 0a06 ORIG_RAX: ff10
RAX: 11000d7bdbe8 RBX:  RCX: 
RDX: 11000d7bdbe0 RSI: 87f007c0 RDI: 0a06
RBP: 88006bdee0a8 R08: fbfff0fe0102 R09: fbfff0fe0102
R10: 0009 R11: fbfff0fe0101 R12: 
R13:  R14: dc00 R15: 82d15610
 
 vprintk_emit+0x567/0x5d0 kernel/printk/printk.c:1769
 vprintk_default+0x2d/0x40 kernel/printk/printk.c:1808
 vprintk_func+0x5c/0xd0 kernel/printk/printk_safe.c:382
 printk+0xcd/0xfe kernel/printk/printk.c:1841
 evbug_connect+0x1de/0x260 drivers/input/evbug.c:69
 input_attach_handler+0x59a/0x740 drivers/input/input.c:1002
 input_register_device+0xcb8/0xf90 drivers/input/input.c:2159
 usbtouch_

usb/gadget: stalls in dummy_timer

[Andrey Konovalov]

Hi!

I've been getting stall reports like this one while fuzzing the USB
stack with gadgetfs. I'm wondering whether this is a bug in gadgetfs
or is this report induced by the changes I've made to the USB core
code. I didn't touch gadgetfs code though (except for adding a few
printk's).

I'm on commit 81a84ad3cb5711cec79f4dd53a4ce026b092c432

usbtouchscreen 2-1:8.0: usbtouch_irq - usb_submit_urb failed with result: -12
INFO: rcu_sched self-detected stall on CPU
INFO: rcu_sched detected stalls on CPUs/tasks:
2-...: (1 GPs behind) idle=ba2/142/0 softirq=100255/100259 fqs=2
(detected by 1, t=48363 jiffies, g=20668, c=20667, q=2875)
Sending NMI from CPU 1 to CPUs 2:
NMI backtrace for cpu 2
CPU: 2 PID: 9620 Comm: udevd Not tainted 4.13.0+ #87
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
task: 88003a414e00 task.stack: 88003aaa8000
RIP: 0010:inb arch/x86/include/asm/io.h:340 [inline]
RIP: 0010:io_serial_in+0x70/0x90 drivers/tty/serial/8250/8250_port.c:430
RSP: 0018:88006dc05638 EFLAGS: 0002
RAX: dc60 RBX: 03fd RCX: 
RDX: 03fd RSI: 0005 RDI: 88791fe8
RBP: 88006dc05648 R08: fbfff0fe0100 R09: fbfff0fe0100
R10: 0007 R11: fbfff0fe00ff R12: 88791fe0
R13: 0020 R14: fbfff10f2438 R15: fbfff10f23ff
FS:  7f88402d27a0() GS:88006dc0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 7f88402d9000 CR3: 3d4ec000 CR4: 06e0
Call Trace:
 
 serial_in drivers/tty/serial/8250/8250.h:115 [inline]
 wait_for_xmitr+0x8e/0x1d0 drivers/tty/serial/8250/8250_port.c:2015
 serial8250_console_putchar+0x24/0x60 drivers/tty/serial/8250/8250_port.c:3149
 uart_console_write+0x5c/0xf0 drivers/tty/serial/serial_core.c:1856
 serial8250_console_write+0x319/0x670 drivers/tty/serial/8250/8250_port.c:3215
 univ8250_console_write+0x6b/0x80 drivers/tty/serial/8250/8250_core.c:594
 call_console_drivers kernel/printk/printk.c:1586 [inline]
 console_unlock+0x8a1/0xcd0 kernel/printk/printk.c:2245
 vprintk_emit+0x567/0x5d0 kernel/printk/printk.c:1769
 vprintk_default+0x2d/0x40 kernel/printk/printk.c:1808
 vprintk_func+0x5c/0xd0 kernel/printk/printk_safe.c:382
 printk+0xcd/0xfe kernel/printk/printk.c:1841
 print_cpu_stall_info_begin kernel/rcu/tree_plugin.h:1643 [inline]
 print_cpu_stall+0x1a4/0x6d0 kernel/rcu/tree.c:1524
 check_cpu_stall.isra.72+0x707/0xe90 kernel/rcu/tree.c:1604
 __rcu_pending kernel/rcu/tree.c:3457 [inline]
 rcu_pending kernel/rcu/tree.c:3519 [inline]
 rcu_check_callbacks+0x241/0xa50 kernel/rcu/tree.c:2861
 update_process_times+0x35/0x70 kernel/time/timer.c:1590
 tick_sched_handle+0xf5/0x160 kernel/time/tick-sched.c:161
 tick_sched_timer+0x47/0x120 kernel/time/tick-sched.c:1190
 __run_hrtimer kernel/time/hrtimer.c:1213 [inline]
 __hrtimer_run_queues+0x3f4/0x970 kernel/time/hrtimer.c:1277
 hrtimer_interrupt+0x22a/0x720 kernel/time/hrtimer.c:1311
 local_apic_timer_interrupt+0x74/0xe0 arch/x86/kernel/apic/apic.c:1019
 smp_apic_timer_interrupt+0x76/0xa0 arch/x86/kernel/apic/apic.c:1043
 apic_timer_interrupt+0x89/0x90 arch/x86/entry/entry_64.S:482
RIP: 0010:arch_local_irq_restore arch/x86/include/asm/paravirt.h:814 [inline]
RIP: 0010:__raw_spin_unlock_irqrestore
include/linux/spinlock_api_smp.h:160 [inline]
RIP: 0010:_raw_spin_unlock_irqrestore+0xf5/0x160 kernel/locking/spinlock.c:191
RSP: 0018:88006dc06c40 EFLAGS: 0a06 ORIG_RAX: ff10
RAX: 11000db80d95 RBX: 11000db80d89 RCX: dc00
RDX: dc00 RSI: 0a06 RDI: 0a06
RBP: 88006dc06d48 R08: fbfff0fe0104 R09: fbfff0fe0104
R10: 88006dc06420 R11: fbfff0fe0103 R12: 11000db80d9d
R13: 11000db80d8d R14: 88006ac48000 R15: 88006c172b08
 spin_unlock_irqrestore include/linux/spinlock.h:354 [inline]
 dummy_timer+0x1aa8/0x38c0 drivers/usb/gadget/udc/dummy_hcd.c:1938
 call_timer_fn+0xba/0x390 kernel/time/timer.c:1281
 expire_timers kernel/time/timer.c:1320 [inline]
 __run_timers+0x9d0/0xda0 kernel/time/timer.c:1620
 run_timer_softirq+0x51/0xb0 kernel/time/timer.c:1646
 __do_softirq+0x258/0x7ac kernel/softirq.c:284
 invoke_softirq kernel/softirq.c:364 [inline]
 irq_exit+0x14e/0x180 kernel/softirq.c:405
 exiting_irq arch/x86/include/asm/apic.h:638 [inline]
 smp_apic_timer_interrupt+0x7b/0xa0 arch/x86/kernel/apic/apic.c:1044
Lost 134 message(s)!
rcu_sched kthread starved for 48353 jiffies! g20668 c20667 f0x0
RCU_GP_WAIT_FQS(3) ->state=0x1
rcu_sched   S18936 9  2 0x
Call Trace:
 context_switch kernel/sched/core.c:2771 [inline]
 __schedule+0x6fa/0x1780 kernel/sched/core.c:3332
 schedule+0x106/0x450 kernel/sched/core.c:3391
 schedule_timeout+0x1d8/0x440 kernel/time/timer.c:1743
 rcu_gp_kthread+0x1edd/0x47e0 kernel/rcu/tree.c:2242
 kthread+0x324/0x3f0 kernel/kthread.c:231
 ret_from_fork+0x25/0x30 arch/x86/entry/entry_64.S:425
2-...: (1 GPs 

Re: gadgetfs: how to wait for USB device initialization?

[Andrey Konovalov]

On Tue, Jun 13, 2017 at 6:22 PM, Tal Shorer <tal.sho...@gmail.com> wrote:
> On Tue, Jun 13, 2017 at 7:02 PM, Tal Shorer <tal.sho...@gmail.com> wrote:
>> On Tue, Jun 13, 2017 at 3:21 PM, Andrey Konovalov <andreyk...@google.com> 
>> wrote:
>>> Hi!
>>>
>>> I'm trying to use gadgetfs to fuzz USB device drivers by simply
>>> connecting random devices for now.
>>>
>>> What I want to achieve right now is the following:
>>>
>>> 1. mount gadgetfs
>>> 2. emulate connection of a new USB device
>>> 3. wait for the device to finish initializing
>>> 4. unmount gadgetfs
>>> 5. goto 1
>>>
>>> The question is how do I wait for the device to finish initializing
>>> (the corresponding USB driver to finish probing?) before unmounting
>>> gadgetfs? As I understand, when I write device description to
>>> "/dev/gadget/dummy_udc" the initialization happens asynchronously
>>> after writing is done.
>>>
>>
>> You can use inotify on the state file inside a udc's sysfs directory.
>> It's awesome like that.
>> Here's a sample code that doesn't do any cleanups because I'm lazy:
>> https://gist.github.com/talshorer/61be1bc3472cc2a7b4866b9bd5a239ca
> And I forgot usage >:
> ./wait_udc_configured /sys/devices/platform/dummy_udc.0/udc/dummy_udc.0/state

Hi Tal,

I will try this, thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: usb/gadget: potential deadlock in gadgetfs_suspend

[Andrey Konovalov]

On Tue, Jun 13, 2017 at 7:44 PM, Alan Stern <st...@rowland.harvard.edu> wrote:
> On Tue, 13 Jun 2017, Andrey Konovalov wrote:
>
>> Hi Alan,
>>
>> Thanks for the patch!
>>
>> I've been testing with your patch applied and the "bad spinlock magic"
>> crashes seem to be gone. However I got another crash (happened only
>> once over the night), which happens during "spin_lock_irqsave
>> (>lock, flags)":
>>
>> kasan: GPF could be caused by NULL-ptr deref or user memory access
>> general protection fault:  [#1] SMP KASAN
>> Dumping ftrace buffer:
>>(ftrace buffer empty)
>> Modules linked in:
>> CPU: 3 PID: 900 Comm: kworker/3:1 Not tainted 4.12.0-rc4+ #36
>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>> Workqueue: usb_hub_wq hub_event
>> task: 88006c5aadc0 task.stack: 88006c62
>> RIP: 0010:__lock_acquire+0xbe5/0x3690 kernel/locking/lockdep.c:3246
>> RSP: 0018:88006c625a80 EFLAGS: 00010006
>> RAX: dc00 RBX: 88006c5aadc0 RCX: 
>> RDX: 0003 RSI:  RDI: 11000d8c4bab
>> RBP: 88006c625fc0 R08: 0001 R09: 0001
>> R10: 88006c5ab698 R11: 87dd2e80 R12: dc00
>> R13: 0001 R14: 0018 R15: 
>> FS:  () GS:88006dd0() knlGS:
>> CS:  0010 DS:  ES:  CR0: 80050033
>> CR2: 20fd CR3: 6797e000 CR4: 06e0
>> Call Trace:
>>  lock_acquire+0x22d/0x560 kernel/locking/lockdep.c:3855
>>  __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
>>  _raw_spin_lock_irqsave+0xc9/0x110 kernel/locking/spinlock.c:159
>>  gadgetfs_disconnect+0xf1/0x230 drivers/usb/gadget/legacy/inode.c:1664
>>  usb_gadget_udc_reset+0x3b/0xb0 drivers/usb/gadget/udc/core.c:1020
>>  set_link_state+0x648/0x9f0 drivers/usb/gadget/udc/dummy_hcd.c:446
>>  dummy_hub_control+0x11bb/0x1fb0 drivers/usb/gadget/udc/dummy_hcd.c:2243
>>  rh_call_control drivers/usb/core/hcd.c:689 [inline]
>>  rh_urb_enqueue drivers/usb/core/hcd.c:846 [inline]
>>  usb_hcd_submit_urb+0x92f/0x20b0 drivers/usb/core/hcd.c:1650
>>  usb_submit_urb+0x8b2/0x12c0 drivers/usb/core/urb.c:542
>>  usb_start_wait_urb+0x148/0x5b0 drivers/usb/core/message.c:56
>>  usb_internal_control_msg drivers/usb/core/message.c:100 [inline]
>>  usb_control_msg+0x341/0x4d0 drivers/usb/core/message.c:151
>>  set_port_feature+0x73/0x90 drivers/usb/core/hub.c:422
>>  hub_port_reset+0x277/0x1550 drivers/usb/core/hub.c:2772
>>  hub_port_init+0x7dc/0x2940 drivers/usb/core/hub.c:4510
>>  hub_port_connect drivers/usb/core/hub.c:4826 [inline]
>>  hub_port_connect_change drivers/usb/core/hub.c:4999 [inline]
>>  port_event drivers/usb/core/hub.c:5105 [inline]
>>  hub_event+0x1ae1/0x3d40 drivers/usb/core/hub.c:5185
>>  process_one_work+0xc08/0x1bd0 kernel/workqueue.c:2097
>>  process_scheduled_works kernel/workqueue.c:2157 [inline]
>>  worker_thread+0xb2b/0x1860 kernel/workqueue.c:2233
>>  kthread+0x363/0x440 kernel/kthread.c:231
>>  ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:424
>> Code: e9 03 f3 48 ab 48 81 c4 18 05 00 00 44 89 e0 5b 41 5c 41 5d 41
>> 5e 41 5f 5d c3 4c 89 f2 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80>
>> 3c 02 00 0f 85 51 24 00 00 49 81 3e 40 ea 13 87 41 bd 00 00
>> RIP: __lock_acquire+0xbe5/0x3690 kernel/locking/lockdep.c:3246 RSP:
>> 88006c625a80
>> ---[ end trace f5a7b971fc1b0546 ]---
>> Kernel panic - not syncing: Fatal exception
>> Shutting down cpus with NMI
>> Dumping ftrace buffer:
>>(ftrace buffer empty)
>> Kernel Offset: disabled
>> Rebooting in 86400 seconds..
>
> I guess the structure containing the spinlock was already deallocated
> when gadgetfs_disconnect was called.  But I don't see how that could
> have happened, with the patched locking.
>
> If you can't replicate this then there's not much hope of tracking it
> down.
>
> If you can, then perhaps it would help to trace each time any function
> calls either put_dev or get_dev in inode.c.

OK, I'll let you know if I manage to reproduce this. I'll report it in
a separate thread then.

Anyway, your patch fixes the crashes I reported initially, thanks!

>
> Alan Stern
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

gadgetfs: how to wait for USB device initialization?

[Andrey Konovalov]

Hi!

I'm trying to use gadgetfs to fuzz USB device drivers by simply
connecting random devices for now.

What I want to achieve right now is the following:

1. mount gadgetfs
2. emulate connection of a new USB device
3. wait for the device to finish initializing
4. unmount gadgetfs
5. goto 1

The question is how do I wait for the device to finish initializing
(the corresponding USB driver to finish probing?) before unmounting
gadgetfs? As I understand, when I write device description to
"/dev/gadget/dummy_udc" the initialization happens asynchronously
after writing is done.

To mount and unmount gadgetfs right now I do:
mount("none", "/dev/gadget", "gadgetfs", 0, NULL)
umount2("/dev/gadget", MNT_FORCE | MNT_DETACH)

Thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: usb/gadget: potential deadlock in gadgetfs_suspend

[Andrey Konovalov]

On Mon, Jun 12, 2017 at 10:25 PM, Alan Stern  wrote:
>
> As you surmised, this was caused by a race.  The race was between
> dummy_udc_stop() and set_link_state(), both in dummy_hcd.c.  A symptom
> of this race is that the first routine clears dum->driver while the
> second dereferences it, and neither access is protected by a lock.
>
> It turns out this problem affects at least one other UDC driver
> (net2280.c).  Below is a patch that adds the missing lock (and removes
> some unneeded unlocks) from these drivers.  It turns out that the
> disconnect, reset, suspend, and resume callbacks should all be invoked
> while the UDC's lock is held, because they can race with gadget driver
> unbinding.
>
> Adding locked regions can lead to the possibility of deadlock or
> lockdep violations.  Please let me know if the patch below raises any
> problems.

Hi Alan,

Thanks for the patch!

I've been testing with your patch applied and the "bad spinlock magic"
crashes seem to be gone. However I got another crash (happened only
once over the night), which happens during "spin_lock_irqsave
(>lock, flags)":

kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault:  [#1] SMP KASAN
Dumping ftrace buffer:
   (ftrace buffer empty)
Modules linked in:
CPU: 3 PID: 900 Comm: kworker/3:1 Not tainted 4.12.0-rc4+ #36
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: usb_hub_wq hub_event
task: 88006c5aadc0 task.stack: 88006c62
RIP: 0010:__lock_acquire+0xbe5/0x3690 kernel/locking/lockdep.c:3246
RSP: 0018:88006c625a80 EFLAGS: 00010006
RAX: dc00 RBX: 88006c5aadc0 RCX: 
RDX: 0003 RSI:  RDI: 11000d8c4bab
RBP: 88006c625fc0 R08: 0001 R09: 0001
R10: 88006c5ab698 R11: 87dd2e80 R12: dc00
R13: 0001 R14: 0018 R15: 
FS:  () GS:88006dd0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 20fd CR3: 6797e000 CR4: 06e0
Call Trace:
 lock_acquire+0x22d/0x560 kernel/locking/lockdep.c:3855
 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
 _raw_spin_lock_irqsave+0xc9/0x110 kernel/locking/spinlock.c:159
 gadgetfs_disconnect+0xf1/0x230 drivers/usb/gadget/legacy/inode.c:1664
 usb_gadget_udc_reset+0x3b/0xb0 drivers/usb/gadget/udc/core.c:1020
 set_link_state+0x648/0x9f0 drivers/usb/gadget/udc/dummy_hcd.c:446
 dummy_hub_control+0x11bb/0x1fb0 drivers/usb/gadget/udc/dummy_hcd.c:2243
 rh_call_control drivers/usb/core/hcd.c:689 [inline]
 rh_urb_enqueue drivers/usb/core/hcd.c:846 [inline]
 usb_hcd_submit_urb+0x92f/0x20b0 drivers/usb/core/hcd.c:1650
 usb_submit_urb+0x8b2/0x12c0 drivers/usb/core/urb.c:542
 usb_start_wait_urb+0x148/0x5b0 drivers/usb/core/message.c:56
 usb_internal_control_msg drivers/usb/core/message.c:100 [inline]
 usb_control_msg+0x341/0x4d0 drivers/usb/core/message.c:151
 set_port_feature+0x73/0x90 drivers/usb/core/hub.c:422
 hub_port_reset+0x277/0x1550 drivers/usb/core/hub.c:2772
 hub_port_init+0x7dc/0x2940 drivers/usb/core/hub.c:4510
 hub_port_connect drivers/usb/core/hub.c:4826 [inline]
 hub_port_connect_change drivers/usb/core/hub.c:4999 [inline]
 port_event drivers/usb/core/hub.c:5105 [inline]
 hub_event+0x1ae1/0x3d40 drivers/usb/core/hub.c:5185
 process_one_work+0xc08/0x1bd0 kernel/workqueue.c:2097
 process_scheduled_works kernel/workqueue.c:2157 [inline]
 worker_thread+0xb2b/0x1860 kernel/workqueue.c:2233
 kthread+0x363/0x440 kernel/kthread.c:231
 ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:424
Code: e9 03 f3 48 ab 48 81 c4 18 05 00 00 44 89 e0 5b 41 5c 41 5d 41
5e 41 5f 5d c3 4c 89 f2 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80>
3c 02 00 0f 85 51 24 00 00 49 81 3e 40 ea 13 87 41 bd 00 00
RIP: __lock_acquire+0xbe5/0x3690 kernel/locking/lockdep.c:3246 RSP:
88006c625a80
---[ end trace f5a7b971fc1b0546 ]---
Kernel panic - not syncing: Fatal exception
Shutting down cpus with NMI
Dumping ftrace buffer:
   (ftrace buffer empty)
Kernel Offset: disabled
Rebooting in 86400 seconds..

>
> Alan Stern
>
>
>
> Index: usb-4.x/drivers/usb/gadget/legacy/inode.c
> ===
> --- usb-4.x.orig/drivers/usb/gadget/legacy/inode.c
> +++ usb-4.x/drivers/usb/gadget/legacy/inode.c
> @@ -1679,9 +1679,10 @@ static void
>  gadgetfs_suspend (struct usb_gadget *gadget)
>  {
> struct dev_data *dev = get_gadget_data (gadget);
> +   unsigned long   flags;
>
> INFO (dev, "suspended from state %d\n", dev->state);
> -   spin_lock (>lock);
> +   spin_lock_irqsave(>lock, flags);
> switch (dev->state) {
> case STATE_DEV_SETUP:   // VERY odd... host died??
> case STATE_DEV_CONNECTED:
> @@ -1692,7 +1693,7 @@ gadgetfs_suspend (struct usb_gadget *gad
>   

Re: usb/gadget: potential deadlock in gadgetfs_suspend

[Andrey Konovalov]

On Mon, Jun 12, 2017 at 6:11 PM, Andrey Konovalov <andreyk...@google.com> wrote:
> On Fri, Jun 9, 2017 at 9:14 PM, Alan Stern <st...@rowland.harvard.edu> wrote:
>> On Fri, 9 Jun 2017, Andrey Konovalov wrote:
>>
>>> On Fri, Jun 9, 2017 at 2:41 PM, Andrey Konovalov <andreyk...@google.com> 
>>> wrote:
>>> > Hi,
>>> >
>>> > I'm getting some hangs while fuzzing the kernel with syzkaller.
>>> >
>>> > Possibly it happens during the execution of the following syzkaller 
>>> > program:
>>> >
>>> > mmap(&(0x7f00/0xb9)=nil, (0xb9), 0x3, 0x32,
>>> > 0x, 0x0)
>>> > r0 = 
>>> > open$usb(&(0x7f001000)="2f6465762f6761646765742f64756d6d795f75646300",
>>> > 0xc002, 0x0)
>>> > r1 = 
>>> > open$usb(&(0x7f002000)="2f6465762f6761646765742f64756d6d795f75646300",
>>> > 0x1, 0x102)
>>> > write$usb(r1, &(0x7f003000)={0x0, {0x9, 0x2, 0x1b, 0x0, 0x5, 0x0,
>>> > 0x80, 0x8, 0x9, 0x4, 0x1000, 0xfef9, 0x1, 0xff, 0x0,
>>
>> I don't understand these large constants.  They're supposed to be __u8
>> values.  Do they get truncated to the least significant byte?
>
> This program doesn't lead to crashes, it was a bug in syzkaller. The
> format keeps changing, I'll explain it if I send another program.
>
>>
>>> > 0x8, 0x80, [{0x9, 0x5, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}]}, {0x12, 0x1,
>>> > 0x0, 0x0, 0x4b5, 0x7c, 0x0, 0x3, 0x4, 0x0, 0x8, 0xd686, 0x0, 0x1}},
>>> > 0x31)
>>> >
>>> > I haven't managed to get the exact same stack trace (or any at all
>>> > actually) while trying to reproduce the bug with this program, but the
>>> > kernel definitely hangs.
>
> It seems that I get the stall reports quite rarely and I can't
> reproduce them. However I get the "bad spinlock magic" crashes quite
> often and able to reproduce them. So I can apply debug patches.
>
> Reproducing sometimes requires quite some time (~10 minutes), so this
> seems to be some kind of race. I noticed, that often I unmount
> gadgetfs before the USB device has enough time to properly initialize,
> so this might be a race of unmount vs device initialization or
> something similar.

Aha, got KASAN report:

==
BUG: KASAN: use-after-free in __lock_acquire+0x3069/0x3690
kernel/locking/lockdep.c:3246
Read of size 8 at addr 88003a2bdaf8 by task kworker/3:1/903

CPU: 3 PID: 903 Comm: kworker/3:1 Not tainted 4.12.0-rc4+ #35
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: usb_hub_wq hub_event
Call Trace:
 __dump_stack lib/dump_stack.c:16 [inline]
 dump_stack+0x292/0x395 lib/dump_stack.c:52
 print_address_description+0x78/0x280 mm/kasan/report.c:252
 kasan_report_error mm/kasan/report.c:351 [inline]
 kasan_report+0x230/0x340 mm/kasan/report.c:408
 __asan_report_load8_noabort+0x19/0x20 mm/kasan/report.c:429
 __lock_acquire+0x3069/0x3690 kernel/locking/lockdep.c:3246
 lock_acquire+0x22d/0x560 kernel/locking/lockdep.c:3855
 __raw_spin_lock include/linux/spinlock_api_smp.h:142 [inline]
 _raw_spin_lock+0x2f/0x40 kernel/locking/spinlock.c:151
 spin_lock include/linux/spinlock.h:299 [inline]
 gadgetfs_suspend+0x89/0x130 drivers/usb/gadget/legacy/inode.c:1682
 set_link_state+0x88e/0xae0 drivers/usb/gadget/udc/dummy_hcd.c:455
 dummy_hub_control+0xd7e/0x1fb0 drivers/usb/gadget/udc/dummy_hcd.c:2074
 rh_call_control drivers/usb/core/hcd.c:689 [inline]
 rh_urb_enqueue drivers/usb/core/hcd.c:846 [inline]
 usb_hcd_submit_urb+0x92f/0x20b0 drivers/usb/core/hcd.c:1650
 usb_submit_urb+0x8b2/0x12c0 drivers/usb/core/urb.c:542
 usb_start_wait_urb+0x148/0x5b0 drivers/usb/core/message.c:56
 usb_internal_control_msg drivers/usb/core/message.c:100 [inline]
 usb_control_msg+0x341/0x4d0 drivers/usb/core/message.c:151
 usb_clear_port_feature+0x74/0xa0 drivers/usb/core/hub.c:412
 hub_port_disable+0x123/0x510 drivers/usb/core/hub.c:4177
 hub_port_init+0x1ed/0x2940 drivers/usb/core/hub.c:4648
 hub_port_connect drivers/usb/core/hub.c:4826 [inline]
 hub_port_connect_change drivers/usb/core/hub.c:4999 [inline]
 port_event drivers/usb/core/hub.c:5105 [inline]
 hub_event+0x1ae1/0x3d40 drivers/usb/core/hub.c:5185
 process_one_work+0xc08/0x1bd0 kernel/workqueue.c:2097
 process_scheduled_works kernel/workqueue.c:2157 [inline]
 worker_thread+0xb2b/0x1860 kernel/workqueue.c:2233
 kthread+0x363/0x440 kernel/kthread.c:231
 ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:424

Allocated by task 9958:
 save_stack_trace+0x1b/0x20 arch/x86/kernel/stacktrace.c:59
 save_stack+0x43/0xd0 mm/kasan/kasan.c:513
 set_track mm/kasan/kasan.c:5

Re: usb/gadget: potential deadlock in gadgetfs_suspend

[Andrey Konovalov]

On Fri, Jun 9, 2017 at 9:14 PM, Alan Stern <st...@rowland.harvard.edu> wrote:
> On Fri, 9 Jun 2017, Andrey Konovalov wrote:
>
>> On Fri, Jun 9, 2017 at 2:41 PM, Andrey Konovalov <andreyk...@google.com> 
>> wrote:
>> > Hi,
>> >
>> > I'm getting some hangs while fuzzing the kernel with syzkaller.
>> >
>> > Possibly it happens during the execution of the following syzkaller 
>> > program:
>> >
>> > mmap(&(0x7f00/0xb9)=nil, (0xb9), 0x3, 0x32,
>> > 0x, 0x0)
>> > r0 = 
>> > open$usb(&(0x7f001000)="2f6465762f6761646765742f64756d6d795f75646300",
>> > 0xc002, 0x0)
>> > r1 = 
>> > open$usb(&(0x7f002000)="2f6465762f6761646765742f64756d6d795f75646300",
>> > 0x1, 0x102)
>> > write$usb(r1, &(0x7f003000)={0x0, {0x9, 0x2, 0x1b, 0x0, 0x5, 0x0,
>> > 0x80, 0x8, 0x9, 0x4, 0x1000, 0xfef9, 0x1, 0xff, 0x0,
>
> I don't understand these large constants.  They're supposed to be __u8
> values.  Do they get truncated to the least significant byte?

This program doesn't lead to crashes, it was a bug in syzkaller. The
format keeps changing, I'll explain it if I send another program.

>
>> > 0x8, 0x80, [{0x9, 0x5, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}]}, {0x12, 0x1,
>> > 0x0, 0x0, 0x4b5, 0x7c, 0x0, 0x3, 0x4, 0x0, 0x8, 0xd686, 0x0, 0x1}},
>> > 0x31)
>> >
>> > I haven't managed to get the exact same stack trace (or any at all
>> > actually) while trying to reproduce the bug with this program, but the
>> > kernel definitely hangs.

It seems that I get the stall reports quite rarely and I can't
reproduce them. However I get the "bad spinlock magic" crashes quite
often and able to reproduce them. So I can apply debug patches.

Reproducing sometimes requires quite some time (~10 minutes), so this
seems to be some kind of race. I noticed, that often I unmount
gadgetfs before the USB device has enough time to properly initialize,
so this might be a race of unmount vs device initialization or
something similar.

>
> Can you get a usbmon trace for the test?

I wasn't able to reproduce the crash with usbmon tracing enabled.
Maybe usbmon tracing affects timings somehow and the race is quite
less likely to be triggered. I'll keep trying though.

> And can you enable debugging for the usbcore module?
>
> echo "module usbcore =p" >/sys/kernel/debug/dynamic_debug/control
>

I was able to reproduce the crash with debugging for usbcore enabled:

https://gist.github.com/xairy/52bfb302d824eb55d39776eb156812cc

>> > On commit b29794ec95c6856b316c2295904208bf11ffddd9 (4.12-rc4+) with
>> > Alan's patch applied.
>> >
>> > gadgetfs: bound to dummy_udc driver
>> > gadgetfs: suspended from state 2
>> > INFO: rcu_sched detected stalls on CPUs/tasks:
>> > 1-...: (0 ticks this GP) idle=966/140/0 softirq=37706/37706 
>> > fqs=5250
>> > (detected by 2, t=21002 jiffies, g=26575, c=26574, q=183)
>> > Sending NMI from CPU 2 to CPUs 1:
>> > NMI backtrace for cpu 1
>> > CPU: 1 PID: 1394 Comm: kworker/1:2 Not tainted 4.12.0-rc4+ #24
>> > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 
>> > 01/01/2011
>> > Workqueue: usb_hub_wq hub_event
>> > task: 88003ebfb640 task.stack: c900024fc000
>> > RIP: 0010:rep_nop arch/x86/include/asm/processor.h:619 [inline]
>> > RIP: 0010:cpu_relax arch/x86/include/asm/processor.h:624 [inline]
>> > RIP: 0010:virt_spin_lock arch/x86/include/asm/qspinlock.h:63 [inline]
>> > RIP: 0010:queued_spin_lock_slowpath+0x20/0x1a0 
>> > kernel/locking/qspinlock.c:421
>> > RSP: 0018:c900024ff9f0 EFLAGS: 0002
>> > RAX: 7d72e420 RBX: 88007d72e768 RCX: 0001
>> > RDX: 0001 RSI: 7d72e420 RDI: 88007d72e768
>> > RBP: c900024ff9f0 R08: 0006 R09: 0020
>> > R10: c900024ffa50 R11: 00d52301 R12: 88007da9c298
>> > R13:  R14:  R15: 82cfc5a0
>> > FS:  () GS:88003ed0() 
>> > knlGS:
>> > CS:  0010 DS:  ES:  CR0: 80050033
>> > CR2: 7f728a487000 CR3: 371e6000 CR4: 06e0
>> > Call Trace:
>> >  __raw_spin_lock include/asm-generic/qspinlock.h:103 [inline]
>> >  _raw_spin_lock+0x1c/0x20 kernel/locking/spinlock.c:151
>> >  spin_lock include/linux/spinlock.h:299 [inline]
>> >  gadgetfs_suspend+

Re: usb/gadget: potential deadlock in gadgetfs_suspend

[Andrey Konovalov]

On Fri, Jun 9, 2017 at 2:41 PM, Andrey Konovalov <andreyk...@google.com> wrote:
> Hi,
>
> I'm getting some hangs while fuzzing the kernel with syzkaller.
>
> Possibly it happens during the execution of the following syzkaller program:
>
> mmap(&(0x7f00/0xb9)=nil, (0xb9), 0x3, 0x32,
> 0x, 0x0)
> r0 = 
> open$usb(&(0x7f001000)="2f6465762f6761646765742f64756d6d795f75646300",
> 0xc002, 0x0)
> r1 = 
> open$usb(&(0x7f002000)="2f6465762f6761646765742f64756d6d795f75646300",
> 0x1, 0x102)
> write$usb(r1, &(0x7f003000)={0x0, {0x9, 0x2, 0x1b, 0x0, 0x5, 0x0,
> 0x80, 0x8, 0x9, 0x4, 0x1000, 0xfef9, 0x1, 0xff, 0x0,
> 0x8, 0x80, [{0x9, 0x5, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}]}, {0x12, 0x1,
> 0x0, 0x0, 0x4b5, 0x7c, 0x0, 0x3, 0x4, 0x0, 0x8, 0xd686, 0x0, 0x1}},
> 0x31)
>
> I haven't managed to get the exact same stack trace (or any at all
> actually) while trying to reproduce the bug with this program, but the
> kernel definitely hangs.
>
> On commit b29794ec95c6856b316c2295904208bf11ffddd9 (4.12-rc4+) with
> Alan's patch applied.
>
> gadgetfs: bound to dummy_udc driver
> gadgetfs: suspended from state 2
> INFO: rcu_sched detected stalls on CPUs/tasks:
> 1-...: (0 ticks this GP) idle=966/140/0 softirq=37706/37706 
> fqs=5250
> (detected by 2, t=21002 jiffies, g=26575, c=26574, q=183)
> Sending NMI from CPU 2 to CPUs 1:
> NMI backtrace for cpu 1
> CPU: 1 PID: 1394 Comm: kworker/1:2 Not tainted 4.12.0-rc4+ #24
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> Workqueue: usb_hub_wq hub_event
> task: 88003ebfb640 task.stack: c900024fc000
> RIP: 0010:rep_nop arch/x86/include/asm/processor.h:619 [inline]
> RIP: 0010:cpu_relax arch/x86/include/asm/processor.h:624 [inline]
> RIP: 0010:virt_spin_lock arch/x86/include/asm/qspinlock.h:63 [inline]
> RIP: 0010:queued_spin_lock_slowpath+0x20/0x1a0 kernel/locking/qspinlock.c:421
> RSP: 0018:c900024ff9f0 EFLAGS: 0002
> RAX: 7d72e420 RBX: 88007d72e768 RCX: 0001
> RDX: 0001 RSI: 7d72e420 RDI: 88007d72e768
> RBP: c900024ff9f0 R08: 0006 R09: 0020
> R10: c900024ffa50 R11: 00d52301 R12: 88007da9c298
> R13:  R14:  R15: 82cfc5a0
> FS:  () GS:88003ed0() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 7f728a487000 CR3: 371e6000 CR4: 06e0
> Call Trace:
>  __raw_spin_lock include/asm-generic/qspinlock.h:103 [inline]
>  _raw_spin_lock+0x1c/0x20 kernel/locking/spinlock.c:151
>  spin_lock include/linux/spinlock.h:299 [inline]
>  gadgetfs_suspend+0x32/0x90 drivers/usb/gadget/legacy/inode.c:1684
>  set_link_state+0x39c/0x440 drivers/usb/gadget/udc/dummy_hcd.c:455
>  dummy_hub_control+0x3e7/0x650 drivers/usb/gadget/udc/dummy_hcd.c:2074
>  rh_call_control drivers/usb/core/hcd.c:689 [inline]
>  rh_urb_enqueue drivers/usb/core/hcd.c:846 [inline]
>  usb_hcd_submit_urb+0x327/0xcf0 drivers/usb/core/hcd.c:1650
>  usb_submit_urb+0x355/0x6f0 drivers/usb/core/urb.c:542
>  usb_start_wait_urb+0x5f/0x110 drivers/usb/core/message.c:56
>  usb_internal_control_msg drivers/usb/core/message.c:100 [inline]
>  usb_control_msg+0xd9/0x120 drivers/usb/core/message.c:151
>  usb_clear_port_feature+0x46/0x60 drivers/usb/core/hub.c:412
>  hub_port_disable+0x65/0x1d0 drivers/usb/core/hub.c:4177
>  hub_port_init+0x10a/0xee0 drivers/usb/core/hub.c:4648
>  hub_port_connect drivers/usb/core/hub.c:4826 [inline]
>  hub_port_connect_change drivers/usb/core/hub.c:4999 [inline]
>  port_event drivers/usb/core/hub.c:5105 [inline]
>  hub_event+0xa0b/0x16e0 drivers/usb/core/hub.c:5189
>  process_one_work+0x1fb/0x4c0 kernel/workqueue.c:2097
>  process_scheduled_works kernel/workqueue.c:2157 [inline]
>  worker_thread+0x2ab/0x4c0 kernel/workqueue.c:2233
>  kthread+0x140/0x160 kernel/kthread.c:231
>  ret_from_fork+0x25/0x30 arch/x86/entry/entry_64.S:424
> Code: 66 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 e5 0f 1f 44 00 00 ba
> 01 00 00 00 8b 07 85 c0 75 0a f0 0f b1 17 85 c0 75 f2 5d c3 f3 90 
> ec 81 fe 00 01 00 00 0f 84 92 00 00 00 41 b8 01 01 00 00 b9

Here are a few similar reports:

gadgetfs: bound to dummy_udc driver
gadgetfs: suspended from state 2
BUG: spinlock bad magic on CPU#3, kworker/3:1/222
 lock: 0x88003cdb9a70, .magic: dead4ead, .owner: /-1, .owner_cpu: -1
CPU: 3 PID: 222 Comm: kworker/3:1 Not tainted 4.12.0-rc4+ #28
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: usb_hub_wq hub_event
Call Trace:
 __dump_stack lib/dump_stack.c:16 [inline]
 dump_stack+0x8e/0xcd lib/dump_stack.c:52
 spin_

Re: usb/gadget: potential deadlock in gadgetfs_suspend

[Andrey Konovalov]

On Fri, Jun 9, 2017 at 2:41 PM, Andrey Konovalov <andreyk...@google.com> wrote:
> Hi,
>
> I'm getting some hangs while fuzzing the kernel with syzkaller.
>
> Possibly it happens during the execution of the following syzkaller program:
>
> mmap(&(0x7f00/0xb9)=nil, (0xb9), 0x3, 0x32,
> 0x, 0x0)
> r0 = 
> open$usb(&(0x7f001000)="2f6465762f6761646765742f64756d6d795f75646300",
> 0xc002, 0x0)
> r1 = 
> open$usb(&(0x7f002000)="2f6465762f6761646765742f64756d6d795f75646300",
> 0x1, 0x102)
> write$usb(r1, &(0x7f003000)={0x0, {0x9, 0x2, 0x1b, 0x0, 0x5, 0x0,
> 0x80, 0x8, 0x9, 0x4, 0x1000, 0xfef9, 0x1, 0xff, 0x0,
> 0x8, 0x80, [{0x9, 0x5, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}]}, {0x12, 0x1,
> 0x0, 0x0, 0x4b5, 0x7c, 0x0, 0x3, 0x4, 0x0, 0x8, 0xd686, 0x0, 0x1}},
> 0x31)
>
> I haven't managed to get the exact same stack trace (or any at all
> actually) while trying to reproduce the bug with this program, but the
> kernel definitely hangs.

Never mind, this program is unrelated to the hang.

>
> On commit b29794ec95c6856b316c2295904208bf11ffddd9 (4.12-rc4+) with
> Alan's patch applied.
>
> gadgetfs: bound to dummy_udc driver
> gadgetfs: suspended from state 2
> INFO: rcu_sched detected stalls on CPUs/tasks:
> 1-...: (0 ticks this GP) idle=966/140/0 softirq=37706/37706 
> fqs=5250
> (detected by 2, t=21002 jiffies, g=26575, c=26574, q=183)
> Sending NMI from CPU 2 to CPUs 1:
> NMI backtrace for cpu 1
> CPU: 1 PID: 1394 Comm: kworker/1:2 Not tainted 4.12.0-rc4+ #24
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> Workqueue: usb_hub_wq hub_event
> task: 88003ebfb640 task.stack: c900024fc000
> RIP: 0010:rep_nop arch/x86/include/asm/processor.h:619 [inline]
> RIP: 0010:cpu_relax arch/x86/include/asm/processor.h:624 [inline]
> RIP: 0010:virt_spin_lock arch/x86/include/asm/qspinlock.h:63 [inline]
> RIP: 0010:queued_spin_lock_slowpath+0x20/0x1a0 kernel/locking/qspinlock.c:421
> RSP: 0018:c900024ff9f0 EFLAGS: 0002
> RAX: 7d72e420 RBX: 88007d72e768 RCX: 0001
> RDX: 0001 RSI: 7d72e420 RDI: 88007d72e768
> RBP: c900024ff9f0 R08: 0006 R09: 0020
> R10: c900024ffa50 R11: 00d52301 R12: 88007da9c298
> R13:  R14:  R15: 82cfc5a0
> FS:  () GS:88003ed0() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 7f728a487000 CR3: 371e6000 CR4: 06e0
> Call Trace:
>  __raw_spin_lock include/asm-generic/qspinlock.h:103 [inline]
>  _raw_spin_lock+0x1c/0x20 kernel/locking/spinlock.c:151
>  spin_lock include/linux/spinlock.h:299 [inline]
>  gadgetfs_suspend+0x32/0x90 drivers/usb/gadget/legacy/inode.c:1684
>  set_link_state+0x39c/0x440 drivers/usb/gadget/udc/dummy_hcd.c:455
>  dummy_hub_control+0x3e7/0x650 drivers/usb/gadget/udc/dummy_hcd.c:2074
>  rh_call_control drivers/usb/core/hcd.c:689 [inline]
>  rh_urb_enqueue drivers/usb/core/hcd.c:846 [inline]
>  usb_hcd_submit_urb+0x327/0xcf0 drivers/usb/core/hcd.c:1650
>  usb_submit_urb+0x355/0x6f0 drivers/usb/core/urb.c:542
>  usb_start_wait_urb+0x5f/0x110 drivers/usb/core/message.c:56
>  usb_internal_control_msg drivers/usb/core/message.c:100 [inline]
>  usb_control_msg+0xd9/0x120 drivers/usb/core/message.c:151
>  usb_clear_port_feature+0x46/0x60 drivers/usb/core/hub.c:412
>  hub_port_disable+0x65/0x1d0 drivers/usb/core/hub.c:4177
>  hub_port_init+0x10a/0xee0 drivers/usb/core/hub.c:4648
>  hub_port_connect drivers/usb/core/hub.c:4826 [inline]
>  hub_port_connect_change drivers/usb/core/hub.c:4999 [inline]
>  port_event drivers/usb/core/hub.c:5105 [inline]
>  hub_event+0xa0b/0x16e0 drivers/usb/core/hub.c:5189
>  process_one_work+0x1fb/0x4c0 kernel/workqueue.c:2097
>  process_scheduled_works kernel/workqueue.c:2157 [inline]
>  worker_thread+0x2ab/0x4c0 kernel/workqueue.c:2233
>  kthread+0x140/0x160 kernel/kthread.c:231
>  ret_from_fork+0x25/0x30 arch/x86/entry/entry_64.S:424
> Code: 66 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 e5 0f 1f 44 00 00 ba
> 01 00 00 00 8b 07 85 c0 75 0a f0 0f b1 17 85 c0 75 f2 5d c3 f3 90 
> ec 81 fe 00 01 00 00 0f 84 92 00 00 00 41 b8 01 01 00 00 b9
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

usb/gadget: potential deadlock in gadgetfs_suspend

[Andrey Konovalov]

Hi,

I'm getting some hangs while fuzzing the kernel with syzkaller.

Possibly it happens during the execution of the following syzkaller program:

mmap(&(0x7f00/0xb9)=nil, (0xb9), 0x3, 0x32,
0x, 0x0)
r0 = open$usb(&(0x7f001000)="2f6465762f6761646765742f64756d6d795f75646300",
0xc002, 0x0)
r1 = open$usb(&(0x7f002000)="2f6465762f6761646765742f64756d6d795f75646300",
0x1, 0x102)
write$usb(r1, &(0x7f003000)={0x0, {0x9, 0x2, 0x1b, 0x0, 0x5, 0x0,
0x80, 0x8, 0x9, 0x4, 0x1000, 0xfef9, 0x1, 0xff, 0x0,
0x8, 0x80, [{0x9, 0x5, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}]}, {0x12, 0x1,
0x0, 0x0, 0x4b5, 0x7c, 0x0, 0x3, 0x4, 0x0, 0x8, 0xd686, 0x0, 0x1}},
0x31)

I haven't managed to get the exact same stack trace (or any at all
actually) while trying to reproduce the bug with this program, but the
kernel definitely hangs.

On commit b29794ec95c6856b316c2295904208bf11ffddd9 (4.12-rc4+) with
Alan's patch applied.

gadgetfs: bound to dummy_udc driver
gadgetfs: suspended from state 2
INFO: rcu_sched detected stalls on CPUs/tasks:
1-...: (0 ticks this GP) idle=966/140/0 softirq=37706/37706 fqs=5250
(detected by 2, t=21002 jiffies, g=26575, c=26574, q=183)
Sending NMI from CPU 2 to CPUs 1:
NMI backtrace for cpu 1
CPU: 1 PID: 1394 Comm: kworker/1:2 Not tainted 4.12.0-rc4+ #24
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: usb_hub_wq hub_event
task: 88003ebfb640 task.stack: c900024fc000
RIP: 0010:rep_nop arch/x86/include/asm/processor.h:619 [inline]
RIP: 0010:cpu_relax arch/x86/include/asm/processor.h:624 [inline]
RIP: 0010:virt_spin_lock arch/x86/include/asm/qspinlock.h:63 [inline]
RIP: 0010:queued_spin_lock_slowpath+0x20/0x1a0 kernel/locking/qspinlock.c:421
RSP: 0018:c900024ff9f0 EFLAGS: 0002
RAX: 7d72e420 RBX: 88007d72e768 RCX: 0001
RDX: 0001 RSI: 7d72e420 RDI: 88007d72e768
RBP: c900024ff9f0 R08: 0006 R09: 0020
R10: c900024ffa50 R11: 00d52301 R12: 88007da9c298
R13:  R14:  R15: 82cfc5a0
FS:  () GS:88003ed0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 7f728a487000 CR3: 371e6000 CR4: 06e0
Call Trace:
 __raw_spin_lock include/asm-generic/qspinlock.h:103 [inline]
 _raw_spin_lock+0x1c/0x20 kernel/locking/spinlock.c:151
 spin_lock include/linux/spinlock.h:299 [inline]
 gadgetfs_suspend+0x32/0x90 drivers/usb/gadget/legacy/inode.c:1684
 set_link_state+0x39c/0x440 drivers/usb/gadget/udc/dummy_hcd.c:455
 dummy_hub_control+0x3e7/0x650 drivers/usb/gadget/udc/dummy_hcd.c:2074
 rh_call_control drivers/usb/core/hcd.c:689 [inline]
 rh_urb_enqueue drivers/usb/core/hcd.c:846 [inline]
 usb_hcd_submit_urb+0x327/0xcf0 drivers/usb/core/hcd.c:1650
 usb_submit_urb+0x355/0x6f0 drivers/usb/core/urb.c:542
 usb_start_wait_urb+0x5f/0x110 drivers/usb/core/message.c:56
 usb_internal_control_msg drivers/usb/core/message.c:100 [inline]
 usb_control_msg+0xd9/0x120 drivers/usb/core/message.c:151
 usb_clear_port_feature+0x46/0x60 drivers/usb/core/hub.c:412
 hub_port_disable+0x65/0x1d0 drivers/usb/core/hub.c:4177
 hub_port_init+0x10a/0xee0 drivers/usb/core/hub.c:4648
 hub_port_connect drivers/usb/core/hub.c:4826 [inline]
 hub_port_connect_change drivers/usb/core/hub.c:4999 [inline]
 port_event drivers/usb/core/hub.c:5105 [inline]
 hub_event+0xa0b/0x16e0 drivers/usb/core/hub.c:5189
 process_one_work+0x1fb/0x4c0 kernel/workqueue.c:2097
 process_scheduled_works kernel/workqueue.c:2157 [inline]
 worker_thread+0x2ab/0x4c0 kernel/workqueue.c:2233
 kthread+0x140/0x160 kernel/kthread.c:231
 ret_from_fork+0x25/0x30 arch/x86/entry/entry_64.S:424
Code: 66 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 e5 0f 1f 44 00 00 ba
01 00 00 00 8b 07 85 c0 75 0a f0 0f b1 17 85 c0 75 f2 5d c3 f3 90 
ec 81 fe 00 01 00 00 0f 84 92 00 00 00 41 b8 01 01 00 00 b9
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: usb/gadget: another GPF in usb_gadget_unregister_driver

[Andrey Konovalov]

On Thu, Jun 8, 2017 at 5:55 PM, Alan Stern <st...@rowland.harvard.edu> wrote:
> On Thu, 8 Jun 2017, Andrey Konovalov wrote:
>
>> On Wed, Jun 7, 2017 at 11:20 PM, Alan Stern <st...@rowland.harvard.edu> 
>> wrote:
>> > On Wed, 7 Jun 2017, Andrey Konovalov wrote:
>> >
>> >> On Wed, Jun 7, 2017 at 4:43 PM, Alan Stern <st...@rowland.harvard.edu> 
>> >> wrote:
>> >> > On Wed, 7 Jun 2017, Andrey Konovalov wrote:
>> >> >
>> >> >> Hi,
>> >> >>
>> >> >> I've got the following error report while fuzzing the kernel with 
>> >> >> syzkaller.
>> >> >>
>> >> >> On commit b29794ec95c6856b316c2295904208bf11ffddd9 (4.12-rc4+).
>> >> >>
>> >> >> This looks quite similar to
>> >> >> https://groups.google.com/forum/#!topic/syzkaller/HDawLBeeORI
>> >> >
>> >> > It does look very similar, but that problem was supposed to have been
>> >> > fixed by commit 7b0173811260 ("usb: gadget: udc: core: fix return code
>> >> > of usb_gadget_probe_driver()").
>> >> >
>> >> >> I'm able to reproduce this, so I can collect some debug traces if 
>> >> >> needed.
>> >> >
>> >> > Can you provide an strace or the equivalent?
>> >>
>> >> Here's the syzkaller program (which is actually two programs executed
>> >> consequently):
>> >> https://gist.github.com/xairy/fe0a7531e00df5e8bc23e2e56e413510
>> >>
>> >> Here's the strace log:
>> >> https://gist.github.com/xairy/5fadc3b5d8b2b80c97e566538de08bc4
>> >
>> > Do you know which of the two programs got the GPF?  I can't tell from
>> > the strace log.
>> >
>> >> Unfortunately there's a lot of unrelated garbage, but I can't extract
>> >> a simple C reproducer.
>> >
>> > That's okay, it's easy enough to see what's going on.  One program
>> > opens /dev/gadget/dummy_udc, writes an invalid setup string, then
>> > writes a valid setup string, and then exits.  The other program just
>> > opens the file and then exits.
>> >
>> >> I can also apply patches with debug printk's, run the reproducer and
>> >> send you the result if that will help.
>>
>> I've extract another crash log, which is a little simpler:
>> https://gist.github.com/xairy/b8c814cbd731e4632e8e8fa0f51a29e8
>>
>> >
>> > Maybe you can patch usb_gadget_probe_driver() in
>> > drivers/usb/gadget/udc/core.c.  Find out whether the "if
>> > (!driver->match_existing_only)" test is executed and whether it
>> > succeeds, and find out whether the code following "found:" is executed.
>> > I would expect that the test is not executed and the jump to "found:"
>> > is taken, so udc_bind_to_driver() is called and returns 0.  Thus,
>> > udc->driver should be set to driver.
>>
>> Here's the funcgraph for usb_gadget_probe_driver:
>> https://gist.github.com/xairy/3221e2cb9c59514880d24c955de30b80
>>
>> The (!driver->match_existing_only) test is not executed.
>> The code following "found:" is executed.
>>
>> >
>> > Also, in usb_gadget_unregister_driver(), in the list_for_each_entry()
>> > loop, we should have udc->driver == driver and therefore ret should get
>> > set to 0.  Consequently, the list_del() near the end should not be
>> > executed and so the GPF should not occur.
>>
>> Here's the funcgraph for usb_gadget_unregister_driver:
>> https://gist.github.com/xairy/887c52a12af8c9f9fe8ba3e4fa0ef1f0
>>
>> What you described happens during the first call of
>> usb_gadget_unregister_driver(), however there's another one after
>> that, which is probably triggered by the second program.
>>
>> >
>> > In particular, do these subroutines get called more than once?
>>
>> usb_gadget_unregister_driver() is called twice, the GPF happens during
>> the second call.
>
> Good, that's definitive.  And I feel stupid for missing this bug.
> The patch is below.

Perfect, this fixes the issue, thanks!

>
> Alan Stern
>
>
>
> Index: usb-4.x/drivers/usb/gadget/legacy/inode.c
> ===
> --- usb-4.x.orig/drivers/usb/gadget/legacy/inode.c
> +++ usb-4.x/drivers/usb/gadget/legacy/inode.c
> @@ -1183,8 +1183,10 @@ dev_release (struct inode *inode, struct
>
> /* closing ep0 === shutdown all */
>
> -   if (dev->gadget_registered)
> +   if (dev->gadget_registered) {
> usb_gadget_unregister_driver (_driver);
> +   dev->gadget_registered = false;
> +   }
>
> /* at this point "good" hardware has disconnected the
>  * device from USB; the host won't see it any more.
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: usb/gadget: another GPF in usb_gadget_unregister_driver

[Andrey Konovalov]

On Wed, Jun 7, 2017 at 11:20 PM, Alan Stern <st...@rowland.harvard.edu> wrote:
> On Wed, 7 Jun 2017, Andrey Konovalov wrote:
>
>> On Wed, Jun 7, 2017 at 4:43 PM, Alan Stern <st...@rowland.harvard.edu> wrote:
>> > On Wed, 7 Jun 2017, Andrey Konovalov wrote:
>> >
>> >> Hi,
>> >>
>> >> I've got the following error report while fuzzing the kernel with 
>> >> syzkaller.
>> >>
>> >> On commit b29794ec95c6856b316c2295904208bf11ffddd9 (4.12-rc4+).
>> >>
>> >> This looks quite similar to
>> >> https://groups.google.com/forum/#!topic/syzkaller/HDawLBeeORI
>> >
>> > It does look very similar, but that problem was supposed to have been
>> > fixed by commit 7b0173811260 ("usb: gadget: udc: core: fix return code
>> > of usb_gadget_probe_driver()").
>> >
>> >> I'm able to reproduce this, so I can collect some debug traces if needed.
>> >
>> > Can you provide an strace or the equivalent?
>>
>> Here's the syzkaller program (which is actually two programs executed
>> consequently):
>> https://gist.github.com/xairy/fe0a7531e00df5e8bc23e2e56e413510
>>
>> Here's the strace log:
>> https://gist.github.com/xairy/5fadc3b5d8b2b80c97e566538de08bc4
>
> Do you know which of the two programs got the GPF?  I can't tell from
> the strace log.
>
>> Unfortunately there's a lot of unrelated garbage, but I can't extract
>> a simple C reproducer.
>
> That's okay, it's easy enough to see what's going on.  One program
> opens /dev/gadget/dummy_udc, writes an invalid setup string, then
> writes a valid setup string, and then exits.  The other program just
> opens the file and then exits.
>
>> I can also apply patches with debug printk's, run the reproducer and
>> send you the result if that will help.

I've extract another crash log, which is a little simpler:
https://gist.github.com/xairy/b8c814cbd731e4632e8e8fa0f51a29e8

>
> Maybe you can patch usb_gadget_probe_driver() in
> drivers/usb/gadget/udc/core.c.  Find out whether the "if
> (!driver->match_existing_only)" test is executed and whether it
> succeeds, and find out whether the code following "found:" is executed.
> I would expect that the test is not executed and the jump to "found:"
> is taken, so udc_bind_to_driver() is called and returns 0.  Thus,
> udc->driver should be set to driver.

Here's the funcgraph for usb_gadget_probe_driver:
https://gist.github.com/xairy/3221e2cb9c59514880d24c955de30b80

The (!driver->match_existing_only) test is not executed.
The code following "found:" is executed.

>
> Also, in usb_gadget_unregister_driver(), in the list_for_each_entry()
> loop, we should have udc->driver == driver and therefore ret should get
> set to 0.  Consequently, the list_del() near the end should not be
> executed and so the GPF should not occur.

Here's the funcgraph for usb_gadget_unregister_driver:
https://gist.github.com/xairy/887c52a12af8c9f9fe8ba3e4fa0ef1f0

What you described happens during the first call of
usb_gadget_unregister_driver(), however there's another one after
that, which is probably triggered by the second program.

>
> In particular, do these subroutines get called more than once?

usb_gadget_unregister_driver() is called twice, the GPF happens during
the second call.

>
> Alan Stern
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: usb/gadget: another GPF in usb_gadget_unregister_driver

[Andrey Konovalov]

On Wed, Jun 7, 2017 at 4:43 PM, Alan Stern <st...@rowland.harvard.edu> wrote:
> On Wed, 7 Jun 2017, Andrey Konovalov wrote:
>
>> Hi,
>>
>> I've got the following error report while fuzzing the kernel with syzkaller.
>>
>> On commit b29794ec95c6856b316c2295904208bf11ffddd9 (4.12-rc4+).
>>
>> This looks quite similar to
>> https://groups.google.com/forum/#!topic/syzkaller/HDawLBeeORI
>
> It does look very similar, but that problem was supposed to have been
> fixed by commit 7b0173811260 ("usb: gadget: udc: core: fix return code
> of usb_gadget_probe_driver()").
>
>> I'm able to reproduce this, so I can collect some debug traces if needed.
>
> Can you provide an strace or the equivalent?

Here's the syzkaller program (which is actually two programs executed
consequently):
https://gist.github.com/xairy/fe0a7531e00df5e8bc23e2e56e413510

Here's the strace log:
https://gist.github.com/xairy/5fadc3b5d8b2b80c97e566538de08bc4

Unfortunately there's a lot of unrelated garbage, but I can't extract
a simple C reproducer.

I can also apply patches with debug printk's, run the reproducer and
send you the result if that will help.

>
> Alan Stern
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

usb/gadget: another GPF in usb_gadget_unregister_driver

[Andrey Konovalov]

Hi,

I've got the following error report while fuzzing the kernel with syzkaller.

On commit b29794ec95c6856b316c2295904208bf11ffddd9 (4.12-rc4+).

This looks quite similar to
https://groups.google.com/forum/#!topic/syzkaller/HDawLBeeORI

I'm able to reproduce this, so I can collect some debug traces if needed.

kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault:  [#1] SMP KASAN
Dumping ftrace buffer:
   (ftrace buffer empty)
Modules linked in:
CPU: 2 PID: 4820 Comm: syz-executor0 Not tainted 4.12.0-rc4+ #5
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
task: 880039542dc0 task.stack: 88003bdd
RIP: 0010:__list_del_entry_valid+0x7e/0x170 lib/list_debug.c:51
RSP: 0018:88003bdd6e50 EFLAGS: 00010246
RAX: dc00 RBX:  RCX: 0001
RDX:  RSI: 86504948 RDI: 86504950
RBP: 88003bdd6e68 R08: 880039542dc0 R09: 8778ce00
R10: 88003bdd6e68 R11: dc00 R12: 
R13: dc00 R14: 1100077badd2 R15: 864d2e40
FS:  () GS:88006dc0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 2014aff9 CR3: 06022000 CR4: 06e0
Call Trace:
 __list_del_entry include/linux/list.h:116 [inline]
 list_del include/linux/list.h:124 [inline]
 usb_gadget_unregister_driver+0x166/0x4c0 drivers/usb/gadget/udc/core.c:1387
 dev_release+0x80/0x160 drivers/usb/gadget/legacy/inode.c:1187
 __fput+0x332/0x7f0 fs/file_table.c:209
 fput+0x15/0x20 fs/file_table.c:245
 task_work_run+0x19b/0x270 kernel/task_work.c:116
 exit_task_work include/linux/task_work.h:21 [inline]
 do_exit+0x18a3/0x2820 kernel/exit.c:878
 do_group_exit+0x149/0x420 kernel/exit.c:982
 get_signal+0x77f/0x1780 kernel/signal.c:2318
 do_signal+0xd2/0x2130 arch/x86/kernel/signal.c:808
 exit_to_usermode_loop+0x1a7/0x240 arch/x86/entry/common.c:157
 prepare_exit_to_usermode arch/x86/entry/common.c:194 [inline]
 syscall_return_slowpath+0x3ba/0x410 arch/x86/entry/common.c:263
 entry_SYSCALL_64_fastpath+0xbc/0xbe
RIP: 0033:0x4461f9
RSP: 002b:7fdac2b1ecf8 EFLAGS: 0246 ORIG_RAX: 00ca
RAX: fe00 RBX: 007080c8 RCX: 004461f9
RDX:  RSI:  RDI: 007080c8
RBP: 007080a8 R08:  R09: 
R10:  R11: 0246 R12: 
R13:  R14: 7fdac2b1f9c0 R15: 7fdac2b1f700
Code: 00 00 00 00 ad de 49 39 c4 74 6a 48 b8 00 02 00 00 00 00 ad de
48 89 da 48 39 c3 74 74 48 c1 ea 03 48 b8 00 00 00 00 00 fc ff df <80>
3c 02 00 0f 85 92 00 00 00 48 8b 13 48 39 f2 75 66 49 8d 7c
RIP: __list_del_entry_valid+0x7e/0x170 lib/list_debug.c:51 RSP: 88003bdd6e50
---[ end trace 30e94b1eec4831c8 ]---
Kernel panic - not syncing: Fatal exception
Dumping ftrace buffer:
   (ftrace buffer empty)
Kernel Offset: disabled
Rebooting in 86400 seconds..
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: usb/gadget: warning in dummy_free_request

[Andrey Konovalov]

On Tue, Dec 27, 2016 at 12:40 PM, Felipe Balbi <ba...@kernel.org> wrote:
>
> Hi,
>
> Andrey Konovalov <andreyk...@google.com> writes:
>> Hi!
>>
>> I've got the following error report while running the syzkaller fuzzer.
>>
>> On commit 3c49de52d5647cda8b42c4255cf8a29d1e22eff5 (Dec 2).
>>
>> WARNING: CPU: 0 PID: 5257 at drivers/usb/gadget/udc/dummy_hcd.c:672
>> dummy_free_request+0x153/0x170
>> Kernel panic - not syncing: panic_on_warn set ...
>>
>> usb 2-1: string descriptor 0 read error: -71
>> usb 2-1: New USB device found, idVendor=, idProduct=
>> usb 2-1: New USB device strings: Mfr=0, Product=170, SerialNumber=0
>> CPU: 0 PID: 5257 Comm: syz-executor0 Not tainted 4.9.0-rc7+ #16
>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>>  88006af0ec48 81f96aba 0200 11000d5e1d1c
>>  ed000d5e1d14 0a06 41b58ab3 8598b4c8
>>  81f96828 41b58ab3 85942a10 81432790
>> Call Trace:
>>  [< inline >] __dump_stack lib/dump_stack.c:15
>>  [] dump_stack+0x292/0x398 lib/dump_stack.c:51
>>  [] panic+0x1cb/0x3a9 kernel/panic.c:179
>>  [] __warn+0x1c4/0x1e0 kernel/panic.c:542
>>  [] warn_slowpath_null+0x2c/0x40 kernel/panic.c:585
>>  [] dummy_free_request+0x153/0x170
>> drivers/usb/gadget/udc/dummy_hcd.c:672
>>  [] usb_ep_free_request+0xc0/0x420
>> drivers/usb/gadget/udc/core.c:195
>>  [] gadgetfs_unbind+0x131/0x190
>> drivers/usb/gadget/legacy/inode.c:1612
>>  [] usb_gadget_remove_driver+0x10f/0x2b0
>> drivers/usb/gadget/udc/core.c:1228
>>  [] usb_gadget_unregister_driver+0x1b6/0x2c0
>> drivers/usb/gadget/udc/core.c:1357
>>  [] dev_release+0x80/0x160
>> drivers/usb/gadget/legacy/inode.c:1187
>>  [] __fput+0x332/0x7f0 fs/file_table.c:208
>>  [] fput+0x15/0x20 fs/file_table.c:244
>>  [] task_work_run+0x19b/0x270 kernel/task_work.c:116
>>  [< inline >] exit_task_work include/linux/task_work.h:21
>>  [] do_exit+0x16aa/0x2530 kernel/exit.c:828
>>  [] do_group_exit+0x149/0x420 kernel/exit.c:932
>>  [] get_signal+0x76d/0x17b0 kernel/signal.c:2307
>>  [] do_signal+0xd2/0x2120 arch/x86/kernel/signal.c:807
>>  [] exit_to_usermode_loop+0x170/0x200
>> arch/x86/entry/common.c:156
>>  [< inline >] prepare_exit_to_usermode arch/x86/entry/common.c:190
>>  [] syscall_return_slowpath+0x3d3/0x420
>> arch/x86/entry/common.c:259
>>  [] entry_SYSCALL_64_fastpath+0xc0/0xc2
>> Dumping ftrace buffer:
>>(ftrace buffer empty)
>> Kernel Offset: disabled
>
> There have been several emails like this one. Can you check if
> my branch testing/fixes is working for you?

Hi Felipe,

This was fixed by Alan with the "USB: dummy-hcd: fix bug in
stop_activity (handle ep0)" patch.

Thanks!

>
> --
> balbi
>
> --
> You received this message because you are subscribed to the Google Groups 
> "syzkaller" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to syzkaller+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: usb/core: warning in usb_create_ep_devs/sysfs_create_dir_ns

[Andrey Konovalov]

On Fri, Dec 16, 2016 at 7:01 PM, Alan Stern <st...@rowland.harvard.edu> wrote:
> On Mon, 12 Dec 2016, Andrey Konovalov wrote:
>
>> Hi!
>>
>> While running the syzkaller fuzzer I've got the following error report.
>>
>> On commit 3c49de52d5647cda8b42c4255cf8a29d1e22eff5 (Dev 2).
>>
>> WARNING: CPU: 2 PID: 865 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x8a/0xa0
>> gadgetfs: disconnected
>> sysfs: cannot create duplicate filename
>> '/devices/platform/dummy_hcd.0/usb2/2-1/2-1:64.0/ep_05'
>> Kernel panic - not syncing: panic_on_warn set ...
>>
>> CPU: 2 PID: 865 Comm: kworker/2:1 Not tainted 4.9.0-rc7+ #34
>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>> Workqueue: usb_hub_wq hub_event
>>  88006bee64c8 81f96b8a 0001 11000d7dcc2c
>>  ed000d7dcc24 0001 41b58ab3 8598b510
>>  81f968f8 850fee20 85cff020 dc00
>> Call Trace:
>>  [< inline >] __dump_stack lib/dump_stack.c:15
>>  [] dump_stack+0x292/0x398 lib/dump_stack.c:51
>>  [] panic+0x1cb/0x3a9 kernel/panic.c:179
>>  [] __warn+0x1c4/0x1e0 kernel/panic.c:542
>>  [] warn_slowpath_fmt+0xc5/0x110 kernel/panic.c:565
>>  [] sysfs_warn_dup+0x8a/0xa0 fs/sysfs/dir.c:30
>>  [] sysfs_create_dir_ns+0x178/0x1d0 fs/sysfs/dir.c:59
>>  [< inline >] create_dir lib/kobject.c:71
>>  [] kobject_add_internal+0x227/0xa60 lib/kobject.c:229
>>  [< inline >] kobject_add_varg lib/kobject.c:366
>>  [] kobject_add+0x139/0x220 lib/kobject.c:411
>>  [] device_add+0x353/0x1660 drivers/base/core.c:1088
>>  [] device_register+0x1d/0x20 drivers/base/core.c:1206
>>  [] usb_create_ep_devs+0x163/0x260
>> drivers/usb/core/endpoint.c:195
>>  [] create_intf_ep_devs+0x13b/0x200
>> drivers/usb/core/message.c:1030
>>  [] usb_set_configuration+0x1083/0x18d0
>> drivers/usb/core/message.c:1937
>
> Hi, Andrey:
>
> Please check whether the patch below fixes this problem.

Hi Alan,

Been testing with your patch for the last day, haven't seen any more
reports or other issues.

Tested-by: Andrey Konovalov <andreyk...@google.com>

Thanks!

>
> Alan Stern
>
>
>
> Index: usb-4.x/drivers/usb/core/config.c
> ===
> --- usb-4.x.orig/drivers/usb/core/config.c
> +++ usb-4.x/drivers/usb/core/config.c
> @@ -234,6 +234,16 @@ static int usb_parse_endpoint(struct dev
> if (ifp->desc.bNumEndpoints >= num_ep)
> goto skip_to_next_endpoint_or_interface_descriptor;
>
> +   /* Check for duplicate endpoint addresses */
> +   for (i = 0; i < ifp->desc.bNumEndpoints; ++i) {
> +   if (ifp->endpoint[i].desc.bEndpointAddress ==
> +   d->bEndpointAddress) {
> +   dev_warn(ddev, "config %d interface %d altsetting %d 
> has a duplicate endpoint with address 0x%X, skipping\n",
> +   cfgno, inum, asnum, d->bEndpointAddress);
> +   goto skip_to_next_endpoint_or_interface_descriptor;
> +   }
> +   }
> +
> endpoint = >endpoint[ifp->desc.bNumEndpoints];
> ++ifp->desc.bNumEndpoints;
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

usb/core: warning in usb_create_ep_devs/sysfs_create_dir_ns

[Andrey Konovalov]

Hi!

While running the syzkaller fuzzer I've got the following error report.

On commit 3c49de52d5647cda8b42c4255cf8a29d1e22eff5 (Dev 2).

WARNING: CPU: 2 PID: 865 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x8a/0xa0
gadgetfs: disconnected
sysfs: cannot create duplicate filename
'/devices/platform/dummy_hcd.0/usb2/2-1/2-1:64.0/ep_05'
Kernel panic - not syncing: panic_on_warn set ...

CPU: 2 PID: 865 Comm: kworker/2:1 Not tainted 4.9.0-rc7+ #34
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: usb_hub_wq hub_event
 88006bee64c8 81f96b8a 0001 11000d7dcc2c
 ed000d7dcc24 0001 41b58ab3 8598b510
 81f968f8 850fee20 85cff020 dc00
Call Trace:
 [< inline >] __dump_stack lib/dump_stack.c:15
 [] dump_stack+0x292/0x398 lib/dump_stack.c:51
 [] panic+0x1cb/0x3a9 kernel/panic.c:179
 [] __warn+0x1c4/0x1e0 kernel/panic.c:542
 [] warn_slowpath_fmt+0xc5/0x110 kernel/panic.c:565
 [] sysfs_warn_dup+0x8a/0xa0 fs/sysfs/dir.c:30
 [] sysfs_create_dir_ns+0x178/0x1d0 fs/sysfs/dir.c:59
 [< inline >] create_dir lib/kobject.c:71
 [] kobject_add_internal+0x227/0xa60 lib/kobject.c:229
 [< inline >] kobject_add_varg lib/kobject.c:366
 [] kobject_add+0x139/0x220 lib/kobject.c:411
 [] device_add+0x353/0x1660 drivers/base/core.c:1088
 [] device_register+0x1d/0x20 drivers/base/core.c:1206
 [] usb_create_ep_devs+0x163/0x260
drivers/usb/core/endpoint.c:195
 [] create_intf_ep_devs+0x13b/0x200
drivers/usb/core/message.c:1030
 [] usb_set_configuration+0x1083/0x18d0
drivers/usb/core/message.c:1937
 [] generic_probe+0x6e/0xe0 drivers/usb/core/generic.c:172
 [] usb_probe_device+0xaa/0xe0 drivers/usb/core/driver.c:263
 [< inline >] really_probe drivers/base/dd.c:375
 [] driver_probe_device+0x514/0x980 drivers/base/dd.c:515
 [] __device_attach_driver+0x22b/0x290 drivers/base/dd.c:610
 [] bus_for_each_drv+0x15c/0x200 drivers/base/bus.c:463
 [] __device_attach+0x266/0x3c0 drivers/base/dd.c:667
 [] device_initial_probe+0x1a/0x20 drivers/base/dd.c:714
 [] bus_probe_device+0x1e6/0x290 drivers/base/bus.c:557
 [] device_add+0xd06/0x1660 drivers/base/core.c:1136
 [] usb_new_device+0x9af/0x1e80 drivers/usb/core/hub.c:2508
 [< inline >] hub_port_connect drivers/usb/core/hub.c:4891
 [< inline >] hub_port_connect_change drivers/usb/core/hub.c:4996
 [< inline >] port_event drivers/usb/core/hub.c:5102
 [] hub_event+0x1689/0x36d0 drivers/usb/core/hub.c:5182
 [] process_one_work+0xb2a/0x1aa0 kernel/workqueue.c:2096
 [] worker_thread+0x20f/0x18a0 kernel/workqueue.c:2230
 [] kthread+0x323/0x3e0 kernel/kthread.c:209
 [] ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:433
Dumping ftrace buffer:
   (ftrace buffer empty)
Kernel Offset: disabled
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: usb/gadget: warning in ep_write_iter/__alloc_pages_nodemask

[Andrey Konovalov]

On Mon, Dec 12, 2016 at 9:31 PM, Andrey Konovalov <andreyk...@google.com> wrote:
> Hi!
>
> While running the syzkaller fuzzer I've got the following error report.
>
> The issue is that the len argument is not checked for being too big.
>
> WARNING: CPU: 1 PID: 9935 at mm/page_alloc.c:3511
> __alloc_pages_nodemask+0x159c/0x1e20
> Kernel panic - not syncing: panic_on_warn set ...
>
> CPU: 1 PID: 9935 Comm: syz-executor0 Not tainted 4.9.0-rc7+ #34
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>  88006949f2c8 81f96b8a 0200 11000d293dec
>  ed000d293de4 0a06 41b58ab3 8598b510
>  81f968f8 41b58ab3 85942a58 81432860
> Call Trace:
>  [< inline >] __dump_stack lib/dump_stack.c:15
>  [] dump_stack+0x292/0x398 lib/dump_stack.c:51
>  [] panic+0x1cb/0x3a9 kernel/panic.c:179
>  [] __warn+0x1c4/0x1e0 kernel/panic.c:542
>  [] warn_slowpath_null+0x2c/0x40 kernel/panic.c:585
>  [< inline >] __alloc_pages_slowpath mm/page_alloc.c:3511
>  [] __alloc_pages_nodemask+0x159c/0x1e20 
> mm/page_alloc.c:3781
>  [] alloc_pages_current+0x1c7/0x6b0 mm/mempolicy.c:2072
>  [< inline >] alloc_pages include/linux/gfp.h:469
>  [] kmalloc_order+0x1f/0x70 mm/slab_common.c:1015
>  [] kmalloc_order_trace+0x1f/0x160 mm/slab_common.c:1026
>  [< inline >] kmalloc_large include/linux/slab.h:422
>  [] __kmalloc+0x210/0x2d0 mm/slub.c:3723
>  [< inline >] kmalloc include/linux/slab.h:495
>  [] ep_write_iter+0x167/0xb50
> drivers/usb/gadget/legacy/inode.c:664
>  [< inline >] new_sync_write fs/read_write.c:499
>  [] __vfs_write+0x483/0x760 fs/read_write.c:512
>  [] vfs_write+0x170/0x4e0 fs/read_write.c:560
>  [< inline >] SYSC_write fs/read_write.c:607
>  [] SyS_write+0xfb/0x230 fs/read_write.c:599
>  [] entry_SYSCALL_64_fastpath+0x1f/0xc2
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Kernel Offset: disabled

+syzkaller
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

usb/gadget: warning in ep_write_iter/__alloc_pages_nodemask

[Andrey Konovalov]

Hi!

While running the syzkaller fuzzer I've got the following error report.

The issue is that the len argument is not checked for being too big.

WARNING: CPU: 1 PID: 9935 at mm/page_alloc.c:3511
__alloc_pages_nodemask+0x159c/0x1e20
Kernel panic - not syncing: panic_on_warn set ...

CPU: 1 PID: 9935 Comm: syz-executor0 Not tainted 4.9.0-rc7+ #34
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
 88006949f2c8 81f96b8a 0200 11000d293dec
 ed000d293de4 0a06 41b58ab3 8598b510
 81f968f8 41b58ab3 85942a58 81432860
Call Trace:
 [< inline >] __dump_stack lib/dump_stack.c:15
 [] dump_stack+0x292/0x398 lib/dump_stack.c:51
 [] panic+0x1cb/0x3a9 kernel/panic.c:179
 [] __warn+0x1c4/0x1e0 kernel/panic.c:542
 [] warn_slowpath_null+0x2c/0x40 kernel/panic.c:585
 [< inline >] __alloc_pages_slowpath mm/page_alloc.c:3511
 [] __alloc_pages_nodemask+0x159c/0x1e20 mm/page_alloc.c:3781
 [] alloc_pages_current+0x1c7/0x6b0 mm/mempolicy.c:2072
 [< inline >] alloc_pages include/linux/gfp.h:469
 [] kmalloc_order+0x1f/0x70 mm/slab_common.c:1015
 [] kmalloc_order_trace+0x1f/0x160 mm/slab_common.c:1026
 [< inline >] kmalloc_large include/linux/slab.h:422
 [] __kmalloc+0x210/0x2d0 mm/slub.c:3723
 [< inline >] kmalloc include/linux/slab.h:495
 [] ep_write_iter+0x167/0xb50
drivers/usb/gadget/legacy/inode.c:664
 [< inline >] new_sync_write fs/read_write.c:499
 [] __vfs_write+0x483/0x760 fs/read_write.c:512
 [] vfs_write+0x170/0x4e0 fs/read_write.c:560
 [< inline >] SYSC_write fs/read_write.c:607
 [] SyS_write+0xfb/0x230 fs/read_write.c:599
 [] entry_SYSCALL_64_fastpath+0x1f/0xc2
Dumping ftrace buffer:
   (ftrace buffer empty)
Kernel Offset: disabled
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: usb/gadget: use-after-free in gadgetfs_setup

[Andrey Konovalov]

On Mon, Dec 12, 2016 at 9:09 PM, Alan Stern <st...@rowland.harvard.edu> wrote:
> On Mon, 12 Dec 2016, Andrey Konovalov wrote:
>
>> On Mon, Dec 12, 2016 at 7:44 PM, Alan Stern <st...@rowland.harvard.edu> 
>> wrote:
>> >
>> > I'm still puzzled.  Can you try running the test with the diagnostic
>> > patch below?  The resulting kernel log ought to help pin down where the
>> > problem comes from.
>>
>> Sure, here's the log:
>>
>> usb 1-1: string descriptor 0 read error: -71
>> usb 1-1: New USB device found, idVendor=, idProduct=0002
>> usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=7
>> usb 1-1: can't set config #131, error -71
>> usb 1-1: USB disconnect, device number 45
>> gadgetfs: bound to dummy_udc driver
>> dummy: stop_activity
>> usb 1-1: new full-speed USB device number 46 using dummy_hcd
>> gadgetfs: connected
>> dummy: queue 88006addc300 ep ep0
>> dummy: complete 88006addc300 ep ep0
>> dummy: stop_activity
>> gadgetfs: disconnected
>> gadgetfs: connected
>> dummy: queue 88006addc300 ep ep0
>> dummy: complete 88006addc300 ep ep0
>> dummy: queue 88006addc300 ep ep0
>> dummy: complete 88006addc300 ep ep0
>> dummy: queue 88006addc300 ep ep0
>> dummy: complete 88006addc300 ep ep0
>> usb 1-1: config 131 has too many interfaces: 158, using maximum allowed: 32
>> usb 1-1: config 131 has 1 interface, different from the descriptor's value: 
>> 158
>> dummy: queue 88006addc300 ep ep0
>> dummy: stop_activity
>> gadgetfs: disconnected
>> [ cut here ]
>> WARNING: CPU: 1 PID: 4892 at drivers/usb/gadget/udc/dummy_hcd.c:675
>> dummy_free_request+0x153/0x170
>
> Ah, good, that clears it up.  The problem is that stop_activity() nukes
> all the endpoints except for endpoint 0!
>
> The patch below should fix the problem.

It does!

Thanks!

>
> Alan Stern
>
>
>
> Index: usb-4.x/drivers/usb/gadget/udc/dummy_hcd.c
> ===
> --- usb-4.x.orig/drivers/usb/gadget/udc/dummy_hcd.c
> +++ usb-4.x/drivers/usb/gadget/udc/dummy_hcd.c
> @@ -338,6 +338,7 @@ static void stop_activity(struct dummy *
> /* The timer is left running so that outstanding URBs can fail */
>
> /* nuke any pending requests first, so driver i/o is quiesced */
> +   nuke(dum, >ep[0]);
> list_for_each_entry(ep, >gadget.ep_list, ep.ep_list)
> nuke(dum, ep);
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: usb/gadget: use-after-free in gadgetfs_setup

[Andrey Konovalov]

On Mon, Dec 12, 2016 at 7:44 PM, Alan Stern  wrote:
>
> I'm still puzzled.  Can you try running the test with the diagnostic
> patch below?  The resulting kernel log ought to help pin down where the
> problem comes from.

Sure, here's the log:

usb 1-1: string descriptor 0 read error: -71
usb 1-1: New USB device found, idVendor=, idProduct=0002
usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=7
usb 1-1: can't set config #131, error -71
usb 1-1: USB disconnect, device number 45
gadgetfs: bound to dummy_udc driver
dummy: stop_activity
usb 1-1: new full-speed USB device number 46 using dummy_hcd
gadgetfs: connected
dummy: queue 88006addc300 ep ep0
dummy: complete 88006addc300 ep ep0
dummy: stop_activity
gadgetfs: disconnected
gadgetfs: connected
dummy: queue 88006addc300 ep ep0
dummy: complete 88006addc300 ep ep0
dummy: queue 88006addc300 ep ep0
dummy: complete 88006addc300 ep ep0
dummy: queue 88006addc300 ep ep0
dummy: complete 88006addc300 ep ep0
usb 1-1: config 131 has too many interfaces: 158, using maximum allowed: 32
usb 1-1: config 131 has 1 interface, different from the descriptor's value: 158
dummy: queue 88006addc300 ep ep0
dummy: stop_activity
gadgetfs: disconnected
[ cut here ]
WARNING: CPU: 1 PID: 4892 at drivers/usb/gadget/udc/dummy_hcd.c:675
dummy_free_request+0x153/0x170
Modules linked in:
CPU: 1 PID: 4892 Comm: syz-executor Not tainted 4.9.0-rc7+ #33
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
 88006b966d10 81f96b8a 41b58ab3 11000d72cd35
 ed000d72cd2d 8800615a5800 41b58ab3 8598b6d0
 81f968f8 41b58ab3 859412a0 813f0590
Call Trace:
 [< inline >] __dump_stack lib/dump_stack.c:15
 [] dump_stack+0x292/0x398 lib/dump_stack.c:51
 [] __warn+0x19f/0x1e0 kernel/panic.c:550
 [] warn_slowpath_null+0x2c/0x40 kernel/panic.c:585
 [] dummy_free_request+0x153/0x170
drivers/usb/gadget/udc/dummy_hcd.c:675
 [] usb_ep_free_request+0xc0/0x420
drivers/usb/gadget/udc/core.c:195
 [] gadgetfs_unbind+0x131/0x190
drivers/usb/gadget/legacy/inode.c:1612
 [] usb_gadget_remove_driver+0x10f/0x2b0
drivers/usb/gadget/udc/core.c:1228
 [] usb_gadget_unregister_driver+0x154/0x240
drivers/usb/gadget/udc/core.c:1357
 [] dev_release+0x80/0x160
drivers/usb/gadget/legacy/inode.c:1187
 [] __fput+0x332/0x7f0 fs/file_table.c:208
 [] fput+0x15/0x20 fs/file_table.c:244
 [] task_work_run+0x19b/0x270 kernel/task_work.c:116
 [< inline >] exit_task_work ./include/linux/task_work.h:21
 [] do_exit+0x16aa/0x2530 kernel/exit.c:828
 [] do_group_exit+0x149/0x420 kernel/exit.c:932
 [] get_signal+0x76d/0x17b0 kernel/signal.c:2307
 [] do_signal+0xd2/0x2120 arch/x86/kernel/signal.c:807
 [] exit_to_usermode_loop+0x170/0x200
arch/x86/entry/common.c:156
 [< inline >] prepare_exit_to_usermode arch/x86/entry/common.c:190
 [] syscall_return_slowpath+0x3d3/0x420
arch/x86/entry/common.c:259
 [] entry_SYSCALL_64_fastpath+0xc0/0xc2
arch/x86/entry/entry_64.S:244
---[ end trace a9660fdf4f9ba45b ]---
usb 1-1: string descriptor 0 read error: -71
usb 1-1: New USB device found, idVendor=, idProduct=0002
usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=7
usb 1-1: can't set config #131, error -71
usb 1-1: USB disconnect, device number 46
gadgetfs: bound to dummy_udc driver
dummy: stop_activity
usb 1-1: new full-speed USB device number 47 using dummy_hcd
dummy: stale 88006addc300 ep ep0
==
BUG: KASAN: use-after-free in __list_del_entry+0x267/0x280 at addr
88006addc308
Read of size 8 by task swapper/1/0
CPU: 1 PID: 0 Comm: swapper/1 Tainted: GW   4.9.0-rc7+ #33
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
 88006cb06c60 81f96b8a 0001 11000d960d1f
 ed000d960d17  41b58ab3 8598b6d0
 81f968f8 853df840 85cff020 dc00
Call Trace:
  [   96.936042]  [] dump_stack+0x292/0x398
 [] kasan_object_err+0x1c/0x70 mm/kasan/report.c:159
 [< inline >] print_address_description mm/kasan/report.c:197
 [] kasan_report_error+0x1f0/0x4e0 mm/kasan/report.c:286
 [< inline >] kasan_report mm/kasan/report.c:306
 [] __asan_report_load8_noabort+0x3e/0x40
mm/kasan/report.c:327
 [] __list_del_entry+0x267/0x280 lib/list_debug.c:48
 [< inline >] list_del_init ./include/linux/list.h:145
 [] dummy_timer+0x3367/0x35f0
drivers/usb/gadget/udc/dummy_hcd.c:1839
...

Let me know if you need to test something else.

>
> Alan Stern
>
>
>
> Index: usb-4.x/drivers/usb/gadget/udc/dummy_hcd.c
> ===
> --- usb-4.x.orig/drivers/usb/gadget/udc/dummy_hcd.c
> +++ usb-4.x/drivers/usb/gadget/udc/dummy_hcd.c
> @@ -318,6 +318,7 @@ static void nuke(struct dummy *dum, stru

Re: usb/gadget: use-after-free in gadgetfs_setup

[Andrey Konovalov]

On Fri, Dec 9, 2016 at 8:57 PM, Alan Stern <st...@rowland.harvard.edu> wrote:
> On Fri, 9 Dec 2016, Andrey Konovalov wrote:
>
>> On Wed, Dec 7, 2016 at 8:15 PM, Alan Stern <st...@rowland.harvard.edu> wrote:
>> > On Wed, 7 Dec 2016, Andrey Konovalov wrote:
>> >
>> >> > And in any case, is there any way you can post the series of system
>> >> > calls that syzkaller makes so we can tell what went wrong?
>> >>
>> >> I've attached a reproducer for a use-after-free in gadgetfs_setup().
>> >> You need to enable KASAN to see the reports.
>> >
>> > Okay, that helps.  I see the problem: dev->hs_config ends up containing
>> > a stale pointer in dev_config().  The patch below ought to fix that;
>> > please verify that it really does.
>>
>> Hi Alan,
>>
>> Have been fuzzing with your patch, haven't seen any more reports.
>>
>> Thanks!
>
> Okay, good.  I'll submit the two patches.
>
> Can you also provide reproducers for the "GPF in
> usb_gadget_unregister_driver" and the "warning in dummy_free_request"
> tests?

Hi Alan,

I haven't managed to obtain a working reproducer, though the fuzzer
hits it pretty often :(

Here is a syzkaller description of the program which triggers the
crash (note that syzkaller can run each call concurrently):

mmap(&(0x7f00/0x5000)=nil, (0x5000), 0x3, 0x32, 0x, 0x0)
r0 = open$usb(&(0x7f00)="2f6465762f6761646765742f64756d6d795f75646300",
0x602, 0x0)
read$usb(r0, 
&(0x7f00)="00",
0xcf)
write$usb(r0, &(0x7f003000-0x28)={0x0, {0x9, 0x2, 0x12,
0xff9e, 0x83, 0x5, 0x80, 0x0}, {0x9, 0x4, 0x0, 0x0, 0x0,
0x0, 0x55, 0x4, 0x9}, {0x12, 0x1, 0x2, 0x8001, 0x8, 0x6, 0x0, 0x0,
0x2, 0x2, 0x0, 0x0, 0x7, 0x1}}, 0x28)
read$usb(r0, &(0x7f004000-0xf)="", 0xc)
read$usb(r0, 
&(0x7f004000)="",
0x1c)

The second argument of write$usb (which is probably the most
interesting call) is a structure of the following format:

usb_init {
  tag const[0, int32]
  config usb_config_descriptor
  interface usb_interface_descriptor
  device usb_device_descriptor
} [packed]

usb_config_descriptor, usb_interface_descriptor and
usb_device_descriptor correspond to kernel structures as defined in
include/uapi/linux/usb/ch9.h

I noticed that both reports happen one after another on the same testcase.
Below a part of the kernel log with both reports.

I hope some of that helps.

gadgetfs: bound to dummy_udc driver
usb 1-1: new full-speed USB device number 6 using dummy_hcd
gadgetfs: connected
gadgetfs: disconnected
gadgetfs: connected
usb 1-1: config 131 has too many interfaces: 158, using maximum allowed: 32
usb 1-1: config 131 has 1 interface, different from the descriptor's value: 158
gadgetfs: disconnected
[ cut here ]
WARNING: CPU: 0 PID: 4410 at drivers/usb/gadget/udc/dummy_hcd.c:672
dummy_free_request+0x153/0x170
Modules linked in:
CPU: 0 PID: 4410 Comm: syz-executor Not tainted 4.9.0-rc7+ #32
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
 88006a64ed10 81f96b8a 41b58ab3 11000d4c9d35
 ed000d4c9d2d 880065f8ac00 41b58ab3 8598b510
 81f968f8 41b58ab3 859410e0 813f0590
Call Trace:
 [< inline >] __dump_stack lib/dump_stack.c:15
 [] dump_stack+0x292/0x398 lib/dump_stack.c:51
 [] __warn+0x19f/0x1e0 kernel/panic.c:550
 [] warn_slowpath_null+0x2c/0x40 kernel/panic.c:585
 [] dummy_free_request+0x153/0x170
drivers/usb/gadget/udc/dummy_hcd.c:672
 [] usb_ep_free_request+0xc0/0x420
drivers/usb/gadget/udc/core.c:195
 [] gadgetfs_unbind+0x131/0x190
drivers/usb/gadget/legacy/inode.c:1612
 [] usb_gadget_remove_driver+0x10f/0x2b0
drivers/usb/gadget/udc/core.c:1228
 [] usb_gadget_unregister_driver+0x154/0x240
drivers/usb/gadget/udc/core.c:1357
 [] dev_release+0x80/0x160
drivers/usb/gadget/legacy/inode.c:1187
 [] __fput+0x332/0x7f0 fs/file_table.c:208
 [] fput+0x15/0x20 fs/file_table.c:244
 [] task_work_run+0x19b/0x270 kernel/task_work.c:116
 [< inline >] exit_task_work ./include/linux/task_work.h:21
 [] do_exit+0x16aa/0x2530 kernel/exit.c:828
 [] do_group_exit+0x149/0x420 kernel/exit.c:932
 [] get_signal+0x76d/0x17b0 kernel/signal.c:2307
 [] do_signal+0xd2/0x

Re: Emulating USB devices from userspace

[Andrey Konovalov]

On Fri, Dec 9, 2016 at 8:20 AM, Greg Kroah-Hartman
<gre...@linuxfoundation.org> wrote:
> On Fri, Dec 09, 2016 at 12:38:23AM +0100, Andrey Konovalov wrote:
>> Hi,
>>
>> I'm working on a way to extend syzkaller [1] to support fuzzing of the
>> USB subsystem. The idea is to be able to emulate various USB devices
>> and fuzz communication between the emulated device and the kernel. I'm
>> looking for a way to emulate devices from userspace. Similar to how
>> tuntap allows to create virtual network interfaces and emit ethernet
>> traffic by writing to /dev/net/tun.
>>
>> While googling for some information on this I found mentions of
>> gadgetfs and functionfs. As far as I understand, they allow to turn a
>> USB host into a gadget and provide a way to communicate with another
>> host from a userspace application running on the gadget machine.
>
> Not quite.  They are to drive a USB "gadget" device (i.e. the thing you
> plug into a USB host, like a keyboard).  You use that if you are running
> Linux inside of that keyboard.  Or inside your phone, it uses this
> interface when talking to your laptop.
>
>> There's also usbfs, which allows to communicate with a usb gadget
>> directly from a userspace application.
>
> usbfs is to talk to a USB gadget through the host controller, so you can
> use it to fuzz a USB gadget driver, if a host driver is not already
> bound to the device.
>
>> Am I right, that none of the above actually fit my needs?
>
> No, it should fit your needs just fine.  Use the dummy USB gadget
> controller driver to set up the USB gadget device, and control it that
> way.  It is how many people develop their USB gadget drivers directly on
> a non-gadget system (like a desktop.)

Hi Greg,

OK, it's starting to make some sense.
Dummy actually means loopback, correct?

Right now whenever I mount gadgetfs I see a dummy_udc file. This
basically means that I have gadgetfs set up in a loopback mode (since
I have CONFIG_USB_DUMMY_HCD=y). Now I can write USB device description
to dummy_udc and the kernel will find an appropriate driver and
loopback the communication with this driver to the exposed epN files.
Is my understanding of this correct?

>
>> Is there some way to emulate USB devices from a userspace application
>> via some kernel interface?
>
> Yes, use functionfs.

As I understand, the way to write gadget drivers with functionfs is to
describe something that's called a function by mounting functionfs and
writing to the files it provides. Then you need to use configfs to
actually compose these functions into a device.

Is this correct?

What does a function stands for in this context? A USB configuration?

How do I enable loopback with functionfs?

Are there any advantages of using functionfs over gadgetfs for fuzzing?

Thanks!

>
> have fun!
>
> greg k-h
>
> --
> You received this message because you are subscribed to the Google Groups 
> "syzkaller" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to syzkaller+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Emulating USB devices from userspace

[Andrey Konovalov]

Hi,

I'm working on a way to extend syzkaller [1] to support fuzzing of the
USB subsystem. The idea is to be able to emulate various USB devices
and fuzz communication between the emulated device and the kernel. I'm
looking for a way to emulate devices from userspace. Similar to how
tuntap allows to create virtual network interfaces and emit ethernet
traffic by writing to /dev/net/tun.

While googling for some information on this I found mentions of
gadgetfs and functionfs. As far as I understand, they allow to turn a
USB host into a gadget and provide a way to communicate with another
host from a userspace application running on the gadget machine.
There's also usbfs, which allows to communicate with a usb gadget
directly from a userspace application.

Am I right, that none of the above actually fit my needs?

Is there some way to emulate USB devices from a userspace application
via some kernel interface?

If not, what would be the easiest way to implement one? I'm thinking
this should be possible by adding some hooks into the kernel, the
question is what to hook and where?

Thanks!

[1] https://github.com/google/syzkaller
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: usb/gadget: use-after-free in gadgetfs_setup

[Andrey Konovalov]

On Wed, Dec 7, 2016 at 8:15 PM, Alan Stern <st...@rowland.harvard.edu> wrote:
> On Wed, 7 Dec 2016, Andrey Konovalov wrote:
>
>> > And in any case, is there any way you can post the series of system
>> > calls that syzkaller makes so we can tell what went wrong?
>>
>> I've attached a reproducer for a use-after-free in gadgetfs_setup().
>> You need to enable KASAN to see the reports.
>
> Okay, that helps.  I see the problem: dev->hs_config ends up containing
> a stale pointer in dev_config().  The patch below ought to fix that;
> please verify that it really does.

Hi Alan,

Have been fuzzing with your patch, haven't seen any more reports.

Thanks!

>
> The syzkaller test also shows that there should be a few more checks
> for valid values in dev->config->wTotalLength and
> dev->hs_config->wTotalLength.  I'll do those in a separate patch.
>
> Alan Stern
>
>
>
> Index: usb-4.x/drivers/usb/gadget/legacy/inode.c
> ===
> --- usb-4.x.orig/drivers/usb/gadget/legacy/inode.c
> +++ usb-4.x/drivers/usb/gadget/legacy/inode.c
> @@ -1799,6 +1799,8 @@ dev_config (struct file *fd, const char
> goto fail;
> kbuf += total;
> length -= total;
> +   } else {
> +   dev->hs_config = NULL;
> }
>
> /* could support multiple configs, using another encoding! */
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: usb/gadget: use-after-free in gadgetfs_setup

[Andrey Konovalov]

On Tue, Dec 6, 2016 at 9:30 PM, Alan Stern <st...@rowland.harvard.edu> wrote:
> [CC: list drastically trimmed]
>
> On Tue, 6 Dec 2016, Andrey Konovalov wrote:
>
>> On Tue, Dec 6, 2016 at 1:28 PM, Andrey Konovalov <andreyk...@google.com> 
>> wrote:
>> > On Mon, Dec 5, 2016 at 8:31 PM, Alan Stern <st...@rowland.harvard.edu> 
>> > wrote:
>> >> On Mon, 5 Dec 2016, Andrey Konovalov wrote:
>> >>
>> >>> Hi!
>> >>>
>> >>> I've got the following error report while running the syzkaller fuzzer.
>> >>>
>> >>> On commit 3c49de52d5647cda8b42c4255cf8a29d1e22eff5 (Dec 2).
>> >>>
>> >>> BUG: KASAN: use-after-free in gadgetfs_setup+0x208a/0x20e0 at addr
>> >>> 88003dfe5bf2
>
>> >> Can you test whether the patch below fixes this problem?
>> >
>> > Hi Alan,
>> >
>> > Yes, I believe it does.
>> > It also seems to fix the warnings in dummy_free_request() I've been 
>> > getting.
>>
>> It seems that I was wrong. Still see both use-after-free and warnings.
>
> You posted three messages about possibly related problems:
>
> use-after-free in gadgetfs_setup (this one),
>
> GPF in usb_gadget_unregister_driver,
>
> warning in dummy_free_request.
>
> Are you saying the patch below didn't fix any of them?

No, as far as I can see.

>
> And in any case, is there any way you can post the series of system
> calls that syzkaller makes so we can tell what went wrong?

I've attached a reproducer for a use-after-free in gadgetfs_setup().
You need to enable KASAN to see the reports.

Thanks for looking at this!

>
> Alan Stern
>
>> >> Index: usb-4.x/drivers/usb/gadget/legacy/inode.c
>> >> ===
>> >> --- usb-4.x.orig/drivers/usb/gadget/legacy/inode.c
>> >> +++ usb-4.x/drivers/usb/gadget/legacy/inode.c
>> >> @@ -1762,6 +1762,10 @@ dev_config (struct file *fd, const char
>> >> }
>> >> spin_unlock_irq(>lock);
>> >>
>> >> +   /* Registered but not yet bound to a UDC driver? */
>> >> +   if (dev->gadget_registered)
>> >> +   return -EIO;
>> >> +
>> >> if (len < (USB_DT_CONFIG_SIZE + USB_DT_DEVICE_SIZE + 4))
>> >> return -EINVAL;
>> >>
>


gadget-setup-uaf-poc.c
Description: Binary data

Re: net/gadget: slab-out-of-bounds write in dev_config

[Andrey Konovalov]

On Tue, Dec 6, 2016 at 4:30 PM, Alan Stern <st...@rowland.harvard.edu> wrote:
> On Tue, 6 Dec 2016, Andrey Konovalov wrote:
>
>> Hi!
>>
>> I've got the following error report while running the syzkaller fuzzer.
>>
>> ep0_write() doesn't check the length, so a user can cause an
>> out-of-bounds with both size and data controlled.
>> There's a comment which says "IN DATA+STATUS caller makes len <=
>> wLength". While I'm not exactly sure what that means, the length seems
>> to be passed unmodified directly from dev_config().
>
> You're right about the comment being misleading.  It looks like
> somebody forgot to actually do the check.
>
>> This doesn't seem to be a critical security issue since gadgetfs can't
>> be mounted from a user namespace.
>>
>> On commit 3c49de52d5647cda8b42c4255cf8a29d1e22eff5 (Dec 2).
>>
>> ==
>> BUG: KASAN: slab-out-of-bounds in dev_config+0x86f/0x1190 at addr
>> 88003c47e160
>> Write of size 65537 by task syz-executor0/6356
>> CPU: 3 PID: 6356 Comm: syz-executor0 Not tainted 4.9.0-rc7+ #19
>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>>  88003c107ad8 81f96aba 3dc11ef0 110007820eee
>>  ed0007820ee6 88003dc11f00 41b58ab3 8598b4c8
>>  81f96828 813fb4a0 88003b6eadc0 88003c107738
>> Call Trace:
>>  [< inline >] __dump_stack lib/dump_stack.c:15
>>  [] dump_stack+0x292/0x398 lib/dump_stack.c:51
>>  [] kasan_object_err+0x1c/0x70 mm/kasan/report.c:159
>>  [< inline >] print_address_description mm/kasan/report.c:197
>>  [] kasan_report_error+0x1f0/0x4e0 mm/kasan/report.c:286
>>  [] kasan_report+0x35/0x40 mm/kasan/report.c:306
>>  [< inline >] check_memory_region_inline mm/kasan/kasan.c:308
>>  [] check_memory_region+0x139/0x190 mm/kasan/kasan.c:315
>>  [] kasan_check_write+0x14/0x20 mm/kasan/kasan.c:326
>>  [< inline >] copy_from_user arch/x86/include/asm/uaccess.h:689
>>  [< inline >] ep0_write drivers/usb/gadget/legacy/inode.c:1135
>>  [] dev_config+0x86f/0x1190
>> drivers/usb/gadget/legacy/inode.c:1759
>>  [] __vfs_write+0x5d5/0x760 fs/read_write.c:510
>>  [] vfs_write+0x170/0x4e0 fs/read_write.c:560
>>  [< inline >] SYSC_write fs/read_write.c:607
>>  [] SyS_write+0xfb/0x230 fs/read_write.c:599
>>  [] entry_SYSCALL_64_fastpath+0x1f/0xc2
>
> How does this patch work out?

I believe it fixes the issue.

Thanks!

>
> Alan Stern
>
>
>
> Index: usb-4.x/drivers/usb/gadget/legacy/inode.c
> ===
> --- usb-4.x.orig/drivers/usb/gadget/legacy/inode.c
> +++ usb-4.x/drivers/usb/gadget/legacy/inode.c
> @@ -1126,7 +1126,7 @@ ep0_write (struct file *fd, const char _
> /* data and/or status stage for control request */
> } else if (dev->state == STATE_DEV_SETUP) {
>
> -   /* IN DATA+STATUS caller makes len <= wLength */
> +   len = min(len, (size_t) dev->setup_wLength);
> if (dev->setup_in) {
> retval = setup_req (dev->gadget->ep0, dev->req, len);
> if (retval == 0) {
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: usb/gadget: use-after-free in gadgetfs_setup

[Andrey Konovalov]

On Tue, Dec 6, 2016 at 1:28 PM, Andrey Konovalov <andreyk...@google.com> wrote:
> On Mon, Dec 5, 2016 at 8:31 PM, Alan Stern <st...@rowland.harvard.edu> wrote:
>> On Mon, 5 Dec 2016, Andrey Konovalov wrote:
>>
>>> Hi!
>>>
>>> I've got the following error report while running the syzkaller fuzzer.
>>>
>>> On commit 3c49de52d5647cda8b42c4255cf8a29d1e22eff5 (Dec 2).
>>>
>>> BUG: KASAN: use-after-free in gadgetfs_setup+0x208a/0x20e0 at addr
>>> 88003dfe5bf2
>>> Read of size 2 by task syz-executor0/22994
>>> CPU: 3 PID: 22994 Comm: syz-executor0 Not tainted 4.9.0-rc7+ #16
>>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>>>  88006df06a18 81f96aba e0528500 11000dbe0cd6
>>>  ed000dbe0cce 88006df068f0 41b58ab3 8598b4c8
>>>  81f96828 11000dbe0ccd 88006df06708 88006df06748
>>> Call Trace:
>>>   [  201.343209]  [< inline >] __dump_stack lib/dump_stack.c:15
>>>   [  201.343209]  [] dump_stack+0x292/0x398
>>> lib/dump_stack.c:51
>>>  [] kasan_object_err+0x1c/0x70 mm/kasan/report.c:159
>>>  [< inline >] print_address_description mm/kasan/report.c:197
>>>  [] kasan_report_error+0x1f0/0x4e0 mm/kasan/report.c:286
>>>  [< inline >] kasan_report mm/kasan/report.c:306
>>>  [] __asan_report_load_n_noabort+0x3a/0x40
>>> mm/kasan/report.c:337
>>>  [< inline >] config_buf drivers/usb/gadget/legacy/inode.c:1298
>>>  [] gadgetfs_setup+0x208a/0x20e0
>>> drivers/usb/gadget/legacy/inode.c:1368
>>>  [] dummy_timer+0x11f0/0x36d0
>>> drivers/usb/gadget/udc/dummy_hcd.c:1858
>>>  [] call_timer_fn+0x241/0x800 kernel/time/timer.c:1308
>>>  [< inline >] expire_timers kernel/time/timer.c:1348
>>>  [] __run_timers+0xa06/0xec0 kernel/time/timer.c:1641
>>>  [] run_timer_softirq+0x21/0x80 kernel/time/timer.c:1654
>>>  [] __do_softirq+0x2fb/0xb63 kernel/softirq.c:284
>>>  [< inline >] invoke_softirq kernel/softirq.c:364
>>>  [] irq_exit+0x19e/0x1d0 kernel/softirq.c:405
>>>  [< inline >] exiting_irq arch/x86/include/asm/apic.h:659
>>>  [] smp_apic_timer_interrupt+0x7b/0xa0
>>> arch/x86/kernel/apic/apic.c:960
>>>  [] apic_timer_interrupt+0x8c/0xa0
>>> arch/x86/entry/entry_64.S:489
>>>   [  201.343209]  [] ?
>>> _raw_spin_unlock_irqrestore+0x119/0x1a0
>>>  [] try_to_wake_up+0x174/0x1160 kernel/sched/core.c:2099
>>>  [< inline >] wake_up_process kernel/sched/core.c:2165
>>>  [] wake_up_q+0x8a/0xe0 kernel/sched/core.c:469
>>>  [] futex_wake+0x5be/0x6c0 kernel/futex.c:1453
>>>  [] do_futex+0x11bd/0x1f00 kernel/futex.c:3219
>>>  [< inline >] SYSC_futex kernel/futex.c:3275
>>>  [] SyS_futex+0x2fc/0x400 kernel/futex.c:3243
>>>  [] entry_SYSCALL_64_fastpath+0x1f/0xc2
>>
>> Can you test whether the patch below fixes this problem?
>
> Hi Alan,
>
> Yes, I believe it does.
> It also seems to fix the warnings in dummy_free_request() I've been getting.

It seems that I was wrong. Still see both use-after-free and warnings.

>
> Thanks!
>
>>
>> Alan Stern
>>
>>
>>
>> Index: usb-4.x/drivers/usb/gadget/legacy/inode.c
>> ===
>> --- usb-4.x.orig/drivers/usb/gadget/legacy/inode.c
>> +++ usb-4.x/drivers/usb/gadget/legacy/inode.c
>> @@ -1762,6 +1762,10 @@ dev_config (struct file *fd, const char
>> }
>> spin_unlock_irq(>lock);
>>
>> +   /* Registered but not yet bound to a UDC driver? */
>> +   if (dev->gadget_registered)
>> +   return -EIO;
>> +
>> if (len < (USB_DT_CONFIG_SIZE + USB_DT_DEVICE_SIZE + 4))
>> return -EINVAL;
>>
>>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

net/gadget: slab-out-of-bounds write in dev_config

[Andrey Konovalov]

Hi!

I've got the following error report while running the syzkaller fuzzer.

ep0_write() doesn't check the length, so a user can cause an
out-of-bounds with both size and data controlled.
There's a comment which says "IN DATA+STATUS caller makes len <=
wLength". While I'm not exactly sure what that means, the length seems
to be passed unmodified directly from dev_config().

This doesn't seem to be a critical security issue since gadgetfs can't
be mounted from a user namespace.

On commit 3c49de52d5647cda8b42c4255cf8a29d1e22eff5 (Dec 2).

==
BUG: KASAN: slab-out-of-bounds in dev_config+0x86f/0x1190 at addr
88003c47e160
Write of size 65537 by task syz-executor0/6356
CPU: 3 PID: 6356 Comm: syz-executor0 Not tainted 4.9.0-rc7+ #19
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
 88003c107ad8 81f96aba 3dc11ef0 110007820eee
 ed0007820ee6 88003dc11f00 41b58ab3 8598b4c8
 81f96828 813fb4a0 88003b6eadc0 88003c107738
Call Trace:
 [< inline >] __dump_stack lib/dump_stack.c:15
 [] dump_stack+0x292/0x398 lib/dump_stack.c:51
 [] kasan_object_err+0x1c/0x70 mm/kasan/report.c:159
 [< inline >] print_address_description mm/kasan/report.c:197
 [] kasan_report_error+0x1f0/0x4e0 mm/kasan/report.c:286
 [] kasan_report+0x35/0x40 mm/kasan/report.c:306
 [< inline >] check_memory_region_inline mm/kasan/kasan.c:308
 [] check_memory_region+0x139/0x190 mm/kasan/kasan.c:315
 [] kasan_check_write+0x14/0x20 mm/kasan/kasan.c:326
 [< inline >] copy_from_user arch/x86/include/asm/uaccess.h:689
 [< inline >] ep0_write drivers/usb/gadget/legacy/inode.c:1135
 [] dev_config+0x86f/0x1190
drivers/usb/gadget/legacy/inode.c:1759
 [] __vfs_write+0x5d5/0x760 fs/read_write.c:510
 [] vfs_write+0x170/0x4e0 fs/read_write.c:560
 [< inline >] SYSC_write fs/read_write.c:607
 [] SyS_write+0xfb/0x230 fs/read_write.c:599
 [] entry_SYSCALL_64_fastpath+0x1f/0xc2
Object at 88003c47e038, in cache kmalloc-1024 size: 1024
Allocated:
PID = 4565
 [   43.417154] [] save_stack_trace+0x16/0x20
arch/x86/kernel/stacktrace.c:57
 [   43.417154] [] save_stack+0x43/0xd0 mm/kasan/kasan.c:495
 [   43.417154] [< inline >] set_track mm/kasan/kasan.c:507
 [   43.417154] [] kasan_kmalloc+0xad/0xe0
mm/kasan/kasan.c:598
 [   43.417154] [] kmem_cache_alloc_trace+0x82/0x270
mm/slub.c:2735
 [   43.417154] [< inline >] kmalloc include/linux/slab.h:490
 [   43.417154] [< inline >] kzalloc include/linux/slab.h:636
 [   43.417154] [< inline >] dev_new
drivers/usb/gadget/legacy/inode.c:170
 [   43.417154] [] gadgetfs_fill_super+0x24a/0x540
drivers/usb/gadget/legacy/inode.c:1987
 [   43.417154] [] mount_single+0xf1/0x160 fs/super.c:1146
 [   43.417154] [] gadgetfs_mount+0x2c/0x40
drivers/usb/gadget/legacy/inode.c:2013
 [   43.417154] [] mount_fs+0x97/0x2e0 fs/super.c:1177
 [   43.417154] [] vfs_kern_mount.part.24+0x67/0x2f0
fs/namespace.c:954
 [   43.417154] [< inline >] vfs_kern_mount fs/namespace.c:2433
 [   43.417154] [< inline >] do_new_mount fs/namespace.c:2436
 [   43.417154] [] do_mount+0x418/0x2da0 fs/namespace.c:2758
 [   43.417154] [< inline >] SYSC_mount fs/namespace.c:2974
 [   43.417154] [] SyS_mount+0xab/0x120 fs/namespace.c:2951
 [   43.417154] [] entry_SYSCALL_64_fastpath+0x1f/0xc2
Freed:
PID = 0
(stack is not available)
Memory state around the buggy address:
 88003c47e100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 88003c47e180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>88003c47e200: 00 00 00 00 00 00 00 00 00 00 00 00 fc fc fc fc
   ^
 88003c47e280: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
 88003c47e300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
==
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: usb/gadget: use-after-free in gadgetfs_setup

[Andrey Konovalov]

On Mon, Dec 5, 2016 at 8:31 PM, Alan Stern <st...@rowland.harvard.edu> wrote:
> On Mon, 5 Dec 2016, Andrey Konovalov wrote:
>
>> Hi!
>>
>> I've got the following error report while running the syzkaller fuzzer.
>>
>> On commit 3c49de52d5647cda8b42c4255cf8a29d1e22eff5 (Dec 2).
>>
>> BUG: KASAN: use-after-free in gadgetfs_setup+0x208a/0x20e0 at addr
>> 88003dfe5bf2
>> Read of size 2 by task syz-executor0/22994
>> CPU: 3 PID: 22994 Comm: syz-executor0 Not tainted 4.9.0-rc7+ #16
>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>>  88006df06a18 81f96aba e0528500 11000dbe0cd6
>>  ed000dbe0cce 88006df068f0 41b58ab3 8598b4c8
>>  81f96828 11000dbe0ccd 88006df06708 88006df06748
>> Call Trace:
>>   [  201.343209]  [< inline >] __dump_stack lib/dump_stack.c:15
>>   [  201.343209]  [] dump_stack+0x292/0x398
>> lib/dump_stack.c:51
>>  [] kasan_object_err+0x1c/0x70 mm/kasan/report.c:159
>>  [< inline >] print_address_description mm/kasan/report.c:197
>>  [] kasan_report_error+0x1f0/0x4e0 mm/kasan/report.c:286
>>  [< inline >] kasan_report mm/kasan/report.c:306
>>  [] __asan_report_load_n_noabort+0x3a/0x40
>> mm/kasan/report.c:337
>>  [< inline >] config_buf drivers/usb/gadget/legacy/inode.c:1298
>>  [] gadgetfs_setup+0x208a/0x20e0
>> drivers/usb/gadget/legacy/inode.c:1368
>>  [] dummy_timer+0x11f0/0x36d0
>> drivers/usb/gadget/udc/dummy_hcd.c:1858
>>  [] call_timer_fn+0x241/0x800 kernel/time/timer.c:1308
>>  [< inline >] expire_timers kernel/time/timer.c:1348
>>  [] __run_timers+0xa06/0xec0 kernel/time/timer.c:1641
>>  [] run_timer_softirq+0x21/0x80 kernel/time/timer.c:1654
>>  [] __do_softirq+0x2fb/0xb63 kernel/softirq.c:284
>>  [< inline >] invoke_softirq kernel/softirq.c:364
>>  [] irq_exit+0x19e/0x1d0 kernel/softirq.c:405
>>  [< inline >] exiting_irq arch/x86/include/asm/apic.h:659
>>  [] smp_apic_timer_interrupt+0x7b/0xa0
>> arch/x86/kernel/apic/apic.c:960
>>  [] apic_timer_interrupt+0x8c/0xa0
>> arch/x86/entry/entry_64.S:489
>>   [  201.343209]  [] ?
>> _raw_spin_unlock_irqrestore+0x119/0x1a0
>>  [] try_to_wake_up+0x174/0x1160 kernel/sched/core.c:2099
>>  [< inline >] wake_up_process kernel/sched/core.c:2165
>>  [] wake_up_q+0x8a/0xe0 kernel/sched/core.c:469
>>  [] futex_wake+0x5be/0x6c0 kernel/futex.c:1453
>>  [] do_futex+0x11bd/0x1f00 kernel/futex.c:3219
>>  [< inline >] SYSC_futex kernel/futex.c:3275
>>  [] SyS_futex+0x2fc/0x400 kernel/futex.c:3243
>>  [] entry_SYSCALL_64_fastpath+0x1f/0xc2
>
> Can you test whether the patch below fixes this problem?

Hi Alan,

Yes, I believe it does.
It also seems to fix the warnings in dummy_free_request() I've been getting.

Thanks!

>
> Alan Stern
>
>
>
> Index: usb-4.x/drivers/usb/gadget/legacy/inode.c
> ===
> --- usb-4.x.orig/drivers/usb/gadget/legacy/inode.c
> +++ usb-4.x/drivers/usb/gadget/legacy/inode.c
> @@ -1762,6 +1762,10 @@ dev_config (struct file *fd, const char
> }
> spin_unlock_irq(>lock);
>
> +   /* Registered but not yet bound to a UDC driver? */
> +   if (dev->gadget_registered)
> +   return -EIO;
> +
> if (len < (USB_DT_CONFIG_SIZE + USB_DT_DEVICE_SIZE + 4))
> return -EINVAL;
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] usbip: fix warning in vhci_hcd_probe/lockdep_init_map

[Andrey Konovalov]

On Mon, Dec 5, 2016 at 9:00 PM, Shuah Khan <shua...@osg.samsung.com> wrote:
> Hi Andrey,
>
> On 12/05/2016 12:56 PM, Shuah Khan wrote:
>> vhci_hcd calls sysfs_create_group() with dynamically allocated sysfs
>> attributes triggering the lock-class key not persistent warning. Call
>> sysfs_attr_init() for dynamically allocated sysfs attributes to fix it.
>>
>> vhci_hcd vhci_hcd: USB/IP Virtual Host Controller
>> vhci_hcd vhci_hcd: new USB bus registered, assigned bus number 2
>> BUG: key 88006a7e8d18 not in .data!
>> [ cut here ]
>> WARNING: CPU: 0 PID: 1 at kernel/locking/lockdep.c:3131
>> lockdep_init_map+0x60c/0x770
>> DEBUG_LOCKS_WARN_ON(1)[1.567044] Modules linked in:
>> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.0-rc7+ #58
>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>>  88006bce6eb8 81f96c8a 0a02 11000d79cd6a
>>  ed000d79cd62 00046bce6ed8 41b58ab3 8598af40
>>  81f969f8  41b58ab3 0200
>> Call Trace:
>>  [< inline >] __dump_stack lib/dump_stack.c:15
>>  [] dump_stack+0x292/0x398 lib/dump_stack.c:51
>>  [] __warn+0x19f/0x1e0 kernel/panic.c:550
>>  [] warn_slowpath_fmt+0xc5/0x110 kernel/panic.c:565
>>  [] lockdep_init_map+0x60c/0x770 
>> kernel/locking/lockdep.c:3131
>>  [] __kernfs_create_file+0x114/0x2a0 fs/kernfs/file.c:954
>>  [] sysfs_add_file_mode_ns+0x225/0x520 fs/sysfs/file.c:305
>>  [< inline >] create_files fs/sysfs/group.c:64
>>  [] internal_create_group+0x239/0x8f0 fs/sysfs/group.c:134
>>  [] sysfs_create_group+0x1f/0x30 fs/sysfs/group.c:156
>>  [] vhci_start+0x5b4/0x7a0 drivers/usb/usbip/vhci_hcd.c:978
>>  [] usb_add_hcd+0x8da/0x1c60 drivers/usb/core/hcd.c:2867
>>  [] vhci_hcd_probe+0x97/0x130
>> drivers/usb/usbip/vhci_hcd.c:1103
>>  ---
>>  ---
>> ---[ end trace c33c7b202cf3aac8 ]---
>>
>> Signed-off-by: Shuah Khan <shua...@osg.samsung.com>
>> Reported-by: Andrey Konovalov <andreyk...@google.com>
>
> Here is the fix. Fixed the warning I reproduced on my system.
> Let me know if it works for you.

Hi Shuah,

This fixes the warning I've been seeing.

Thanks!

>
> thanks,
> -- Shuah
>
>> ---
>>  drivers/usb/usbip/vhci_sysfs.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/usb/usbip/vhci_sysfs.c b/drivers/usb/usbip/vhci_sysfs.c
>> index c404017..b96e5b1 100644
>> --- a/drivers/usb/usbip/vhci_sysfs.c
>> +++ b/drivers/usb/usbip/vhci_sysfs.c
>> @@ -361,6 +361,7 @@ static void set_status_attr(int id)
>>   status->attr.attr.name = status->name;
>>   status->attr.attr.mode = S_IRUGO;
>>   status->attr.show = status_show;
>> + sysfs_attr_init(>attr.attr);
>>  }
>>
>>  static int init_status_attrs(void)
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html