BMC/Intel-BMC/linux.git/net/bluetooth/mgmt.c, branch dev-4.4

Bluetooth: Fix potential buffer overflow with Add Advertising

2016-04-12T16:08:54+00:00

commit 6a0e78072c2ae7b20b14e0249d8108441ea928d2 upstream. The Add Advertising command handler does the appropriate checks for the AD and Scan Response data, however fails to take into account the general length of the mgmt command itself, which could lead to potential buffer overflows. This patch adds the necessary check that the mgmt command length is consistent with the given ad and scan_rsp lengths. Signed-off-by: Johan Hedberg Signed-off-by: Marcel Holtmann Signed-off-by: Greg Kroah-Hartman

Bluetooth: Take advantage of connection abort helpers

2015-10-22T09:37:22+00:00

Convert the various places mapping connection state to disconnect/cancel HCI command to use the new hci_abort_conn helper API. Signed-off-by: Johan Hedberg Signed-off-by: Marcel Holtmann

Bluetooth: Fix crash in SMP when unpairing

2015-10-22T07:02:03+00:00

When unpairing the keys stored in hci_dev are removed. If SMP is ongoing the SMP context will also have references to these keys, so removing them from the hci_dev lists will make the pointers invalid. This can result in the following type of crashes: BUG: unable to handle kernel paging request at 6b6b6b6b IP: [] __list_del_entry+0x44/0x71 *pde = 00000000 Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC Modules linked in: hci_uart btqca btusb btintel btbcm btrtl hci_vhci rfcomm bluetooth_6lowpan bluetooth CPU: 0 PID: 723 Comm: kworker/u5:0 Not tainted 4.3.0-rc3+ #1379 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.8.1-20150318_183358- 04/01/2014 Workqueue: hci0 hci_rx_work [bluetooth] task: f19da940 ti: f1a94000 task.ti: f1a94000 EIP: 0060:[] EFLAGS: 00010202 CPU: 0 EIP is at __list_del_entry+0x44/0x71 EAX: c0088d20 EBX: f30fcac0 ECX: 6b6b6b6b EDX: 6b6b6b6b ESI: f4b60000 EDI: c0088d20 EBP: f1a95d90 ESP: f1a95d8c DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 CR0: 8005003b CR2: 6b6b6b6b CR3: 319e5000 CR4: 00000690 Stack: f30fcac0 f1a95db0 f82dc3e1 f1bfc000 00000000 c106524f f1bfc000 f30fd020 f1a95dc0 f1a95dd0 f82dcbdb f1a95de0 f82dcbdb 00000067 f1bfc000 f30fd020 f1a95de0 f1a95df0 f82d1126 00000067 f82d1126 00000006 f30fd020 f1bfc000 Call Trace: [] smp_chan_destroy+0x192/0x240 [bluetooth] [] ? trace_hardirqs_on_caller+0x14e/0x169 [] smp_teardown_cb+0x47/0x64 [bluetooth] [] ? smp_teardown_cb+0x47/0x64 [bluetooth] [] l2cap_chan_del+0x5d/0x14d [bluetooth] [] ? l2cap_chan_del+0x5d/0x14d [bluetooth] [] l2cap_conn_del+0x109/0x17b [bluetooth] [] ? l2cap_conn_del+0x109/0x17b [bluetooth] [] ? hci_event_packet+0x5b1/0x2092 [bluetooth] [] l2cap_disconn_cfm+0x49/0x50 [bluetooth] [] ? l2cap_disconn_cfm+0x49/0x50 [bluetooth] [] hci_event_packet+0x5d4/0x2092 [bluetooth] [] ? skb_release_data+0x6a/0x95 [] ? hci_send_to_monitor+0xe7/0xf4 [bluetooth] [] ? _raw_spin_unlock_irqrestore+0x44/0x57 [] hci_rx_work+0xf1/0x28b [bluetooth] [] ? hci_rx_work+0xf1/0x28b [bluetooth] [] ? __lock_is_held+0x2e/0x44 [] process_one_work+0x232/0x432 [] ? rcu_read_lock_sched_held+0x50/0x5a [] ? process_one_work+0x232/0x432 [] worker_thread+0x1b8/0x255 [] ? rescuer_thread+0x23c/0x23c [] kthread+0x91/0x96 [] ? _raw_spin_unlock_irq+0x27/0x44 [] ret_from_kernel_thread+0x21/0x30 [] ? kthread_parkme+0x1e/0x1e To solve the issue, introduce a new smp_cancel_pairing() API that can be used to clean up the SMP state before touching the hci_dev lists. Signed-off-by: Johan Hedberg Signed-off-by: Marcel Holtmann

Bluetooth: Disable auto-connection parameters when unpairing

2015-10-22T07:02:03+00:00

For connection parameters that are left around until a disconnection we should at least clear any auto-connection properties. This way a new Add Device call is required to re-set them after calling Unpair Device. Signed-off-by: Johan Hedberg Signed-off-by: Marcel Holtmann

Bluetooth: Remove unnecessary indentation in unpair_device()

2015-10-21T16:40:21+00:00

Instead of doing all of the LE-specific handling in an else-branch in unpair_device() create a 'done' label for the BR/EDR branch to jump to and then remove the else-branch completely. Signed-off-by: Johan Hedberg Signed-off-by: Marcel Holtmann

Bluetooth: Use hci_conn_hash_lookup_le() when possible

2015-10-21T16:38:22+00:00

Use the new hci_conn_hash_lookup_le() API to look up LE connections. This way we're guaranteed exact matches that also take into account the address type. Signed-off-by: Johan Hedberg Signed-off-by: Marcel Holtmann

Bluetooth: Add le_addr_type() helper function

2015-10-21T16:35:00+00:00

The mgmt code needs to convert from mgmt/L2CAP address types to HCI in many places. Having a dedicated helper function for this simplifies code by shortening it and removing unnecessary 'addr_type' variables. Signed-off-by: Johan Hedberg Signed-off-by: Marcel Holtmann

Bluetooth: Fix removing connection parameters when unpairing

2015-10-20T22:49:24+00:00

The commit 89cbb0638e9b7 introduced support for deferred connection parameter removal when unpairing by removing them only once an existing connection gets disconnected. However, it failed to address the scenario when we're *not* connected and do an unpair operation. What makes things worse is that most user space BlueZ versions will first issue a disconnect request and only then unpair, meaning the buggy code will be triggered every time. This effectively causes the kernel to resume scanning and reconnect to a device for which we've removed all keys and GATT database information. This patch fixes the issue by adding the missing call to the hci_conn_params_del() function to a branch which handles the case of no existing connection. Signed-off-by: Johan Hedberg Signed-off-by: Marcel Holtmann Cc: stable@vger.kernel.org # 3.19+

Bluetooth: Don't use remote address type to decide IRK persistency

2015-10-20T22:49:21+00:00

There are LE devices on the market that start off by announcing their public address and then once paired switch to using private address. To be interoperable with such devices we should simply trust the fact that we're receiving an IRK from them to indicate that they may use private addresses in the future. Instead, simply tie the persistency to the bonding/no-bonding information the same way as for LTKs and CSRKs. Signed-off-by: Johan Hedberg Signed-off-by: Marcel Holtmann

Bluetooth: Fix initializing conn_params in scan phase

2015-10-16T07:24:41+00:00

This patch makes sure that conn_params that were created just for explicit_connect, will get properly deleted during cleanup. Signed-off-by: Jakub Pawlowski Acked-by: Johan Hedberg Signed-off-by: Marcel Holtmann