CVE-2025-21827 in Linux
Summary
by MITRE • 03/06/2025
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: btusb: mediatek: Add locks for usb_driver_claim_interface()
The documentation for usb_driver_claim_interface() 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 hci_power_on [bluetooth]
Call trace: usb_driver_claim_interface btusb_mtk_claim_iso_intf btusb_mtk_setup hci_dev_open_sync hci_power_on process_scheduled_works worker_thread 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: usb_suspend_both usb_runtime_suspend __rpm_callback rpm_suspend pm_runtime_work process_scheduled_works
Both errors appear to be fixed with the proper locking.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 02/16/2026
This vulnerability exists in the Linux kernel's Bluetooth subsystem specifically within the Mediatek btusb driver implementation. The issue stems from improper synchronization mechanisms when calling usb_driver_claim_interface() function outside of the standard probe() context. The Linux USB subsystem documentation explicitly requires that "the device lock" be acquired before invoking usb_driver_claim_interface() from non-probe locations, as this function operates on USB interface device objects that require proper locking to prevent race conditions and inconsistent states. The Mediatek btusb driver fails to acquire this necessary lock during its execution path, creating a critical synchronization flaw.
The vulnerability manifests through a specific call chain that begins with workqueue execution in the Bluetooth subsystem and progresses through hci_power_on processing. The execution path shows usb_driver_claim_interface() being called from btusb_mtk_claim_iso_intf, which is invoked during btusb_mtk_setup, ultimately triggered by hci_dev_open_sync and hci_power_on functions. This sequence occurs within the worker_thread context of the kernel's workqueue system, where the device lock that should have been acquired during the initial probe phase has not been maintained. The missing lock results in failed interface claims and can escalate to more severe conditions including NULL pointer dereferences.
The operational impact of this vulnerability extends beyond simple interface claiming failures to potentially catastrophic system states. When the device lock is not properly acquired, the system encounters "Failed to claim iso interface" errors that disrupt Bluetooth functionality and can cause complete driver failures. More critically, the absence of proper locking can lead to NULL pointer dereferences where intf->dev.driver becomes NULL, causing kernel oops and system instability. These conditions can be exploited to cause denial of service attacks or potentially allow privilege escalation scenarios, as demonstrated by the runtime suspend callback chain that can trigger the NULL pointer dereference during rpm_suspend operations. The vulnerability affects all systems running Linux kernels with Mediatek Bluetooth USB adapters and represents a fundamental failure in the USB device management locking strategy.
The fix for this vulnerability requires implementing proper device lock acquisition before calling usb_driver_claim_interface() in the Mediatek btusb driver. This involves ensuring that the device lock is properly held throughout the execution path where usb_driver_claim_interface() is invoked, particularly in the btusb_mtk_claim_iso_intf function. The solution aligns with CWE-362, which addresses concurrent execution using improper locking mechanisms, and maps to ATT&CK technique T1059.003 for privilege escalation through kernel exploits. System administrators should update to patched kernel versions that implement proper locking mechanisms, while organizations should review their Bluetooth device configurations to ensure proper device lock management. The vulnerability demonstrates the critical importance of adhering to kernel USB subsystem locking requirements and maintaining proper synchronization across all device driver operations, particularly in high-concurrency environments where workqueue processing occurs alongside device management functions.