| Message ID | 20230906034754.1.I0cd65c6ecb991a13b224614c32c1946f9eecea3d@changeid (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | Bluetooth: Avoid redundant authentication | expand |
| Context | Check | Description |
|---|---|---|
| tedd_an/pre-ci_am | success | Success |
| tedd_an/CheckPatch | success | CheckPatch PASS |
| tedd_an/GitLint | success | Gitlint PASS |
| tedd_an/SubjectPrefix | success | Gitlint PASS |
| tedd_an/BuildKernel | success | BuildKernel PASS |
| tedd_an/CheckAllWarning | success | CheckAllWarning PASS |
| tedd_an/CheckSparse | success | CheckSparse PASS |
| tedd_an/CheckSmatch | success | CheckSparse PASS |
| tedd_an/BuildKernel32 | success | BuildKernel32 PASS |
| tedd_an/TestRunnerSetup | success | TestRunnerSetup PASS |
| tedd_an/TestRunner_l2cap-tester | success | TestRunner PASS |
| tedd_an/TestRunner_iso-tester | success | TestRunner PASS |
| tedd_an/TestRunner_bnep-tester | success | TestRunner PASS |
| tedd_an/TestRunner_mgmt-tester | success | TestRunner PASS |
| tedd_an/TestRunner_rfcomm-tester | success | TestRunner PASS |
| tedd_an/TestRunner_sco-tester | success | TestRunner PASS |
| tedd_an/TestRunner_ioctl-tester | success | TestRunner PASS |
| tedd_an/TestRunner_mesh-tester | success | TestRunner PASS |
| tedd_an/TestRunner_smp-tester | success | TestRunner PASS |
| tedd_an/TestRunner_userchan-tester | success | TestRunner PASS |
| tedd_an/IncrementalBuild | success | Incremental Build PASS |
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=781869 ---Test result--- Test Summary: CheckPatch PASS 0.63 seconds GitLint PASS 0.25 seconds SubjectPrefix PASS 0.07 seconds BuildKernel PASS 39.68 seconds CheckAllWarning PASS 43.41 seconds CheckSparse PASS 48.95 seconds CheckSmatch PASS 133.42 seconds BuildKernel32 PASS 38.55 seconds TestRunnerSetup PASS 581.13 seconds TestRunner_l2cap-tester PASS 32.76 seconds TestRunner_iso-tester PASS 70.55 seconds TestRunner_bnep-tester PASS 13.60 seconds TestRunner_mgmt-tester PASS 246.02 seconds TestRunner_rfcomm-tester PASS 19.89 seconds TestRunner_sco-tester PASS 23.17 seconds TestRunner_ioctl-tester PASS 22.51 seconds TestRunner_mesh-tester PASS 16.90 seconds TestRunner_smp-tester PASS 17.71 seconds TestRunner_userchan-tester PASS 14.09 seconds IncrementalBuild PASS 35.72 seconds --- Regards, Linux Bluetooth
Hi Ying, On Tue, Sep 5, 2023 at 8:48 PM Ying Hsu <yinghsu@chromium.org> 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. > > Signed-off-by: Ying Hsu <yinghsu@chromium.org> > --- > Tested CTS Verifier 13 Secure Server test on a chromebook with AC9560. > > net/bluetooth/hci_conn.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c > index 9d5057cef30a..27c0a3080631 100644 > --- a/net/bluetooth/hci_conn.c > +++ b/net/bluetooth/hci_conn.c > @@ -2420,10 +2420,11 @@ int hci_conn_security(struct hci_conn *conn, __u8 sec_level, __u8 auth_type, > goto encrypt; > > /* An authenticated combination key has sufficient security for > - security level 3. */ > + * security level 3 or lower. > + */ > if ((conn->key_type == HCI_LK_AUTH_COMBINATION_P192 || > conn->key_type == HCI_LK_AUTH_COMBINATION_P256) && > - sec_level == BT_SECURITY_HIGH) > + sec_level <= BT_SECURITY_HIGH) > goto encrypt; > > /* An unauthenticated combination key has sufficient security for > -- > 2.42.0.283.g2d96d420d3-goog How about we do something like: https://gist.github.com/Vudentz/be49a40789ec713f9441face9bd642cc That way we cover similar situations for other security levels.
diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c index 9d5057cef30a..27c0a3080631 100644 --- a/net/bluetooth/hci_conn.c +++ b/net/bluetooth/hci_conn.c @@ -2420,10 +2420,11 @@ int hci_conn_security(struct hci_conn *conn, __u8 sec_level, __u8 auth_type, goto encrypt; /* An authenticated combination key has sufficient security for - security level 3. */ + * security level 3 or lower. + */ if ((conn->key_type == HCI_LK_AUTH_COMBINATION_P192 || conn->key_type == HCI_LK_AUTH_COMBINATION_P256) && - sec_level == BT_SECURITY_HIGH) + sec_level <= BT_SECURITY_HIGH) goto encrypt; /* An unauthenticated combination key has sufficient security for
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. net/bluetooth/hci_conn.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)