CVE-2025-21827: Bluetooth: btusb: mediatek: Add locks for usb_driver_claim_interface()
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: btusb: mediatek: Add locks for usbdriverclaiminterface()
The documentation for usbdriverclaiminterface() says that "the device lock" is needed when the function is called from places other than probe(). This appears to be the lock for the USB interface device. The Mediatek btusb code gets called via this path:
Workqueue: hci0 hcipoweron [bluetooth] Call trace: usbdriverclaiminterface btusbmtkclaimisointf btusbmtksetup hcidevopensync hcipoweron processscheduledworks workerthread kthread
With the above call trace the device lock hasn't been claimed. Claim it.
Without this fix, we'd sometimes see the error "Failed to claim iso interface". Sometimes we'd even see worse errors, like a NULL pointer dereference (where intf->dev.driver was NULL) with a trace like:
Call trace: usbsuspendboth usbruntimesuspend rpmcallback rpmsuspend pmruntimework processscheduledworks
Both errors appear to be fixed with the proper locking.
Affected Software
Event History
Frequently Asked Questions
What is the severity of CVE-2025-21827?
CVE-2025-21827 has a medium severity rating due to potential concurrency issues in Bluetooth handling in the Linux kernel.
How do I fix CVE-2025-21827?
To fix CVE-2025-21827, update your Linux kernel to the latest stable version that contains the patches addressing this vulnerability.
What software is affected by CVE-2025-21827?
CVE-2025-21827 affects the Linux Kernel, particularly the Bluetooth subsystem in devices utilizing the btusb driver.
What is the nature of the vulnerability in CVE-2025-21827?
CVE-2025-21827 is a concurrency vulnerability that occurs when the usb_driver_claim_interface() function is improperly accessed, leading to potential device lock issues.
Is there a workaround for CVE-2025-21827?
There are no specific workarounds recommended for CVE-2025-21827, and upgrading the kernel is the best course of action.