Bluetooth: Fix tracking local SSP authentication requirement
authorJohan Hedberg <johan.hedberg@intel.com>
Fri, 11 Jul 2014 12:32:23 +0000 (15:32 +0300)
committerMarcel Holtmann <marcel@holtmann.org>
Fri, 11 Jul 2014 13:23:23 +0000 (15:23 +0200)
commit6c53823ae0e10e723131055e1e65dd6a328a228e
tree99204b4d1eb473fb20d167bca8c995c1ec00227e
parent6afd04ad6b6608fe2d9abce120bd8c0bc6aba287
Bluetooth: Fix tracking local SSP authentication requirement

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@intel.com>
Tested-by: Szymon Janc <szymon.janc@tieto.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Cc: stable@vger.kernel.org # 3.16
net/bluetooth/hci_event.c