In btusb_mtk_setup(), we set `btmtk_data->isopkt_intf` to: usb_ifnum_to_if(data->udev, MTK_ISO_IFNUM)
That function can return NULL in some cases. Even when it returns NULL, though, we still go on to call btusb_mtk_claim_iso_intf().
As of commit e9087e828827 ("Bluetooth: btusb: mediatek: Add locks for usb_driver_claim_interface()"), calling btusb_mtk_claim_iso_intf() when `btmtk_data->isopkt_intf` is NULL will cause a crash because we'll end up passing a bad pointer to device_lock(). 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.
Resolve the crash in btusb_mtk_claim_iso_intf() by adding a NULL check at the start of the function. This makes the code handle a NULL `btmtk_data->isopkt_intf` the same way it did before the problematic commit (just with a slight change to the error message printed).
Reported-by: IncogCyberpunk incogcyberpunk@proton.me Closes: http://lore.kernel.org/r/a380d061-479e-4713-bddd-1d6571ca7e86@leemhuis.info Fixes: e9087e828827 ("Bluetooth: btusb: mediatek: Add locks for usb_driver_claim_interface()") Cc: stable@vger.kernel.org Tested-by: IncogCyberpunk incogcyberpunk@proton.me Signed-off-by: Douglas Anderson dianders@chromium.org ---
Changes in v3: - Added Cc to stable. - Added IncogCyberpunk Tested-by tag. - v2: https://patch.msgid.link/20251119092641.v2.1.I1ae7aebc967e52c7c4be7aa65fbd81...
Changes in v2: - Rebase atop commit 529ac8e706c3 ("Bluetooth: ... mtk iso interface") - v1: https://patch.msgid.link/20251119085354.1.I1ae7aebc967e52c7c4be7aa65fbd81736...
drivers/bluetooth/btusb.c | 5 +++++ 1 file changed, 5 insertions(+)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c index fcc62e2fb641..683ac02e964b 100644 --- a/drivers/bluetooth/btusb.c +++ b/drivers/bluetooth/btusb.c @@ -2751,6 +2751,11 @@ static void btusb_mtk_claim_iso_intf(struct btusb_data *data) if (!btmtk_data) return;
+ 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
Dear Douglas,
Thank you for your patch.
Am 20.11.25 um 17:12 schrieb Douglas Anderson:
In btusb_mtk_setup(), we set `btmtk_data->isopkt_intf` to: usb_ifnum_to_if(data->udev, MTK_ISO_IFNUM)
That function can return NULL in some cases. Even when it returns NULL, though, we still go on to call btusb_mtk_claim_iso_intf().
As of commit e9087e828827 ("Bluetooth: btusb: mediatek: Add locks for usb_driver_claim_interface()"), calling btusb_mtk_claim_iso_intf() when `btmtk_data->isopkt_intf` is NULL will cause a crash because we'll end up passing a bad pointer to device_lock(). 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.
Resolve the crash in btusb_mtk_claim_iso_intf() by adding a NULL check at the start of the function. This makes the code handle a NULL `btmtk_data->isopkt_intf` the same way it did before the problematic commit (just with a slight change to the error message printed).
Reported-by: IncogCyberpunk incogcyberpunk@proton.me Closes: http://lore.kernel.org/r/a380d061-479e-4713-bddd-1d6571ca7e86@leemhuis.info Fixes: e9087e828827 ("Bluetooth: btusb: mediatek: Add locks for usb_driver_claim_interface()") Cc: stable@vger.kernel.org Tested-by: IncogCyberpunk incogcyberpunk@proton.me Signed-off-by: Douglas Anderson dianders@chromium.org
Changes in v3:
- Added Cc to stable.
- Added IncogCyberpunk Tested-by tag.
- v2: https://patch.msgid.link/20251119092641.v2.1.I1ae7aebc967e52c7c4be7aa65fbd81...
Changes in v2:
Rebase atop commit 529ac8e706c3 ("Bluetooth: ... mtk iso interface")
v1: https://patch.msgid.link/20251119085354.1.I1ae7aebc967e52c7c4be7aa65fbd81736...
drivers/bluetooth/btusb.c | 5 +++++ 1 file changed, 5 insertions(+)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c index fcc62e2fb641..683ac02e964b 100644 --- a/drivers/bluetooth/btusb.c +++ b/drivers/bluetooth/btusb.c @@ -2751,6 +2751,11 @@ static void btusb_mtk_claim_iso_intf(struct btusb_data *data) if (!btmtk_data) return;
- if (!btmtk_data->isopkt_intf) {
bt_dev_err(data->hdev, "Can't claim NULL iso interface");
As an error is printed now, what should be done about? Do drivers need fixing? Is it broken hardware?
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
Reviewed-by: Paul Menzel pmenzel@molgen.mpg.de
Kind regards,
Paul
Hi,
On Thu, Nov 20, 2025 at 9:04 AM Paul Menzel pmenzel@molgen.mpg.de wrote:
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c index fcc62e2fb641..683ac02e964b 100644 --- a/drivers/bluetooth/btusb.c +++ b/drivers/bluetooth/btusb.c @@ -2751,6 +2751,11 @@ static void btusb_mtk_claim_iso_intf(struct btusb_data *data) if (!btmtk_data) return;
if (!btmtk_data->isopkt_intf) {bt_dev_err(data->hdev, "Can't claim NULL iso interface");As an error is printed now,
An error was also printed before commit e9087e828827 ("Bluetooth: btusb: mediatek: Add locks for usb_driver_claim_interface()") too, it was just a different error message. Previously the NULL would have been noticed by usb_driver_claim_interface(), which would have returned -ENODEV. That error would have been noticed and the message printed would have been:
Failed to claim iso interface: -19
So that error is merely changed into:
Can't claim NULL iso interface
what should be done about? Do drivers need fixing? Is it broken hardware?
Personally, I have no idea. I was mostly trying to get the regression fixed and, after looking at the code, I was convinced that this would get us back to working at least as well as we did before commit e9087e828827 ("Bluetooth: btusb: mediatek: Add locks for usb_driver_claim_interface()"), plus we'd still have the device_lock() in place to avoid the problems I noticed earlier. It sounds as if, even with the error printed, things were working well enough for IncogCyberpunk.
If someone wants to analyze how / why `btmtk_data->isopkt_intf` would be NULL in this case and if we should do something better to handle it, I'd certainly support it!
return;}/* * The function usb_driver_claim_interface() is documented to need * locks held if it's not called from a probe routine. The code hereReviewed-by: Paul Menzel pmenzel@molgen.mpg.de
Thanks!
-Doug
Hello:
This patch was applied to bluetooth/bluetooth-next.git (master) by Luiz Augusto von Dentz luiz.von.dentz@intel.com:
On Thu, 20 Nov 2025 08:12:28 -0800 you wrote:
In btusb_mtk_setup(), we set `btmtk_data->isopkt_intf` to: usb_ifnum_to_if(data->udev, MTK_ISO_IFNUM)
That function can return NULL in some cases. Even when it returns NULL, though, we still go on to call btusb_mtk_claim_iso_intf().
As of commit e9087e828827 ("Bluetooth: btusb: mediatek: Add locks for usb_driver_claim_interface()"), calling btusb_mtk_claim_iso_intf() when `btmtk_data->isopkt_intf` is NULL will cause a crash because we'll end up passing a bad pointer to device_lock(). 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.
[...]
Here is the summary with links: - [v3] Bluetooth: btusb: mediatek: Avoid btusb_mtk_claim_iso_intf() NULL deref https://git.kernel.org/bluetooth/bluetooth-next/c/dd6dda907d09
You are awesome, thank you!
linux-stable-mirror@lists.linaro.org
-
Doug Anderson -
Douglas Anderson
-
patchwork-bot+bluetooth＠kernel.org -
Paul Menzel