From: sashiko-bot@kernel.org
To: "Wei Jie Law" <98lawweijie@gmail.com>
Cc: linux-input@vger.kernel.org, dmitry.torokhov@gmail.com
Subject: Re: [PATCH] HID: wacom: fix OOB read in wacom_wac_pen_serial_enforce()
Date: Sat, 22 Aug 2026 12:24:51 +0000 [thread overview]
Message-ID: <20260822122451.61CF31F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260822120926.153849-1-98lawweijie@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] A 1-byte out-of-bounds heap read occurs in `wacom_wac_pen_serial_enforce` when processing an unnumbered HID report.
--
--- Patch [1]: [PATCH] HID: wacom: fix OOB read in wacom_wac_pen_serial_enforce() ---
commit 7eb0a702b27b2b8dba9547945aa50ecb4a4d7cc0
Author: Wei Jie Law <98lawweijie@gmail.com>
HID: wacom: fix OOB read in wacom_wac_pen_serial_enforce()
This commit fixes an out-of-bounds read in wacom_wac_pen_serial_enforce()
by clamping the usage iteration count to the field's actual report count.
This prevents extracting data beyond the received report bounds when a
descriptor lists more usages than its Report Count.
> diff --git a/drivers/hid/wacom_sys.c b/drivers/hid/wacom_sys.c
> index 0eafa483b7f75..1ea8763b68a82 100644
> --- a/drivers/hid/wacom_sys.c
> +++ b/drivers/hid/wacom_sys.c
> @@ -113,8 +113,10 @@ static int wacom_wac_pen_serial_enforce(struct hid_device *hdev,
>
> /* Queue events which have invalid tool type or serial number */
> for (i = 0; i < report->maxfield; i++) {
> - for (j = 0; j < report->field[i]->maxusage; j++) {
> - struct hid_field *field = report->field[i];
> + struct hid_field *field = report->field[i];
> + unsigned int count = min(field->maxusage, field->report_count);
> +
> + for (j = 0; j < count; j++) {
> struct hid_usage *usage = &field->usage[j];
> unsigned int equivalent_usage = wacom_equivalent_usage(usage->hid);
> unsigned int offset;
[Severity: High]
This isn't a bug introduced by this patch, but does the call to
hid_field_extract() later in this loop cause an out-of-bounds read if the
report is unnumbered?
Inside the loop, the code calls:
value = hid_field_extract(hdev, raw_data+1, offset + j * size, size);
This blindly adds 1 to raw_data, assuming raw_data[0] is a report ID. If an
attacker crafts a USB HID device (or uses UHID) with the Wacom vendor ID
(0x056a) but provides a descriptor with no Report ID, the transport layer
allocates a buffer exactly matching the payload size.
For the last field in such an unnumbered report, this reads 1 byte past the
end of the heap allocation. Since the extracted value can be stored in
wacom_wac->serial[0] and emitted to userspace via MSC_SERIAL events, could
this lead to a 1-byte out-of-bounds heap read and information disclosure?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260822120926.153849-1-98lawweijie@gmail.com?part=1
next prev parent reply other threads:[~2026-08-22 12:24 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-22 12:09 [PATCH] HID: wacom: fix OOB read in wacom_wac_pen_serial_enforce() Wei Jie Law
2026-08-22 12:24 ` sashiko-bot [this message]
2026-08-25 10:35 ` Wei Jie LAW
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260822122451.61CF31F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=98lawweijie@gmail.com \
--cc=dmitry.torokhov@gmail.com \
--cc=linux-input@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.