CVE-2026-53255

What it actually does

This is a Linux kernel Bluetooth Management (MGMT) parsing flaw in advertising data validation. The parser reads an advertising element length byte and then inspects the following type byte before first confirming that the type byte is still within the supplied buffer. A malformed MGMT_OP_ADD_ADVERTISING request can therefore trigger a one-byte out-of-bounds read in kernel memory. The most likely technical result is a kernel warning, KASAN report, or denial of service on systems configured to panic on kernel memory errors; the issue does not describe a practical remote code execution path or confirmed information disclosure primitive.

Why it matters to the business

Systems with Bluetooth enabled and exposed to users or services able to issue Bluetooth management commands may be vulnerable to local disruption. In practical terms, exploitation could destabilize affected hosts, interrupt Bluetooth-dependent workflows, and generate kernel faults requiring investigation or reboot. The risk is currently lower than actively exploited vulnerabilities because EPSS is low, there is no known public exploit maturity, and it is not listed in CISA KEV, but kernel flaws should still be patched through normal vulnerability management because they affect a privileged system component.

How an attack unfolds

An attacker first needs a way to submit Bluetooth MGMT commands on an affected Linux system, typically through local access or a compromised process with sufficient privileges or capabilities to interact with the Bluetooth HCI management interface. The attacker crafts an MGMT_OP_ADD_ADVERTISING request containing malformed advertising TLV data where the length byte appears as the final byte of the buffer. When the kernel processes the request, tlv_data_is_valid() reads the length byte and then attempts to inspect data[i + 1] as the advertising type before confirming that the element fits inside the buffer. This causes a one-byte read past the supplied advertising data. On kernels with memory sanitizers or strict panic settings, this can produce a KASAN vmalloc-out-of-bounds report or potentially crash the host; on production kernels without sanitizers, exploitation may be less visible and may only result in rejected advertising data or undefined adjacent-byte reads.

How to fix it

Apply a Linux kernel update from the relevant distribution or vendor that includes the Bluetooth MGMT fix validating advertising TLV element length before inspecting the type byte. No exact affected product or fixed version list was provided, so remediation should be tracked through the operating system vendor’s kernel advisories for this CVE or by confirming the upstream Bluetooth MGMT patch is present. Where immediate patching is not possible, reduce exposure by disabling Bluetooth on systems that do not require it, preventing untrusted users or containers from accessing Bluetooth/HCI management interfaces, limiting CAP_NET_ADMIN and related device access, and monitoring for kernel Bluetooth MGMT errors.

How to confirm the fix worked

Confirm the installed kernel package is at or above the vendor-fixed release containing the Bluetooth MGMT TLV validation patch. If source validation is possible, verify that tlv_data_is_valid() checks that each non-empty advertising element fits within the provided buffer before reading data[i + 1]. Operationally, validate that Bluetooth remains functional after patching and that attempts to submit malformed MGMT_OP_ADD_ADVERTISING data are rejected without KASAN, oops, panic, or vmalloc-out-of-bounds messages in kernel logs. Also verify that unnecessary Bluetooth services and device access are disabled on systems where Bluetooth is not required.

Typical attack path

1. Gain local execution on a Linux host or compromise a process that can access the Bluetooth HCI management interface.
2. Confirm Bluetooth support is present and the host accepts Bluetooth MGMT advertising commands.
3. Open the relevant Bluetooth HCI management socket or use tooling capable of sending MGMT_OP_ADD_ADVERTISING requests.
4. Send an advertising payload with malformed TLV data where a field length byte is positioned at the end of the supplied buffer.
5. Trigger the vulnerable parser path in tlv_data_is_valid() through add_advertising() and hci_mgmt_cmd().
6. Cause a kernel out-of-bounds read, potentially producing kernel sanitizer logs, an oops, or a denial-of-service condition depending on kernel configuration.

How to detect it

Look for evidence in kernel logs and system journals because exploitation occurs inside the Linux kernel Bluetooth MGMT path and is unlikely to leave application-level artifacts. Useful sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, system crash dumps, kdump/vmcore records, and EDR telemetry that captures kernel oops or panic events. Search for KASAN or kernel oops reports showing vmalloc-out-of-bounds reads in tlv_data_is_valid(), with call traces including add_advertising(), hci_mgmt_cmd(), and hci_sock_sendmsg(). Also review audit logs for unexpected privileged Bluetooth management access, suspicious use of Bluetooth testing tools, privileged containers with host device access, or unusual processes opening AF_BLUETOOTH/HCI sockets. Because the flaw is a one-byte out-of-bounds read in request parsing, there may be no durable file artifact; absence of logs does not prove absence of attempted exploitation, especially on kernels without KASAN or persistent kernel logging.

• BUG: KASAN: vmalloc-out-of-bounds in tlv_data_is_valid()
• vmalloc-out-of-bounds in tlv_data_is_valid()
• Read of size 1
• tlv_data_is_valid()
• add_advertising()
• hci_mgmt_cmd()
• hci_sock_sendmsg()
• MGMT_OP_ADD_ADVERTISING
• Bluetooth: MGMT
• KASAN: vmalloc-out-of-bounds

What your security team should do

• Prioritize patching Linux systems with Bluetooth enabled, especially multi-user systems, developer workstations, kiosks, laptops, and hosts running workloads that may have access to host Bluetooth devices.
• Inventory systems with Bluetooth adapters, btusb modules, bluetoothd, or exposed HCI devices, and determine whether untrusted users or containers can reach Bluetooth management interfaces.
• Apply vendor kernel updates during the next maintenance window; accelerate patching for systems configured to panic on kernel oops or systems where Bluetooth availability is operationally important.
• Disable Bluetooth or unload/block Bluetooth kernel modules on servers and appliances that do not require Bluetooth functionality.
• Restrict access to /dev, HCI sockets, privileged containers, and Linux capabilities such as CAP_NET_ADMIN to prevent untrusted workloads from issuing Bluetooth management commands.
• Add monitoring for kernel log messages referencing tlv_data_is_valid(), MGMT_OP_ADD_ADVERTISING, vmalloc-out-of-bounds, and Bluetooth MGMT parsing faults.
• Treat any matching kernel sanitizer or oops events as potential exploitation attempts or robustness testing until benign root cause is confirmed.