Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <ed32aad7-41c0-c84d-c1f3-085a4d43ce09@buaa.edu.cn>
In-Reply-To: <ed32aad7-41c0-c84d-c1f3-085a4d43ce09@buaa.edu.cn>
From:   Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Date:   Fri, 4 Aug 2023 22:09:44 -0700
Message-ID: <CABBYNZJZbiyhnary2F7iZMKg5xSFKNV0iRVJ6ye7NayS-z-a0Q@mail.gmail.com>
Subject: Re: [BUG]Bluetooth: possible semantic bug when the status field of
 the HCI_Connection_Complete packet set to non-zero
To:     Xinyu Liu <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
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Hi,

On Fri, Aug 4, 2023 at 9:35=E2=80=AFPM Xinyu Liu <LXYbhu@buaa.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_C=
onnection_Complete packet from the hardware controller. In normal cases, th=
e status field of this packet is zero, which means that the connection is s=
uccessfully completed:
>
> However, in our testing, when the status field was set to non-zero, 47 fo=
r instance, the Bluetooth connection failed. After that, when we attempt to=
 reestablish a Bluetooth connection, the connection always fails. Upon anal=
yzing the event packets sent from the controller to the host server, we obs=
erved that the Status field of the HCI_Command_Status packet becomes 0B, in=
dicating that the controller believes the connection already exists. This s=
ituation 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 Blue=
tooth 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 be=
tter 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.


--=20
Luiz Augusto von Dentz