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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox