linux-toradex.git/net/bluetooth/smp.c, branch v4.10

Bluetooth: SMP: Add support for H7 crypto function and CT2 auth flag

2016-12-08T06:50:24+00:00

Bluetooth 5.0 introduces a new H7 key generation function that's used
when both sides of the pairing set the CT2 authentication flag to 1.

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

Bluetooth: Fix not registering BR/EDR SMP channel with force_bredr flag

2016-09-19T18:19:34+00:00

If force_bredr is set SMP BR/EDR channel should also be for non-SC
capable controllers. Since hcidev flag is persistent wrt power toggle
it can be already set when calling smp_register(). This resulted in
SMP BR/EDR channel not being registered even if HCI_FORCE_BREDR_SMP
flag was set.

This also fix NULL pointer dereference when trying to disable
force_bredr after power cycle.

BUG: unable to handle kernel NULL pointer dereference at 0000000000000388
IP: [] smp_del_chan+0x18/0x80 [bluetooth]

Call Trace:
[] force_bredr_smp_write+0xba/0x100 [bluetooth]
[] full_proxy_write+0x54/0x90
[] __vfs_write+0x37/0x160
[] ? selinux_file_permission+0xd7/0x110
[] ? security_file_permission+0x3d/0xc0
[] ? percpu_down_read+0x12/0x50
[] vfs_write+0xb5/0x1a0
[] SyS_write+0x55/0xc0
[] entry_SYSCALL_64_fastpath+0x1a/0xa4
Code: 48 8b 45 f0 eb c1 0f 1f 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f
      44 00 00 f6 05 c6 3b 02 00 04 55 48 89 e5 41 54 53 49 89 fc 75
      4b
      <49> 8b 9c 24 88 03 00 00 48 85 db 74 31 49 c7 84 24 88 03 00 00
RIP  [] smp_del_chan+0x18/0x80 [bluetooth]
RSP 
CR2: 0000000000000388

Signed-off-by: Szymon Janc 
Signed-off-by: Marcel Holtmann

Bluetooth: Switch SMP to crypto_cipher_encrypt_one()

2016-07-08T10:20:57+00:00

SMP does ECB crypto on stack buffers.  This is complicated and
fragile, and it will not work if the stack is virtually allocated.

Switch to the crypto_cipher interface, which is simpler and safer.

Signed-off-by: Andy Lutomirski 
Acked-by: Herbert Xu 
Acked-by: Johan Hedberg 
Tested-by: Johan Hedberg 
Signed-off-by: Marcel Holtmann

Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6

2016-03-17T18:22:54+00:00

Pull crypto update from Herbert Xu:
"Here is the crypto update for 4.6:

API:
- Convert remaining crypto_hash users to shash or ahash, also convert
blkcipher/ablkcipher users to skcipher.
- Remove crypto_hash interface.
- Remove crypto_pcomp interface.
- Add crypto engine for async cipher drivers.
- Add akcipher documentation.
- Add skcipher documentation.

Algorithms:
- Rename crypto/crc32 to avoid name clash with lib/crc32.
- Fix bug in keywrap where we zero the wrong pointer.

Drivers:
- Support T5/M5, T7/M7 SPARC CPUs in n2 hwrng driver.
- Add PIC32 hwrng driver.
- Support BCM6368 in bcm63xx hwrng driver.
- Pack structs for 32-bit compat users in qat.
- Use crypto engine in omap-aes.
- Add support for sama5d2x SoCs in atmel-sha.
- Make atmel-sha available again.
- Make sahara hashing available again.
- Make ccp hashing available again.
- Make sha1-mb available again.
- Add support for multiple devices in ccp.
- Improve DMA performance in caam.
- Add hashing support to rockchip"

* 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: (116 commits)
crypto: qat - remove redundant arbiter configuration
crypto: ux500 - fix checks of error code returned by devm_ioremap_resource()
crypto: atmel - fix checks of error code returned by devm_ioremap_resource()
crypto: qat - Change the definition of icp_qat_uof_regtype
hwrng: exynos - use __maybe_unused to hide pm functions
crypto: ccp - Add abstraction for device-specific calls
crypto: ccp - CCP versioning support
crypto: ccp - Support for multiple CCPs
crypto: ccp - Remove check for x86 family and model
crypto: ccp - memset request context to zero during import
lib/mpi: use "static inline" instead of "extern inline"
lib/mpi: avoid assembler warning
hwrng: bcm63xx - fix non device tree compatibility
crypto: testmgr - allow rfc3686 aes-ctr variants in fips mode.
crypto: qat - The AE id should be less than the maximal AE number
lib/mpi: Endianness fix
crypto: rockchip - add hash support for crypto engine in rk3288
crypto: xts - fix compile errors
crypto: doc - add skcipher API documentation
crypto: doc - update AEAD AD handling
...

Bluetooth: Fix incorrect removing of IRKs

2016-01-29T10:47:24+00:00

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 
Cc: stable@vger.kernel.org # 4.4+

Bluetooth: Use skcipher and hash

2016-01-27T12:36:04+00:00

This patch replaces uses of blkcipher with skcipher and the long
obsolete hash interface with shash.

Signed-off-by: Herbert Xu 
Acked-by: Marcel Holtmann

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