CVE-2026-64126

What it actually does

This Linux kernel Bluetooth management flaw occurs in handling of MGMT_OP_ADD_EXT_ADV_DATA. The command accepts variable-length advertising and scan-response data, but the kernel did not verify that the supplied command length actually contained the number of bytes declared by adv_data_len and scan_rsp_len. A local process with CAP_NET_ADMIN in the initial user namespace can submit a malformed, short Bluetooth management command that causes the kernel to read past the end of the command buffer. Depending on adjacent slab memory contents, this can disclose kernel memory through a later MGMT_OP_GET_ADV_INSTANCE call. The reported failure mode is an 8-byte slab out-of-bounds read detected by KASAN. The primary impact is local information disclosure from kernel memory, with possible secondary stability impact if malformed parsing causes kernel warnings or crashes on hardened/debug builds.

Why it matters to the business

Systems that expose Bluetooth support and permit privileged local users or services to exercise Bluetooth management operations may allow those users to read small amounts of kernel memory they should not be able to access. Although exploitation requires local privileged capability rather than remote network access, the issue can weaken host isolation, expose sensitive kernel-resident data, and support follow-on exploitation by an attacker who has already gained a foothold with elevated network-administration permissions. The low EPSS and absence from the Known Exploited Vulnerabilities catalog suggest no broad public exploitation signal at this time, but kernel vulnerabilities should still be remediated through normal patch cycles, especially on multi-user systems, developer workstations, laptops, gateways, and hosts where Bluetooth is enabled.

How an attack unfolds

An attacker first obtains local code execution on a Linux system and gains CAP_NET_ADMIN in the initial user namespace, such as through a privileged process, misconfigured service, or container/runtime configuration that grants excessive host-level capabilities. The attacker then opens the Bluetooth management interface and submits a crafted MGMT_OP_ADD_EXT_ADV_DATA command whose fixed header advertises adv_data_len and/or scan_rsp_len values larger than the actual command payload. Because vulnerable kernels validate and copy based on the declared lengths rather than the real buffer length, the handler can pass an out-of-bounds pointer into TLV validation and may copy bytes located beyond the submitted command buffer into the advertising instance. The attacker then queries the advertising instance using MGMT_OP_GET_ADV_INSTANCE to retrieve the stored data and recover leaked kernel memory bytes. Repeating the sequence may allow collection of additional adjacent memory fragments. On systems with sanitizers or strict kernel diagnostics, attempts may also generate KASAN slab-out-of-bounds reports or Bluetooth management warnings.

How to fix it

Apply a Linux kernel update that includes the Bluetooth MGMT fix validating that the command length equals the fixed MGMT_ADD_EXT_ADV_DATA_SIZE header plus the declared advertising-data and scan-response lengths before parsing cp->data. Where vendor kernel package versions are available, upgrade to the vendor-fixed kernel release for the affected distribution and reboot into the updated kernel. If immediate patching is not possible, reduce exposure by disabling Bluetooth where it is not required, blocking or unloading Bluetooth kernel modules where operationally feasible, and preventing untrusted local users, services, or containers from receiving CAP_NET_ADMIN in the initial user namespace. Capability reduction is especially important because exploitation requires that privilege. Treat mitigation as temporary; the durable fix is a patched kernel.

How to confirm the fix worked

Confirm that systems have booted into a kernel build containing the upstream or vendor backport for the Bluetooth MGMT Add Extended Advertising Data length validation. Do not rely only on package installation; verify the running kernel with uname or vendor inventory tooling after reboot. Validate that Bluetooth is disabled or unavailable on systems where it is not needed, and confirm that untrusted workloads are not granted host-level CAP_NET_ADMIN. For engineering validation, a controlled negative test can attempt to submit a short MGMT_OP_ADD_EXT_ADV_DATA command with inconsistent adv_data_len and scan_rsp_len values; a fixed kernel should reject the command rather than producing KASAN, slab out-of-bounds, kernel warning, or readable leaked data through MGMT_OP_GET_ADV_INSTANCE. Review kernel logs for absence of Bluetooth management parsing warnings or KASAN reports after testing.

Typical attack path

1. Gain local code execution on a Linux host where Bluetooth support is present and enabled or reachable.
2. Obtain CAP_NET_ADMIN in the initial user namespace, or compromise a process that already has that capability.
3. Open the Bluetooth management control interface used by BlueZ/kernel Bluetooth management operations.
4. Send a malformed MGMT_OP_ADD_EXT_ADV_DATA request with adv_data_len and/or scan_rsp_len values that do not match the actual command payload length.
5. Trigger the vulnerable kernel path to read beyond the provided management command buffer and store adjacent bytes as advertising or scan-response data.
6. Call MGMT_OP_GET_ADV_INSTANCE to read back the advertising instance and recover leaked kernel memory fragments.
7. Optionally repeat the malformed command/readback sequence to collect more memory or to aid further local exploitation.

How to detect it

Look for evidence of malformed Bluetooth management activity and kernel memory-safety reports. Relevant sources include kernel logs from dmesg, journald, syslog, auditd process execution records, endpoint telemetry, and container/runtime audit logs showing capability grants. Search for KASAN or slab out-of-bounds read messages involving Bluetooth MGMT, add_ext_adv_data, tlv_data_is_valid, MGMT_OP_ADD_EXT_ADV_DATA, or advertising instance handling. Investigate local processes that interact with Bluetooth control interfaces unexpectedly, especially custom binaries, scripts, fuzzers, or processes running with CAP_NET_ADMIN. Review audit logs for execution of Bluetooth tooling or direct access to management sockets by users or services that do not normally administer Bluetooth. Also review container and service configurations for recent addition of CAP_NET_ADMIN or privileged mode, because the exploit prerequisite is a strong signal for risk. Absence of logs does not prove absence of exploitation: successful exploitation may only disclose memory without creating durable artifacts unless kernel diagnostics, audit rules, or endpoint telemetry were enabled at the time.

• MGMT_OP_ADD_EXT_ADV_DATA
• MGMT_OP_GET_ADV_INSTANCE
• add_ext_adv_data
• tlv_data_is_valid
• Bluetooth: MGMT
• KASAN: slab-out-of-bounds
• slab-out-of-bounds read
• BUG: KASAN
• cap_net_admin
• CAP_NET_ADMIN
• /sys/module/bluetooth
• /proc/sys/kernel/kptr_restrict
• btmgmt
• bluetoothd
• privileged: true
• --cap-add=NET_ADMIN

What your security team should do

• Prioritize patching Linux systems with Bluetooth enabled and systems that allow local interactive users, privileged services, or container workloads with CAP_NET_ADMIN.
• Inventory hosts for running kernel versions and confirm reboot completion after kernel package updates.
• Disable Bluetooth on servers, appliances, virtual machines, and other systems where it is not operationally required.
• Audit container, service, and sudo/polkit configurations for unnecessary CAP_NET_ADMIN grants, especially grants that apply in the initial host user namespace.
• Monitor kernel logs for KASAN, slab out-of-bounds, Bluetooth MGMT, or advertising-instance errors that may indicate probing or exploit attempts.
• Treat suspicious local use of Bluetooth management operations by non-Bluetooth applications as a potential compromise indicator and investigate the originating process and user.
• Because there is no current KEV listing and EPSS is low, handle as an important kernel hardening update rather than an emergency internet-wide exposure, unless local privilege boundaries or Bluetooth-enabled endpoints are critical to the organization.