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>] [day] [month] [year] [list]
Message-ID: <CABBYNZJtGo2SSRREH9jpAKM8UoEUNgK9uzyPuzqDdks_KBoDdw@mail.gmail.com>
Date: Mon, 26 Jun 2023 12:25:12 -0700
From: Luiz Augusto von Dentz <luiz.dentz@...il.com>
To: 刘新宇 <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_Command_Status: possible semantic bug when
 Num_HCI_Command_Packets set to zero

Hi,

On Mon, Jun 26, 2023 at 7:25 AM 刘新宇 <lxybhu@...a.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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