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>

diff --git a/net/bluetooth/smp.c b/net/bluetooth/smp.c
index bf3568c46847f1a54b5f38e3ae29d2daeb87870f..8339d6b0f2b8467e89eba618be368e522f346e76 100644 (file)
--- 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)