linux-stable.git/drivers, branch v3.2.98

USB: core: prevent malicious bNumInterfaces overflow

2018-01-01T20:51:04+00:00

commit 48a4ff1c7bb5a32d2e396b03132d20d552c0eca7 upstream.

A malicious USB device with crafted descriptors can cause the kernel
to access unallocated memory by setting the bNumInterfaces value too
high in a configuration descriptor.  Although the value is adjusted
during parsing, this adjustment is skipped in one of the error return
paths.

This patch prevents the problem by setting bNumInterfaces to 0
initially.  The existing code already sets it to the proper value
after parsing is complete.

Signed-off-by: Alan Stern 
Reported-by: Andrey Konovalov 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings

tun/tap: sanitize TUNSETSNDBUF input

2018-01-01T20:51:00+00:00

commit 93161922c658c714715686cd0cf69b090cb9bf1d upstream.

Syzkaller found several variants of the lockup below by setting negative
values with the TUNSETSNDBUF ioctl.  This patch adds a sanity check
to both the tun and tap versions of this ioctl.

  watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [repro:2389]
  Modules linked in:
  irq event stamp: 329692056
  hardirqs last  enabled at (329692055): [] _raw_spin_unlock_irqrestore+0x31/0x75
  hardirqs last disabled at (329692056): [] apic_timer_interrupt+0x98/0xb0
  softirqs last  enabled at (35659740): [] __do_softirq+0x328/0x48c
  softirqs last disabled at (35659731): [] irq_exit+0xbc/0xd0
  CPU: 0 PID: 2389 Comm: repro Not tainted 4.14.0-rc7 #23
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
  task: ffff880009452140 task.stack: ffff880006a20000
  RIP: 0010:_raw_spin_lock_irqsave+0x11/0x80
  RSP: 0018:ffff880006a27c50 EFLAGS: 00000282 ORIG_RAX: ffffffffffffff10
  RAX: ffff880009ac68d0 RBX: ffff880006a27ce0 RCX: 0000000000000000
  RDX: 0000000000000001 RSI: ffff880006a27ce0 RDI: ffff880009ac6900
  RBP: ffff880006a27c60 R08: 0000000000000000 R09: 0000000000000000
  R10: 0000000000000001 R11: 000000000063ff00 R12: ffff880009ac6900
  R13: ffff880006a27cf8 R14: 0000000000000001 R15: ffff880006a27cf8
  FS:  00007f4be4838700(0000) GS:ffff88000cc00000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 0000000020101000 CR3: 0000000009616000 CR4: 00000000000006f0
  Call Trace:
   prepare_to_wait+0x26/0xc0
   sock_alloc_send_pskb+0x14e/0x270
   ? remove_wait_queue+0x60/0x60
   tun_get_user+0x2cc/0x19d0
   ? __tun_get+0x60/0x1b0
   tun_chr_write_iter+0x57/0x86
   __vfs_write+0x156/0x1e0
   vfs_write+0xf7/0x230
   SyS_write+0x57/0xd0
   entry_SYSCALL_64_fastpath+0x1f/0xbe
  RIP: 0033:0x7f4be4356df9
  RSP: 002b:00007ffc18101c08 EFLAGS: 00000293 ORIG_RAX: 0000000000000001
  RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f4be4356df9
  RDX: 0000000000000046 RSI: 0000000020101000 RDI: 0000000000000005
  RBP: 00007ffc18101c40 R08: 0000000000000001 R09: 0000000000000001
  R10: 0000000000000001 R11: 0000000000000293 R12: 0000559c75f64780
  R13: 00007ffc18101d30 R14: 0000000000000000 R15: 0000000000000000

Fixes: 33dccbb050bb ("tun: Limit amount of queued packets per device")
Fixes: 20d29d7a916a ("net: macvtap driver")
Signed-off-by: Craig Gallek 
Reviewed-by: Eric Dumazet 
Signed-off-by: David S. Miller 
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings

macvtap: fix TUNSETSNDBUF values > 64k

2018-01-01T20:51:00+00:00

commit 3ea79249e81e5ed051f2e6480cbde896d99046e8 upstream.

Upon TUNSETSNDBUF,  macvtap reads the requested sndbuf size into
a local variable u.
commit 39ec7de7092b ("macvtap: fix uninitialized access on
TUNSETIFF") changed its type to u16 (which is the right thing to
do for all other macvtap ioctls), breaking all values > 64k.

The value of TUNSETSNDBUF is actually a signed 32 bit integer, so
the right thing to do is to read it into an int.

Cc: David S. Miller 
Fixes: 39ec7de7092b ("macvtap: fix uninitialized access on TUNSETIFF")
Reported-by: Mark A. Peloquin
Bisected-by: Matthew Rosato 
Reported-by: Christian Borntraeger 
Signed-off-by: Michael S. Tsirkin 
Tested-by:  Matthew Rosato 
Acked-by: Christian Borntraeger 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings

can: esd_usb2: Fix can_dlc value for received RTR, frames

2018-01-01T20:50:59+00:00

commit 72d92e865d1560723e1957ee3f393688c49ca5bf upstream.

The dlc member of the struct rx_msg contains also the ESD_RTR flag to
mark received RTR frames. Without the fix the can_dlc value for received
RTR frames would always be set to 8 by get_can_dlc() instead of the
received value.

Fixes: 96d8e90382dc ("can: Add driver for esd CAN-USB/2 device")
Signed-off-by: Stefan Mätje 
Signed-off-by: Marc Kleine-Budde 
Signed-off-by: Ben Hutchings

usb: quirks: add quirk for WORLDE MINI MIDI keyboard

2018-01-01T20:50:59+00:00

commit 2811501e6d8f5747d08f8e25b9ecf472d0dc4c7d upstream.

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 
Reported-by: Владимир Мартьянов 
Signed-off-by: Felipe Balbi 
Signed-off-by: Greg Kroah-Hartman 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

usb: cdc_acm: Add quirk for Elatec TWN3

2018-01-01T20:50:59+00:00

commit 765fb2f181cad669f2beb87842a05d8071f2be85 upstream.

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: Maksim Salau 
Acked-by: Oliver Neukum 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings

scsi: zfcp: fix erp_action use-before-initialize in REC action trace

2018-01-01T20:50:58+00:00

commit ab31fd0ce65ec93828b617123792c1bb7c6dcc42 upstream.

