summaryrefslogtreecommitdiffstats
path: root/net/bluetooth/smp.h
diff options
context:
space:
mode:
authorJohan Hedberg <johan.hedberg@intel.com>2014-09-05 21:19:55 +0200
committerMarcel Holtmann <marcel@holtmann.org>2014-09-08 19:07:56 +0200
commitb28b4943660f4e36f118b751ec606c103ba6b1cc (patch)
tree8a9b4f821044f982f878b74019098fa946aa0863 /net/bluetooth/smp.h
parentBluetooth: Fix calling smp_distribute_keys() when still waiting for keys (diff)
downloadlinux-b28b4943660f4e36f118b751ec606c103ba6b1cc.tar.xz
linux-b28b4943660f4e36f118b751ec606c103ba6b1cc.zip
Bluetooth: Add strict checks for allowed SMP PDUs
SMP defines quite clearly when certain PDUs are to be expected/allowed and when not, but doesn't have any explicit request/response definition. So far the code has relied on each PDU handler to behave correctly if receiving PDUs at an unexpected moment, however this requires many different checks and is prone to errors. This patch introduces a generic way to keep track of allowed PDUs and thereby reduces the responsibility & load on individual command handlers. The tracking is implemented using a simple bit-mask where each opcode maps to its own bit. If the bit is set the corresponding PDU is allow and if the bit is not set the PDU is not allowed. As a simple example, when we send the Pairing Request we'd set the bit for Pairing Response, and when we receive the Pairing Response we'd clear the bit for Pairing Response. Since the disallowed PDU rejection is now done in a single central place we need to be a bit careful of which action makes most sense to all cases. Previously some, such as Security Request, have been simply ignored whereas others have caused an explicit disconnect. The only PDU rejection action that keeps good interoperability and can be used for all the applicable use cases is to drop the data. This may raise some concerns of us now being more lenient for misbehaving (and potentially malicious) devices, but the policy of simply dropping data has been a successful one for many years e.g. in L2CAP (where this is the *only* policy for such cases - we never request disconnection in l2cap_core.c because of bad data). Furthermore, we cannot prevent connected devices from creating the SMP context (through a Security or Pairing Request), and once the context exists looking up the corresponding bit for the received opcode and deciding to reject it is essentially an equally lightweight operation as the kind of rejection that l2cap_core.c already successfully does. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Diffstat (limited to 'net/bluetooth/smp.h')
-rw-r--r--net/bluetooth/smp.h2
1 files changed, 2 insertions, 0 deletions
diff --git a/net/bluetooth/smp.h b/net/bluetooth/smp.h
index cf1094617c69..5240537efde3 100644
--- a/net/bluetooth/smp.h
+++ b/net/bluetooth/smp.h
@@ -102,6 +102,8 @@ struct smp_cmd_security_req {
__u8 auth_req;
} __packed;
+#define SMP_CMD_MAX 0x0b
+
#define SMP_PASSKEY_ENTRY_FAILED 0x01
#define SMP_OOB_NOT_AVAIL 0x02
#define SMP_AUTH_REQUIREMENTS 0x03