All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] HID: intel-thc-hid: reject oversized QuickSPI GET_REPORT responses
@ 2026-08-18 14:02 Jérémy Jean
  2026-08-18 14:15 ` sashiko-bot
  0 siblings, 1 reply; 2+ messages in thread
From: Jérémy Jean @ 2026-08-18 14:02 UTC (permalink / raw)
  To: Even Xu, Xinpeng Sun
  Cc: Jiri Kosina, Benjamin Tissoires, linux-input, linux-kernel,
	Jérémy Jean

Thread the HID core caller length into quickspi_get_report() and reject
responses that exceed the caller-provided buffer before the final copy.
Snapshot the completed response length once so the bound check, copy, and
returned byte count all use the same value.

Fixes: 9d8d51735a3a ("HID: intel-thc-hid: intel-quickspi: Add HIDSPI protocol implementation")
Assisted-by: Codex:gpt-5
Signed-off-by: Jérémy Jean <Jeremy.Jean@oss.cyber.gouv.fr>
---
 .../intel-thc-hid/intel-quickspi/quickspi-hid.c   |  2 +-
 .../intel-quickspi/quickspi-protocol.c            | 15 ++++++++++++---
 .../intel-quickspi/quickspi-protocol.h            |  2 +-
 3 files changed, 14 insertions(+), 5 deletions(-)

diff --git a/drivers/hid/intel-thc-hid/intel-quickspi/quickspi-hid.c b/drivers/hid/intel-thc-hid/intel-quickspi/quickspi-hid.c
index 91d5807b4a83..a60a0a7f16aa 100644
--- a/drivers/hid/intel-thc-hid/intel-quickspi/quickspi-hid.c
+++ b/drivers/hid/intel-thc-hid/intel-quickspi/quickspi-hid.c
@@ -61,7 +61,7 @@ static int quickspi_hid_raw_request(struct hid_device *hid,
 
 	switch (reqtype) {
 	case HID_REQ_GET_REPORT:
-		ret = quickspi_get_report(qsdev, rtype, reportnum, buf);
+		ret = quickspi_get_report(qsdev, rtype, reportnum, buf, len);
 		break;
 	case HID_REQ_SET_REPORT:
 		ret = quickspi_set_report(qsdev, rtype, reportnum, buf, len);
diff --git a/drivers/hid/intel-thc-hid/intel-quickspi/quickspi-protocol.c b/drivers/hid/intel-thc-hid/intel-quickspi/quickspi-protocol.c
index cb19057f1191..acc9d67c53ca 100644
--- a/drivers/hid/intel-thc-hid/intel-quickspi/quickspi-protocol.c
+++ b/drivers/hid/intel-thc-hid/intel-quickspi/quickspi-protocol.c
@@ -342,10 +342,12 @@ int reset_tic(struct quickspi_device *qsdev)
 }
 
 int quickspi_get_report(struct quickspi_device *qsdev,
-			u8 report_type, unsigned int report_id, void *buf)
+			u8 report_type, unsigned int report_id,
+			void *buf, size_t buf_len)
 {
 	int rep_type;
 	int ret;
+	u32 report_len;
 
 	if (report_type == HID_INPUT_REPORT) {
 		rep_type = GET_INPUT_REPORT;
@@ -371,10 +373,17 @@ int quickspi_get_report(struct quickspi_device *qsdev,
 		return -ETIMEDOUT;
 	}
 	qsdev->get_report_cmpl = false;
+	report_len = READ_ONCE(qsdev->report_len);
+
+	if (report_len > buf_len) {
+		dev_err_once(qsdev->dev, "Get report response too large: %u vs %zu\n",
+			     report_len, buf_len);
+		return -EINVAL;
+	}
 
-	memcpy(buf, qsdev->report_buf, qsdev->report_len);
+	memcpy(buf, qsdev->report_buf, report_len);
 
-	return qsdev->report_len;
+	return report_len;
 }
 
 int quickspi_set_report(struct quickspi_device *qsdev,
diff --git a/drivers/hid/intel-thc-hid/intel-quickspi/quickspi-protocol.h b/drivers/hid/intel-thc-hid/intel-quickspi/quickspi-protocol.h
index 775e29c1ed13..aa2c935dafe8 100644
--- a/drivers/hid/intel-thc-hid/intel-quickspi/quickspi-protocol.h
+++ b/drivers/hid/intel-thc-hid/intel-quickspi/quickspi-protocol.h
@@ -12,7 +12,7 @@ struct quickspi_device;
 
 void quickspi_handle_input_data(struct quickspi_device *qsdev, u32 buf_len);
 int quickspi_get_report(struct quickspi_device *qsdev, u8 report_type,
-			unsigned int report_id, void *buf);
+			unsigned int report_id, void *buf, size_t buf_len);
 int quickspi_set_report(struct quickspi_device *qsdev, u8 report_type,
 			unsigned int report_id, void *buf, u32 buf_len);
 int quickspi_get_report_descriptor(struct quickspi_device *qsdev);
-- 
2.47.3


^ permalink raw reply related	[flat|nested] 2+ messages in thread

* Re: [PATCH] HID: intel-thc-hid: reject oversized QuickSPI GET_REPORT responses
  2026-08-18 14:02 [PATCH] HID: intel-thc-hid: reject oversized QuickSPI GET_REPORT responses Jérémy Jean
@ 2026-08-18 14:15 ` sashiko-bot
  0 siblings, 0 replies; 2+ messages in thread
From: sashiko-bot @ 2026-08-18 14:15 UTC (permalink / raw)
  To: Jérémy Jean; +Cc: linux-input, dmitry.torokhov

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:

