linux-kernel - Re: [PATCH] Bluetooth: Add filter for Qualcomm debug packets

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>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAJNNDm=C4PFTUy93jpKDNwZPbDt4fC-rykWRHC=NDsL_fkkJiQ@mail.gmail.com>
Date: Tue, 7 Oct 2025 11:37:29 -0400
From: Pascal Giard <evilynux@...il.com>
To: Luiz Augusto von Dentz <luiz.dentz@...il.com>
Cc: marcel@...tmann.org, linux-bluetooth@...r.kernel.org, 
	linux-kernel@...r.kernel.org, Pascal Giard <pascal.giard@...mtl.ca>
Subject: Re: [PATCH] Bluetooth: Add filter for Qualcomm debug packets

Hi Luiz,


Le mar. 7 oct. 2025, à 10 h 46, Luiz Augusto von Dentz
<luiz.dentz@...il.com> a écrit :
>
> Hi Pascal,
>
> On Tue, Oct 7, 2025 at 10:16 AM Pascal Giard <evilynux@...il.com> wrote:
> >
> > Dear Luiz,
> >
> > Le lun. 6 oct. 2025, à 13 h 21, Luiz Augusto von Dentz
> > <luiz.dentz@...il.com> a écrit :
> > >
> > > Hi Pascal,
> > >
> > > On Fri, Oct 3, 2025 at 4:59 PM Pascal Giard <evilynux@...il.com> wrote:
> > > >
> > > > Some Qualcomm Bluetooth controllers, e.g., QCNFA765 send debug packets
> > > > as ACL frames with header 0x2EDC. The kernel misinterprets these as
> > > > malformed ACL packets, causing repeated errors:
> > > >
> > > >   Bluetooth: hci0: ACL packet for unknown connection handle 3804
> > > >
> > > > This can occur hundreds of times per minute, greatly cluttering logs.
> > > > On my computer, I am observing approximately 7 messages per second
> > > > when streaming audio to a speaker.
> > > >
> > > > For Qualcomm controllers exchanging over UART, hci_qca.c already
> > > > filters out these debug packets. This patch is for controllers
> > > > not going through UART, but USB.
> > > >
> > > > This patch filters these packets in btusb_recv_acl() before they reach
> > > > the HCI layer, redirecting them to hci_recv_diag().
> > > >
> > > > Tested on: Thinkpad T14 gen2 (AMD) with QCNFA765, kernel 6.16.9
> > > >
> > > > Signed-off-by: Pascal Giard <pascal.giard@...mtl.ca>
> > > > ---
> > > >  drivers/bluetooth/btusb.c | 9 +++++++++
> > > >  1 file changed, 9 insertions(+)
> > > >
> > > > diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
> > > > index 5e9ebf0c5312..900400646315 100644
> > > > --- a/drivers/bluetooth/btusb.c
> > > > +++ b/drivers/bluetooth/btusb.c
> > > > @@ -68,6 +68,9 @@ static struct usb_driver btusb_driver;
> > > >  #define BTUSB_ACTIONS_SEMI             BIT(27)
> > > >  #define BTUSB_BARROT                   BIT(28)
> > > >
> > > > +/* Qualcomm firmware debug packets header */
> > > > +#define QCA_DEBUG_HEADER       0x2EDC
> > > > +
> > > >  static const struct usb_device_id btusb_table[] = {
> > > >         /* Generic Bluetooth USB device */
> > > >         { USB_DEVICE_INFO(0xe0, 0x01, 0x01) },
> > > > @@ -1229,6 +1232,12 @@ static int btusb_recv_intr(struct btusb_data *data, void *buffer, int count)
> > > >
> > > >  static int btusb_recv_acl(struct btusb_data *data, struct sk_buff *skb)
> > > >  {
> > > > +       /* Drop QCA firmware debug packets sent as ACL frames */
> > > > +       if (skb->len >= 2) {
> > > > +               if (get_unaligned_le16(skb->data) == QCA_DEBUG_HEADER)
> > > > +                       return hci_recv_diag(data->hdev, skb);
> > > > +       }
> > >
> > > Well it turns out that handle 0x2EDC is actually a valid handle, so we
> > > can't just reclassify these packets just because Qualcomm thinks that
> > > it could reserve it for its own, so this needs to be using
> > > classify_pkt_type to reclassify the packets to the handle 0x2EDC to
> > > HCI_DIAG_PKT for the models affected.
> >
> > Thank you for considering my patch. Based on your comment, I had a
> > look at how btintel.c uses classify_pkt_type, and I think I understand
> > what you are expecting of me.
> >
> > Before I submit a new version, should I go very narrow (just the
> > VID:PID=0x0489:0xe0d0 I know for certain has the issue) or should I
> > lump in all modules with the WCN6855 chip? The latter seems somewhat
> > reasonable to me given how hci_qca.c does it (even broader).
> > Therefore, I'm thinking of reusing BTUSB_QCA_WCN6855.
>
> I'm afraid you will need to figure it out, probably only qualcomm
> folks can tell which chips use this logic, also is it always enabled
> to send debug information or that requires a vendor command to enable
> debug traces to be sent using that handle?

I went with lumping in all WCN6855 chips. I have not sent any command
to enable debug traces, so my understanding is that this is the
default behavior on at least some controllers.
I have sent a new version of the patch for your consideration, where I
have tried to follow the approach you suggested.

Thanks again!

-Pascal