linux-kernel - Re: [REGRESSION] Bluetooth adapter provided by `btusb` not recognized since v6.13.2

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

Message-ID: <5rFwJreAVujrYXDGZZxW32PHa6HZ29PEP4R5-dqS9dbU3FI__qe3zIUx31TIHO_LjuURCSwaGucSFBPeXAjf00XzAxTzXbmf1AaY6neyQ3Q=@proton.me>
Date: Thu, 20 Nov 2025 00:43:15 +0000
From: incogcyberpunk@...ton.me
To: Doug Anderson <dianders@...omium.org>
Cc: Thorsten Leemhuis <regressions@...mhuis.info>, "regressions@...ts.linux.dev" <regressions@...ts.linux.dev>, "marcel@...tmann.org" <marcel@...tmann.org>, "luiz.dentz@...il.com" <luiz.dentz@...il.com>, "linux-bluetooth@...r.kernel.org" <linux-bluetooth@...r.kernel.org>, "johan.hedberg@...il.com" <johan.hedberg@...il.com>, "sean.wang@...iatek.com" <sean.wang@...iatek.com>, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [REGRESSION] Bluetooth adapter provided by `btusb` not recognized since v6.13.2

Yes, manually updating `drivers/btusb/btusb.c` , with the below proposed patch fixes the regression issue.
The proposed patch solves the regression of `bluetooth adapter provided by btusb not being recognized in both the stable and the mainline kernel since 6.13.2`

The proposed patch: 
`
index a722446ec73d..1466e0f1865d 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -2714,6 +2714,11 @@ static void btusb_mtk_claim_iso_intf(struct btusb_data *data)
 	struct btmtk_data *btmtk_data = hci_get_priv(data->hdev);
 	int err;
 
+	if (!btmtk_data->isopkt_intf) {
+		bt_dev_err(data->hdev, "Can't claim NULL iso interface");
+		return;
+	}
+
 	/*
 	 * The function usb_driver_claim_interface() is documented to need
 	 * locks held if it's not called from a probe routine. The code here
`

I applied the patch as suggested, but now what do I have to do to get this fixed upstream and fixed in the next mainline & stable releases.

Also, could you brief a bit, on how this proposed patch containing , a NULL check for the `btmtk_data->isopkt_intf`; solves the problems introduced by the problematic commit with: [ Upstream commit e9087e828827e5a5c85e124ce77503f2b81c3491 ]


Regards,
IncogCyberpunk