From: sashiko-bot@kernel.org
To: "Even Xu" <even.xu@intel.com>
Cc: linux-input@vger.kernel.org, dmitry.torokhov@gmail.com
Subject: Re: [PATCH 1/2] HID: Intel-thc-hid: Intel-quicki2c: Fix buffer overflow
Date: Tue, 22 Sep 2026 03:03:14 +0000 [thread overview]
Message-ID: <20260922030314.82CC91F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260922024638.932865-2-even.xu@intel.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] hid: intel-quicki2c: incomplete buffer fix and stale report_len causes -EINVAL for large payloads
--
commit 3ae5fe57bf2559497c69a1a1f4feb9ea45f51690
Author: Even Xu <even.xu@intel.com>
HID: Intel-thc-hid: Intel-quicki2c: Fix buffer overflow
The patch modifies buffer allocations in the intel-quicki2c driver to
account for packet headers in addition to the payload length. This is
intended to prevent buffer overflows when the payload reaches its maximum
size.
> diff --git a/drivers/hid/intel-thc-hid/intel-quicki2c/pci-quicki2c.c b/drivers/hid/intel-thc-hid/intel-quicki2c/pci-quicki2c.c
> index 0d2ad7bc3648a..2537288b50261 100644
> --- a/drivers/hid/intel-thc-hid/intel-quicki2c/pci-quicki2c.c
> +++ b/drivers/hid/intel-thc-hid/intel-quicki2c/pci-quicki2c.c
> @@ -606,7 +606,8 @@ static int quicki2c_alloc_report_buf(struct quicki2c_device *qcdev)
> */
> max_report_len = max(le16_to_cpu(qcdev->dev_desc.max_input_len), SZ_4K);
>
> - qcdev->input_buf = devm_kzalloc(qcdev->dev, max_report_len, GFP_KERNEL);
> + qcdev->input_buf = devm_kzalloc(qcdev->dev,
> + HIDI2C_PACKET_LEN(max_report_len), GFP_KERNEL);
> if (!qcdev->input_buf)
> return -ENOMEM;
>
> @@ -616,7 +617,8 @@ static int quicki2c_alloc_report_buf(struct quicki2c_device *qcdev)
> max_report_len = max(le16_to_cpu(qcdev->dev_desc.max_output_len),
> max_report_len);
>
> - qcdev->report_buf = devm_kzalloc(qcdev->dev, max_report_len, GFP_KERNEL);
> + qcdev->report_buf = devm_kzalloc(qcdev->dev,
> + HIDI2C_PACKET_LEN(max_report_len), GFP_KERNEL);
[Severity: Medium]
Does HIDI2C_PACKET_LEN() add enough space for the headers? It appears to only
add 2 bytes, but output operations and SET_REPORT might require up to 9 bytes
of command headers (e.g., cmd_reg, cmd, data_reg, length).
Also, qcdev->report_len is not updated to match the new size, remaining as
max_report_len just below this allocation.
Will this cause maximum-sized payloads to be incorrectly rejected with -EINVAL?
In quicki2c_init_write_buf(), there is a bounds check:
if (buf_len > write_buf_len)
return -EINVAL;
This evaluates the total packet length (including headers) against the
unadjusted report_len (passed as write_buf_len), causing valid maximum-sized
payloads to be rejected.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260922024638.932865-1-even.xu@intel.com?part=1
next prev parent reply other threads:[~2026-09-22 3:03 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-22 2:46 [PATCH 0/2] HID: Intel-thc-hid: Fix potential buffer overflow Even Xu
2026-09-22 2:46 ` [PATCH 1/2] HID: Intel-thc-hid: Intel-quicki2c: Fix " Even Xu
2026-09-22 3:03 ` sashiko-bot [this message]
2026-09-22 2:46 ` [PATCH 2/2] HID: Intel-thc-hid: Intel-quickspi: " Even Xu
2026-09-23 16:48 ` [PATCH 0/2] HID: Intel-thc-hid: Fix potential " Jiri Kosina
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=20260922030314.82CC91F000FF@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=dmitry.torokhov@gmail.com \
--cc=even.xu@intel.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.