CVE-2025-68298 in Linux
Summary
by MITRE • 12/16/2025
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: btusb: mediatek: Avoid btusb_mtk_claim_iso_intf() NULL deref
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).
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 05/24/2026
The vulnerability CVE-2025-68298 represents a critical null pointer dereference issue within the Linux kernel's Bluetooth subsystem, specifically affecting the mediatek Bluetooth USB driver implementation. This flaw exists in the btusb_mtk_claim_iso_intf() function where the driver fails to properly validate a pointer returned by usb_ifnum_to_if() before attempting to use it. The issue stems from the btusb_mtk_setup() function which assigns the result of usb_ifnum_to_if(data->udev, MTK_ISO_IFNUM) directly to btmtk_data->isopkt_intf without checking if the returned value is NULL. This condition occurs when the USB interface number does not correspond to a valid interface, which can happen during device enumeration or when handling certain hardware configurations.
The technical exploitation of this vulnerability occurs when the Bluetooth USB driver attempts to claim an ISO interface that does not exist, leading to a kernel crash due to passing a NULL pointer to device_lock() function. Prior to commit e9087e828827, the driver would have gracefully handled such cases by passing the NULL pointer directly to usb_driver_claim_interface() which would detect the invalid pointer and return an appropriate error code. However, the subsequent code change introduced a regression where the NULL pointer handling was broken, causing a kernel oops or system crash when device_lock() attempts to operate on a NULL interface pointer. This represents a classic case of improper error handling and null pointer validation that violates the principle of defensive programming in kernel space operations.
The operational impact of this vulnerability extends beyond simple system crashes to potentially enable denial of service attacks against systems running affected Linux kernel versions. An attacker could potentially trigger this condition through malicious Bluetooth device enumeration or by connecting specific hardware configurations that cause the USB interface lookup to fail. The vulnerability affects systems using mediatek Bluetooth USB adapters and demonstrates the critical importance of proper pointer validation in kernel drivers, particularly in USB subsystem implementations. This flaw could be exploited in scenarios where an attacker has physical access to a device or can influence Bluetooth device enumeration, potentially leading to complete system unavailability. The issue also highlights the risks associated with seemingly benign code refactoring that inadvertently breaks existing error handling mechanisms.
The resolution for CVE-2025-68298 involves implementing a simple yet critical null pointer check at the beginning of the btusb_mtk_claim_iso_intf() function. This fix ensures that when btmtk_data->isopkt_intf is NULL, the function gracefully handles the condition without attempting to dereference the invalid pointer. The solution maintains backward compatibility with existing error handling patterns while preventing the kernel crash that occurred after the problematic commit. This approach aligns with the CWE-476 principle of null pointer dereference prevention and follows the ATT&CK technique T1499.004 for resource exhaustion through system crash. The fix demonstrates the importance of defensive programming practices in kernel space where a single missing validation can lead to complete system compromise, and it reinforces the need for comprehensive testing of driver code changes, particularly those involving USB interface management and device locking mechanisms.