From: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
To: Xin-Yu Liu <LXYbhu@buaa.edu.cn>
Cc: marcel@holtmann.org, johan.hedberg@gmail.com,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, baijiaju1990@gmail.com, sy2239101@buaa.edu.cn,
linux-bluetooth@vger.kernel.org, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org
Subject: Re: [BUG]Bluetooth: HCI_Connection_Complete: possible semantic bug when HCI_Connection_Complete is discarded
Date: Tue, 15 Aug 2023 10:53:14 -0700 [thread overview]
Message-ID: <CABBYNZ+_LFZ4uNHRKqb39_J-vDKj2qkmiTGikP8uMi3v4YtLsg@mail.gmail.com> (raw)
In-Reply-To: <869240bf-7f91-4131-b56a-7ac2585dee4e@buaa.edu.cn>
Hi,
On Tue, Aug 15, 2023 at 6:56 AM Xin-Yu Liu <LXYbhu@buaa.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
parent reply other threads:[~2023-08-15 17:54 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <869240bf-7f91-4131-b56a-7ac2585dee4e@buaa.edu.cn>]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CABBYNZ+_LFZ4uNHRKqb39_J-vDKj2qkmiTGikP8uMi3v4YtLsg@mail.gmail.com \
--to=luiz.dentz@gmail.com \
--cc=LXYbhu@buaa.edu.cn \
--cc=baijiaju1990@gmail.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=johan.hedberg@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-bluetooth@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marcel@holtmann.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sy2239101@buaa.edu.cn \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.