Pre-existing issues:
- [High] Missing bounds check on user-supplied buffer length in `quickspi_set_report` leads to a heap buffer overflow in `write_cmd_to_txdma`.
- [High] Preexisting heap buffer overflows in the QuickSPI DMA input reporting paths due to 4KB-aligned boundary checks and unaligned allocations.
- [High] Concurrent `raw_request` calls are not serialized, leading to data races and corruption on the shared `qsdev->report_buf`.
- [High] Incomplete fix in `quickspi_get_report` protects the user buffer but fails to prevent an out-of-bounds read from the kernel heap.
--

--- Patch [1]: [PATCH] HID: intel-thc-hid: reject oversized QuickSPI GET_REPORT responses ---
commit 95a4cfcd8aa1ba2ab8a0e552fbf091c155176036
Author: Jérémy Jean <Jeremy.Jean@oss.cyber.gouv.fr>

HID: intel-thc-hid: reject oversized QuickSPI GET_REPORT responses

Thread the HID core caller length into quickspi_get_report() and reject
responses that exceed the caller-provided buffer before the final copy.
Snapshot the completed response length once so the bound check, copy, and
returned byte count all use the same value.

Fixes: 9d8d51735a3a ("HID: intel-thc-hid: intel-quickspi: Add HIDSPI protocol implementation")
Assisted-by: Codex:gpt-5
Signed-off-by: Jérémy Jean <Jeremy.Jean@oss.cyber.gouv.fr>

> diff --git a/drivers/hid/intel-thc-hid/intel-quickspi/quickspi-hid.c b/drivers/hid/intel-thc-hid/intel-quickspi/quickspi-hid.c
> index 91d5807b4a830..a60a0a7f16aad 100644
> --- a/drivers/hid/intel-thc-hid/intel-quickspi/quickspi-hid.c
> +++ b/drivers/hid/intel-thc-hid/intel-quickspi/quickspi-hid.c
> @@ -61,7 +61,7 @@ static int quickspi_hid_raw_request(struct hid_device *hid,
>  
>  	switch (reqtype) {
>  	case HID_REQ_GET_REPORT:
> -		ret = quickspi_get_report(qsdev, rtype, reportnum, buf);
> +		ret = quickspi_get_report(qsdev, rtype, reportnum, buf, len);

[Severity: High]
This isn't a bug introduced by this patch, but are concurrent raw_request
calls serialized here?

It looks like multiple threads could invoke quickspi_hid_raw_request()
simultaneously from userspace. Without a driver-level mutex, could
concurrent threads write outgoing commands directly into the single shared
qsdev->report_buf in write_cmd_to_txdma()?

>  		break;
>  	case HID_REQ_SET_REPORT:
>  		ret = quickspi_set_report(qsdev, rtype, reportnum, buf, len);

[Severity: High]
This is a pre-existing issue, but does this pass an unvalidated user length
through to quickspi_set_report()?

If userspace issues a SET_REPORT request with a payload up to 4096 bytes, len
is passed to write_cmd_to_txdma() without being validated against the
allocation size of the internal buffer. Could this unconditionally execute:

memcpy(write_buf->content, report_buf, report_buf_len);

into qsdev->report_buf and overflow the kernel heap?

>  		break;
>  	default:

[ ... ]

> diff --git a/drivers/hid/intel-thc-hid/intel-quickspi/quickspi-protocol.c b/drivers/hid/intel-thc-hid/intel-quickspi/quickspi-protocol.c
> index cb19057f1191b..acc9d67c53ca0 100644
> --- a/drivers/hid/intel-thc-hid/intel-quickspi/quickspi-protocol.c
> +++ b/drivers/hid/intel-thc-hid/intel-quickspi/quickspi-protocol.c

[ ... ]

> @@ -371,10 +373,17 @@ int quickspi_get_report(struct quickspi_device *qsdev,
>  		return -ETIMEDOUT;
>  	}
>  	qsdev->get_report_cmpl = false;
> +	report_len = READ_ONCE(qsdev->report_len);
> +
> +	if (report_len > buf_len) {
> +		dev_err_once(qsdev->dev, "Get report response too large: %u vs %zu\n",
> +			     report_len, buf_len);
> +		return -EINVAL;
> +	}
>  
> -	memcpy(buf, qsdev->report_buf, qsdev->report_len);
> +	memcpy(buf, qsdev->report_buf, report_len);

[Severity: High]
This is a pre-existing issue, but does this check prevent out-of-bounds reads
from qsdev->report_buf?

While the new bounds check prevents overflowing the destination buf, it
doesn't seem to verify if report_len exceeds the allocation size of the source
buffer qsdev->report_buf.

Since report_len is derived from an incoming hardware packet, if userspace
requests a large buffer length, could this memcpy read past the end of
qsdev->report_buf and leak adjacent kernel heap memory to userspace?

[Severity: High]
This isn't a bug introduced by this patch, but how is the capacity of
qsdev->report_buf validated against hardware DMA limits during allocation and
reporting?

It appears qsdev->input_buf and qsdev->report_buf are allocated to a precise
descriptor size in quickspi_alloc_report_buf(). However, the DMA limits are
aligned to 4KB in read_dma_buffer():

if (mes_len > read_config->max_packet_size) { ... }
ret = sg_copy_to_buffer(sg, nent, read_buff, mes_len);

If a device sends a packet larger than the descriptor size but smaller than
the 4KB-aligned max packet size, could this unconditionally copy the payload
into qsdev->report_buf and overflow the heap?

> -	return qsdev->report_len;
> +	return report_len;
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260818140245.1903804-2-Jeremy.Jean@oss.cyber.gouv.fr?part=1

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2026-08-18 14:15 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-08-18 14:02 [PATCH] HID: intel-thc-hid: reject oversized QuickSPI GET_REPORT responses Jérémy Jean
2026-08-18 14:15 ` sashiko-bot

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.