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!
Hey,
It's been almost a week since the regression was reported and an patch was provided to fix the issue, which has now been accepted in the linux-next tree; but I see that despite being a patch for regression, a merge/pull request was not made upstream for the latest -rc mainline release.
Is there any way that I can track the updates for this patch to be onto the mainline release?
Sorry, if I am missing anything.
Regards, IncogCyberpunk
Hi,
On Tue, Nov 25, 2025 at 10:18 PM incogcyberpunk@proton.me wrote:
Hey,
It's been almost a week since the regression was reported and an patch was provided to fix the issue, which has now been accepted in the linux-next tree; but I see that despite being a patch for regression, a merge/pull request was not made upstream for the latest -rc mainline release.
Is there any way that I can track the updates for this patch to be onto the mainline release?
Sorry, if I am missing anything.
This was merged into net tree a few days ago:
https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=8a...
So it should get into Linus tree in the next few days.
Regards, IncogCyberpunk
Hi,
Don't want to add trouble, just out of curiosity.
What is normally the route for patches to get into the mainline kernel?
Isn't it as follows , as suggested in the documentations ? subsystem -> -next -> mainline -> stable ?
What's this net tree , and how are the patches cherrypicked onto the mainline kernel? is there a certain process?
Regards, IncogCyberpunk
linux-stable-mirror@lists.linaro.org
-
Doug Anderson -
Douglas Anderson
-
incogcyberpunk＠proton.me -
Luiz Augusto von Dentz -
patchwork-bot+bluetooth＠kernel.org -
Paul Menzel