Devicetree
 help / color / mirror / Atom feed
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

  reply	other threads:[~2026-10-19 19:26 UTC|newest]

Thread overview: 18+ 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-20 16:34   ` Rob Herring (Arm)
2026-10-20 17:57   ` Conor Dooley
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox