---
id: "CVE-2026-98499"
kind: "vulnerability"
aliases: ["CVE-2026-98499"]
title: "Linux kernel: Wacom HID driver reads past report, leaks memory"
severity: "low"
cvss: null
epss: null
exploited: false
status: "open"
category: "infrastructure"
products: []
ecosystems: []
tags: ["desktop-linux", "hid", "infrastructure", "linux-kernel", "server-linux", "wacom"]
not_affected_if: ["module-not-loaded", "no-wacom-hardware"]
published_at: "2026-10-18T16:17:00+00:00"
first_seen_at: "2026-10-23T21:57:15+00:00"
updated_at: "2026-10-25T05:25:35+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98499", "first_seen_at": "2026-10-23T21:57:15+00:00"}]
---

# Linux kernel: Wacom HID driver reads past report, leaks memory

A malicious or malformed USB HID device with a crafted descriptor can make the Wacom driver read memory beyond the end of a received report. The leaked value is reported to userspace as an MSC_SERIAL input event, so an attacker gets kernel memory contents as information disclosure.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- Run `uname -r` and compare against the fixed kernel version in your distribution's advisory (unknown in the sources)
- Check whether the Wacom HID driver is loaded with `lsmod | grep wacom`

## Fix

- Update the Linux kernel to a release that includes the upstream commit fixing wacom_wac_pen_serial_enforce() (fixed version: unknown in the sources)
- Until patched, unload the driver with `modprobe -r wacom` if no Wacom tablet is in use

## Timeline

- 2026-10-23T21:57:15+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-98499

## From the sources

In the Linux kernel, the following vulnerability has been resolved:

HID: wacom: fix OOB read in wacom_wac_pen_serial_enforce()

The 'wacom_wac_pen_serial_enforce()' function may calculate and pass an
invalid offset to hid_field_extract(), resulting in memory reads at
incorrect addresses -- possibly beyond the end of the report.  If a
field in the HID descriptor lists more usages than its Report Count
actually reserves space for, the function's inner 'j' will walk past
the end of the field:

	for (i = 0; i < report->maxfield; i++) {
		for (j = 0; j < report->field[i]->maxusage; j++) {
			...
			value = hid_field_extract(hdev, raw_data + 1,
						  offset + j * size, size);

A descriptor listing 12288 usages against Report Count 1 has the loop
extract the usage at index 12287 from bit offset 98296 -- about 12 KB
past a 2-byte received report.  The value is stored in
wacom_wac->serial[0] and can reach userspace as an MSC_SERIAL event,
making this an information disclosure.

Clamp the loop to field->report_count, the number of value slots the
report holds.  Value slots past the last declared usage are still
scanned; they reuse that usage (HID 1.11, 6.2.2.8).

Verified on v6.12.105 with a UHID reproducer: a 2-byte report from
such a descriptor trips KASAN before the patch and not after it.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_
