| Message ID | 20230907043933.v2.1.I0cd65c6ecb991a13b224614c32c1946f9eecea3d@changeid |
|---|---|
| State | Accepted |
| Commit | 4c8a783f388277d3e210f9d8d875585a75aa2bb1 |
| Headers | show |
| Series | [v2] Bluetooth: Avoid redundant authentication | expand |
This is automated email and please do not reply to this email! Dear submitter, Thank you for submitting the patches to the linux bluetooth mailing list. This is a CI test results with your patch series: PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=782141 ---Test result--- Test Summary: CheckPatch PASS 0.66 seconds GitLint PASS 0.30 seconds SubjectPrefix PASS 0.11 seconds BuildKernel PASS 32.62 seconds CheckAllWarning PASS 35.64 seconds CheckSparse PASS 40.47 seconds CheckSmatch PASS 113.20 seconds BuildKernel32 PASS 30.92 seconds TestRunnerSetup PASS 475.32 seconds TestRunner_l2cap-tester PASS 26.90 seconds TestRunner_iso-tester PASS 47.91 seconds TestRunner_bnep-tester PASS 10.35 seconds TestRunner_mgmt-tester PASS 220.23 seconds TestRunner_rfcomm-tester PASS 15.73 seconds TestRunner_sco-tester PASS 19.14 seconds TestRunner_ioctl-tester PASS 17.48 seconds TestRunner_mesh-tester PASS 13.01 seconds TestRunner_smp-tester PASS 13.90 seconds TestRunner_userchan-tester PASS 10.87 seconds IncrementalBuild PASS 29.19 seconds --- Regards, Linux Bluetooth
Hello: This patch was applied to bluetooth/bluetooth-next.git (master) by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>: On Thu, 7 Sep 2023 04:39:34 +0000 you wrote: > While executing the Android 13 CTS Verifier Secure Server test on a > ChromeOS device, it was observed that the Bluetooth host initiates > authentication for an RFCOMM connection after SSP completes. > When this happens, some Intel Bluetooth controllers, like AC9560, would > disconnect with "Connection Rejected due to Security Reasons (0x0e)". > > Historically, BlueZ did not mandate this authentication while an > authenticated combination key was already in use for the connection. > This behavior was changed since commit 7b5a9241b780 > ("Bluetooth: Introduce requirements for security level 4"). > So, this patch addresses the aforementioned disconnection issue by > restoring the previous behavior. > > [...] Here is the summary with links: - [v2] Bluetooth: Avoid redundant authentication https://git.kernel.org/bluetooth/bluetooth-next/c/4c8a783f3882 You are awesome, thank you!
diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c index 9d5057cef30a..7a6f20338db8 100644 --- a/net/bluetooth/hci_conn.c +++ b/net/bluetooth/hci_conn.c @@ -2413,34 +2413,41 @@ int hci_conn_security(struct hci_conn *conn, __u8 sec_level, __u8 auth_type, if (!test_bit(HCI_CONN_AUTH, &conn->flags)) goto auth; - /* An authenticated FIPS approved combination key has sufficient - * security for security level 4. */ - if (conn->key_type == HCI_LK_AUTH_COMBINATION_P256 && - sec_level == BT_SECURITY_FIPS) - goto encrypt; - - /* An authenticated combination key has sufficient security for - security level 3. */ - if ((conn->key_type == HCI_LK_AUTH_COMBINATION_P192 || - conn->key_type == HCI_LK_AUTH_COMBINATION_P256) && - sec_level == BT_SECURITY_HIGH) - goto encrypt; - - /* An unauthenticated combination key has sufficient security for - security level 1 and 2. */ - if ((conn->key_type == HCI_LK_UNAUTH_COMBINATION_P192 || - conn->key_type == HCI_LK_UNAUTH_COMBINATION_P256) && - (sec_level == BT_SECURITY_MEDIUM || sec_level == BT_SECURITY_LOW)) - goto encrypt; - - /* A combination key has always sufficient security for the security - levels 1 or 2. High security level requires the combination key - is generated using maximum PIN code length (16). - For pre 2.1 units. */ - if (conn->key_type == HCI_LK_COMBINATION && - (sec_level == BT_SECURITY_MEDIUM || sec_level == BT_SECURITY_LOW || - conn->pin_length == 16)) - goto encrypt; + switch (conn->key_type) { + case HCI_LK_AUTH_COMBINATION_P256: + /* An authenticated FIPS approved combination key has + * sufficient security for security level 4 or lower. + */ + if (sec_level <= BT_SECURITY_FIPS) + goto encrypt; + break; + case HCI_LK_AUTH_COMBINATION_P192: + /* An authenticated combination key has sufficient security for + * security level 3 or lower. + */ + if (sec_level <= BT_SECURITY_HIGH) + goto encrypt; + break; + case HCI_LK_UNAUTH_COMBINATION_P192: + case HCI_LK_UNAUTH_COMBINATION_P256: + /* An unauthenticated combination key has sufficient security + * for security level 2 or lower. + */ + if (sec_level <= BT_SECURITY_MEDIUM) + goto encrypt; + break; + case HCI_LK_COMBINATION: + /* A combination key has always sufficient security for the + * security levels 2 or lower. High security level requires the + * combination key is generated using maximum PIN code length + * (16). For pre 2.1 units. + */ + if (sec_level <= BT_SECURITY_MEDIUM || conn->pin_length == 16) + goto encrypt; + break; + default: + break; + } auth: if (test_bit(HCI_CONN_ENCRYPT_PEND, &conn->flags))
While executing the Android 13 CTS Verifier Secure Server test on a ChromeOS device, it was observed that the Bluetooth host initiates authentication for an RFCOMM connection after SSP completes. When this happens, some Intel Bluetooth controllers, like AC9560, would disconnect with "Connection Rejected due to Security Reasons (0x0e)". Historically, BlueZ did not mandate this authentication while an authenticated combination key was already in use for the connection. This behavior was changed since commit 7b5a9241b780 ("Bluetooth: Introduce requirements for security level 4"). So, this patch addresses the aforementioned disconnection issue by restoring the previous behavior. Signed-off-by: Ying Hsu <yinghsu@chromium.org> --- - Tested CTS Verifier 13 Secure Server test on a chromebook with AC9560. - Manual tests on classic mouse/keyboard/headset, BLE keyboard/mouse. Changes in v2: - Transitioned from multiple 'if' blocks to a 'switch-case' structure for clarity and maintainability. net/bluetooth/hci_conn.c | 63 ++++++++++++++++++++++------------------ 1 file changed, 35 insertions(+), 28 deletions(-)