Cloudanix VulnDB

CVE-2026-43051

High · 8.1

CVSS

8.1

EPSS

0.3%

Published

May 1, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A nearby attacker using a malicious Bluetooth input device could crash some Linux systems or potentially expose sensitive system memory unless the kernel is updated.

Exploitation
Adjacent Network
Attacker needs
None
Complexity
Low
Impact
Data Exposure
Component
OS kernel
Class
Memory Corruption
Remediation
Patch
Effort
Low
Patch risk
Low

What it actually does

This is an adjacent-network Linux kernel memory-safety flaw in the Wacom Bluetooth HID input driver. The vulnerable wacom_intuos_bt_irq() handler processes specific Bluetooth HID report IDs without verifying that the received report buffer is long enough. A crafted short report for report ID 0x03 or 0x04 can cause the kernel driver to read beyond the end of the supplied report buffer. The most likely technical outcomes are kernel memory disclosure through unintended reads and kernel instability or crash, resulting in denial of service. The CVSS vector indicates no privileges or user interaction are required, but the attacker must be within an adjacent Bluetooth attack path and the vulnerable Wacom HID code path must be reachable.

Why it matters to the business

Organizations using vulnerable Linux kernels on desktops, laptops, workstations, kiosks, or specialized systems with Bluetooth HID support may be exposed to local-proximity attacks. Successful exploitation could crash affected systems or potentially expose sensitive kernel memory, disrupting user productivity and increasing the risk of information disclosure. The flaw is not currently listed in CISA KEV, has no known mature public exploit, is not associated with ransomware use, and has a low stable EPSS score, so broad internet-scale exploitation is unlikely; however, systems in shared offices, public spaces, labs, classrooms, or high-security environments where untrusted Bluetooth proximity is plausible should still be prioritized.

How an attack unfolds

An attacker positions themselves within Bluetooth range of a vulnerable Linux system that has the Wacom Bluetooth HID driver path available. They then use a malicious or modified Bluetooth HID device, or equivalent Bluetooth tooling, to present or interact as a Wacom-compatible HID source. Instead of sending a valid-length HID report, the attacker sends a malformed short report using report ID 0x03 or 0x04. The vulnerable kernel handler processes the report without sufficient length validation and reads past the end of the received buffer while copying report-derived values into the Wacom device state. Depending on memory layout and kernel hardening, this can cause a kernel warning, KASAN finding, system crash, or exposure of unintended kernel memory. There is no indication from the supplied intelligence that this vulnerability provides reliable remote code execution.

How to fix it

Upgrade affected Linux kernels to a version containing the upstream fix for the Wacom Bluetooth HID report length validation. Because no exact fixed package versions were provided, use the latest security update from the operating system or kernel vendor and verify that the patch adding explicit length checks for Wacom Bluetooth report IDs 0x03 and 0x04 is included. Where immediate patching is not possible, reduce exposure by disabling Bluetooth on systems that do not need it, blocking or removing untrusted Bluetooth HID devices, disabling the Wacom kernel module if Wacom devices are not required, enforcing Bluetooth pairing controls, and limiting use of affected systems in untrusted physical proximity areas.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel version includes the vendor security update for this issue or the upstream Wacom HID bounds-checking patch. Validate that rebooted systems are actually running the updated kernel, not only that the package is installed. Check whether the Wacom driver is loaded using standard Linux module inventory commands and confirm whether Bluetooth HID is enabled where it is not required. On test systems, a malformed short report for Wacom Bluetooth report ID 0x03 or 0x04 should be rejected or logged as a short report rather than causing an out-of-bounds read, KASAN finding, or kernel crash. Review kernel logs after validation for Wacom, HID, Bluetooth, Oops, BUG, or KASAN messages.

Typical attack path

  1. Identify a Linux system within Bluetooth range that may have Bluetooth HID enabled and a vulnerable kernel Wacom HID driver.
  2. Prepare a malicious Bluetooth HID device or Bluetooth attack tool capable of sending Wacom-like HID reports.
  3. Trigger the vulnerable Wacom Bluetooth input handling path by connecting, pairing, or otherwise causing the target to process the malicious HID report stream.
  4. Send a crafted short HID report using report ID 0x03 or 0x04 that is shorter than the required safe length.
  5. Cause the kernel driver to perform an out-of-bounds read while processing the report.
  6. Observe effects such as kernel warnings, crash, input-device malfunction, or possible memory disclosure depending on system configuration and exploit reliability.

How to detect it

To determine whether exploitation may already have occurred, review kernel, system, and endpoint telemetry for crashes or warnings involving the Wacom HID driver and Bluetooth HID input processing. Primary sources include journald, syslog, dmesg, kernel crash dumps, KASAN reports, endpoint detection telemetry, Bluetooth pairing history, and incident reports for unexpected reboots or input-device failures. Look for kernel call traces referencing wacom_intuos_bt_irq, Wacom Bluetooth HID processing, short HID reports, slab or heap out-of-bounds reads, kernel Oops events, panic events, or KASAN findings. Also review Bluetooth controller and pairing logs for unknown HID devices, unexpected Wacom-like devices, or connection attempts near the time of kernel instability. Patched systems may log warnings for short reports rather than crashing; those warnings can indicate attempted triggering or malformed device behavior. Because no public exploit artifacts or threat actor tooling are identified in the supplied intelligence, detection should focus on behavioral evidence rather than known malware indicators.

  • wacom_intuos_bt_irq
  • KASAN: slab-out-of-bounds
  • KASAN: out-of-bounds
  • BUG: KASAN
  • kernel BUG
  • Oops:
  • Kernel panic
  • hid-wacom
  • wacom
  • Bluetooth HID
  • HIDP
  • short report
  • report 0x03
  • report 0x04
  • /sys/module/wacom
  • /proc/modules

What your security team should do

  • Prioritize kernel updates for Linux endpoints and workstations that use Bluetooth, Wacom tablets, shared physical spaces, or high-risk user populations.
  • Inventory systems with Bluetooth enabled and the Wacom HID driver loaded or available, especially laptops and workstations.
  • Disable Bluetooth or the Wacom driver on systems where they are not operationally required until patched.
  • Restrict Bluetooth pairing to trusted devices and remove unknown or stale Bluetooth HID pairings.
  • Monitor kernel logs for Wacom HID warnings, KASAN out-of-bounds reports, kernel Oops events, and unexplained crashes involving Bluetooth HID input handling.
  • For sensitive environments, consider physical proximity risk controls such as disabling discoverability, limiting Bluetooth use in secure areas, and investigating unknown Bluetooth devices near critical systems.
  • Track vendor advisories for exact distribution-specific fixed kernel versions and ensure systems are rebooted into the fixed kernel after update deployment.

The record

In the Linux kernel, the following vulnerability has been resolved: HID: wacom: fix out-of-bounds read in wacom_intuos_bt_irq The wacom_intuos_bt_irq() function processes Bluetooth HID reports without sufficient bounds checking. A maliciously crafted short report can trigger an out-of-bounds read when copying data into the wacom structure. Specifically, report 0x03 requires at least 22 bytes to safely read the processed data and battery status, while report 0x04 (which falls through to 0x03) requires 32 bytes. Add explicit length checks for these report IDs and log a warning if a short report is received.

Affected packages

Ecosystem Package Introduced Fixed

Related vulnerabilities