summaryrefslogtreecommitdiffstats
path: root/net/bluetooth/af_bluetooth.c
diff options
context:
space:
mode:
authorMarcel Holtmann <marcel@holtmann.org>2008-09-09 07:19:20 +0200
committerMarcel Holtmann <marcel@holtmann.org>2008-09-09 07:19:20 +0200
commite7c29cb16c833441fd2160642bb13025f4e7ac70 (patch)
tree7ba44be60b7bf9c4e7bee459735ebabdc85eb8fd /net/bluetooth/af_bluetooth.c
parent09ab6f4c2376a0fc31abde1e2991513f900ea825 (diff)
downloadlinux-e7c29cb16c833441fd2160642bb13025f4e7ac70.tar.gz
linux-e7c29cb16c833441fd2160642bb13025f4e7ac70.tar.bz2
linux-e7c29cb16c833441fd2160642bb13025f4e7ac70.zip
[Bluetooth] Reject L2CAP connections on an insecure ACL link
The Security Mode 4 of the Bluetooth 2.1 specification has strict authentication and encryption requirements. It is the initiators job to create a secure ACL link. However in case of malicious devices, the acceptor has to make sure that the ACL is encrypted before allowing any kind of L2CAP connection. The only exception here is the PSM 1 for the service discovery protocol, because that is allowed to run on an insecure ACL link. Previously it was enough to reject a L2CAP connection during the connection setup phase, but with Bluetooth 2.1 it is forbidden to do any L2CAP protocol exchange on an insecure link (except SDP). The new hci_conn_check_link_mode() function can be used to check the integrity of an ACL link. This functions also takes care of the cases where Security Mode 4 is disabled or one of the devices is based on an older specification. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Diffstat (limited to 'net/bluetooth/af_bluetooth.c')
-rw-r--r--net/bluetooth/af_bluetooth.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/net/bluetooth/af_bluetooth.c b/net/bluetooth/af_bluetooth.c
index 1edfdf4c095b..f6348e078aa4 100644
--- a/net/bluetooth/af_bluetooth.c
+++ b/net/bluetooth/af_bluetooth.c
@@ -49,7 +49,7 @@
#define BT_DBG(D...)
#endif
-#define VERSION "2.12"
+#define VERSION "2.13"
/* Bluetooth sockets */
#define BT_MAX_PROTO 8