From: Greg Kroah-Hartman Date: Mon, 7 Jul 2014 18:45:21 +0000 (-0700) Subject: 3.10-stable patches X-Git-Tag: v3.4.98~48 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=355849146314751d33a626b226735ba9eb052692;p=thirdparty%2Fkernel%2Fstable-queue.git 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 index 00000000000..4ded2c30110 --- /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 +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 +@@ -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 index 00000000000..ac282ee7e2e --- /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 +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 +@@ -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 397a36636e0..7f945f37441 100644 --- 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