CVE-2026-105460 in Red Hat
Summary
by MITRE • 10/13/2026
A flaw was found in BlueZ. An out-of-bounds read vulnerability exists in the btmon Bluetooth monitor tool when processing crafted HCI Return Link Keys events. A maliciously crafted btsnoop capture file can specify a large number of link keys that exceeds the actual packet data, causing btmon to read beyond the allocated buffer and crash.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/13/2026
The BlueZ project serves as the official Linux Bluetooth protocol stack, providing essential utilities for managing wireless connectivity on Linux-based systems. Among these tools is btmon, a diagnostic utility designed to monitor and decode HCI (Host Controller Interface) traffic in real-time or from captured files such as btsnoop formats used by Wireshark. The vulnerability identified within this tool represents a critical memory safety issue classified under CWE-125, which denotes an out-of-bounds read condition. This specific flaw occurs during the parsing and processing of HCI Return Link Keys events, where btmon attempts to extract cryptographic key material from incoming data structures.
The technical root cause lies in insufficient validation of packet length fields against actual buffer boundaries. When btmon processes a crafted btsnoop capture file containing an artificially inflated count of link keys within an event structure, the application fails to verify that sufficient payload data exists to satisfy the declared quantity. Consequently, the parsing logic proceeds to read memory locations beyond the allocated buffer space associated with the current packet. This out-of-bounds access triggers a segmentation fault or similar crash mechanism in user-space applications, resulting in immediate termination of the btmon process. While this is primarily a denial-of-service vector due to application instability, such memory corruption issues often serve as precursors to more severe exploitation scenarios if future code paths are modified without addressing underlying buffer management principles.
From an operational perspective, the impact is confined largely to local users or administrators who utilize btmon for debugging Bluetooth stack issues. An attacker would need to trick a user into opening a maliciously crafted btsnoop file within the tool to trigger this crash. This aligns with ATT&CK technique T1204, specifically User Execution, as it requires an interactive action by a privileged or authorized user rather than remote network exploitation. The reliability of diagnostic tools is crucial for maintaining system integrity and troubleshooting connectivity issues; therefore, crashes in such utilities can disrupt security monitoring workflows and hinder incident response efforts during Bluetooth-related investigations.
Mitigation strategies should prioritize updating the BlueZ package to versions where this parsing logic has been hardened with strict bounds checking before accessing array elements derived from packet headers. Security teams should ensure that all systems running btmon are patched against this specific flaw. Additionally, defensive measures include restricting access to sensitive diagnostic tools and implementing file integrity monitoring for capture files used in security analysis environments. Developers reviewing similar code paths within the Bluetooth stack should enforce rigorous input validation practices consistent with secure coding standards like CWE-20, ensuring that all external data sources are validated before being processed by memory-sensitive components.