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: <CAD=FV=XUFEMAuLiFUR7pvPsWJP=_A=6=UGrFX9mobTV1M0gN=w@mail.gmail.com>
Date: Thu, 20 Nov 2025 08:03:44 -0800
From: Doug Anderson <dianders@...omium.org>
To: incogcyberpunk@...ton.me
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

Hi,

On Thu, Nov 20, 2025 at 2:14 AM <incogcyberpunk@...ton.me> wrote:
>
>
> On Thursday, November 20th, 2025 at 12:16 PM <dianders@...omium.org> 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