commit 030ee7ae upstream.

The modem-control signals are managed by the tty-layer during open and
should not be asserted prematurely when set_termios is called from
driver open.

Also make sure that the signals are asserted only when changing speed
from B0.

Fixes: 664d5df9 ("USB: usb-serial ch341: support for DTR/RTS/CTS")
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit a20047f3 upstream.

The private baud_rate variable is used to configure the port at open and
reset-resume and must never be set to (and left at) zero or reset-resume
and all further open attempts will fail.

Fixes: aa91def4 ("USB: ch341: set tty baud speed according to tty
struct")
Fixes: 664d5df9 ("USB: usb-serial ch341: support for DTR/RTS/CTS")
Signed-off-by: Johan Hovold <johan@kernel.org>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 4e2da446 upstream.

DTR and RTS will be asserted by the tty-layer when the port is opened
and deasserted on close (if HUPCL is set). Make sure the initial state
is not-asserted before the port is first opened as well.

Fixes: 664d5df9 ("USB: usb-serial ch341: support for DTR/RTS/CTS")
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 4e46c410 upstream.

Changing the LCR register after initialization does not seem to be reliable
on all chips (particularly not on CH341A). Restructure initialization and
configuration to always reinit the chip on configuration changes instead and
pass the LCR register value directly to the initialization command.

(Note that baud rates above 500kbaud are incorrect, but they're incorrect in
the same way both before and after this patch at least on the CH340G. Fixing
this isn't a priority as higher baud rates don't seem that reliable anyway.)

Cleaned-up version of a patch by Grigori Goronzy
Signed-off-by: Aidan Thornton <makosoft@gmail.com>
Reviewed-by: Grigori Goronzy <greg@chown.ath.cx>
Signed-off-by: Johan Hovold <johan@kernel.org>
[bwh: Backported to 3.2: tty_struct::termios is a pointer, not a struct]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 6fde8d29 upstream.

No functional changes, this just gives names to some registers and USB
requests based on Grigori Goronzy's work and WinChipTech's Linux driver
(which reassuringly agree), then uses them in place of magic numbers.
This also renames the misnamed BREAK2 register (actually UART config)
Signed-off-by: Aidan Thornton <makosoft@gmail.com>
Reviewed-by: Grigori Goronzy <greg@chown.ath.cx>
Signed-off-by: Johan Hovold <johan@kernel.org>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit aa91def4 upstream.

The ch341_set_baudrate() function initialize the device baud speed
according to the value on priv->baud_rate. By default the ch341_open() set
it to a hardcoded value (DEFAULT_BAUD_RATE 9600). Unfortunately, the
tty_struct is not initialized with the same default value. (usually 56700)

This means that the tty_struct and the device baud rate generator are not
synchronized after opening the port.

Fixup is done by calling ch341_set_termios() if tty exist.
Remove unnecessary variable priv->baud_rate setup as it's already done by
ch341_port_probe().
Remove unnecessary call to ch341_set_{handshake,baudrate}() in
ch341_open() as there already called in ch341_configure() and
ch341_set_termios()
Signed-off-by: Nicolas PLANEL <nicolas.planel@enovance.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 394a1033 upstream.

Remove redundant call to ch341_close from error path when submission of
the interrupt urb fails in open.
Signed-off-by: Johan Hovold <johan@kernel.org>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 06946a66 upstream.

All error messages from stack in open are being forwarded except for
one call to usb_submit_urb. Change this for consistency.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 064c3db9 upstream.

Here, If devm_ioremap will fail. It will return NULL.
Then hpriv->base = NULL - 0x20000; Kernel can run into
a NULL-pointer dereference. This error check will avoid
NULL pointer dereference.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 1ebb7114 upstream.

Make sure we have enough of a report structure to validate before
looking at it.
Reported-by: Benoit Camredon <benoit.camredon@airbus.com>
Tested-by: Benoit Camredon <benoit.camredon@airbus.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 0a8fd134 upstream.

When checking a new device's descriptors, the USB core does not check
for duplicate endpoint addresses.  This can cause a problem when the
sysfs files for those endpoints are created; trying to create multiple
files with the same name will provoke a WARNING:

WARNING: CPU: 2 PID: 865 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x8a/0xa0
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
 ffff88006bee64c8 ffffffff81f96b8a ffffffff00000001 1ffff1000d7dcc2c
 ffffed000d7dcc24 0000000000000001 0000000041b58ab3 ffffffff8598b510
 ffffffff81f968f8 ffffffff850fee20 ffffffff85cff020 dffffc0000000000
Call Trace:
 [<     inline     >] __dump_stack lib/dump_stack.c:15
 [<ffffffff81f96b8a>] dump_stack+0x292/0x398 lib/dump_stack.c:51
 [<ffffffff8168c88e>] panic+0x1cb/0x3a9 kernel/panic.c:179
 [<ffffffff812b80b4>] __warn+0x1c4/0x1e0 kernel/panic.c:542
 [<ffffffff812b8195>] warn_slowpath_fmt+0xc5/0x110 kernel/panic.c:565
 [<ffffffff819e70ca>] sysfs_warn_dup+0x8a/0xa0 fs/sysfs/dir.c:30
 [<ffffffff819e7308>] sysfs_create_dir_ns+0x178/0x1d0 fs/sysfs/dir.c:59
 [<     inline     >] create_dir lib/kobject.c:71
 [<ffffffff81fa1b07>] kobject_add_internal+0x227/0xa60 lib/kobject.c:229
 [<     inline     >] kobject_add_varg lib/kobject.c:366
 [<ffffffff81fa2479>] kobject_add+0x139/0x220 lib/kobject.c:411
 [<ffffffff82737a63>] device_add+0x353/0x1660 drivers/base/core.c:1088
 [<ffffffff82738d8d>] device_register+0x1d/0x20 drivers/base/core.c:1206
 [<ffffffff82cb77d3>] usb_create_ep_devs+0x163/0x260 drivers/usb/core/endpoint.c:195
 [<ffffffff82c9f27b>] create_intf_ep_devs+0x13b/0x200 drivers/usb/core/message.c:1030
 [<ffffffff82ca39d3>] usb_set_configuration+0x1083/0x18d0 drivers/usb/core/message.c:1937
 [<ffffffff82cc9e2e>] generic_probe+0x6e/0xe0 drivers/usb/core/generic.c:172
 [<ffffffff82caa7fa>] usb_probe_device+0xaa/0xe0 drivers/usb/core/driver.c:263

This patch prevents the problem by checking for duplicate endpoint
addresses during enumeration and skipping any duplicates.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: Andrey Konovalov <andreyknvl@google.com>
Tested-by: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 8c300fe2 upstream.

When unloading omap2430, we can get the following splat:

WARNING: CPU: 1 PID: 295 at kernel/irq/manage.c:1478 __free_irq+0xa8/0x2c8
Trying to free already-free IRQ 4
...
[<c01a8b78>] (free_irq) from [<bf0aea84>]
(musbhs_dma_controller_destroy+0x28/0xb0 [musb_hdrc])
[<bf0aea84>] (musbhs_dma_controller_destroy [musb_hdrc]) from
[<bf09f88c>] (musb_remove+0xf0/0x12c [musb_hdrc])
[<bf09f88c>] (musb_remove [musb_hdrc]) from [<c056a384>]
(platform_drv_remove+0x24/0x3c)
...

This is because the irq number in use is 260 nowadays, and the dma
controller is using u8 instead of int.

Fixes: 6995eb68 ("USB: musb: enable low level DMA operation for Blackfin")
Signed-off-by: Tony Lindgren <tony@atomide.com>
[b-liu@ti.com: added Fixes tag]
Signed-off-by: Bin Liu <b-liu@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit dd853fd2 upstream.

A negative number can be specified in the cmdline which will be used as
setup_clear_cpu_cap() argument. With that we can clear/set some bit in
memory predceeding boot_cpu_data/cpu_caps_cleared which may cause kernel
to misbehave. This patch adds lower bound check to setup_disablecpuid().

Boris Petkov reproduced a crash:

  [    1.234575] BUG: unable to handle kernel paging request at ffffffff858bd540
  [    1.236535] IP: memcpy_erms+0x6/0x10
Signed-off-by: Lukasz Odzioba <lukasz.odzioba@intel.com>
Acked-by: Borislav Petkov <bp@suse.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: andi.kleen@intel.com
Cc: bp@alien8.de
Cc: dave.hansen@linux.intel.com
Cc: luto@kernel.org
Cc: slaoub@gmail.com
Fixes: ac72e788 ("x86: add generic clearcpuid=... option")
Link: http://lkml.kernel.org/r/1482933340-11857-1-git-send-email-lukasz.odzioba@intel.comSigned-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 432abf68 upstream.

The generic command buffer entry is 128 bits (16 bytes), so the offset
of tail and head pointer should be 16 bytes aligned and increased with
0x10 per command.

When cmd buf is full, head = (tail + 0x10) % CMD_BUFFER_SIZE.

So when left space of cmd buf should be able to store only two
command, we should be issued one COMPLETE_WAIT additionally to wait
all older commands completed. Then the left space should be increased
after IOMMU fetching from cmd buf.

So left check value should be left <= 0x20 (two commands).
Signed-off-by: Huang Rui <ray.huang@amd.com>
Fixes: ac0ea6e9 ('x86/amd-iommu: Improve handling of full command buffer')
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit ef079936 upstream.

Fix NULL-pointer dereference in open() should a malicious device lack
the expected endpoints:

Unable to handle kernel NULL pointer dereference at virtual address 00000030
..
[<bf06a6b0>] (ti_open [ti_usb_3410_5052]) from [<bf02e118>] (serial_port_activate+0x68/0x98 [usbserial])

Fixes: 1da177e4 ("Linux-2.6.12-rc2")
Signed-off-by: Johan Hovold <johan@kernel.org>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit cc090924 upstream.

Fix NULL-pointer dereference in open() should the device lack the
expected endpoints:

Unable to handle kernel NULL pointer dereference at virtual address 00000030
...
PC is at spcp8x5_open+0x30/0xd0 [spcp8x5]

Fixes: 619a6f1d ("USB: add usb-serial spcp8x5 driver")
Signed-off-by: Johan Hovold <johan@kernel.org>
[bwh: Backported to 3.2: add this check to the existing
 usb_serial_driver::attach implementation]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 76ab439e upstream.

Fix NULL-pointer dereference in open() should a type-0 or type-1 device
lack the expected endpoints:

Unable to handle kernel NULL pointer dereference at virtual address 00000030
...
PC is at pl2303_open+0x38/0xec [pl2303]

Note that a missing interrupt-in endpoint would have caused open() to
fail.

Fixes: 1da177e4 ("Linux-2.6.12-rc2")
Signed-off-by: Johan Hovold <johan@kernel.org>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 5afeef23 upstream.

Fix NULL-pointer dereference in open() should the device lack the
expected endpoints:

Unable to handle kernel NULL pointer dereference at virtual address 00000030
...
PC is at oti6858_open+0x30/0x1d0 [oti6858]

Note that a missing interrupt-in endpoint would have caused open() to
fail.

Fixes: 49cdee0e ("USB: oti6858 usb-serial driver (in Nokia CA-42
cable)")
Signed-off-by: Johan Hovold <johan@kernel.org>
[bwh: Backported to 3.2: add this check to the existing
 usb_serial_driver::attach implementation]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit a5bc0194 upstream.

Fix NULL-pointer dereferences at open() and disconnect() should the
device lack the expected bulk-out endpoints:

Unable to handle kernel NULL pointer dereference at virtual address 000000b4
...
[c0170ff0>] (__lock_acquire) from [<c0172f00>] (lock_acquire+0x108/0x264)
[<c0172f00>] (lock_acquire) from [<c06a5090>] (_raw_spin_lock_irqsave+0x58/0x6c)
[<c06a5090>] (_raw_spin_lock_irqsave) from [<c0470684>] (tty_port_tty_set+0x28/0xa4)
[<c0470684>] (tty_port_tty_set) from [<bf08d384>] (omninet_open+0x30/0x40 [omninet])
[<bf08d384>] (omninet_open [omninet]) from [<bf07c118>] (serial_port_activate+0x68/0x98 [usbserial])

Unable to handle kernel NULL pointer dereference at virtual address 00000234
...
[<bf01f418>] (omninet_disconnect [omninet]) from [<bf0016c0>] (usb_serial_disconnect+0xe4/0x100 [usbserial])

Fixes: 1da177e4 ("Linux-2.6.12-rc2")
Signed-off-by: Johan Hovold <johan@kernel.org>
[bwh: Backported to 3.2: add this check to the existing
 usb_serial_driver::attach implementation]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 472d7e55 upstream.

The interrupt URB is killed at final port close since commit
0de9a702 ("USB: overhaul of mos7840 driver").

Fixes: 0de9a702 ("USB: overhaul of mos7840 driver")
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 5c75633e upstream.

Fix NULL-pointer dereference in open() should the device lack the
expected endpoints:

Unable to handle kernel NULL pointer dereference at virtual address 00000030
...
PC is at mos7840_open+0x88/0x8dc [mos7840]

Note that we continue to treat the interrupt-in endpoint as optional for
now.

Fixes: 3f542974 ("USB: Moschip 7840 USB-Serial Driver")
Signed-off-by: Johan Hovold <johan@kernel.org>
[bwh: Backported to 3.2: add this check to the existing
 usb_serial_driver::attach implementation]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit fde1faf8 upstream.

A static usb-serial-driver structure that is used to initialise the
interrupt URB was modified during probe depending on the currently
probed device type, something which could break a parallel probe of a
device of a different type.

Fix this up by overriding the default completion callback for MCS7715
devices in attach() instead. We may want to use two usb-serial driver
instances for the two types later.

Fixes: fb088e33 ("USB: serial: add support for serial port on the
moschip 7715")
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 75dd211e upstream.

Do not submit the interrupt URB until after the parport has been
successfully registered to avoid another use-after-free in the
completion handler when accessing the freed parport private data in case
of a racing completion.

Fixes: b69578df ("USB: usbserial: mos7720: add support for parallel
port on moschip 7715")
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 91a1ff4d upstream.

The interrupt URB was submitted on probe but never stopped on probe
errors. This can lead to use-after-free issues in the completion
handler when accessing the freed usb-serial struct:

Unable to handle kernel paging request at virtual address 6b6b6be7
...
[<bf052e70>] (mos7715_interrupt_callback [mos7720]) from [<c052a894>] (__usb_hcd_giveback_urb+0x80/0x140)
[<c052a894>] (__usb_hcd_giveback_urb) from [<c052a9a4>] (usb_hcd_giveback_urb+0x50/0x138)
[<c052a9a4>] (usb_hcd_giveback_urb) from [<c0550684>] (musb_giveback+0xc8/0x1cc)

Fixes: b69578df ("USB: usbserial: mos7720: add support for parallel
port on moschip 7715")
Signed-off-by: Johan Hovold <johan@kernel.org>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit b05aebc2 upstream.

Fix NULL-pointer dereference at port open if a device lacks the expected
bulk in and out endpoints.

Unable to handle kernel NULL pointer dereference at virtual address 00000030
...
[<bf071c20>] (mos7720_open [mos7720]) from [<bf0490e0>] (serial_port_activate+0x68/0x98 [usbserial])
[<bf0490e0>] (serial_port_activate [usbserial]) from [<c0470ca4>] (tty_port_open+0x9c/0xe8)
[<c0470ca4>] (tty_port_open) from [<bf049d98>] (serial_open+0x48/0x6c [usbserial])
[<bf049d98>] (serial_open [usbserial]) from [<c0469178>] (tty_open+0xcc/0x5cc)

Fixes: 0f64478c ("USB: add USB serial mos7720 driver")
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 21ce5784 upstream.

Fix NULL-pointer dereference in write() should the device lack the
expected interrupt-out endpoint:

Unable to handle kernel NULL pointer dereference at virtual address 00000054
...
PC is at kobil_write+0x144/0x2a0 [kobil_sct]

Fixes: 1da177e4 ("Linux-2.6.12-rc2")
Signed-off-by: Johan Hovold <johan@kernel.org>
[bwh: Backported to 3.2: add this check to the existing
 usb_serial_driver::attach implementation]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 5d9b0f85 upstream.

Check for the expected endpoints in attach() and fail loudly if not
present.

Note that failing to do this appears to be benign since da280e34
("USB: keyspan_pda: clean up write-urb busy handling") which prevents a
NULL-pointer dereference in write() by never marking a non-existent
write-urb as free.

Fixes: 1da177e4 ("Linux-2.6.12-rc2")
Signed-off-by: Johan Hovold <johan@kernel.org>
[bwh: Backported to 3.2: add this check to the existing
 usb_serial_driver::attach implementation]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 90507d54 upstream.

Fix NULL-pointer dereference at open should the device lack a bulk-in or
bulk-out endpoint:

Unable to handle kernel NULL pointer dereference at virtual address 00000030
...
PC is at iuu_open+0x78/0x59c [iuu_phoenix]

Fixes: 07c3b1a1 ("USB: remove broken usb-serial num_endpoints
check")
Signed-off-by: Johan Hovold <johan@kernel.org>
[bwh: Backported to 3.2: add this check to the existing
 usb_serial_driver::attach implementation]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 4f9785cc upstream.

In case a device is left in "boot-mode" we must not register any port
devices in order to avoid a NULL-pointer dereference on open due to
missing endpoints. This could be used by a malicious device to trigger
an OOPS:

Unable to handle kernel NULL pointer dereference at virtual address 00000030
...
[<bf0caa84>] (edge_open [io_ti]) from [<bf0b0118>] (serial_port_activate+0x68/0x98 [usbserial])
[<bf0b0118>] (serial_port_activate [usbserial]) from [<c0470ca4>] (tty_port_open+0x9c/0xe8)
[<c0470ca4>] (tty_port_open) from [<bf0b0da0>] (serial_open+0x48/0x6c [usbserial])
[<bf0b0da0>] (serial_open [usbserial]) from [<c0469178>] (tty_open+0xcc/0x5cc)

Fixes: 1da177e4 ("Linux-2.6.12-rc2")
Signed-off-by: Johan Hovold <johan@kernel.org>
[bwh: Backported to 3.2:
 - No heartbeat_work to initialise earlier
 - No separate port_probe and port_remove operations, so add check for null
   port pointers in edge_release()
 - Adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit a323fefc upstream.

Fix NULL-pointer dereference when clearing halt at open should a
malicious device lack the expected endpoints when in download mode.

Unable to handle kernel NULL pointer dereference at virtual address 00000030
...
[<bf011ed8>] (edge_open [io_ti]) from [<bf000118>] (serial_port_activate+0x68/0x98 [usbserial])
[<bf000118>] (serial_port_activate [usbserial]) from [<c0470ca4>] (tty_port_open+0x9c/0xe8)
[<c0470ca4>] (tty_port_open) from [<bf000da0>] (serial_open+0x48/0x6c [usbserial])
[<bf000da0>] (serial_open [usbserial]) from [<c0469178>] (tty_open+0xcc/0x5cc)

Fixes: 1da177e4 ("Linux-2.6.12-rc2")
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 0dd40842 upstream.

Fix NULL-pointer dereference when initialising URBs at open should a
non-EPIC device lack a bulk-in or interrupt-in endpoint.

Unable to handle kernel NULL pointer dereference at virtual address 00000028
...
PC is at edge_open+0x24c/0x3e8 [io_edgeport]

Note that the EPIC-device probe path has the required sanity checks so
this makes those checks partially redundant.

Fixes: 1da177e4 ("Linux-2.6.12-rc2")
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c4ac4496 upstream.

Make sure to free the URB transfer buffer in case submission fails (e.g.
due to a disconnect).

Fixes: 1da177e4 ("Linux-2.6.12-rc2")
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 3dca0111 upstream.

Fix NULL-pointer dereference when clearing halt at open should the device
lack a bulk-out endpoint.

Unable to handle kernel NULL pointer dereference at virtual address 00000030
...
PC is at cyberjack_open+0x40/0x9c [cyberjack]

Fixes: 1da177e4 ("Linux-2.6.12-rc2")
Signed-off-by: Johan Hovold <johan@kernel.org>
[bwh: Backported to 3.2: add this check to the existing
 usb_serial_driver::attach implementation]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit ee8665e2 upstream.

the tt_info provided by a HS hub might be in use to by a child device
Make sure we free the devices in the correct order.

This is needed in special cases such as when xhci controller is
reset when resuming from hibernate, and all virt_devices are freed.

Also free the virt_devices starting from max slot_id as children
more commonly have higher slot_id than parent.
Reported-by: Guenter Roeck <groeck@chromium.org>
Tested-by: Guenter Roeck <groeck@chromium.org>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 1c069b05 upstream.

Andrey Konovalov's fuzz testing of gadgetfs showed that we should
improve the driver's checks for valid configuration descriptors passed
in by the user.  In particular, the driver needs to verify that the
wTotalLength value in the descriptor is not too short (smaller
than USB_DT_CONFIG_SIZE).  And the check for whether wTotalLength is
too large has to be changed, because the driver assumes there is
always enough room remaining in the buffer to hold a device descriptor
(at least USB_DT_DEVICE_SIZE bytes).

This patch adds the additional check and fixes the existing check.  It
may do a little more than strictly necessary, but one extra check
won't hurt.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit add333a8 upstream.

Andrey Konovalov reports that fuzz testing with syzkaller causes a
KASAN use-after-free bug report in gadgetfs:

BUG: KASAN: use-after-free in gadgetfs_setup+0x208a/0x20e0 at addr ffff88003dfe5bf2
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
 ffff88006df06a18 ffffffff81f96aba ffffffffe0528500 1ffff1000dbe0cd6
 ffffed000dbe0cce ffff88006df068f0 0000000041b58ab3 ffffffff8598b4c8
 ffffffff81f96828 1ffff1000dbe0ccd ffff88006df06708 ffff88006df06748
Call Trace:
 <IRQ> [  201.343209]  [<     inline     >] __dump_stack lib/dump_stack.c:15
 <IRQ> [  201.343209]  [<ffffffff81f96aba>] dump_stack+0x292/0x398 lib/dump_stack.c:51
 [<ffffffff817e4dec>] kasan_object_err+0x1c/0x70 mm/kasan/report.c:159
 [<     inline     >] print_address_description mm/kasan/report.c:197
 [<ffffffff817e5080>] kasan_report_error+0x1f0/0x4e0 mm/kasan/report.c:286
 [<     inline     >] kasan_report mm/kasan/report.c:306
 [<ffffffff817e562a>] __asan_report_load_n_noabort+0x3a/0x40 mm/kasan/report.c:337
 [<     inline     >] config_buf drivers/usb/gadget/legacy/inode.c:1298
 [<ffffffff8322c8fa>] gadgetfs_setup+0x208a/0x20e0 drivers/usb/gadget/legacy/inode.c:1368
 [<ffffffff830fdcd0>] dummy_timer+0x11f0/0x36d0 drivers/usb/gadget/udc/dummy_hcd.c:1858
 [<ffffffff814807c1>] call_timer_fn+0x241/0x800 kernel/time/timer.c:1308
 [<     inline     >] expire_timers kernel/time/timer.c:1348
 [<ffffffff81482de6>] __run_timers+0xa06/0xec0 kernel/time/timer.c:1641
 [<ffffffff814832c1>] run_timer_softirq+0x21/0x80 kernel/time/timer.c:1654
 [<ffffffff84f4af8b>] __do_softirq+0x2fb/0xb63 kernel/softirq.c:284

The cause of the bug is subtle.  The dev_config() routine gets called
twice by the fuzzer.  The first time, the user data contains both a
full-speed configuration descriptor and a high-speed config
descriptor, causing dev->hs_config to be set.  But it also contains an
invalid device descriptor, so the buffer containing the descriptors is
deallocated and dev_config() returns an error.

The second time dev_config() is called, the user data contains only a
full-speed config descriptor.  But dev->hs_config still has the stale
pointer remaining from the first call, causing the routine to think
that there is a valid high-speed config.  Later on, when the driver
dereferences the stale pointer to copy that descriptor, we get a
use-after-free access.

The fix is simple: Clear dev->hs_config if the passed-in data does not
contain a high-speed config descriptor.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: Andrey Konovalov <andreyknvl@google.com>
Tested-by: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit faab5098 upstream.

Andrey Konovalov reports that fuzz testing with syzkaller causes a
KASAN warning in gadgetfs:

BUG: KASAN: slab-out-of-bounds in dev_config+0x86f/0x1190 at addr ffff88003c47e160
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
 ffff88003c107ad8 ffffffff81f96aba ffffffff3dc11ef0 1ffff10007820eee
 ffffed0007820ee6 ffff88003dc11f00 0000000041b58ab3 ffffffff8598b4c8
 ffffffff81f96828 ffffffff813fb4a0 ffff88003b6eadc0 ffff88003c107738
Call Trace:
 [<     inline     >] __dump_stack lib/dump_stack.c:15
 [<ffffffff81f96aba>] dump_stack+0x292/0x398 lib/dump_stack.c:51
 [<ffffffff817e4dec>] kasan_object_err+0x1c/0x70 mm/kasan/report.c:159
 [<     inline     >] print_address_description mm/kasan/report.c:197
 [<ffffffff817e5080>] kasan_report_error+0x1f0/0x4e0 mm/kasan/report.c:286
 [<ffffffff817e5705>] kasan_report+0x35/0x40 mm/kasan/report.c:306
 [<     inline     >] check_memory_region_inline mm/kasan/kasan.c:308
 [<ffffffff817e3fb9>] check_memory_region+0x139/0x190 mm/kasan/kasan.c:315
 [<ffffffff817e4044>] 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
 [<ffffffff83228caf>] dev_config+0x86f/0x1190 drivers/usb/gadget/legacy/inode.c:1759
 [<ffffffff817fdd55>] __vfs_write+0x5d5/0x760 fs/read_write.c:510
 [<ffffffff817ff650>] vfs_write+0x170/0x4e0 fs/read_write.c:560
 [<     inline     >] SYSC_write fs/read_write.c:607
 [<ffffffff81803a5b>] SyS_write+0xfb/0x230 fs/read_write.c:599
 [<ffffffff84f47ec1>] entry_SYSCALL_64_fastpath+0x1f/0xc2

Indeed, there is a comment saying that the value of len is restricted
to a 16-bit integer, but the code doesn't actually do this.

This patch fixes the warning.  It replaces the comment with a
computation that forces the amount of data copied from the user in
ep0_write() to be no larger than the wLength size for the control
transfer, which is a 16-bit quantity.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: Andrey Konovalov <andreyknvl@google.com>
Tested-by: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
[bwh: Backported to 3.2 adjust filename]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 0994b0a2 upstream.

Andrey Konovalov reported that we were not properly checking the upper
limit before of a device configuration size before calling
memdup_user(), which could cause some problems.

So set the upper limit to PAGE_SIZE * 4, which should be good enough for
all devices.
Reported-by: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit bcdbeb84 upstream.

The stop_activity() routine in dummy-hcd is supposed to unlink all
active requests for every endpoint, among other things.  But it
doesn't handle ep0.  As a result, fuzz testing can generate a WARNING
like the following:

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
 ffff88006a64ed10 ffffffff81f96b8a ffffffff41b58ab3 1ffff1000d4c9d35
 ffffed000d4c9d2d ffff880065f8ac00 0000000041b58ab3 ffffffff8598b510
 ffffffff81f968f8 0000000041b58ab3 ffffffff859410e0 ffffffff813f0590
Call Trace:
 [<     inline     >] __dump_stack lib/dump_stack.c:15
 [<ffffffff81f96b8a>] dump_stack+0x292/0x398 lib/dump_stack.c:51
 [<ffffffff812b808f>] __warn+0x19f/0x1e0 kernel/panic.c:550
 [<ffffffff812b831c>] warn_slowpath_null+0x2c/0x40 kernel/panic.c:585
 [<ffffffff830fcb13>] dummy_free_request+0x153/0x170 drivers/usb/gadget/udc/dummy_hcd.c:672
 [<ffffffff830ed1b0>] usb_ep_free_request+0xc0/0x420 drivers/usb/gadget/udc/core.c:195
 [<ffffffff83225031>] gadgetfs_unbind+0x131/0x190 drivers/usb/gadget/legacy/inode.c:1612
 [<ffffffff830ebd8f>] usb_gadget_remove_driver+0x10f/0x2b0 drivers/usb/gadget/udc/core.c:1228
 [<ffffffff830ec084>] usb_gadget_unregister_driver+0x154/0x240 drivers/usb/gadget/udc/core.c:1357

This patch fixes the problem by iterating over all the endpoints in
the driver's ep array instead of iterating over the gadget's ep_list,
which explicitly leaves out ep0.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
[bwh: Backported to 3.2: adjust filename, context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 7e4da3fc upstream.

By convention (according to doc) if function does not provide
get_alt() callback composite framework should assume that it has only
altsetting 0 and should respond with error if host tries to set
other one.

After commit dd4dff8b ("USB: composite: Fix bug: should test
set_alt function pointer before use it")
we started checking set_alt() callback instead of get_alt().
This check is useless as we check if set_alt() is set inside
usb_add_function() and fail if it's NULL.

Let's fix this check and move comment about why we check the get
method instead of set a little bit closer to prevent future false
fixes.

Fixes: dd4dff8b ("USB: composite: Fix bug: should test set_alt function pointer before use it")
Signed-off-by: Krzysztof Opasiak <k.opasiak@samsung.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>