[<prev] [next>] [day] [month] [year] [list]
Message-ID: <CABBYNZ+_LFZ4uNHRKqb39_J-vDKj2qkmiTGikP8uMi3v4YtLsg@mail.gmail.com>
Date: Tue, 15 Aug 2023 10:53:14 -0700
From: Luiz Augusto von Dentz <luiz.dentz@...il.com>
To: Xin-Yu Liu <LXYbhu@...a.edu.cn>
Cc: marcel@...tmann.org, johan.hedberg@...il.com, davem@...emloft.net,
edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com,
baijiaju1990@...il.com, sy2239101@...a.edu.cn,
linux-bluetooth@...r.kernel.org, linux-kernel@...r.kernel.org,
netdev@...r.kernel.org
Subject: Re: [BUG]Bluetooth: HCI_Connection_Complete: possible semantic bug
when HCI_Connection_Complete is discarded
Hi,
On Tue, Aug 15, 2023 at 6:56 AM Xin-Yu Liu <LXYbhu@...a.edu.cn> wrote:
>
> Hello,
>
> Our fuzzing tool finds a possible semantic bug in the Bluetooth system in Linux 6.2:
>
> According to the core specification v5.4, when connecting to a remote device, the Host sends an HCI_Create_Connection command to the Controller, and upon successful execution of this command, the Host receives an HCI_Connection_Complete event:
>
>
>
> In our testing, if the HCI_Connection_Complete event is discarded and not received by the Host, it will result in a connection failure. Subsequently, when attempting to reconnect to the same device, the Host does not send an HCI_Create_Connection command, but instead sends a Create Connection Cancel command and receives the corresponding HCI_Command_Complete event. However, the connection still fails. Performing the same steps after some time yields the same result:
>
>
>
> We are inclined to consider the possibility of occasional HCI event loss, and it is reasonable to expect Bluetooth to incorporate some solution for managing packet loss or implementing a timeout mechanism. However, based on our testing observations, the loss of an HCI_Connection_Complete event during a connection attempt appears to lead to subsequent connection failures, which could potentially be seen as less than optimal. There could be corresponding remedies to address this issue; for instance, implementing a timeout mechanism might be a more favorable option.
There is already a command timeout in place, as for packet loss that
should be handled by the underline driver as it depends on how
reliable the transport is. If you are saying the connection
cancel/abort logic does prevent new connection with the same peer that
would be a bug, that said if the attempts are concurrent, within the
command timeout, then the same hci_conn would be used as there should
be only 1 ACL at time for a given peer.
> We are not sure whether this is a semantic bug or implementation feature in the Linux kernel. Any feedback would be appreciated, thanks!
>
> Best wishes,
> Xinyu Liu
--
Luiz Augusto von Dentz
Powered by blists - more mailing lists