Nicolai Stange
7222c83225
usb/core: usb_alloc_dev(): fix setting of ->portnum
With commit 69bec72598 ("USB: core: let USB device know device node"),
the port1 argument of usb_alloc_dev() gets overwritten as follows:
... usb_alloc_dev(..., unsigned port1)
{
...
if (!parent->parent) {
port1 = usb_hcd_find_raw_port_number(..., port1);
}
...
}
Later on, this now overwritten port1 gets assigned to ->portnum:
dev->portnum = port1;
However, since xhci_find_raw_port_number() isn't idempotent, the
aforementioned commit causes a number of KASAN splats like the following:
BUG: KASAN: slab-out-of-bounds in xhci_find_raw_port_number+0x98/0x170
at addr ffff8801d9311670
Read of size 8 by task kworker/2:1/87
[...]
Workqueue: usb_hub_wq hub_event
0000000000000188 000000005814b877 ffff8800cba17588 ffffffff8191447e
0000000041b58ab3 ffffffff82a03209 ffffffff819143a2 ffffffff82a252f4
ffff8801d93115e0 0000000000000188 ffff8801d9311628 ffff8800cba17588
Call Trace:
[<ffffffff8191447e>] dump_stack+0xdc/0x15e
[<ffffffff819143a2>] ? _atomic_dec_and_lock+0xa2/0xa2
[<ffffffff814e2cd1>] ? print_section+0x61/0xb0
[<ffffffff814e4939>] print_trailer+0x179/0x2c0
[<ffffffff814f0d84>] object_err+0x34/0x40
[<ffffffff814f4388>] kasan_report_error+0x2f8/0x8b0
[<ffffffff814eb91e>] ? __slab_alloc+0x5e/0x90
[<ffffffff812178c0>] ? __lock_is_held+0x90/0x130
[<ffffffff814f5091>] kasan_report+0x71/0xa0
[<ffffffff814ec082>] ? kmem_cache_alloc_trace+0x212/0x560
[<ffffffff81d99468>] ? xhci_find_raw_port_number+0x98/0x170
[<ffffffff814f33d4>] __asan_load8+0x64/0x70
[<ffffffff81d99468>] xhci_find_raw_port_number+0x98/0x170
[<ffffffff81db0105>] xhci_setup_addressable_virt_dev+0x235/0xa10
[<ffffffff81d9ea51>] xhci_setup_device+0x3c1/0x1430
[<ffffffff8121cddd>] ? trace_hardirqs_on+0xd/0x10
[<ffffffff81d9fac0>] ? xhci_setup_device+0x1430/0x1430
[<ffffffff81d9fad3>] xhci_address_device+0x13/0x20
[<ffffffff81d2081a>] hub_port_init+0x55a/0x1550
[<ffffffff81d28705>] hub_event+0xef5/0x24d0
[<ffffffff81d27810>] ? hub_port_debounce+0x2f0/0x2f0
[<ffffffff8195e1ee>] ? debug_object_deactivate+0x1be/0x270
[<ffffffff81210203>] ? print_rt_rq+0x53/0x2d0
[<ffffffff8121657d>] ? trace_hardirqs_off+0xd/0x10
[<ffffffff8226acfb>] ? _raw_spin_unlock_irqrestore+0x5b/0x60
[<ffffffff81250000>] ? irq_domain_set_hwirq_and_chip+0x30/0xb0
[<ffffffff81256339>] ? debug_lockdep_rcu_enabled+0x39/0x40
[<ffffffff812178c0>] ? __lock_is_held+0x90/0x130
[<ffffffff81196877>] process_one_work+0x567/0xec0
[...]
Afterwards, xhci reports some functional errors:
xhci_hcd 0000:00:14.0: ERROR: unexpected setup address command completion
code 0x11.
xhci_hcd 0000:00:14.0: ERROR: unexpected setup address command completion
code 0x11.
usb 4-3: device not accepting address 2, error -22
Fix this by not overwriting the port1 argument in usb_alloc_dev(), but
storing the raw port number as required by OF in an additional variable,
raw_port.
Fixes: 69bec72598 ("USB: core: let USB device know device node")
Signed-off-by: Nicolai Stange <nicstange@gmail.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-03-18 09:19:02 -07:00
..
2016-03-16 17:45:56 -07:00
2016-03-01 16:38:16 -08:00
2016-03-16 14:45:55 -07:00
2016-03-17 13:47:50 -07:00
2016-01-17 12:32:01 -08:00
2016-03-17 11:22:54 -07:00
2016-02-01 12:27:18 -08:00
2016-03-17 13:53:25 -07:00
2016-02-22 14:03:02 -08:00
2016-03-16 09:55:35 -07:00
2016-03-14 14:22:03 +01:00
2016-02-17 00:28:15 +01:00
2016-03-17 11:22:54 -07:00
2016-02-23 14:27:42 +09:00
2016-03-17 12:34:54 -07:00
2016-03-16 08:36:55 -07:00
2016-02-29 11:07:34 +09:00
2016-03-17 13:38:00 -07:00
2016-02-25 15:46:27 +01:00
2016-03-16 14:45:55 -07:00
2016-01-20 17:30:20 -08:00
2016-01-28 17:47:56 +01:00
2016-03-17 13:47:50 -07:00
2016-03-08 18:40:49 -08:00
2016-02-03 08:28:43 -08:00
2016-03-05 12:19:39 -08:00
2016-03-10 21:34:47 +01:00
2016-02-05 16:29:28 -06:00
2016-02-01 13:08:26 -08:00
2016-03-04 18:06:49 -08:00
2016-02-10 12:21:57 -08:00
2016-02-29 23:55:16 +01:00
2016-03-11 10:06:55 +01:00
2016-03-17 13:53:25 -07:00
2016-03-14 09:22:23 +01:00
2016-02-04 09:19:45 -07:00
2016-02-05 16:29:28 -06:00
2016-03-14 14:20:33 +01:00
2016-03-17 11:22:54 -07:00
2016-03-16 18:27:32 -07:00
2016-01-20 18:42:30 -08:00
2016-01-20 17:09:18 -08:00
2016-02-23 21:27:02 -05:00
2016-03-15 21:58:58 -07:00
2016-03-17 13:47:50 -07:00
2016-03-17 13:53:25 -07:00
2016-03-11 16:34:18 -08:00
2016-03-17 13:53:25 -07:00
2016-01-27 20:36:09 +08:00
2016-01-21 19:53:10 -05:00
2016-03-09 17:15:43 -08:00
2016-03-03 14:43:10 -07:00
2016-03-05 12:20:29 -08:00
2016-03-17 13:53:25 -07:00
2016-01-22 18:04:28 -05:00
2016-03-16 14:45:55 -07:00
2016-03-16 14:45:55 -07:00
2016-03-05 12:22:41 -08:00
2016-03-11 23:03:06 +07:00
2016-03-05 12:33:58 -08:00
2016-03-09 23:50:55 +01:00
2016-03-17 12:50:55 -07:00
2016-03-09 00:26:44 +01:00
2016-03-15 12:13:56 -07:00
2016-01-21 15:04:59 +01:00
2016-01-30 09:49:58 +01:00
2016-03-13 15:20:14 +07:00
2016-01-29 17:26:49 -08:00
2016-03-14 17:08:41 +01:00
2016-03-17 13:53:25 -07:00
2016-03-17 11:22:54 -07:00
2016-03-04 12:12:08 +01:00
2016-01-22 17:30:52 -08:00
2016-03-17 12:34:54 -07:00
2016-02-08 14:57:30 -08:00
2016-02-26 12:47:32 +02:00
2016-03-17 13:53:25 -07:00
2016-03-17 11:22:54 -07:00
2016-02-11 07:13:29 -08:00
2016-03-07 16:11:14 -08:00
2016-03-18 09:19:02 -07:00
2016-03-17 13:05:09 -07:00
2016-03-02 17:01:49 +02:00
2016-03-16 18:37:20 -07:00
2016-03-16 14:45:55 -07:00
2016-02-07 23:17:59 -08:00
2016-02-11 19:23:28 -08:00
2016-03-01 16:51:19 -08:00
2016-03-15 16:55:16 -07:00
2016-01-25 09:42:23 +01:00