3.10-stable patches

added patches:
	bluetooth-fix-check-for-connection-encryption.patch
	bluetooth-fix-ssp-acceptor-just-works-confirmation-without-mitm.patch

diff --git a/queue-3.10/bluetooth-fix-check-for-connection-encryption.patch b/queue-3.10/bluetooth-fix-check-for-connection-encryption.patch
new file mode 100644 (file)
index 0000000..4ded2c3
--- /dev/null
+++ b/queue-3.10/bluetooth-fix-check-for-connection-encryption.patch
@@ -0,0 +1,43 @@
+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
+@@ -659,7 +659,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.10/bluetooth-fix-ssp-acceptor-just-works-confirmation-without-mitm.patch b/queue-3.10/bluetooth-fix-ssp-acceptor-just-works-confirmation-without-mitm.patch
new file mode 100644 (file)
index 0000000..ac282ee
--- /dev/null
+++ b/queue-3.10/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 <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
+@@ -3218,8 +3218,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.10/series b/queue-3.10/series
index 397a36636e0460a289b6b6ffe6731f7b9fc6eac1..7f945f37441579a517c726aeaa9934d277fbd85a 100644 (file)
--- a/queue-3.10/series
+++ b/queue-3.10/series
@@ -18,3 +18,5 @@ drm-radeon-dp-fix-lane-clock-setup-for-dp-1.2-capable-devices.patch
 drm-radeon-atom-fix-dithering-on-certain-panels.patch
 drm-radeon-don-t-allow-radeon_gem_domain_cpu-for-command-submission.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