summaryrefslogtreecommitdiff
path: root/net
diff options
context:
space:
mode:
authorJohan Hedberg <johan.hedberg@intel.com>2014-07-14 14:34:55 +0300
committerMarcel Holtmann <marcel@holtmann.org>2014-07-14 13:37:10 +0200
commitb2d5e254ebfe9e4a926265c23bc5943f212fd1ac (patch)
tree86718d8d8e72d9e48042221f4452d604ab78118d /net
parenteb5a4de80f266d0bb7edd43c61894da74faaa91a (diff)
Bluetooth: Fix trying LTK re-encryption when we don't have an LTK
In the case that the key distribution bits cause us not to generate a local LTK we should not try to re-encrypt if we're currently encrypted with an STK. This patch fixes the check for this in the smp_sufficient_security function. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Diffstat (limited to 'net')
-rw-r--r--net/bluetooth/smp.c7
1 files changed, 5 insertions, 2 deletions
diff --git a/net/bluetooth/smp.c b/net/bluetooth/smp.c
index bf3568c46847..8339d6b0f2b8 100644
--- a/net/bluetooth/smp.c
+++ b/net/bluetooth/smp.c
@@ -876,9 +876,12 @@ bool smp_sufficient_security(struct hci_conn *hcon, u8 sec_level)
/* If we're encrypted with an STK always claim insufficient
* security. This way we allow the connection to be re-encrypted
* with an LTK, even if the LTK provides the same level of
- * security.
+ * security. Only exception is if we don't have an LTK (e.g.
+ * because of key distribution bits).
*/
- if (test_bit(HCI_CONN_STK_ENCRYPT, &hcon->flags))
+ if (test_bit(HCI_CONN_STK_ENCRYPT, &hcon->flags) &&
+ hci_find_ltk_by_addr(hcon->hdev, &hcon->dst, hcon->dst_type,
+ hcon->out))
return false;
if (hcon->sec_level >= sec_level)