CVE-2026-98499
NoneCVSS
—
EPSS
0.2%
Published
Oct 18, 2026
CISA due date
—
Cloudanix analysis
A tablet input driver could accidentally read a little extra internal memory and send that data to applications, so updating the system prevents the leak.
- Exploitation
- Local Privilege
- Attacker needs
- Local User
- Complexity
- Moderate
- Impact
- Data Exposure
- Component
- OS kernel
- Class
- Memory Corruption
- Remediation
- Patch
- Effort
- Medium
- Patch risk
- Low
What it actually does
Out-of-bounds read in wacom_wac_pen_serial_enforce() when a HID descriptor declares more usages than its Report Count; the loop index walks past allocated report data and passes an invalid offset to hid_field_extract(), exposing kernel memory contents that are written into wacom_wac->serial[] and emitted as MSC_SERIAL events.
Why it matters to the business
Low-probability kernel-memory disclosure on systems with Wacom tablets or UHID-based virtual devices; requires a kernel update within normal patching cycles but adds urgency for high-security or multi-tenant environments where even small leaks matter.
How an attack unfolds
An attacker supplies a crafted HID descriptor listing far more usages than the declared Report Count, sends a minimal report through a physical tablet or UHID, and triggers the unbounded loop in pen-serial enforcement; the resulting out-of-bounds read value is stored and may be observed from user space.
How to fix it
Apply the upstream fix that clamps the inner loop to field->report_count; rebuild or install the corrected kernel package for the running distribution.
How to confirm the fix worked
Confirm the patch is present by inspecting the wacom driver source for the report_count clamp; re-run the provided UHID reproducer under KASAN and verify no out-of-bounds access is reported.
Typical attack path
- Deliver malicious HID descriptor via physical device or UHID
- Send short report that exercises wacom_wac_pen_serial_enforce()
- Loop index exceeds report_count and reads past buffer end
- Extracted value propagates to MSC_SERIAL event observable in user space
How to detect it
Search kernel logs and audit trails for invocations of wacom_wac_pen_serial_enforce or hid_field_extract with unusually large offsets; monitor MSC_SERIAL events for values that do not match expected device serial numbers.
- wacom_wac_pen_serial_enforce
- hid_field_extract.*offset
- MSC_SERIAL
What your security team should do
- Prioritize kernel updates on systems that expose Wacom or custom HID devices
- Review any local code that parses or forwards HID reports for similar usage-count assumptions
- Add kernel log monitoring for wacom driver anomalies until patches are deployed
The record
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.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|