In the Linux kernel, the following vulnerability has been resolved:
HID: wacom: validate report length in wacom_intuos_pro2_bt_irq
wacom_intuos_pro2_bt_irq() receives the wire report length in len
but never consults it before parsing. After the report-id gate it
unconditionally calls wacom_intuos_pro2_bt_pen() and then, selected by
features.type, a fixed chain of sub-parsers, none of which receive
len:
<pre>
wacom_intuos_pro2_bt_pen(wacom);
if (type == INTUOSP2_BT || type == INTUOSP2S_BT) {
wacom_intuos_pro2_bt_touch(wacom);
wacom_intuos_pro2_bt_pad(wacom);
wacom_intuos_pro2_bt_battery(wacom);
} else {
wacom_intuos_gen3_bt_pad(wacom);
wacom_intuos_gen3_bt_battery(wacom);
}
</pre>
Each sub-parser dereferences wacom->data at fixed offsets. The furthest
byte touched on each branch is:
INTUOSP2_BT / INTUOSP2S_BT: wacom_intuos_pro2_bt_pad() reads data[285]
(the touchring byte), so the report must be at least 286 bytes;
INTUOSHT3_BT ("gen3"): wacom_intuos_gen3_bt_battery() reads data[45],
so the report must be at least 46 bytes.
features.type is selected from the VID/PID id_table entry and
wacom_setup_device_quirks() 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 (MSC_SERIAL /
ABS_MISC / ABS_WHEEL 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 wacom_intuos_bt_irq") already hardened in the
sibling wacom_intuos_bt_irq(), which guards each report id against its
minimum length before parsing.
Guard wacom_intuos_pro2_bt_irq() 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 INTUOSP2_BT/INTUOSP2S_BT,
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.
CVSS Vector: CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H
CVSS Score: 8.1
AV:A - wacom_intuos_pro2_bt_irq() is reached only for BUS_BLUETOOTH Wacom Intuos Pro/HT3 devices (VID 0x056a, PIDs 0x360/0x361/0x377/0x379/0x393/0x3c6/0x3c8/0x3dd) via hidp/uhid HID input reports over L2CAP, so the attacker must be a Bluetooth HID peer on the same radio segment.
AC:L - The attacker fully controls the HID report ID, descriptor, and wire length; any report with data[0]==0x80/0x81 that hid_get_report() accepts is parsed at fixed offsets with no length check, so a short report reliably triggers the OOB read.
PR:N - The attacker is the Bluetooth HID peripheral sending input reports and needs no local account or capability; BlueZ/hidp connection setup is a host-side management path, not a privilege required of the reporting device.
UI:N - After a paired, spoofed, or already-connected Intuos Pro/HT3 Bluetooth HID session exists, the peer can emit the short 0x80/0x81 report on the interrupt channel without further victim clicks, pairing prompts, or mounts.
S:U - The Wacom HID parser and the resulting kernel/input/power_supply impact remain under the same host kernel security authority, with no VM escape, IOMMU/DMA bypass, or other cross-boundary effect.
C:H - The parsers read wacom->data at fixed offsets through data[285] (286 bytes) ignoring len, which is a kernel OOB read, and those bytes are reported to userspace via evdev (MSC_SERIAL, ABS_MISC, ABS_WHEEL, pen/touch axes), a concrete disclosure channel.
I:N - The defect is an out-of-bounds read of the HID report buffer, not an OOB write or UAF, and it does not yield an attacker-controlled kernel memory modification or control-flow hijack primitive.
A:H - Reading hundreds of bytes past a short HID report can fault when the transport buffer is sized to the received report or descriptor rather than a large staging buffer, and an adjacent peer can repeat the malformed report to panic or oops the host.
| Attack Vector |
Adjacent Network |
Scope |
Unchanged |
| Attack Complexity |
Low |
Confidentiality Impact |
High |
| Privileges Required |
None |
Integrity Impact |
None |
| User Interaction |
None |
Availability Impact |
High |
AV:A - wacom_intuos_pro2_bt_irq() is reached only for BUS_BLUETOOTH Wacom Intuos Pro/HT3 devices (VID 0x056a, PIDs 0x360/0x361/0x377/0x379/0x393/0x3c6/0x3c8/0x3dd) via hidp/uhid HID input reports over L2CAP, so the attacker must be a Bluetooth HID peer on the same radio segment.
AC:L - The attacker fully controls the HID report ID, descriptor, and wire length; any report with data[0]==0x80/0x81 that hid_get_report() accepts is parsed at fixed offsets with no length check, so a short report reliably triggers the OOB read.
PR:N - The attacker is the Bluetooth HID peripheral sending input reports and needs no local account or capability; BlueZ/hidp connection setup is a host-side management path, not a privilege required of the reporting device.
UI:N - After a paired, spoofed, or already-connected Intuos Pro/HT3 Bluetooth HID session exists, the peer can emit the short 0x80/0x81 report on the interrupt channel without further victim clicks, pairing prompts, or mounts.
S:U - The Wacom HID parser and the resulting kernel/input/power_supply impact remain under the same host kernel security authority, with no VM escape, IOMMU/DMA bypass, or other cross-boundary effect.
C:H - The parsers read wacom->data at fixed offsets through data[285] (286 bytes) ignoring len, which is a kernel OOB read, and those bytes are reported to userspace via evdev (MSC_SERIAL, ABS_MISC, ABS_WHEEL, pen/touch axes), a concrete disclosure channel.
I:N - The defect is an out-of-bounds read of the HID report buffer, not an OOB write or UAF, and it does not yield an attacker-controlled kernel memory modification or control-flow hijack primitive.
A:H - Reading hundreds of bytes past a short HID report can fault when the transport buffer is sized to the received report or descriptor rather than a large staging buffer, and an adjacent peer can repeat the malformed report to panic or oops the host.
CVSS 3.1