Bluetooth: Fix differentiating stored master vs slave LTK types
authorJohan Hedberg <johan.hedberg@intel.com>
Fri, 31 Jan 2014 03:40:00 +0000 (19:40 -0800)
committerJohan Hedberg <johan.hedberg@intel.com>
Thu, 13 Feb 2014 07:51:41 +0000 (09:51 +0200)
commit98a0b845c63cb74e90a72d1e864ea4be968bdd83
tree464a1121e17e527de1abcc17a425e4e74b366079
parenta513e260ce25eaa5e8c6b834a70085be1d6f40c0
Bluetooth: Fix differentiating stored master vs slave LTK types

If LTK distribution happens in both directions we will have two LTKs for
the same remote device: one which is used when we're connecting as
master and another when we're connecting as slave. When looking up LTKs
from the locally stored list we shouldn't blindly return the first match
but also consider which type of key is in question. If we do not do this
we may end up selecting an incorrect encryption key for a connection.

This patch fixes the issue by always specifying to the LTK lookup
functions whether we're looking for a master or a slave key.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
include/net/bluetooth/hci_core.h
net/bluetooth/hci_core.c
net/bluetooth/hci_event.c
net/bluetooth/smp.c