Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 14
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 19 10月, 2017 2 次提交
  3. 17 10月, 2017 14 次提交
    • F
      usb: quirks: add quirk for WORLDE MINI MIDI keyboard · 2811501e
      由 Felipe Balbi 提交于 
      This keyboard doesn't implement Get String descriptors properly even
though string indexes are valid. What happens is that when requesting
for the String descriptor, the device disconnects and
reconnects. Without this quirk, this loop will continue forever.

Cc: Alan Stern <stern@rowland.harvard.edu>
Reported-by: NВладимир Мартьянов <vilgeforce@gmail.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2811501e
    • J
      usb: musb: sunxi: Explicitly release USB PHY on exit · 6ed05c68
      由 Jonathan Liu 提交于 
      This fixes a kernel oops when unloading the driver due to usb_put_phy
being called after usb_phy_generic_unregister when the device is
detached. Calling usb_phy_generic_unregister causes x->dev->driver to
be NULL in usb_put_phy and results in a NULL pointer dereference.

Cc: stable@vger.kernel.org # v4.3+
Signed-off-by: NJonathan Liu <net147@gmail.com>
Signed-off-by: NBin Liu <b-liu@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6ed05c68
    • J
      usb: musb: Check for host-mode using is_host_active() on reset interrupt · 445ef615
      由 Jonathan Liu 提交于 
      The sunxi musb has a bug where sometimes it will generate a babble
error on device disconnect instead of a disconnect IRQ. When this
happens the musb controller switches from host mode to device mode
(it clears MUSB_DEVCTL_HM/MUSB_DEVCTL_SESSION and sets
MUSB_DEVCTL_BDEVICE) and gets stuck in this state.

The babble error is misdetected as a bus reset because MUSB_DEVCTL_HM
was cleared.

To fix this, use is_host_active() rather than (devctl & MUSB_DEVCTL_HM)
to detect babble error so that sunxi musb babble recovery can handle it
by restoring the mode. This information is provided by the driver logic
and does not rely on register contents.

Cc: stable@vger.kernel.org # v4.1+
Signed-off-by: NJonathan Liu <net147@gmail.com>
Signed-off-by: NBin Liu <b-liu@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      445ef615
    • A
      usb: musb: musb_cppi41: Configure the number of channels for DA8xx · 297d7fe9
      由 Alexandre Bailon 提交于 
      Currently, the number of channels is set to 15 but in the case of DA8xx,
the number of channels is 4.
Update the driver to configure the number of channels at runtime.

Cc: stable@vger.kernel.org  # v4.12+
Signed-off-by: NAlexandre Bailon <abailon@baylibre.com>
Tested-by: NSekhar Nori <nsekhar@ti.com>
Signed-off-by: NBin Liu <b-liu@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      297d7fe9
    • A
      usb: musb: musb_cppi41: Fix cppi41_set_dma_mode() for DA8xx · e10c5b0c
      由 Alexandre Bailon 提交于 
      The way to configure the DMA mode on DA8xx is different from DSPS.
Add a new function to configure DMA mode on DA8xx and use a callback
to call the right function based on the platform.

Cc: stable@vger.kernel.org  # v4.12+
Signed-off-by: NAlexandre Bailon <abailon@baylibre.com>
Tested-by: NSekhar Nori <nsekhar@ti.com>
Signed-off-by: NBin Liu <b-liu@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e10c5b0c
    • A
      usb: musb: musb_cppi41: Fix the address of teardown and autoreq registers · bfa53e0e
      由 Alexandre Bailon 提交于 
      The DA8xx and DSPS platforms don't use the same address for few registers.