v4.10 commit 6f2ce1c6af37 ("scsi: zfcp: fix rport unblock race with LUN
recovery") extended accessing parent pointer fields of struct
zfcp_erp_action for tracing.  If an erp_action has never been enqueued
before, these parent pointer fields are uninitialized and NULL. Examples
are zfcp objects freshly added to the parent object's children list,
before enqueueing their first recovery subsequently. In
zfcp_erp_try_rport_unblock(), we iterate such list. Accessing erp_action
fields can cause a NULL pointer dereference.  Since the kernel can read
from lowcore on s390, it does not immediately cause a kernel page
fault. Instead it can cause hangs on trying to acquire the wrong
erp_action->adapter->dbf->rec_lock in zfcp_dbf_rec_action_lvl()
                      ^bogus^
while holding already other locks with IRQs disabled.

Real life example from attaching lots of LUNs in parallel on many CPUs:

crash> bt 17723
PID: 17723  TASK: ...               CPU: 25  COMMAND: "zfcperp0.0.1800"
 LOWCORE INFO:
  -psw      : 0x0404300180000000 0x000000000038e424
  -function : _raw_spin_lock_wait_flags at 38e424
...
 #0 [fdde8fc90] zfcp_dbf_rec_action_lvl at 3e0004e9862 [zfcp]
 #1 [fdde8fce8] zfcp_erp_try_rport_unblock at 3e0004dfddc [zfcp]
 #2 [fdde8fd38] zfcp_erp_strategy at 3e0004e0234 [zfcp]
 #3 [fdde8fda8] zfcp_erp_thread at 3e0004e0a12 [zfcp]
 #4 [fdde8fe60] kthread at 173550
 #5 [fdde8feb8] kernel_thread_starter at 10add2

zfcp_adapter
 zfcp_port
  zfcp_unit , 0x404040d600000000
  scsi_device NULL, returning early!
zfcp_scsi_dev.status = 0x40000000
0x40000000 ZFCP_STATUS_COMMON_RUNNING

crash> zfcp_unit 
struct zfcp_unit {
  erp_action = {
    adapter = 0x0,
    port = 0x0,
    unit = 0x0,
  },
}

zfcp_erp_action is always fully embedded into its container object. Such
container object is never moved in its object tree (only add or delete).
Hence, erp_action parent pointers can never change.

To fix the issue, initialize the erp_action parent pointers before
adding the erp_action container to any list and thus before it becomes
accessible from outside of its initializing function.

In order to also close the time window between zfcp_erp_setup_act()
memsetting the entire erp_action to zero and setting the parent pointers
again, drop the memset and instead explicitly initialize individually
all erp_action fields except for parent pointers. To be extra careful
not to introduce any other unintended side effect, even keep zeroing the
erp_action fields for list and timer. Also double-check with
WARN_ON_ONCE that erp_action parent pointers never change, so we get to
know when we would deviate from previous behavior.

Signed-off-by: Steffen Maier 
Fixes: 6f2ce1c6af37 ("scsi: zfcp: fix rport unblock race with LUN recovery")
Reviewed-by: Benjamin Block 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Ben Hutchings

iommu/amd: Finish TLB flush in amd_iommu_unmap()

2018-01-01T20:50:58+00:00

commit ce76353f169a6471542d999baf3d29b121dce9c0 upstream.

The function only sends the flush command to the IOMMU(s),
but does not wait for its completion when it returns. Fix
that.

Fixes: 601367d76bd1 ('x86/amd-iommu: Remove iommu_flush_domain function')
Signed-off-by: Joerg Roedel 
Signed-off-by: Ben Hutchings

scsi: libiscsi: fix shifting of DID_REQUEUE host byte

2018-01-01T20:50:57+00:00

commit eef9ffdf9cd39b2986367bc8395e2772bc1284ba upstream.

The SCSI host byte should be shifted left by 16 in order to have
scsi_decide_disposition() do the right thing (.i.e. requeue the
command).

Signed-off-by: Johannes Thumshirn 
Fixes: 661134ad3765 ("[SCSI] libiscsi, bnx2i: make bound ep check common")
Cc: Lee Duncan 
Cc: Hannes Reinecke 
Cc: Bart Van Assche 
Cc: Chris Leech 
Acked-by: Lee Duncan 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Ben Hutchings

usb: renesas_usbhs: Fix DMAC sequence for receiving zero-length packet

2018-01-01T20:50:57+00:00

commit 29c7f3e68eec4ae94d85ad7b5dfdafdb8089f513 upstream.

The DREQE bit of the DnFIFOSEL should be set to 1 after the DE bit of
USB-DMAC on R-Car SoCs is set to 1 after the USB-DMAC received a
zero-length packet. Otherwise, a transfer completion interruption
of USB-DMAC doesn't happen. Even if the driver changes the sequence,
normal operations (transmit/receive without zero-length packet) will
not cause any side-effects. So, this patch fixes the sequence anyway.

Signed-off-by: Kazuya Mizuguchi 
[shimoda: revise the commit log]
Fixes: e73a9891b3a1 ("usb: renesas_usbhs: add DMAEngine support")
Signed-off-by: Yoshihiro Shimoda 
Signed-off-by: Felipe Balbi 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings