CVE-2024-57987 in Linux
Summary
by MITRE • 02/27/2025
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: btrtl: check for NULL in btrtl_setup_realtek()
If insert an USB dongle which chip is not maintained in ic_id_table, it will hit the NULL point accessed. Add a null point check to avoid the Kernel Oops.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 05/24/2026
The vulnerability CVE-2024-57987 represents a critical null pointer dereference issue within the Linux kernel's Bluetooth subsystem, specifically affecting the Realtek USB Bluetooth dongle driver. This flaw exists in the btrtl_setup_realtek() function which is responsible for initializing Bluetooth Realtek chipsets through USB interfaces. The vulnerability arises when users insert USB Bluetooth dongles that utilize chipsets not included in the maintained ic_id_table, creating a scenario where the driver attempts to access a NULL pointer during the device setup process. This represents a classic null pointer dereference vulnerability that can lead to system instability and potential privilege escalation.
The technical implementation of this vulnerability stems from inadequate input validation within the Bluetooth driver's device identification and initialization logic. When a USB Bluetooth device is connected, the kernel's Bluetooth subsystem performs device identification by cross-referencing the detected hardware against the ic_id_table, which contains supported chipset identifiers. However, when an unsupported chipset is encountered, the driver fails to properly handle the missing entry and proceeds to access a NULL pointer that should have been validated before use. This flaw directly corresponds to CWE-476, which defines null pointer dereference as a condition where a null pointer is dereferenced, leading to system crashes or exploitable conditions. The absence of proper null checks in the btrtl_setup_realtek() function creates a path where kernel memory access violations can occur, resulting in kernel oops messages and system instability.
The operational impact of this vulnerability extends beyond simple system crashes, potentially enabling denial of service attacks against systems running affected kernel versions. An attacker with physical access to a target system could exploit this vulnerability by inserting an unsupported USB Bluetooth device, causing the kernel to panic and resulting in system crashes. This represents a privilege escalation vector since the vulnerability occurs during kernel initialization and device enumeration, potentially allowing attackers to gain elevated privileges. The vulnerability is particularly concerning in environments where USB device insertion is not restricted, as it could be exploited to disrupt services or potentially escalate privileges through kernel memory corruption. From an ATT&CK framework perspective, this vulnerability aligns with T1059.001 (Command and Scripting Interpreter: PowerShell) and T1566 (Phishing) as it could be used in attack chains involving physical access or supply chain attacks where malicious USB devices are introduced to compromise systems. The kernel oops condition that results from this vulnerability can also provide attackers with information about kernel memory layout and system configuration, aiding in further exploitation attempts.
The recommended mitigation strategy involves applying the latest kernel security patches that include the null pointer check implementation in the btrtl_setup_realtek() function. System administrators should ensure all Linux systems running kernel versions affected by this vulnerability are updated immediately, particularly in enterprise environments where USB device insertion policies may not be strictly enforced. Additionally, implementing USB device whitelisting policies can provide an additional layer of defense by restricting which USB devices can be connected to systems, thereby preventing exploitation of this vulnerability through unauthorized device insertion. Organizations should also monitor for any potential exploitation attempts through system logs and kernel message outputs that may indicate the occurrence of kernel oops events or system crashes related to Bluetooth device initialization. Regular security audits of kernel configurations and device driver management should be conducted to ensure that only verified and supported USB Bluetooth devices are permitted in production environments, reducing the attack surface for this and similar vulnerabilities.