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