--- /dev/null
+From e694788d73efe139b24f78b036deb97fe57fa8cb Mon Sep 17 00:00:00 2001
+From: Johan Hedberg <johan.hedberg@intel.com>
+Date: Tue, 10 Jun 2014 09:54:24 +0300
+Subject: Bluetooth: Fix check for connection encryption
+
+From: Johan Hedberg <johan.hedberg@intel.com>
+
+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 <johan.hedberg@intel.com>
+Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
--- /dev/null
+From 50143a433b70e3145bcf8a4a4e54f0c11bdee32b Mon Sep 17 00:00:00 2001
+From: Johan Hedberg <johan.hedberg@intel.com>
+Date: Tue, 10 Jun 2014 14:05:57 +0300
+Subject: Bluetooth: Fix indicating discovery state when canceling inquiry
+
+From: Johan Hedberg <johan.hedberg@intel.com>
+
+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 <johan.hedberg@intel.com>
+Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
+ }
+
--- /dev/null
+From ba15a58b179ed76a7e887177f2b06de12c58ec8f Mon Sep 17 00:00:00 2001
+From: Johan Hedberg <johan.hedberg@intel.com>
+Date: Mon, 9 Jun 2014 13:58:14 +0300
+Subject: Bluetooth: Fix SSP acceptor just-works confirmation without MITM
+
+From: Johan Hedberg <johan.hedberg@intel.com>
+
+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 <johan.hedberg@intel.com>
+Tested-by: Szymon Janc <szymon.janc@tieto.com>
+Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
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
projects / thirdparty / kernel / stable-queue.git / commitdiff
