This is a note to let you know that I've just added the patch titled
Bluetooth: Fix tracking local SSP authentication requirement
to the 3.16-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
bluetooth-fix-tracking-local-ssp-authentication-requirement.patch
and it can be found in the queue-3.16 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.
>From 6c53823ae0e10e723131055e1e65dd6a328a228e Mon Sep 17 00:00:00 2001
From: Johan Hedberg <johan.hedberg@xxxxxxxxx>
Date: Fri, 11 Jul 2014 15:32:23 +0300
Subject: Bluetooth: Fix tracking local SSP authentication requirement
From: Johan Hedberg <johan.hedberg@xxxxxxxxx>
commit 6c53823ae0e10e723131055e1e65dd6a328a228e upstream.
When we need to make the decision whether to perform just-works or real
user confirmation we need to know the exact local authentication
requirement that was passed to the controller. So far conn->auth_type
(the local requirement) wasn't in one case updated appropriately in fear
of the user confirmation being rejected later.
The real problem however was not really that conn->auth_type couldn't
represent the true value but that we were checking the local MITM
requirement in an incorrect way. It's perfectly fine to let auth_type
follow what we tell the controller since we're still tracking the target
security level with conn->pending_sec_level.
This patch updates the check for local MITM requirement in the
hci_user_confirm_request_evt function to use the locally requested
security level and ensures that auth_type always represents what we tell
the controller. All other code in hci_user_confirm_request_evt still
uses the auth_type instead of pending_sec_level for determining whether
to do just-works or not, since that's the only value that's in sync with
what the remote device knows.
Signed-off-by: Johan Hedberg <johan.hedberg@xxxxxxxxx>
Tested-by: Szymon Janc <szymon.janc@xxxxxxxxx>
Signed-off-by: Marcel Holtmann <marcel@xxxxxxxxxxxx>
Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
---
net/bluetooth/hci_event.c | 17 ++++++++---------
1 file changed, 8 insertions(+), 9 deletions(-)
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -3538,18 +3538,14 @@ static void hci_io_capa_request_evt(stru
/* If we are initiators, there is no remote information yet */
if (conn->remote_auth == 0xff) {
- cp.authentication = conn->auth_type;
-
/* Request MITM protection if our IO caps allow it
* except for the no-bonding case.
- * conn->auth_type is not updated here since
- * that might cause the user confirmation to be
- * rejected in case the remote doesn't have the
- * IO capabilities for MITM.
*/
if (conn->io_capability != HCI_IO_NO_INPUT_OUTPUT &&
cp.authentication != HCI_AT_NO_BONDING)
- cp.authentication |= 0x01;
+ conn->auth_type |= 0x01;
+
+ cp.authentication = conn->auth_type;
} else {
conn->auth_type = hci_get_auth_req(conn);
cp.authentication = conn->auth_type;
@@ -3621,9 +3617,12 @@ static void hci_user_confirm_request_evt
rem_mitm = (conn->remote_auth & 0x01);
/* If we require MITM but the remote device can't provide that
- * (it has NoInputNoOutput) then reject the confirmation request
+ * (it has NoInputNoOutput) then reject the confirmation
+ * request. We check the security level here since it doesn't
+ * necessarily match conn->auth_type.
*/
- if (loc_mitm && conn->remote_cap == HCI_IO_NO_INPUT_OUTPUT) {
+ if (conn->pending_sec_level > BT_SECURITY_MEDIUM &&
+ conn->remote_cap == HCI_IO_NO_INPUT_OUTPUT) {
BT_DBG("Rejecting request: remote device can't provide MITM");
hci_send_cmd(hdev, HCI_OP_USER_CONFIRM_NEG_REPLY,
sizeof(ev->bdaddr), &ev->bdaddr);
Patches currently in stable-queue which might be from johan.hedberg@xxxxxxxxx are
queue-3.16/bluetooth-fix-using-uninitialized-variable-when-pairing.patch
queue-3.16/bluetooth-fix-tracking-local-ssp-authentication-requirement.patch
queue-3.16/bluetooth-fix-merge-of-advertising-data-and-scan-response-data.patch
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html