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

Bluetooth: Fix NULL pointer dereference in smp_conn_security

2015-08-17T03:52:11+00:00

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:40+00:00

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:53+00:00

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:03+00:00

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:24+00:00

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:23+00:00

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:21+00:00

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

Bluetooth: Use smp->remote_pk + 32 instead of &smp->remote_pk[32]

2015-03-16T19:36:19+00:00

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

Bluetooth: Add clarifying comment when setting local OOB flag

2015-03-16T19:16:08+00:00

It might be a bit counterintuitive to set a 'local' flag based on remote
data. This patch adds a clarifying comment to the pairing req/rsp
handlers when setting the LOCAL_OOB flag based on the PDU received from
the remote side.

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

Bluetooth: Don't send public key if OOB data verification fails

2015-03-16T16:17:38+00:00

When we receive the remote public key, if we have remote OOB data
there's no point in sending our public key to the remote if the OOB data
doesn't match. This patch moves the test for this higher up in the
smp_cmd_public_key() function.

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