lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <e6662867-9296-4e40-ba1d-5bb56a80eaff@buaa.edu.cn>
Date:   Fri, 25 Aug 2023 22:13:56 +0800
From:   Xin-Yu Liu <LXYbhu@...a.edu.cn>
To:     Luiz Augusto von Dentz <luiz.dentz@...il.com>,
        Xin-Yu Liu <by2239112@...a.edu.cn>
Cc:     marcel@...tmann.org, johan.hedberg@...il.com, baijiaju@...a.edu.cn,
        sy2239101@...a.edu.cn, linux-bluetooth@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] net: bluetooth: fix consistent connection failure caused
 by the loss of HCI_Connection_Complete event

Hi,

Thanks for your reply!

After receiving your guidance, we implement the code changes you
provided to us and find that the bug has indeed been resolved.

Thank you for your time, support, and for sharing your knowledge.
We look forward to continuing our involvement in the Linux community
and hope to contribute positively, just as you have done.

Best regards,
Xin-Yu Liu

2023/8/24 5:26, Luiz Augusto von Dentz wrote:
> Hi,
>
> On Wed, Aug 23, 2023 at 5:52 AM Xin-Yu Liu <by2239112@...a.edu.cn> wrote:
>> During a connection attempt, if the HCI_Connection_Complete event
>> is lost and not received by the Host, it will result in
>> a connection failure.
>> In that process, the hci_conn, the handle of which is still
>> HCI_CONN_HANDLE_UNSET, will not be removed from the conn_hash
>> as it would during a regular disconnection opration.
>> Consequently, when an ACL connection is initiated for the same device,
>> the hci_conn is found in hash_conn based on "ba", with its state remaining
>> BT_CONNECT. Then the Host will send an HCI_Create_Connection_Cancel
>> command, which will result in subsequent Bluetooth connections
>> for the same device consistently failing.
>>
>> In order to solve the potential bug, if the hci_conn's state is
>> BT_CONNECT and handle is HCI_CONN_HANDLE_UNSET, remove this hci_conn
>> from conn_hash. This adjustment could potentially help ensure that the
>> specific conn is cleaned up at the appropriate times, then the subsequent
>> connection for the same device will no longer experience failures.
>>
>> Signed-off-by: Xin-Yu Liu <by2239112@...a.edu.cn>
>> ---
>>   net/bluetooth/hci_conn.c | 4 ++++
>>   1 file changed, 4 insertions(+)
>>
>> diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
>> index 76222565e..219c62579 100644
>> --- a/net/bluetooth/hci_conn.c
>> +++ b/net/bluetooth/hci_conn.c
>> @@ -2886,6 +2886,10 @@ int hci_abort_conn(struct hci_conn *conn, u8 reason)
>>                  } else if (conn->type == ACL_LINK) {
>>                          if (conn->hdev->hci_ver < BLUETOOTH_VER_1_2)
>>                                  break;
>> +                       if (conn->state == HCI_CONN_HANDLE_UNSET) {
>> +                               hci_conn_cleanup(conn);
>> +                               break;
>> +                       }
> This won't apply upstream if you are wondering why CI hasn't managed
> to pick it up, this should be fixed by the following line if
> connection cannot be aborted:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/tree/net/bluetooth/hci_sync.c?id=c452805643ff9762626f2c87c2640ab7c7099eb8#n5432
>
>>                          r = hci_send_cmd(conn->hdev,
>>                                           HCI_OP_CREATE_CONN_CANCEL,
>>                                           6, &conn->dst);
>> --
>> 2.25.1
>>
>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