On Da8xx, this is causing some issues (e.g. teardown that doesn't work).
Configure the address of the register during the init and use them instead
of constants.

Cc: stable@vger.kernel.org  # v4.12+
Reported-by: nsekhar@ti.com
Signed-off-by: NAlexandre Bailon <abailon@baylibre.com>
Tested-by: NSekhar Nori <nsekhar@ti.com>
Signed-off-by: NBin Liu <b-liu@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bfa53e0e
    • J
      USB: musb: fix late external abort on suspend · 0c3aae9b
      由 Johan Hovold 提交于 
      The musb delayed irq work was never flushed on suspend, something which
since 4.9 can lead to an external abort if the work is scheduled after
the grandparent's clock has been disabled:

PM: Suspending system (mem)
PM: suspend of devices complete after 125.224 msecs
PM: suspend devices took 0.132 seconds
PM: late suspend of devices complete after 7.423 msecs
PM: noirq suspend of devices complete after 7.083 msecs
suspend debug: Waiting for 5 second(s).
Unhandled fault: external abort on non-linefetch (0x1008) at 0xd0262c60
...
[<c054880c>] (musb_default_readb) from [<c0547b5c>] (musb_irq_work+0x48/0x220)
[<c0547b5c>] (musb_irq_work) from [<c014f8a4>] (process_one_work+0x1f4/0x758)
[<c014f8a4>] (process_one_work) from [<c014fe5c>] (worker_thread+0x54/0x514)
[<c014fe5c>] (worker_thread) from [<c015704c>] (kthread+0x128/0x158)
[<c015704c>] (kthread) from [<c0109330>] (ret_from_fork+0x14/0x24)

Commit 2bff3916 ("usb: musb: Fix PM for hub disconnect") started
scheduling musb_irq_work with a delay of up to a second and with
retries thereby making this easy to trigger, for example, by suspending
shortly after a disconnect.

Note that we set a flag to prevent the irq work from rescheduling itself
during suspend and instead process a disconnect immediately. This takes
care of the case where we are disconnected shortly before suspending.

However, when in host mode, a disconnect while suspended will still
go unnoticed and thus prevent the controller from runtime suspending
upon resume as the session bit is always set. This will need to be
addressed separately.

Fixes: 550a7375 ("USB: Add MUSB and TUSB support")
Fixes: 467d5c98 ("usb: musb: Implement session bit based runtime PM for musb-core")
Fixes: 2bff3916 ("usb: musb: Fix PM for hub disconnect")
Cc: stable <stable@vger.kernel.org>     # 4.9
Cc: Felipe Balbi <felipe.balbi@linux.intel.com>
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: NJohan Hovold <johan@kernel.org>
Tested-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NBin Liu <b-liu@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0c3aae9b
    • J
      USB: musb: fix session-bit runtime-PM quirk · 4f190e0b
      由 Johan Hovold 提交于 
      The current session-bit quirk implementation does not prevent the retry
counter from underflowing, something which could break runtime PM and
keep the device active for a very long time (about 2^32 seconds) after a
disconnect.

This notably breaks the B-device timeout case, but could potentially
cause problems also when the controller is operating as an A-device.

Fixes: 2bff3916 ("usb: musb: Fix PM for hub disconnect")
Cc: stable <stable@vger.kernel.org>     # 4.9
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: NJohan Hovold <johan@kernel.org>
Tested-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NBin Liu <b-liu@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4f190e0b
    • M
      usb: cdc_acm: Add quirk for Elatec TWN3 · 765fb2f1
      由 Maksim Salau 提交于 
      Elatec TWN3 has the union descriptor on data interface. This results in
failure to bind the device to the driver with the following log:
  usb 1-1.2: new full speed USB device using streamplug-ehci and address 4
  usb 1-1.2: New USB device found, idVendor=09d8, idProduct=0320
  usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
  usb 1-1.2: Product: RFID Device (COM)
  usb 1-1.2: Manufacturer: OEM
  cdc_acm 1-1.2:1.0: Zero length descriptor references
  cdc_acm: probe of 1-1.2:1.0 failed with error -22

Adding the NO_UNION_NORMAL quirk for the device fixes the issue.

`lsusb -v` of the device:

Bus 001 Device 003: ID 09d8:0320
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            2 Communications
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0        32
  idVendor           0x09d8
  idProduct          0x0320
  bcdDevice            3.00
  iManufacturer           1 OEM
  iProduct                2 RFID Device (COM)
  iSerial                 0
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           67
    bNumInterfaces          2
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              250mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         2 Communications
      bInterfaceSubClass      2 Abstract (modem)
      bInterfaceProtocol      1 AT-commands (v.25ter)
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0020  1x 32 bytes
        bInterval               2
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass        10 CDC Data
      bInterfaceSubClass      0 Unused
      bInterfaceProtocol      0
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0020  1x 32 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0020  1x 32 bytes
        bInterval               0
      CDC Header:
        bcdCDC               1.10
      CDC Call Management:
        bmCapabilities       0x03
          call management
          use DataInterface
        bDataInterface          1
      CDC ACM:
        bmCapabilities       0x06
          sends break
          line coding and serial state
      CDC Union:
        bMasterInterface        0
        bSlaveInterface         1
Device Status:     0x0000
  (Bus Powered)
Signed-off-by: NMaksim Salau <msalau@iotecha.com>
Acked-by: NOliver Neukum <oneukum@suse.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      765fb2f1
    • H
      USB: devio: Revert "USB: devio: Don't corrupt user memory" · 845d584f
      由 Hans de Goede 提交于 
      Taking the uurb->buffer_length userspace passes in as a maximum for the
actual urbs transfer_buffer_length causes 2 serious issues:

1) It breaks isochronous support for all userspace apps using libusb,
   as existing libusb versions pass in 0 for uurb->buffer_length,
   relying on the kernel using the lenghts of the usbdevfs_iso_packet_desc
   descriptors passed in added together as buffer length.

   This for example causes redirection of USB audio and Webcam's into
   virtual machines using qemu-kvm to no longer work. This is a userspace
   ABI break and as such must be reverted.

   Note that the original commit does not protect other users / the
   kernels memory, it only stops the userspace process making the call
   from shooting itself in the foot.

