CVE-2026-63916

What it actually does

CVE-2026-63916 is an out-of-bounds write in the Linux kernel Wacom HID driver. The vulnerable code assumes the HID_DG_INPUTMODE usage is located in the first field of a HID feature report and writes to field[0]->value using an index derived from the actual usage location. A crafted HID descriptor can place HID_DG_INPUTMODE in a different field while making the first field too small, causing the kernel to write outside the intended value array. Because this occurs in kernel context, successful exploitation can potentially corrupt kernel memory and lead to denial of service, privilege escalation, or broader compromise of confidentiality and integrity. The attack vector is adjacent/physical-proximity style: exploitation requires presenting a malicious or compromised HID device, such as USB, Bluetooth, or another HID transport exposed to the affected system.

Why it matters to the business

Systems that allow attachment or pairing of untrusted HID devices could be crashed or potentially taken over at the kernel level by a malicious peripheral. The most realistic operational risk is workstation or kiosk disruption through kernel panic, but the CVSS impact reflects the possibility of full system compromise if memory corruption is reliably weaponized. This issue is not listed in CISA KEV, is not known to be used in ransomware campaigns, and currently has low EPSS and no public exploit maturity reported, so urgency is highest for endpoints, labs, kiosks, shared workstations, production consoles, and environments where users can connect arbitrary USB or Bluetooth devices.

How an attack unfolds

An attacker prepares a malicious HID device or emulated HID endpoint that advertises a crafted Wacom-like HID descriptor. The descriptor places HID_DG_INPUTMODE in a field other than field zero and arranges the first field so its report_count is smaller than the usage index later used by the driver. When the affected Linux system enumerates the device and the Wacom HID driver processes the feature mapping, the driver records the usage index but later writes to the wrong field in wacom_hid_set_device_mode(). The write lands outside the bounds of field[0]->value, corrupting adjacent kernel memory. Depending on heap layout, hardening, and exploit reliability, the result may be a kernel crash, memory corruption primitive, privilege escalation, or code execution in kernel context.

How to fix it

Upgrade the Linux kernel to a version that includes the upstream fix for the Wacom HID driver issue in wacom_hid_set_device_mode(). If using a distribution kernel, apply the vendor security update rather than only relying on upstream version numbers, because fixes are commonly backported. No exact fixed package versions were provided in the input, so consult the relevant distribution advisory for the patched kernel build. As interim mitigations, restrict physical access to systems, disable or tightly control USB/Bluetooth HID device attachment where feasible, use USB device-control/allowlisting tools, disable the Wacom HID driver on systems that do not require Wacom tablet support, and prevent automatic pairing of untrusted Bluetooth HID devices.

How to confirm the fix worked

Confirm that the running kernel build contains the Wacom HID bounds-checking fix, not just that a package is installed. Validate with the distribution advisory, package changelog, or kernel source/backport notes referencing the Wacom HID out-of-bounds write fix. Check the active kernel using uname -a and verify the patched kernel is booted after update. On source-based or custom kernels, inspect the HID Wacom driver code to confirm wacom_hid_set_device_mode() uses the stored field index for HID_DG_INPUTMODE and validates both the field index and value index before writing. For exposure validation, identify systems with the Wacom HID driver available or loaded and systems that permit untrusted USB/Bluetooth HID attachment.

Typical attack path

1. Attacker obtains physical, local-adjacent, or wireless proximity access sufficient to connect or pair a HID device.
2. Attacker configures a malicious USB/Bluetooth HID device or emulator with a crafted Wacom-compatible HID descriptor.
3. The target Linux system enumerates the device and loads or invokes the Wacom HID driver path.
4. The crafted feature report causes HID_DG_INPUTMODE to be mapped in a nonzero field while field zero has an insufficient report_count.
5. The vulnerable kernel code writes to field[0]->value using an index that is valid for another field but out of bounds for field zero.
6. Kernel memory is corrupted, resulting in a crash or potentially attacker-controlled kernel behavior.

How to detect it

Look for signs of suspicious HID device enumeration followed by kernel warnings, oopses, panics, or memory-corruption reports. Useful sources include systemd journal logs, dmesg, kern.log, syslog, audit logs for USB/Bluetooth events, endpoint device-control logs, EDR telemetry, usbguard logs if deployed, Bluetooth daemon logs, and kernel crash dumps such as kdump/vmcore. Search for Wacom HID driver activity immediately before crashes, unexpected HID descriptors, newly attached USB vendor/product IDs, Bluetooth HID pairing events, and kernel memory-safety messages such as KASAN out-of-bounds reports. Because there is no known public exploit or known campaign at the time of the provided data, detection should focus on behavioral correlation: new or unusual HID/Wacom-like device attachment, followed within seconds or minutes by kernel OOB write, slab corruption, general protection fault, oops, panic, or reboot. If crash dumps are available, inspect stack traces for wacom_hid_set_device_mode(), Wacom HID feature-report handling, hid_hw_request(), or related HID input-mode setup paths.

• wacom_hid_set_device_mode
• HID_DG_INPUTMODE
• hid-wacom
• wacom
• BUG: KASAN: slab-out-of-bounds
• BUG: KASAN: out-of-bounds
• kernel BUG at drivers/hid/wacom
• Oops:
• general protection fault
• Kernel panic - not syncing
• usb .* new .* HID device
• Bluetooth: HIDP

What your security team should do

• Prioritize patching Linux endpoints where users or attackers can connect USB or Bluetooth HID devices, especially shared workstations, kiosks, engineering systems, and physical-accessible servers.
• Apply the vendor-provided kernel update and reboot into the patched kernel; verify the running kernel rather than only package installation state.
• Where Wacom devices are not needed, consider disabling or blacklisting the Wacom HID driver as a compensating control after confirming operational impact.
• Enforce USB and Bluetooth device-control policies, including allowlisting trusted peripherals and blocking new HID device classes where practical.
• Review recent kernel crash, oops, and HID enumeration logs for suspicious Wacom/HID activity, especially around unexpected USB or Bluetooth device connections.
• Treat unexplained kernel panics following HID device connection as potentially security-relevant and preserve volatile logs, kernel crash dumps, and device enumeration artifacts.
• Monitor vendor advisories for exact fixed distribution package versions and for any change in exploit maturity, KEV status, or public proof-of-concept availability.