netdev - Re: [BUG]Bluetooth: possible semantic bug when the status field of the HCI_Connection

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: <CABBYNZJZbiyhnary2F7iZMKg5xSFKNV0iRVJ6ye7NayS-z-a0Q@mail.gmail.com>
Date: Fri, 4 Aug 2023 22:09:44 -0700
From: Luiz Augusto von Dentz <luiz.dentz@...il.com>
To: Xinyu 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: possible semantic bug when the status field of
 the HCI_Connection_Complete packet set to non-zero

Hi,

On Fri, Aug 4, 2023 at 9:35 PM Xinyu Liu <LXYbhu@...a.edu.cn> wrote:
>
> Hello,
>
> Our fuzzing tool finds a possible semantic bug in the Bluetooth system in Linux 6.2:
>
> During the connection process, the host server needs to receive the HCI_Connection_Complete packet from the hardware controller. In normal cases, the status field of this packet is zero, which means that the connection is successfully completed:
>
> However, in our testing, when the status field was set to non-zero, 47 for instance, the Bluetooth connection failed. After that, when we attempt to reestablish a Bluetooth connection, the connection always fails. Upon analyzing the event packets sent from the controller to the host server, we observed that the Status field of the HCI_Command_Status packet becomes 0B, indicating that the controller believes the connection already exists. This situation has been causing the connection failure persistently:

That seems like a link-layer issue, the controller is saying the
connection had failed, and 0x0b also doesn't help either except if you
are saying that the other parameters are actually valid (e.g. handle),
that said the spec seems pretty clear about status other than 0x00
means the connection had failed:

BLUETOOTH CORE SPECIFICATION Version 5.3 | Vol 4, Part E
page 2170

0x01 to 0xFF Connection failed to Complete. See [Vol 1] Part F,
Controller Error Codes
for a list of error codes and descriptions.

>
> In our understanding, it would be more preferable if a single failed Bluetooth connection does not result in subsequent connections also failing. We believe that having some mechanism to facilitate Bluetooth's recovery and restoration to normal functionality could be considered as a potentially better option.
>
> We are not sure whether this is a semantic bug or implementation feature in the Linux kernel. Any feedback would be appreciated, thanks!

Well we can't do much about the dangling connection if we don't know
its handle to be able to disconnect since there is no command to
disconnect by address if that is what you were expecting us to do, so
the bottom line seems to be that sending 0x0b to the controller is
useless since we can't do anything about at the host, well other than
reset but would likely affect other functionality as well.


-- 
Luiz Augusto von Dentz