CVE-2026-63947

What it actually does

This is a Linux kernel Bluetooth HIDP input parsing flaw. The HIDP interrupt-frame handler removes the 1-byte HIDP header and then passes the remaining socket buffer to hidp_input_report(), which previously read keyboard or mouse report bytes without first confirming that the packet contained the required length. A malicious or malformed paired Bluetooth HID device can send a truncated HIDP packet that causes the kernel to read beyond the valid skb payload. The out-of-bounds data may be interpreted as input report data, potentially causing unintended keystrokes, mouse movement, memory-safety side effects, kernel instability, or disclosure of adjacent kernel buffer contents through downstream processing or diagnostics.

Why it matters to the business

Systems that accept Bluetooth keyboards, mice, or other HID devices may be exposed to nearby attackers or malicious paired peripherals. The most practical operational risk is unauthorized or disruptive local input, such as phantom keystrokes or pointer activity, but the kernel memory-safety nature of the bug also raises concern for crashes or broader compromise if exploit techniques mature. The issue is not currently listed in CISA KEV, has no reported exploit maturity in the provided data, and has a low EPSS score, but the high CVSS rating and kernel-level attack surface justify timely patching on laptops, workstations, kiosks, point-of-sale systems, and any Linux devices with Bluetooth HID enabled.

How an attack unfolds

An attacker first needs Bluetooth proximity to the target and a path to communicate as a HIDP device, most plausibly by using a malicious paired Bluetooth keyboard or mouse, compromising an already trusted peripheral, or convincing a user or device-management workflow to pair with an attacker-controlled HID device. After the HIDP connection is established, the attacker sends a malformed interrupt frame whose HIDP header is present but whose report payload is shorter than the kernel expects. On vulnerable kernels, hidp_recv_intr_frame() strips the header and hidp_input_report() continues parsing without sufficient remaining-length validation. The kernel then reads bytes beyond the valid skb data and treats those bytes as part of the HID input report. Depending on surrounding memory contents and device type, this can result in unintended input events, anomalous mouse movement, possible kernel diagnostics, or instability. Fixed kernels replace the unsafe manual parsing with skb_pull_data() checks, causing malformed short packets to be rejected instead of parsed beyond bounds.

How to fix it

Apply the Linux kernel update that contains the Bluetooth HIDP fix for hidp_input_report() length validation. Because no exact affected-product or fixed-version list was provided, use the fixed kernel packages from the relevant Linux distribution, appliance vendor, or upstream stable kernel branch once the patch is incorporated. Prioritize systems with Bluetooth enabled and systems that allow Bluetooth keyboards, mice, barcode scanners, point-of-sale peripherals, or kiosk input devices. If immediate patching is not possible, reduce exposure by disabling Bluetooth where not required, disabling or blocking Bluetooth HIDP/HID device pairing, removing untrusted paired devices, requiring administrative approval for pairing, and limiting physical proximity access to sensitive systems. Reboot after kernel update if required so the patched kernel is actually running.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel, not only the installed package, includes the vendor fix for the Bluetooth HIDP length-check issue. Check distribution advisories and package changelogs for references to the HIDP input report length-check patch, hidp_input_report(), hidp_recv_intr_frame(), or skb_pull_data(). Validate that Bluetooth is disabled on systems where it is not needed, and enumerate paired Bluetooth devices to confirm only expected devices are trusted. Where feasible in a lab, test with malformed or truncated HIDP input traffic and confirm the patched kernel rejects the short packet without phantom input, kernel warnings, KASAN findings, or crashes.

Typical attack path

1. Attacker gets within Bluetooth radio range of a vulnerable Linux system with Bluetooth HID support enabled.
2. Attacker establishes or abuses a paired Bluetooth HIDP device relationship, such as a keyboard or mouse.
3. Attacker sends a truncated HIDP interrupt frame with insufficient report payload after the HIDP header.
4. The vulnerable kernel removes the header and calls hidp_input_report() without adequate length validation.
5. hidp_input_report() reads past the valid skb data while parsing the report.
6. Out-of-bounds bytes are interpreted as HID input data, potentially causing phantom keystrokes, mouse movement, kernel warnings, or instability.

How to detect it

Post-exploitation detection is difficult because the vulnerable path may not generate reliable logs and malformed HIDP packets can be processed as ordinary input. Review kernel logs, system journals, Bluetooth daemon logs, endpoint telemetry, and physical-access records around suspicious user activity. Look for unexpected Bluetooth pairing or reconnection events, newly trusted HID devices, unexplained keyboard or mouse input, kernel warnings, crashes, KASAN reports, or traces mentioning HIDP input handling. On systemd-based Linux systems, useful sources include journalctl output for kernel messages and bluetooth.service, /var/log/kern.log, /var/log/syslog, /var/log/messages, audit logs if Bluetooth management commands are audited, and EDR telemetry for unusual interactive actions following Bluetooth device activity. Because this is an adjacent-network Bluetooth issue, correlate events with proximity-sensitive contexts such as office access, conference rooms, kiosks, or unattended workstations. Absence of logs does not prove absence of exploitation.

• BUG: KASAN: slab-out-of-bounds in hidp_input_report
• hidp_input_report
• hidp_recv_intr_frame
• Bluetooth: HIDP
• input: Bluetooth HID
• bluetoothd
• Device paired
• Paired: yes
• Connected: yes
• Trusted: yes

What your security team should do

• Patch affected Linux kernels on Bluetooth-capable endpoints and appliances, prioritizing laptops, workstations, kiosks, point-of-sale systems, and shared physical-access devices.
• If patching is delayed, disable Bluetooth or restrict Bluetooth HID pairing through endpoint management controls.
• Audit paired Bluetooth devices and remove unknown, stale, or unnecessary HID devices.
• Monitor for unexpected Bluetooth pairing events, new HID devices, anomalous input activity, and kernel memory-safety warnings involving HIDP or Bluetooth input handling.
• Treat suspicious Bluetooth HID activity as a physical-proximity incident: preserve kernel logs, Bluetooth service logs, paired-device state, and endpoint telemetry before reimaging or rebooting where practical.
• Track vendor advisories for exact fixed kernel versions and ensure systems are rebooted into the patched kernel after update.