2) It may cause the kernel to program host controllers to DMA over random
   memory. Just as the devio code used to only look at the iso_packet_desc
   lenghts, the host drivers do the same, relying on the submitter of the
   urbs to make sure the entire buffer is large enough and not checking
   transfer_buffer_length.

   But the "USB: devio: Don't corrupt user memory" commit now takes the
   userspace provided uurb->buffer_length for the buffer-size while copying
   over the user-provided iso_packet_desc lengths 1:1, allowing the user
   to specify a small buffer size while programming the host controller to
   dma a lot more data.

   (Atleast the ohci, uhci, xhci and fhci drivers do not check
    transfer_buffer_length for isoc transfers.)

This reverts commit fa1ed74e ("USB: devio: Don't corrupt user memory")
fixing both these issues.

Cc: Dan Carpenter <dan.carpenter@oracle.com>
Cc: stable@vger.kernel.org
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      845d584f
    • M
      usb: xhci: Handle error condition in xhci_stop_device() · b3207c65
      由 Mayank Rana 提交于 
      xhci_stop_device() calls xhci_queue_stop_endpoint() multiple times
without checking the return value. xhci_queue_stop_endpoint() can
return error if the HC is already halted or unable to queue commands.
This can cause a deadlock condition as xhci_stop_device() would
end up waiting indefinitely for a completion for the command that
didn't get queued. Fix this by checking the return value and bailing
out of xhci_stop_device() in case of error. This patch happens to fix
potential memory leaks of the allocated command structures as well.

Fixes: c311e391 ("xhci: rework command timeout and cancellation,")
Cc: <stable@vger.kernel.org>
Signed-off-by: NMayank Rana <mrana@codeaurora.org>
Signed-off-by: NJack Pham <jackp@codeaurora.org>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b3207c65
    • L
      usb: xhci: Reset halted endpoint if trb is noop · 810a624b
      由 Lu Baolu 提交于 
      When a URB is cancled, xhci driver turns the untransferred trbs
