CVE-2026-89999: HID: wacom: validate report length in wacom_intuos_pro2_bt_irq
In the Linux kernel, the following vulnerability has been resolved:
HID: wacom: validate report length in wacomintuospro2btirq
wacomintuospro2btirq() receives the wire report length in len but never consults it before parsing. After the report-id gate it unconditionally calls wacomintuospro2btpen() and then, selected by features.type, a fixed chain of sub-parsers, none of which receive len:
wacomintuospro2btpen(wacom); if (type == INTUOSP2BT || type == INTUOSP2SBT) { wacomintuospro2bttouch(wacom); wacomintuospro2btpad(wacom); wacomintuospro2btbattery(wacom); } else { wacomintuosgen3btpad(wacom); wacomintuosgen3btbattery(wacom); }
Each sub-parser dereferences wacom->data at fixed offsets. The furthest byte touched on each branch is:
INTUOSP2BT / INTUOSP2SBT: wacomintuospro2btpad() reads data[285] (the touchring byte), so the report must be at least 286 bytes; INTUOSHT3BT ("gen3"): wacomintuosgen3btbattery() reads data[45], so the report must be at least 46 bytes.
features.type is selected from the VID/PID idtable entry and wacomsetupdevicequirks() force-registers the pen/pad/touch inputs for that type independent of the report descriptor, so a malicious or malfunctioning paired/spoofed Bluetooth peripheral can advertise that VID/PID and send an undersized report that still satisfies the data[0] == 0x80/0x81 gate. The driver then reads past the received report and forwards the bytes to userspace via evdev (MSCSERIAL / ABSMISC / ABSWHEEL on the pen and pad input nodes), an out-of-bounds read with a concrete userspace read-back channel, and a true out-of-bounds read on transports whose backing buffer is sized to the (small) report descriptor rather than a fixed-size staging buffer.
This is the same class of bug commit 2f1763f62909 ("HID: wacom: fix out-of-bounds read in wacomintuosbtirq") already hardened in the sibling wacomintuosbtirq(), which guards each report id against its minimum length before parsing.
Guard wacomintuospro2btirq() the same way: before parsing, reject reports shorter than the furthest offset the selected branch actually dereferences, warn, and bail out. Because the whole pen/touch/pad/ battery chain runs unconditionally per branch, a single up-front check against the maximum offset (286 bytes for INTUOSP2BT/INTUOSP2SBT, 46 bytes for the gen3 branch) bounds every sub-parser. Returning 0 on a short report also skips those calls for the same malformed report, which is the safe, conservative behavior.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Implement the fix by validating the Bluetooth HID report length in wacom_intuos_pro2_bt_irq() (and similarly guard wacom_intuos_pro2_bt_irq parsing) so that short/undersized reports that still pass the report-id gate are rejected before sub-parsers dereference wacom->data at fixed offsets (e.g., minimum 286 bytes for INTUOSP2_BT/INTUOSP2S_BT and minimum 46 bytes for the gen3 branch).
Linux kernel HID: Wacom validate report length before parsing in wacom_intuos_pro2_bt_irq() = reject malformed reports with insufficient length (early bail out) before any sub-parser dereference
Event History
Frequently Asked Questions
Which device variants are affected by the missing length validation?
The affected parsing paths are INTUOSP2_BT and INTUOSP2S_BT, which require reports of at least 286 bytes, and INTUOSHT3_BT (“gen3”), which requires reports of at least 46 bytes. The device type is selected from the VID/PID id_table entry.
What occurs when a report is shorter than the parser expects?
After the report-ID check, the handler invokes fixed-offset sub-parsers without passing or checking the received report length. A short report can therefore cause accesses beyond the available report data, including data[285] on the Pro2 paths and data[45] on the gen3 path.
Does registering the relevant input interfaces depend on receiving a full report?
No. wacom_setup_device_quirks() force-registers the pen, pad, and touch inputs for the selected device type independently of the report length.