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

Bluetooth: Fix incorrect removing of IRKs

2016-03-03T23:07:16+00:00

commit cff10ce7b4f02718ffd25e3914e60559f5ef6ca0 upstream. The commit cad20c278085d893ebd616cd20c0747a8e9d53c7 was supposed to fix handling of devices first using public addresses and then switching to RPAs after pairing. Unfortunately it missed a couple of key places in the code. 1. When evaluating which devices should be removed from the existing white list we also need to consider whether we have an IRK for them or not, i.e. a call to hci_find_irk_by_addr() is needed. 2. In smp_notify_keys() we should not be requiring the knowledge of the RPA, but should simply keep the IRK around if the other conditions require it. Signed-off-by: Johan Hedberg Signed-off-by: Marcel Holtmann Signed-off-by: Greg Kroah-Hartman

Bluetooth: Fix l2cap_chan leak in SMP

2015-11-11T22:48:34+00:00

The L2CAP core expects channel implementations to manage the reference returned by the new_connection callback. With sockets this is already handled with each channel being tied to the corresponding socket. With SMP however there's no context to tie the pointer to in the smp_new_conn_cb function. The function can also not just drop the reference since it's the only one at that point. For fixed channels (like SMP) the code path inside the L2CAP core from new_connection() to ready() is short and straight-forwards. The crucial difference is that in ready() the implementation has access to the l2cap_conn that SMP needs associate its l2cap_chan. Instead of taking a new reference in smp_ready_cb() we can simply assume to already own the reference created in smp_new_conn_cb(), i.e. there is no need to call l2cap_chan_hold(). Signed-off-by: Johan Hedberg Signed-off-by: Marcel Holtmann Cc: stable@vger.kernel.org # 3.19+

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: Remove redundant (and possibly wrong) flag clearing

2015-10-21T16:57:03+00:00

There's no need to clear the HCI_CONN_ENCRYPT_PEND flag in smp_failure. In fact, this may cause the encryption tracking to get out of sync as this has nothing to do with HCI activity. Signed-off-by: Johan Hedberg Signed-off-by: Marcel Holtmann

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

Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net

2015-09-26T23:08:27+00:00

Conflicts: net/ipv4/arp.c The net/ipv4/arp.c conflict was one commit adding a new local variable while another commit was deleting one. Signed-off-by: David S. Miller

Bluetooth: Fix typo in smp_ah comment for hash function

2015-09-17T11:20:06+00:00

Signed-off-by: Marcel Holtmann Signed-off-by: Johan Hedberg

Bluetooth: Delay check for conn->smp in smp_conn_security()

2015-09-17T10:28:27+00:00

There are several actions that smp_conn_security() might make that do not require a valid SMP context (conn->smp pointer). One of these actions is to encrypt the link with an existing LTK. If the SMP context wasn't initialized properly we should still allow the independent actions to be done, i.e. the check for the context should only be done at the last possible moment. Reported-by: Chuck Ebbert Signed-off-by: Johan Hedberg Signed-off-by: Marcel Holtmann Cc: stable@vger.kernel.org # 4.0+

Bluetooth: Fix NULL pointer dereference in smp_conn_security

2015-07-23T14:41:24+00:00

The l2cap_conn->smp pointer may be NULL for various valid reasons where SMP has failed to initialize properly. One such scenario is when crypto support is missing, another when the adapter has been powered on through a legacy method. The smp_conn_security() function should have the appropriate check for this situation to avoid NULL pointer dereferences. Signed-off-by: Johan Hedberg Signed-off-by: Marcel Holtmann Cc: stable@vger.kernel.org # 4.0+

Bluetooth: Use actual encryption key size for SMP over BR/EDR

2015-06-12T09:38:45+00:00

When pairing over SMP over BR/EDR the generated LTK has by default the same key size as the BR/EDR Link Key. Make sure we don't set our Pairing Request/Response max value to anything higher than that. Signed-off-by: Johan Hedberg Signed-off-by: Marcel Holtmann