into no-ops.  If an endpoint stalls on a no-op trb that belongs
to the cancelled URB, the event handler won't reset the endpoint.
Hence, it will stay halted.

Link: http://marc.info/?l=linux-usb&m=149582598330127&w=2

Cc: <stable@vger.kernel.org>
Signed-off-by: NLu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      810a624b
    • J
      xhci: Cleanup current_cmd in xhci_cleanup_command_queue() · d1aad52c
      由 Jeffy Chen 提交于 
      KASAN reported use-after-free bug when xhci host controller died:
[  176.952537] BUG: KASAN: use-after-free in xhci_handle_command_timeout+0x68/0x224
[  176.960846] Write of size 4 at addr ffffffc0cbb01608 by task kworker/3:3/1680
...
[  177.180644] Freed by task 0:
[  177.183882]  kasan_slab_free+0x90/0x15c
[  177.188194]  kfree+0x114/0x28c
[  177.191630]  xhci_cleanup_command_queue+0xc8/0xf8
[  177.196916]  xhci_hc_died+0x84/0x358

Problem here is that when the cmd_timer fired, it would try to access
current_cmd while the command queue is already freed by xhci_hc_died().

Cleanup current_cmd in xhci_cleanup_command_queue() to avoid that.

Fixes: d9f11ba9 ("xhci: Rework how we handle unresponsive or hoptlug removed hosts")
Cc: <stable@vger.kernel.org> # v4.12+
Signed-off-by: NJeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d1aad52c
    • M
      xhci: Identify USB 3.1 capable hosts by their port protocol capability · ea7d0d69
      由 Mathias Nyman 提交于 
      Many USB 3.1 capable hosts never updated the Serial Bus Release Number
(SBRN) register to USB 3.1 from USB 3.0

xhci driver identified USB 3.1 capable hosts based on this SBRN register,
which according to specs "contains the release of the Universal Serial
Bus Specification with which this Universal Serial Bus Host Controller
module is compliant." but still in october 2017 gives USB 3.0 as
the only possible option.

Make an additional check for USB 3.1 support and enable it if the xHCI
supported protocol capablity lists USB 3.1 capable ports.

Cc: <stable@vger.kernel.org> # v4.6+
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ea7d0d69
  5. 16 10月, 2017 1 次提交
  7. 14 10月, 2017 2 次提交
    • J
      tty: fall back to N_NULL if switching to N_TTY fails during hangup · e65c62b1
      由 Johannes Weiner 提交于 
      We have seen NULL-pointer dereference crashes in tty->disc_data when the
N_TTY fallback driver failed to open during hangup.  The immediate cause
of this open to fail has been addressed in the preceding patch to
vmalloc(), but this code could be more robust.

