From: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
To: 刘新宇 <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_Command_Status: possible semantic bug when Num_HCI_Command_Packets set to zero
Date: Mon, 26 Jun 2023 12:25:12 -0700 [thread overview]
Message-ID: <CABBYNZJtGo2SSRREH9jpAKM8UoEUNgK9uzyPuzqDdks_KBoDdw@mail.gmail.com> (raw)
In-Reply-To: <259e755c.4eaad.188f817a0f3.Coremail.lxybhu@buaa.edu.cn>
Hi,
On Mon, Jun 26, 2023 at 7:25 AM 刘新宇 <lxybhu@buaa.edu.cn> wrote:
>
> Hello,
>
> Our fuzzing tool finds a possible semantic bug in the Bluetooth system in Linux 5.18:
>
> During the connection process, the host server needs to receive the HCI_Command_Status packet from the hardware controller. In normal cases, the Num_HCI_Command_Packets field of this packet is not zero, and the host server can normally handle this packet. However, in our testing, when the Num_HCI_Command_Packets field is set to zero, the Bluetooth functionality is totally stopped until it is manually reopened.
>
> In the Bluetooth Core Specification 5.4, the section 7.7.15 "Command Status event" says that:
>
> "The Num_HCI_Command_Packets event parameter allows the Controller to indicate the number of HCI command packets the Host can send to the Controller. If the Controller requires the Host to stop sending commands, the Num_HCI_Command_Packets event parameter will be set to zero."
>
> This section does not mean that the Bluetooth functionality needs to be totally stopped when Num_HCI_Command_Packets is zero. Maybe in this case, the Bluetooth functionality could be still available, but the host server could reject any packet until Num_HCI_Command_Packets is not zero.
Well it says, If the Controller requires the Host to stop sending
commands, so if your tool is sending 0 then it is requesting he host
to stop sending more commands, if you want it to continue just send
another Num_HCI_Command_Packets, or are you saying some other
functionality that doesn't require sending commands shall still work?
> 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,
> Xin-Yu Liu
--
Luiz Augusto von Dentz
parent reply other threads:[~2023-06-26 19:25 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <259e755c.4eaad.188f817a0f3.Coremail.lxybhu@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=CABBYNZJtGo2SSRREH9jpAKM8UoEUNgK9uzyPuzqDdks_KBoDdw@mail.gmail.com \
--to=luiz.dentz@gmail.com \
--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=lxybhu@buaa.edu.cn \
--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.