CVE-2026-64407

What it actually does

The flaw is an out-of-bounds read in the Linux kernel NXP Bluetooth UART driver during version 3 firmware download handling. A Bluetooth controller can send a firmware data request containing a 32-bit offset and 16-bit length; the vulnerable code validates only part of the offset calculation and fails to ensure that offset plus length remains inside the firmware image buffer. As a result, the kernel may read memory beyond the end of the loaded firmware blob and transmit those bytes back to the controller over UART. The primary impact is information disclosure from kernel memory or adjacent allocations; depending on memory layout and request size, it may also contribute to instability or driver failure.

Why it matters to the business

Systems using affected Linux kernels with NXP Bluetooth UART hardware could leak sensitive kernel memory to a malicious, compromised, or counterfeit Bluetooth controller during device initialization or firmware download. The practical attack surface is narrower than a typical network-exploitable Linux kernel issue because exploitation generally requires control of, or tampering with, the local Bluetooth controller/UART communication path. Even so, exposed embedded, mobile, industrial, or appliance-like devices may face confidentiality risk, supply-chain concern, and operational disruption if Bluetooth initialization fails or the kernel becomes unstable. The CVE is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, has low EPSS, and has no public exploit maturity indicated, so remediation should be scheduled through normal kernel update processes unless the environment relies heavily on affected NXP Bluetooth UART devices or faces hardware-tampering threats.

How an attack unfolds

An attacker needs a way to influence the NXP Bluetooth controller behavior or the UART traffic between the controller and the Linux host. During Bluetooth firmware download, the host driver waits for firmware data requests from the controller. In the vulnerable v3 request path, a crafted request supplies an offset and length that cause the computed firmware download offset plus length to extend beyond the loaded firmware image. The driver then calls the UART write routine using a pointer derived from the firmware buffer plus the unchecked offset, causing bytes after the firmware buffer to be read from kernel memory and sent to the controller. The attacker collects the returned UART data and may repeat the process with different offsets and lengths to sample adjacent memory. Successful exploitation is most plausible with a malicious or compromised controller, malicious firmware behavior, physical hardware tampering, laboratory access, or supply-chain substitution rather than through ordinary remote Bluetooth pairing alone.

How to fix it

Update to a Linux kernel version or downstream vendor kernel package that includes the fix for the btnxpuart v3 firmware download bounds check in nxp_recv_fw_req_v3(). Because no exact fixed package versions were provided, use the advisory from the relevant Linux distribution, device vendor, or kernel supplier and verify that the patch adds validation that the requested v3 firmware offset and length remain within the firmware image size. Where immediate kernel updates are not possible, reduce exposure by disabling unused Bluetooth functionality, unloading or blacklisting the affected NXP Bluetooth UART driver where operationally feasible, preventing untrusted hardware replacement or UART access, and restricting physical access to devices. For embedded fleets, coordinate firmware and kernel updates through the device OEM because the affected driver may be shipped in a vendor-maintained kernel rather than a mainline kernel package.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel build includes the upstream fix for the btnxpuart nxp_recv_fw_req_v3() bounds check. On source-based or vendor kernel builds, inspect the Bluetooth btnxpuart driver code to ensure the v3 request path rejects requests where the computed offset is outside the firmware image or where offset plus length exceeds the firmware size. On packaged systems, confirm the installed kernel version matches the distribution or vendor advisory that contains the fix, then reboot into that kernel. Validate operationally by ensuring affected devices still initialize Bluetooth successfully and that kernel logs do not show repeated Bluetooth firmware download failures, UART errors, controller resets, or kernel oops events. If security testing is available, use a controlled test harness or instrumented UART/controller emulator to send an oversized v3 firmware request and confirm the patched driver rejects it rather than transmitting out-of-bounds data.

Typical attack path

1. Gain control over the NXP Bluetooth controller, its firmware behavior, or the UART communication path between the controller and Linux host.
2. Trigger or wait for the Bluetooth firmware download sequence handled by the btnxpuart driver.
3. Send a crafted v3 firmware data request with an offset and length that passes the vulnerable lower-bound check but extends beyond the firmware image size.
4. Cause the Linux kernel driver to read past the end of the firmware buffer.
5. Receive the out-of-bounds kernel memory bytes over the UART response path.
6. Repeat requests to attempt broader memory disclosure or to induce driver instability.

How to detect it

Retrospective detection is difficult because the vulnerable path may not log each firmware data request, and the leaked data is sent over an internal UART link to the controller rather than over a normal network connection. Review kernel logs, boot logs, and device health telemetry for anomalies around NXP Bluetooth initialization, firmware download, UART communication, controller resets, and kernel crashes. Useful sources include dmesg, journald, syslog, persistent kernel logs, crash dumps, pstore/ramoops, embedded device health logs, and any available UART bus captures from hardware debugging. Look for repeated Bluetooth firmware download attempts, unexplained controller reinitialization, unexpected failures shortly after boot or resume, and kernel oops traces referencing btnxpuart or nxp_recv_fw_req_v3. In high-risk investigations, compare Bluetooth controller firmware provenance and hardware identity against known-good inventory, inspect for physical tampering, and analyze UART traces for v3 firmware data requests whose offset plus length exceeds the legitimate firmware image size. Because no public exploitation campaign or threat actor is identified, detections should focus on abnormal local device behavior rather than internet-facing indicators.

• btnxpuart
• nxp_recv_fw_req_v3
• v3_data_req
• fw_dnld_v3_offset
• fw_v3_offset_correction
• Bluetooth: btnxpuart
• firmware download
• serdev_device_write_buf

What your security team should do

• Inventory Linux systems and embedded devices that use NXP Bluetooth UART hardware or load the btnxpuart driver.
• Prioritize kernel updates for products where Bluetooth is enabled, the hardware is physically accessible, or supply-chain/device-tampering risk is relevant.
• Track vendor advisories for the exact fixed kernel package or firmware bundle because downstream Linux and embedded vendors may backport the fix without changing to a new upstream kernel version.
• Where Bluetooth is not required, disable it or prevent the affected driver from loading until patched.
• Add monitoring for unusual Bluetooth initialization failures, kernel oops messages, UART firmware download errors, or repeated controller resets on systems using NXP Bluetooth UART devices.
• For high-assurance or tamper-exposed devices, review hardware trust assumptions around replaceable Bluetooth modules, UART access, debug headers, and manufacturing supply-chain controls.
• Do not treat low EPSS or non-KEV status as proof of no risk in embedded or physical-access threat models; instead, use them to prioritize this below remotely exploitable kernel vulnerabilities.