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=WRYYYB+G4-7y7uVR8QCEEMp2iRfmtsAa29UfyNCVD=4Q@mail.gmail.com>
Date: Wed, 19 Nov 2025 22:30:48 -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 Wed, Nov 19, 2025 at 5:04 PM <incogcyberpunk@...ton.me> wrote:
>
> Excellant , i will reply to the lore so that further progress from the Bluetooth maintainers can take place.
>
> Also ,
>  Yes .Simply because this is an unknown territory for me, i had a hard time understanding the problems just from the commit patch message.
>
> I would be grateful if I could understand how the `btmtk_data->isopkt_intf` being NULL caused a crash due to the commit in 6.13.2 and what it means to say `Prior to that
> commit we'd pass the NULL pointer directly to
> usb_driver_claim_interface() which would detect it and return an
> error, which was handled.`.
> How was the pointer passed directly such that the device_lock mutex , worked in an undesired manner to lock the adapter and turn it on.

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.