As Alan pointed out in commit 8a8dabf2 ("tty: handle the case where
we cannot restore a line discipline"), the N_TTY driver, historically
the safe fallback that could never fail, can indeed fail, but the
surrounding code is not prepared to handle this.  To avoid crashes he
added a new N_NULL driver to take N_TTY's place as the last resort.

Hook that fallback up to the hangup path.  Update tty_ldisc_reinit() to
reflect the reality that n_tty_open can indeed fail.

Link: http://lkml.kernel.org/r/20171004185959.GC2136@cmpxchg.orgSigned-off-by: NJohannes Weiner <hannes@cmpxchg.org>
Cc: Alan Cox <alan@llwyncelyn.cymru>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Michal Hocko <mhocko@suse.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e65c62b1
    • Z
      mm: only display online cpus of the numa node · 064f0e93
      由 Zhen Lei 提交于 
      When I execute numactl -H (which reads /sys/devices/system/node/nodeX/cpumap
and displays cpumask_of_node for each node), I get different result
on X86 and arm64.  For each numa node, the former only displayed online
CPUs, and the latter displayed all possible CPUs.  Unfortunately, both
Linux documentation and numactl manual have not described it clear.

I sent a mail to ask for help, and Michal Hocko replied that he
preferred to print online cpus because it doesn't really make much sense
to bind anything on offline nodes.

Will said:
 "I suspect the vast majority (if not all) code that reads this file was
  developed for x86, so having the same behaviour for arm64 sounds like
  something we should do ASAP before people try to special case with
  things like #ifdef __aarch64__. I'd rather have this in 4.14 if
  possible."

Link: http://lkml.kernel.org/r/1506678805-15392-2-git-send-email-thunder.leizhen@huawei.comSigned-off-by: NZhen Lei <thunder.leizhen@huawei.com>
Acked-by: NMichal Hocko <mhocko@suse.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Tianhong Ding <dingtianhong@huawei.com>
Cc: Hanjun Guo <guohanjun@huawei.com>
Cc: Libin <huawei.libin@huawei.com>
Cc: Kefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      064f0e93
  9. 13 10月, 2017 8 次提交
  11. 12 10月, 2017 9 次提交
  13. 11 10月, 2017 4 次提交
    • A
      HID: hid-elecom: extend to fix descriptor for HUGE trackball · a0933a45
      由 Alex Manoussakis 提交于 
      In addition to DEFT, Elecom introduced a larger trackball called HUGE, in
both wired (M-HT1URBK) and wireless (M-HT1DRBK) versions. It has the same
buttons and behavior as the DEFT. This patch adds the two relevant USB IDs
to enable operation of the three Fn buttons on the top of the device.

Cc: Diego Elio Petteno <flameeyes@flameeyes.eu>
Signed-off-by: NAlex Manoussakis <amanou@gnu.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      a0933a45
    • J
      HID: usbhid: fix out-of-bounds bug · f043bfc9
      由 Jaejoong Kim 提交于 
      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 ffff88006c5f8edf by task kworker/1:2/1261

	CPU: 1 PID: 1261 Comm: kworker/1:2 Not tainted
	4.14.0-rc1-42251-gebb2c243 #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

Cc: stable@vger.kernel.org
Reported-by: NAndrey Konovalov <andreyknvl@google.com>
Signed-off-by: NJaejoong Kim <climbbb.kim@gmail.com>
Tested-by: NAndrey Konovalov <andreyknvl@google.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      f043bfc9
    • A
      usb: usbtest: fix NULL pointer dereference · 7c80f9e4
      由 Alan Stern 提交于 
      If the usbtest driver encounters a device with an IN bulk endpoint but
no OUT bulk endpoint, it will try to dereference a NULL pointer
(out->desc.bEndpointAddress).  The problem can be solved by adding a
missing test.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Reported-by: NAndrey Konovalov <andreyknvl@google.com>
Tested-by: NAndrey Konovalov <andreyknvl@google.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
      7c80f9e4
    • A
      usb: gadget: configfs: Fix memory leak of interface directory data · ff74745e
      由 Andrew Gabbasov 提交于 
      Kmemleak checking configuration reports a memory leak in
usb_os_desc_prepare_interf_dir function when rndis function
instance is freed and then allocated again. For example, this
happens with FunctionFS driver with RNDIS function enabled
when "ffs-test" test application is run several times in a row.

The data for intermediate "os_desc" group for interface directories
is allocated as a single VLA chunk and (after a change of default
groups handling) is not ever freed and actually not stored anywhere
besides inside a list of default groups of a parent group.

The fix is to make usb_os_desc_prepare_interf_dir function return
a pointer to allocated data (as a pointer to the first VLA item)
instead of (an unused) integer and to make the caller component
(currently the only one is RNDIS function) responsible for storing
the pointer and freeing the memory when appropriate.

Fixes: 1ae1602d ("configfs: switch ->default groups to a linked list")
Cc: stable@vger.kernel.org
Signed-off-by: NAndrew Gabbasov <andrew_gabbasov@mentor.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
      ff74745e