From 5ca0a58a05fb0f0bee4eac6bcb0fde52ed8589d4 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Mon, 7 Jul 2014 11:45:24 -0700 Subject: [PATCH] 3.14-stable patches added patches: bluetooth-fix-check-for-connection-encryption.patch bluetooth-fix-indicating-discovery-state-when-canceling-inquiry.patch bluetooth-fix-ssp-acceptor-just-works-confirmation-without-mitm.patch --- ...-fix-check-for-connection-encryption.patch | 43 +++++++++++++++++ ...scovery-state-when-canceling-inquiry.patch | 37 +++++++++++++++ ...just-works-confirmation-without-mitm.patch | 47 +++++++++++++++++++ queue-3.14/series | 3 ++ 4 files changed, 130 insertions(+) create mode 100644 queue-3.14/bluetooth-fix-check-for-connection-encryption.patch create mode 100644 queue-3.14/bluetooth-fix-indicating-discovery-state-when-canceling-inquiry.patch create mode 100644 queue-3.14/bluetooth-fix-ssp-acceptor-just-works-confirmation-without-mitm.patch diff --git a/queue-3.14/bluetooth-fix-check-for-connection-encryption.patch b/queue-3.14/bluetooth-fix-check-for-connection-encryption.patch new file mode 100644 index 00000000000..72593c9eb29 --- /dev/null +++ b/queue-3.14/bluetooth-fix-check-for-connection-encryption.patch @@ -0,0 +1,43 @@ +From e694788d73efe139b24f78b036deb97fe57fa8cb Mon Sep 17 00:00:00 2001 +From: Johan Hedberg +Date: Tue, 10 Jun 2014 09:54:24 +0300 +Subject: Bluetooth: Fix check for connection encryption + +From: Johan Hedberg + +commit e694788d73efe139b24f78b036deb97fe57fa8cb upstream. + +The conn->link_key variable tracks the type of link key in use. It is +set whenever we respond to a link key request as well as when we get a +link key notification event. + +These two events do not however always guarantee that encryption is +enabled: getting a link key request and responding to it may only mean +that the remote side has requested authentication but not encryption. On +the other hand, the encrypt change event is a certain guarantee that +encryption is enabled. The real encryption state is already tracked in +the conn->link_mode variable through the HCI_LM_ENCRYPT bit. + +This patch fixes a check for encryption in the hci_conn_auth function to +use the proper conn->link_mode value and thereby eliminates the chance +of a false positive result. + +Signed-off-by: Johan Hedberg +Signed-off-by: Marcel Holtmann +Signed-off-by: Greg Kroah-Hartman + +--- + net/bluetooth/hci_conn.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/net/bluetooth/hci_conn.c ++++ b/net/bluetooth/hci_conn.c +@@ -759,7 +759,7 @@ static int hci_conn_auth(struct hci_conn + /* If we're already encrypted set the REAUTH_PEND flag, + * otherwise set the ENCRYPT_PEND. + */ +- if (conn->key_type != 0xff) ++ if (conn->link_mode & HCI_LM_ENCRYPT) + set_bit(HCI_CONN_REAUTH_PEND, &conn->flags); + else + set_bit(HCI_CONN_ENCRYPT_PEND, &conn->flags); diff --git a/queue-3.14/bluetooth-fix-indicating-discovery-state-when-canceling-inquiry.patch b/queue-3.14/bluetooth-fix-indicating-discovery-state-when-canceling-inquiry.patch new file mode 100644 index 00000000000..98fa0abf95a --- /dev/null +++ b/queue-3.14/bluetooth-fix-indicating-discovery-state-when-canceling-inquiry.patch @@ -0,0 +1,37 @@ +From 50143a433b70e3145bcf8a4a4e54f0c11bdee32b Mon Sep 17 00:00:00 2001 +From: Johan Hedberg +Date: Tue, 10 Jun 2014 14:05:57 +0300 +Subject: Bluetooth: Fix indicating discovery state when canceling inquiry + +From: Johan Hedberg + +commit 50143a433b70e3145bcf8a4a4e54f0c11bdee32b upstream. + +When inquiry is canceled through the HCI_Cancel_Inquiry command there is +no Inquiry Complete event generated. Instead, all we get is the command +complete for the HCI_Inquiry_Cancel command. This means that we must +call the hci_discovery_set_state() function from the respective command +complete handler in order to ensure that user space knows the correct +discovery state. + +Signed-off-by: Johan Hedberg +Signed-off-by: Marcel Holtmann +Signed-off-by: Greg Kroah-Hartman + +--- + net/bluetooth/hci_event.c | 4 ++++ + 1 file changed, 4 insertions(+) + +--- a/net/bluetooth/hci_event.c ++++ b/net/bluetooth/hci_event.c +@@ -48,6 +48,10 @@ static void hci_cc_inquiry_cancel(struct + smp_mb__after_clear_bit(); /* wake_up_bit advises about this barrier */ + wake_up_bit(&hdev->flags, HCI_INQUIRY); + ++ hci_dev_lock(hdev); ++ hci_discovery_set_state(hdev, DISCOVERY_STOPPED); ++ hci_dev_unlock(hdev); ++ + hci_conn_check_pending(hdev); + } + diff --git a/queue-3.14/bluetooth-fix-ssp-acceptor-just-works-confirmation-without-mitm.patch b/queue-3.14/bluetooth-fix-ssp-acceptor-just-works-confirmation-without-mitm.patch new file mode 100644 index 00000000000..535f3525221 --- /dev/null +++ b/queue-3.14/bluetooth-fix-ssp-acceptor-just-works-confirmation-without-mitm.patch @@ -0,0 +1,47 @@ +From ba15a58b179ed76a7e887177f2b06de12c58ec8f Mon Sep 17 00:00:00 2001 +From: Johan Hedberg +Date: Mon, 9 Jun 2014 13:58:14 +0300 +Subject: Bluetooth: Fix SSP acceptor just-works confirmation without MITM + +From: Johan Hedberg + +commit ba15a58b179ed76a7e887177f2b06de12c58ec8f upstream. + +From the Bluetooth Core Specification 4.1 page 1958: + +"if both devices have set the Authentication_Requirements parameter to +one of the MITM Protection Not Required options, authentication stage 1 +shall function as if both devices set their IO capabilities to +DisplayOnly (e.g., Numeric comparison with automatic confirmation on +both devices)" + +So far our implementation has done user confirmation for all just-works +cases regardless of the MITM requirements, however following the +specification to the word means that we should not be doing confirmation +when neither side has the MITM flag set. + +Signed-off-by: Johan Hedberg +Tested-by: Szymon Janc +Signed-off-by: Marcel Holtmann +Signed-off-by: Greg Kroah-Hartman + +--- + net/bluetooth/hci_event.c | 7 +++++-- + 1 file changed, 5 insertions(+), 2 deletions(-) + +--- a/net/bluetooth/hci_event.c ++++ b/net/bluetooth/hci_event.c +@@ -3177,8 +3177,11 @@ static void hci_user_confirm_request_evt + + /* If we're not the initiators request authorization to + * proceed from user space (mgmt_user_confirm with +- * confirm_hint set to 1). */ +- if (!test_bit(HCI_CONN_AUTH_PEND, &conn->flags)) { ++ * confirm_hint set to 1). The exception is if neither ++ * side had MITM in which case we do auto-accept. ++ */ ++ if (!test_bit(HCI_CONN_AUTH_PEND, &conn->flags) && ++ (loc_mitm || rem_mitm)) { + BT_DBG("Confirming auto-accept as acceptor"); + confirm_hint = 1; + goto confirm; diff --git a/queue-3.14/series b/queue-3.14/series index b1639115be2..e47cb570025 100644 --- a/queue-3.14/series +++ b/queue-3.14/series @@ -37,3 +37,6 @@ drm-gk208-gr-add-missing-registers-to-grctx-init.patch drm-i915-avoid-div-by-zero-when-pixel_multiplier-is-zero.patch drm-i915-set-backlight-duty-cycle-after-backlight-enable-for-gen4.patch drm-vmwgfx-fix-incorrect-write-to-read-only-register-v2.patch +bluetooth-fix-ssp-acceptor-just-works-confirmation-without-mitm.patch +bluetooth-fix-check-for-connection-encryption.patch +bluetooth-fix-indicating-discovery-state-when-canceling-inquiry.patch -- 2.47.3