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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CABBYNZ+0W5Aaq1BfzMc1fcQGCUFrDfQcDyffaG=+0LE0=G-wug@mail.gmail.com>
Date: Tue, 7 Oct 2025 10:45:46 -0400
From: Luiz Augusto von Dentz <luiz.dentz@...il.com>
To: Pascal Giard <evilynux@...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 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?

> Thanks,
>
> -Pascal
> --
> Homepage (http://pascal.giard.info)
> École de technologie supérieure (http://etsmtl.ca)



-- 
Luiz Augusto von Dentz