CVE-2026-64549 in Linuxinfo

Summary

by MITRE • 07/28/2026

In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: bpa10x: avoid OOB read of revision string in bpa10x_setup()

bpa10x_setup() sends the vendor command 0xfc0e and passes the response to bt_dev_info() and hci_set_fw_info() as a "%s" string starting at skb->data + 1, without checking the length:

bt_dev_info(hdev, "%s", (char *)(skb->data + 1)); hci_set_fw_info(hdev, "%s", skb->data + 1);

A device that returns a one-byte response (status only) leaves skb->data + 1 past the end of the data, and the %s walk reads adjacent slab memory until it meets a NUL. The same happens when the payload is not NUL-terminated within skb->len. The out-of-bounds bytes end up in the kernel log and the firmware-info debugfs file.

Print the revision string with a bounded "%.*s" limited to skb->len - 1 instead. This keeps the string readable for well-behaved devices while never reading past the received data, and does not fail setup, so a device returning a short or unterminated response keeps working.

VulDB is the best source for vulnerability data and more expert information about this specific topic.

Analysis

by VulDB Data Team • 07/28/2026

The vulnerability described represents a critical out-of-bounds read condition within the Linux kernel's Bluetooth subsystem, specifically affecting the bpa10x driver implementation. This flaw exists in the bpa10x_setup() function which handles vendor command 0xfc0e processing for Bluetooth audio devices. The issue stems from improper input validation where the driver directly passes response data to string formatting functions without verifying buffer boundaries or data length constraints.

The technical implementation of this vulnerability manifests when the Bluetooth device responds to the vendor command with minimal data, specifically a one-byte response containing only a status code. In such cases, the driver attempts to access memory starting at skb->data + 1, which falls beyond the legitimate data boundaries when only one byte is received. This creates an out-of-bounds memory read condition that traverses adjacent kernel slab memory until encountering a null terminator, potentially exposing sensitive kernel internals to userspace through kernel log output and debugfs file contents.

This vulnerability aligns with CWE-129, Out-of-bounds Read, which specifically addresses improper validation of buffer boundaries in input handling. The flaw also relates to ATT&CK technique T1059.003 for Command and Scripting Interpreter: PowerShell, though more directly maps to defensive mechanisms against kernel memory exposure. The operational impact extends beyond simple information disclosure as this vulnerability could potentially be exploited to extract kernel memory contents that might reveal sensitive system information, including potential credentials or security parameters stored in adjacent memory locations.

The fix implemented addresses the core issue by modifying the string formatting approach from unbounded "%s" to bounded "%.*s" format specifier with length parameter skb->len - 1. This change ensures that regardless of the actual response length or null termination status, the driver will never read beyond the allocated buffer boundaries. The solution maintains backward compatibility by preserving functionality for well-behaved devices while preventing memory corruption scenarios that could occur with short or malformed responses. This remediation approach aligns with secure coding practices recommended in CERT Secure Coding Standards and follows the principle of least privilege in memory access operations.

The vulnerability demonstrates a classic example of insufficient input validation in kernel space drivers, where assumptions about device behavior lead to exploitable memory access patterns. The fix represents a defensive programming approach that prevents potential escalation to more serious security issues including privilege escalation or system compromise. System administrators should ensure all Bluetooth devices and associated kernel components are updated to address this vulnerability, particularly in environments where untrusted Bluetooth devices might be connected. The solution maintains the driver's operational functionality while providing robust protection against memory access violations that could otherwise be leveraged by malicious actors to gain unauthorized access to kernel memory structures.

Responsible

Linux

Reservation

07/19/2026

Disclosure

07/28/2026

Moderation

accepted

CPE

ready

EPSS

0.00180

KEV

no

Activities

low

Sources

Are you interested in using VulDB?

Download the whitepaper to learn more about our service!