RE: [PATCH v2] HID: intel-thc-hid: intel-quickspi: validate GET REPORT response size

[Xu, Even]

> -----Original Message-----
> From: HyeongJun An <sammiee5311@xxxxxxxxx>
> Sent: Tuesday, October 27, 2026 5:41 PM
> To: Xu, Even <even.xu@xxxxxxxxx>
> Cc: jikos@xxxxxxxxxx; bentiss@xxxxxxxxxx; srinivas.pandruvada@xxxxxxxxxxxxxxx;
> Zhang, Rui1 <rui1.zhang@xxxxxxxxx>; linux-input@xxxxxxxxxxxxxxx; linux-
> kernel@xxxxxxxxxxxxxxx; stable@xxxxxxxxxxxxxxx
> Subject: Re: [PATCH v2] HID: intel-thc-hid: intel-quickspi: validate GET REPORT
> response size
> 
> Hello Even,
> 
> Thank you for picking this up, and thanks to Rui for testing it.
> 
> On Tue, Oct 27, 2026 at 10:58:20AM +0800, Even Xu wrote:
> > -		qsdev->report_len = sizeof(body_hdr->content_id) + input_len;
> > +		report_len = sizeof(body_hdr->content_id) + input_len;
> > +		if (report_len > qsdev->report_buf_size) {
> 
> One question about this bound. The DATA case accepts a content_len up to
> max_input_len, and the GET response adds the content ID on top of that. A
> GET_FEATURE or GET_INPUT_REPORT response of the same size then gives
> report_len = max_input_len + 1, which this version rejects when max_input_len is
> the larger of the two lengths. v1 compared against the allocation, which has the
> output report header to spare.

It's a valid question.
Based on my experience with enabling, touch vendors typically leave some headroom when setting the max input size and max output size, and in most cases, the packet size doesn't reach either limit.

> 
> Can a response that large happen? If it can, comparing input_len would keep the
> same limit as the DATA case:
> 
> 	if (input_len > qsdev->report_buf_size) {

Given that we've left enough headroom, this is a good suggestion. Let's go ahead with it.

Best Regards,
Even Xu

> 
> Best regards,
> HyeongJun