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

From: Doug Anderson

Date: Thu Nov 20 2025 - 11:04:02 EST


Hi,

On Thu, Nov 20, 2025 at 2:14 AM <incogcyberpunk@xxxxxxxxx> wrote:
>
>
> On Thursday, November 20th, 2025 at 12:16 PM <dianders@xxxxxxxxxxxx> wrote:
> > In 6.13.1, the following could happen:
> >
> > 1. We'd be running btusb_mtk_setup()
> >
> > 2. In btusb_mtk_setup(), we'd run:
> > btmtk_data->isopkt_intf = usb_ifnum_to_if(data->udev, MTK_ISO_IFNUM)
> >
> > 3. If usb_ifnum_to_if() returned NULL, "btmtk_data->isopkt_intf" would be NULL.
> >
> > 4. Next, btusb_mtk_setup() would call btusb_mtk_claim_iso_intf().
> >
> > 5. btusb_mtk_claim_iso_intf() would pass "btmtk_data->isopkt_intf"
> > (NULL) to usb_driver_claim_interface() as "iface".
> >
> > 6. usb_driver_claim_interface() would see that its parameter "iface"
> > is NULL and would return an error.
> >
> > 7. btusb_mtk_claim_iso_intf() would notice the error, print "Failed to
> > claim iso interface: %d", and return.
> >
> >
> > In 6.13.2 after commit e9087e828827 ("Bluetooth: btusb: mediatek: Add
> > locks for usb_driver_claim_interface()"), we'd add in this step after
> > step 4:
> >
> > 4.5 btusb_mtk_claim_iso_intf() would call:
> > device_lock(&btmtk_data->isopkt_intf->dev);
> >
> > If "btmtk_data->isopkt_intf" is NULL, this is the same as
> > "&(NULL->dev)", so we'd pass a number that's very close to NULL in as
> > the dev pointer. Then device_lock() would try to dereference that and
> > crash.
>
>
> Sorry for the lack of knowledge on my part, but could you provide insights as how the bluetooth was functioning wihout errors in 6.13.1 :
>
> 1. Is it because there was no device_lock() checks in 6.13.1 and is because of the newly added `device_lock()` added on 6.13.2 ?
> 2. Is it because there was `device_lock()` in 6.13.1 that despite being provided a NULL pointer,`device_lock()` could dereference and the bluetooth adapter would turn on BUT in 6.13.2 , `device_lock()` would be provided a number close to NULL which could not be dereferenced and hence the bluetooth adapter wouldn't turn on ?

Right. There was no "device_lock()" checks in 6.13.1. The lack of
"device_lock()" caused a different kind of crash (sometimes), which is
why I added it. ...but I missed that we need to check for NULL before
calling device_lock().

-Doug