From: sashiko-bot@kernel.org
To: "Jingyuan Liang" <jingyliang@chromium.org>
Cc: linux-input@vger.kernel.org, linux-trace-kernel@vger.kernel.org,
devicetree@vger.kernel.org, robh@kernel.org, conor+dt@kernel.org,
dmitry.torokhov@gmail.com
Subject: Re: [PATCH v6 04/11] HID: spi-hid: add spi-hid driver HID layer
Date: Mon, 19 Oct 2026 19:26:57 +0000 [thread overview]
Message-ID: <sashiko-outbox-178143@kernel.org> (raw)
In-Reply-To: <20261019-send-upstream-v6-4-cb9ba4b3d6fa@chromium.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] HID: spi-hid: zero-length report descriptor accepted in spi_hid_ll_parse()
--
commit 9328ec8c48a0b55cf1019d845ec2c37e89f4cdbb
Author: Jingyuan Liang <jingyliang@chromium.org>
HID: spi-hid: add spi-hid driver HID layer
This commit adds the HID low-level driver callbacks and device creation logic
for spi-hid, handling report descriptor fetching, buffer allocation, and
output/feature report requests.
> diff --git a/drivers/hid/spi-hid/spi-hid-core.c b/drivers/hid/spi-hid/spi-hid-core.c
> index 02a7608c4b882..fca7a44eeb9f9 100644
> --- a/drivers/hid/spi-hid/spi-hid-core.c
> +++ b/drivers/hid/spi-hid/spi-hid-core.c
[ ... ]
> @@ -84,11 +185,484 @@ static const char *spi_hid_power_mode_string(enum hidspi_power_state power_state
[ ... ]
> +/*
> + * This function returns the length of the report descriptor, or a negative
> + * error code if something went wrong.
> + */
> +static int spi_hid_report_descriptor_request(struct spi_hid *shid)
> +{
> + struct device *dev = &shid->spi->dev;
> + struct spi_hid_output_report report = {
> + .report_type = REPORT_DESCRIPTOR,
> + .content_length = 0,
> + .content_id = SPI_HID_OUTPUT_REPORT_CONTENT_ID_DESC_REQUEST,
> + .content = NULL,
> + };
> + int ret;
> +
> + ret = spi_hid_sync_request(shid, &report);
> + if (ret) {
> + dev_err(dev,
> + "Expected report descriptor not received: %d\n", ret);
> + return ret;
> + }
> +
> + ret = shid->response_length;
> + if (ret != shid->desc.report_descriptor_length) {
> + ret = min_t(unsigned int, ret, shid->desc.report_descriptor_length);
> + dev_err(dev, "Received report descriptor length doesn't match device descriptor field, using min of the two: %d\n",
> + ret);
> + }
> +
> + return ret;
> +}
[ ... ]
> +static int spi_hid_ll_parse(struct hid_device *hid)
> +{
> + struct spi_device *spi = hid->driver_data;
> + struct spi_hid *shid = spi_get_drvdata(spi);
> + struct device *dev = &spi->dev;
> + unsigned int rsize = shid->desc.report_descriptor_length;
> + int error, len;
> +
> + if (rsize > HID_MAX_DESCRIPTOR_SIZE) {
> + dev_err(dev,
> + "Report descriptor size %d is greater than HID_MAX_DESCRIPTOR_SIZE %d\n",
> + rsize, HID_MAX_DESCRIPTOR_SIZE);
> + return -EINVAL;
> + }
> +
> + if (rsize > shid->bufsize) {
> + error = spi_hid_alloc_buffers(shid, rsize);
> + if (error)
> + return error;
> + }
> +
> + len = spi_hid_report_descriptor_request(shid);
> + if (len < 0) {
> + dev_err(dev, "Report descriptor request failed, %d\n", len);
> + return len;
> + }
> +
> + /*
> + * FIXME: below call returning 0 doesn't mean that the report descriptor
> + * is good. We might be caching a crc32 of a corrupted r. d. or who
> + * knows what the FW sent. Need to have a feedback loop about r. d.
> + * being ok and only then cache it.
> + */
> + error = hid_parse_report(hid, (u8 *)shid->response->content, len);
> + if (error) {
> + dev_err(dev, "failed parsing report: %d\n", error);
> + return error;
> + }
> + shid->report_descriptor_crc32 = crc32_le(0,
> + (unsigned char const *)shid->response->content,
> + len);
> +
> + set_bit(SPI_HID_READY, &shid->flags);
> +
> + return 0;
> +}
[Severity: Medium]
What happens in spi_hid_ll_parse() if the report descriptor length is 0?
In spi_hid_ll_parse(), rsize (shid->desc.report_descriptor_length) is checked
against HID_MAX_DESCRIPTOR_SIZE, but not for zero. Later in the series, the
commit "HID: spi-hid: add HID SPI protocol implementation" validates
raw->rep_desc_len != 0 in spi_hid_dev_desc_response(), but if a device returns
a REPORT_DESCRIPTOR_RESPONSE with content_length == 0 (shid->response_length ==
0), spi_hid_report_descriptor_request() computes min_t(unsigned int, 0,
shid->desc.report_descriptor_length) and returns 0.
Both spi_hid_ll_parse() here and spi_hid_refresh_device() in the protocol patch
only check if (len < 0), treating len == 0 as success.
When len == 0 is passed to hid_parse_report():
drivers/hid/hid-core.c:hid_parse_report() {
hid->dev_rdesc = kmemdup(start, size, GFP_KERNEL);
if (!hid->dev_rdesc)
return -ENOMEM;
hid->dev_rsize = size;
return 0;
}
kmemdup() returns ZERO_SIZE_PTR (non-NULL), so hid_parse_report() returns 0.
spi_hid_ll_parse() then caches a CRC32 of 0 and sets SPI_HID_READY, and
hid_add_device() sees a non-NULL hdev->dev_rdesc and calls device_add(),
registering an unusable hid_device while bypassing SPI_HID_ERROR reset
recovery.
Should spi_hid_report_descriptor_request() or its callers reject a 0-length
report descriptor (for example, checking !rsize in spi_hid_ll_parse() and
returning -EINVAL when shid->response_length == 0 or len <= 0)?
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261019-send-upstream-v6-0-cb9ba4b3d6fa@chromium.org?part=4
next prev parent reply other threads:[~2026-10-19 19:26 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-19 19:01 [PATCH v6 00/11] Add spi-hid transport driver Jingyuan Liang
2026-10-19 19:01 ` [PATCH v6 01/11] Documentation: Correction in HID output_report callback description Jingyuan Liang
2026-10-19 19:01 ` [PATCH v6 02/11] HID: Add BUS_SPI support and define HID_SPI_DEVICE macro Jingyuan Liang
2026-10-19 19:01 ` [PATCH v6 03/11] HID: spi-hid: add transport driver skeleton for HID over SPI bus Jingyuan Liang
2026-10-19 19:11 ` sashiko-bot
2026-10-19 19:01 ` [PATCH v6 04/11] HID: spi-hid: add spi-hid driver HID layer Jingyuan Liang
2026-10-19 19:26 ` sashiko-bot [this message]
2026-10-19 19:01 ` [PATCH v6 05/11] HID: spi-hid: add HID SPI protocol implementation Jingyuan Liang
2026-10-19 19:22 ` sashiko-bot
2026-10-19 19:01 ` [PATCH v6 06/11] HID: spi-hid: add spi_hid traces Jingyuan Liang
2026-10-19 19:01 ` [PATCH v6 07/11] HID: spi-hid: add ACPI support for HID over SPI Jingyuan Liang
2026-10-19 19:01 ` [PATCH v6 08/11] dt-bindings: input: Document hid-over-spi DT schema Jingyuan Liang
2026-10-19 19:01 ` [PATCH v6 09/11] HID: spi-hid: add device tree support for HID over SPI Jingyuan Liang
2026-10-19 19:01 ` [PATCH v6 10/11] HID: spi-hid: add power management implementation Jingyuan Liang
2026-10-19 19:36 ` sashiko-bot
2026-10-19 19:01 ` [PATCH v6 11/11] HID: spi-hid: add panel follower support Jingyuan Liang
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=sashiko-outbox-178143@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dmitry.torokhov@gmail.com \
--cc=jingyliang@chromium.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=robh@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.