Created attachment 305410 [details] wireshark screenshot Our fuzzing tool finds a possible semantic bug in the Bluetooth system in Linux 6.2: According to the core specification v5.4, the HCI_Inquiry command triggers the BR/EDR Controller to enter Inquiry Mode, a process used for discovering nearby BR/EDR Controllers. Furthermore, it is specified that an HCI_Command_Status event should be sent to the Host when the BR/EDR Controller has started the Inquiry process. In our testing, if a related HCI_Command_Status event is sent by the controller without a preceding HCI_Inquiry command from the host, this could lead to a failure in establishing Bluetooth connections. Through our examination and debugging of the Linux 6.2 source code, we have identified the underlying cause of the observed phenomenon: (1.1) When the HCI_Command_Status event related to the HCI_Inquiry command is received, the function hci_cs_inquiry (/net/bluetooth/hci_event.c:2289) is called. (1.2) This leads to the execution of set_bit(HCI_INQUIRY, &hdev->flags); (/net/bluetooth/hci_event.c:2298). (2.1) Upon initiating an ACL connection for the first time, the function hci_acl_create_connection (/net/bluetooth/hci_conn.c:212) is called. (2.2) The result of test_bit(HCI_INQUIRY, &hdev->flags) (/net/bluetooth/hci_conn.c:228) being true causes the connection's state to change to BT_CONNECT2, and the HCI_Inquiry_Cancel command is sent. (3.1) When the HCI_Command_Complete event related to the HCI_Inquiry_Cancel command is received, the function hci_cc_inquiry_cancel (/net/bluetooth/hci_event.c:84) is called. (3.2) The Status field of the HCI_Command_Complete event being 0x0c results in the execution of return rp->status; (/net/bluetooth/hci_event.c:104). (4.1) A timeout triggers hci_conn_timeout (/net/bluetooth/hci_conn.c:638), which in turn calls hci_abort_conn (/net/bluetooth/hci_conn.c:2771). (4.2) This leads to the execution of case BT_CONNECT2: (/net/bluetooth/hci_conn.c:2771), where the HCI_Reject_Connection_Request command is sent. We are not sure whether this is a semantic bug or implementation feature in the Linux kernel. Any feedback would be appreciated, thanks!
(In reply to Si-Jie Bai from comment #0) > Created attachment 305410 [details] > wireshark screenshot > > Our fuzzing tool finds a possible semantic bug in the Bluetooth system in > Linux 6.2: > > According to the core specification v5.4, the HCI_Inquiry command triggers > the BR/EDR Controller to enter Inquiry Mode, a process used for discovering > nearby BR/EDR Controllers. Furthermore, it is specified that an > HCI_Command_Status event should be sent to the Host when the BR/EDR > Controller has started the Inquiry process. > > In our testing, if a related HCI_Command_Status event is sent by the > controller without a preceding HCI_Inquiry command from the host, this could > lead to a failure in establishing Bluetooth connections. > > Through our examination and debugging of the Linux 6.2 source code, we have > identified the underlying cause of the observed phenomenon: > > (1.1) When the HCI_Command_Status event related to the HCI_Inquiry command > is received, the function hci_cs_inquiry (/net/bluetooth/hci_event.c:2289) > is called. > > (1.2) This leads to the execution of set_bit(HCI_INQUIRY, &hdev->flags); > (/net/bluetooth/hci_event.c:2298). > > (2.1) Upon initiating an ACL connection for the first time, the function > hci_acl_create_connection (/net/bluetooth/hci_conn.c:212) is called. > > (2.2) The result of test_bit(HCI_INQUIRY, &hdev->flags) > (/net/bluetooth/hci_conn.c:228) being true causes the connection's state to > change to BT_CONNECT2, and the HCI_Inquiry_Cancel command is sent. > > (3.1) When the HCI_Command_Complete event related to the HCI_Inquiry_Cancel > command is received, the function hci_cc_inquiry_cancel > (/net/bluetooth/hci_event.c:84) is called. > > (3.2) The Status field of the HCI_Command_Complete event being 0x0c results > in the execution of return rp->status; (/net/bluetooth/hci_event.c:104). > > (4.1) A timeout triggers hci_conn_timeout (/net/bluetooth/hci_conn.c:638), > which in turn calls hci_abort_conn (/net/bluetooth/hci_conn.c:2771). > > (4.2) This leads to the execution of case BT_CONNECT2: > (/net/bluetooth/hci_conn.c:2771), where the HCI_Reject_Connection_Request > command is sent. > > We are not sure whether this is a semantic bug or implementation feature in > the Linux kernel. Any feedback would be appreciated, thanks!
(In reply to Si-Jie Bai from comment #0) > Created attachment 305410 [details] > wireshark screenshot > > Our fuzzing tool finds a possible semantic bug in the Bluetooth system in > Linux 6.2: > > According to the core specification v5.4, the HCI_Inquiry command triggers > the BR/EDR Controller to enter Inquiry Mode, a process used for discovering > nearby BR/EDR Controllers. Furthermore, it is specified that an > HCI_Command_Status event should be sent to the Host when the BR/EDR > Controller has started the Inquiry process. > > In our testing, if a related HCI_Command_Status event is sent by the > controller without a preceding HCI_Inquiry command from the host, this could > lead to a failure in establishing Bluetooth connections. > > Through our examination and debugging of the Linux 6.2 source code, we have > identified the underlying cause of the observed phenomenon: > > (1.1) When the HCI_Command_Status event related to the HCI_Inquiry command > is received, the function hci_cs_inquiry (/net/bluetooth/hci_event.c:2289) > is called. > > (1.2) This leads to the execution of set_bit(HCI_INQUIRY, &hdev->flags); > (/net/bluetooth/hci_event.c:2298). > > (2.1) Upon initiating an ACL connection for the first time, the function > hci_acl_create_connection (/net/bluetooth/hci_conn.c:212) is called. > > (2.2) The result of test_bit(HCI_INQUIRY, &hdev->flags) > (/net/bluetooth/hci_conn.c:228) being true causes the connection's state to > change to BT_CONNECT2, and the HCI_Inquiry_Cancel command is sent. > > (3.1) When the HCI_Command_Complete event related to the HCI_Inquiry_Cancel > command is received, the function hci_cc_inquiry_cancel > (/net/bluetooth/hci_event.c:84) is called. > > (3.2) The Status field of the HCI_Command_Complete event being 0x0c results > in the execution of return rp->status; (/net/bluetooth/hci_event.c:104). > > (4.1) A timeout triggers hci_conn_timeout (/net/bluetooth/hci_conn.c:638), > which in turn calls hci_abort_conn (/net/bluetooth/hci_conn.c:2771). > > (4.2) This leads to the execution of case BT_CONNECT2: > (/net/bluetooth/hci_conn.c:2771), where the HCI_Reject_Connection_Request > command is sent. > > We are not sure whether this is a semantic bug or implementation feature in > the Linux kernel. Any feedback would be appreciated, thanks! Can you check latest mainline (currently v6.7-rc1)?
https://patchwork.kernel.org/project/bluetooth/patch/20231120151039.323068-1-luiz.dentz@gmail.com/
(In reply to Bagas Sanjaya from comment #2) > (In reply to Si-Jie Bai from comment #0) > > Created attachment 305410 [details] > > wireshark screenshot > > > > Our fuzzing tool finds a possible semantic bug in the Bluetooth system in > > Linux 6.2: > > > > According to the core specification v5.4, the HCI_Inquiry command triggers > > the BR/EDR Controller to enter Inquiry Mode, a process used for discovering > > nearby BR/EDR Controllers. Furthermore, it is specified that an > > HCI_Command_Status event should be sent to the Host when the BR/EDR > > Controller has started the Inquiry process. > > > > In our testing, if a related HCI_Command_Status event is sent by the > > controller without a preceding HCI_Inquiry command from the host, this > could > > lead to a failure in establishing Bluetooth connections. > > > > Through our examination and debugging of the Linux 6.2 source code, we have > > identified the underlying cause of the observed phenomenon: > > > > (1.1) When the HCI_Command_Status event related to the HCI_Inquiry command > > is received, the function hci_cs_inquiry (/net/bluetooth/hci_event.c:2289) > > is called. > > > > (1.2) This leads to the execution of set_bit(HCI_INQUIRY, &hdev->flags); > > (/net/bluetooth/hci_event.c:2298). > > > > (2.1) Upon initiating an ACL connection for the first time, the function > > hci_acl_create_connection (/net/bluetooth/hci_conn.c:212) is called. > > > > (2.2) The result of test_bit(HCI_INQUIRY, &hdev->flags) > > (/net/bluetooth/hci_conn.c:228) being true causes the connection's state to > > change to BT_CONNECT2, and the HCI_Inquiry_Cancel command is sent. > > > > (3.1) When the HCI_Command_Complete event related to the HCI_Inquiry_Cancel > > command is received, the function hci_cc_inquiry_cancel > > (/net/bluetooth/hci_event.c:84) is called. > > > > (3.2) The Status field of the HCI_Command_Complete event being 0x0c results > > in the execution of return rp->status; (/net/bluetooth/hci_event.c:104). > > > > (4.1) A timeout triggers hci_conn_timeout (/net/bluetooth/hci_conn.c:638), > > which in turn calls hci_abort_conn (/net/bluetooth/hci_conn.c:2771). > > > > (4.2) This leads to the execution of case BT_CONNECT2: > > (/net/bluetooth/hci_conn.c:2771), where the HCI_Reject_Connection_Request > > command is sent. > > > > We are not sure whether this is a semantic bug or implementation feature in > > the Linux kernel. Any feedback would be appreciated, thanks! > > Can you check latest mainline (currently v6.7-rc1)? Thank you for your valuable input and feedback! I greatly appreciate your response. I have confirmed that the bug can be reproduced on the latest mainline and it generates the same issue. Comment3 has already provided a patch for this bug: https://patchwork.kernel.org/project/bluetooth/patch/20231120151039.323068-1-luiz.dentz@gmail.com/ I have confirmed that the bug has been effectively resolved on the latest mainline with this patch. I sincerely appreciate your valuable input and solution once again. It has greatly assisted us in the bug fixing process!
(In reply to Luiz Von Dentz from comment #3) > https://patchwork.kernel.org/project/bluetooth/patch/20231120151039.323068-1- > luiz.dentz@gmail.com/ Thank you for your valuable input and feedback! I greatly appreciate your response. I have confirmed that the bug has been effectively resolved on the latest mainline with this patch. I sincerely appreciate your valuable input and solution once again. It has greatly assisted us in the bug fixing process!
(In reply to Si-Jie Bai from comment #5) > (In reply to Luiz Von Dentz from comment #3) > > > https://patchwork.kernel.org/project/bluetooth/patch/20231120151039.323068-1- > > luiz.dentz@gmail.com/ > > Thank you for your valuable input and feedback! I greatly appreciate your > response. > > I have confirmed that the bug has been effectively resolved on the latest > mainline with this patch. > > I sincerely appreciate your valuable input and solution once again. It has > greatly assisted us in the bug fixing process! Do you mind replying with a Tested-by on the mailing list.
(In reply to Luiz Von Dentz from comment #6) > (In reply to Si-Jie Bai from comment #5) > > (In reply to Luiz Von Dentz from comment #3) > > > > > > https://patchwork.kernel.org/project/bluetooth/patch/20231120151039.323068-1- > > > luiz.dentz@gmail.com/ > > > > Thank you for your valuable input and feedback! I greatly appreciate your > > response. > > > > I have confirmed that the bug has been effectively resolved on the latest > > mainline with this patch. > > > > I sincerely appreciate your valuable input and solution once again. It has > > greatly assisted us in the bug fixing process! > > Do you mind replying with a Tested-by on the mailing list. Hello Luiz Von Dentz, I have tested the patch related to bug report 218151 in the Linux kernel version v6.7-rc1. My testing focused on reproducing the steps outlined in the bug report to evaluate Bluetooth connectivity. During my tests, I executed the steps to reproduce the bug, and I am pleased to report that the Bluetooth connection was successful, indicating that the issue has been resolved in this kernel version. Based on these results, I can confirm that the patch effectively addresses the issue in the specified environment. Tested-by: Si-Jie Bai <sy2239101@buaa.edu.cn> Best regards, Si-Jie Bai