kernel/net/bluetooth/smp.c, branch linux-4.1.y

Bluetooth: Fix missing encryption refresh on Security Request

2018-05-23T01:33:57Z

[ Upstream commit 64e759f58f128730b97a3c3a26d283c075ad7c86 ] If Security Request is received on connection that is already encrypted with sufficient security master should perform encryption key refresh procedure instead of just ignoring Slave Security Request (Core Spec 5.0 Vol 3 Part H 2.4.6). > ACL Data RX: Handle 3585 flags 0x02 dlen 6 SMP: Security Request (0x0b) len 1 Authentication requirement: Bonding, No MITM, SC, No Keypresses (0x09) < HCI Command: LE Start Encryption (0x08|0x0019) plen 28 Handle: 3585 Random number: 0x0000000000000000 Encrypted diversifier: 0x0000 Long term key: 44264272a5c426a9e868f034cf0e69f3 > HCI Event: Command Status (0x0f) plen 4 LE Start Encryption (0x08|0x0019) ncmd 1 Status: Success (0x00) > HCI Event: Encryption Key Refresh Complete (0x30) plen 3 Status: Success (0x00) Handle: 3585 Signed-off-by: Szymon Janc Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin

Bluetooth: use constant time memory comparison for secret values

2017-09-01T18:24:28Z

[ Upstream commit 329d82309824ff1082dc4a91a5bbed8c3bec1580 ] This file is filled with complex cryptography. Thus, the comparisons of MACs and secret keys and curve points and so forth should not add timing attacks, which could either result in a direct forgery, or, given the complexity, some other type of attack. Signed-off-by: Jason A. Donenfeld Signed-off-by: Marcel Holtmann Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin

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

2015-10-22T21:43:18Z

commit d8949aad3eab5d396f4fefcd581773bf07b9a79e upstream. 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 Signed-off-by: Greg Kroah-Hartman

Bluetooth: Fix NULL pointer dereference in smp_conn_security

2015-08-17T03:52:11Z

commit 25ba265390c09b0a2b2f3fd9ba82e37248b7a371 upstream. 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 Signed-off-by: Greg Kroah-Hartman

Bluetooth: Export SMP selftest result in debugfs

2015-04-02T05:47:40Z

When SMP selftest is enabled, then besides printing the result into the kernel message buffer, also create a debugfs file that allows retrieving the same information. Signed-off-by: Marcel Holtmann Signed-off-by: Johan Hedberg

Bluetooth: Refactor L2CAP variables into l2cap_ctrl

2015-03-30T21:20:53Z

We're getting very close to the maximum possible size of bt_skb_cb. To prepare to shrink the struct with the help of a union this patch moves all L2CAP related variables into the l2cap_ctrl struct. To later add other 'ctrl' structs the L2CAP one is renamed simple 'l2cap' instead of 'control'. Signed-off-by: Johan Hedberg Signed-off-by: Marcel Holtmann

Bluetooth: Fix potential NULL dereference in SMP channel setup

2015-03-18T06:30:03Z

When the allocation of the L2CAP channel for the BR/EDR security manager fails, then the smp variable might be NULL. In that case do not try to free the non-existing crypto contexts Reported-by: Dan Carpenter Signed-off-by: Marcel Holtmann Signed-off-by: Johan Hedberg

Bluetooth: Add workaround for broken OS X legacy SMP pairing

2015-03-17T17:58:24Z

OS X version 10.10.2 (and possibly older versions) doesn't support LE Secure Connections but incorrectly copies all authentication request bits from a Security Request to its Pairing Request. The result is that an SC capable initiator (such as BlueZ) will think OS X intends to do SC when in fact it's incapable of it: < ACL Data TX: Handle 3585 flags 0x00 dlen 6 SMP: Security Request (0x0b) len 1 Authentication requirement: Bonding, No MITM, SC, No Keypresses (0x09) > ACL Data RX: Handle 3585 flags 0x02 dlen 11 SMP: Pairing Request (0x01) len 6 IO capability: KeyboardDisplay (0x04) OOB data: Authentication data not present (0x00) Authentication requirement: Bonding, No MITM, SC, No Keypresses (0x09) Max encryption key size: 16 Initiator key distribution: EncKey (0x01) Responder key distribution: EncKey IdKey Sign (0x07) < ACL Data TX: Handle 3585 flags 0x00 dlen 11 SMP: Pairing Response (0x02) len 6 IO capability: NoInputNoOutput (0x03) OOB data: Authentication data not present (0x00) Authentication requirement: Bonding, No MITM, SC, No Keypresses (0x09) Max encryption key size: 16 Initiator key distribution: EncKey (0x01) Responder key distribution: EncKey Sign (0x05) The pairing eventually fails when we get an unexpected Pairing Confirm PDU instead of a Public Key PDU: > ACL Data RX: Handle 3585 flags 0x02 dlen 21 SMP: Pairing Confirm (0x03) len 16 Confim value: bcc3bed31b8f313a78ec3cce32685faf It is only at this point that we can speculate that the remote doesn't really support SC. This patch creates a workaround for the just-works model, however the MITM case is unsolvable because the OS X user has already been requested to enter a PIN which we're now expected to randomly generate and show the user (i.e. a chicken-and-egg problem). Signed-off-by: Johan Hedberg Signed-off-by: Marcel Holtmann

Bluetooth: Rename smp->local_rr into smp->local_rand

2015-03-16T19:36:23Z

The variable for the out-of-band random number was badly named and with that confusing. Just rename it to local_rand so it is clear what value it represents. Signed-off-by: Marcel Holtmann Signed-off-by: Johan Hedberg

Bluetooth: Add extra SMP_DBG statement for remote OOB data

2015-03-16T19:36:21Z

Just for pure debugging purposes print the remote out-of-band data that has been received and is going to be used. Signed-off-by: Marcel Holtmann Signed-off-by: Johan Hedberg