summaryrefslogtreecommitdiff
path: root/net/bluetooth/smp.c
diff options
context:
space:
mode:
authorMarcel Holtmann <marcel@holtmann.org>2014-07-24 17:20:58 +0400
committerJohan Hedberg <johan.hedberg@intel.com>2014-07-26 15:13:19 +0400
commit66d8e837ab4f58722c56ccbfa5ab9a522cebde78 (patch)
tree98e032b8f9aee078b93817a44e52a76c4239d595 /net/bluetooth/smp.c
parent8540f6c0364722b141547c6c7ac366c3ea77390b (diff)
downloadlinux-66d8e837ab4f58722c56ccbfa5ab9a522cebde78.tar.xz
Bluetooth: Fix white list handling with resolvable private addresses
Devices using resolvable private addresses are required to provide an identity resolving key. These devices can not be found using the current controller white list support. This means if the kernel knows about any devices with an identity resolving key, the white list filtering must be disabled. However so far the kernel kept identity resolving keys around even for devices that are not using resolvable private addresses. The notification to userspace clearly hints to not store the key and so it is best to just remove the key from the kernel as well at that point. With this it easy now to detect when using the white list is possible or when kernel side resolving of addresses is required. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Diffstat (limited to 'net/bluetooth/smp.c')
-rw-r--r--net/bluetooth/smp.c16
1 files changed, 16 insertions, 0 deletions
diff --git a/net/bluetooth/smp.c b/net/bluetooth/smp.c
index e49c83d8b957..a7c344b4acbc 100644
--- a/net/bluetooth/smp.c
+++ b/net/bluetooth/smp.c
@@ -1291,6 +1291,22 @@ static void smp_notify_keys(struct l2cap_conn *conn)
bacpy(&hcon->dst, &smp->remote_irk->bdaddr);
hcon->dst_type = smp->remote_irk->addr_type;
l2cap_conn_update_id_addr(hcon);
+
+ /* When receiving an indentity resolving key for
+ * a remote device that does not use a resolvable
+ * private address, just remove the key so that
+ * it is possible to use the controller white
+ * list for scanning.
+ *
+ * Userspace will have been told to not store
+ * this key at this point. So it is safe to
+ * just remove it.
+ */
+ if (!bacmp(&smp->remote_irk->rpa, BDADDR_ANY)) {
+ list_del(&smp->remote_irk->list);
+ kfree(smp->remote_irk);
+ smp->remote_irk = NULL;
+ }
}
/* The LTKs and CSRKs should be persistent only if both sides