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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