Re: [RFC v3 2/2] HID: core: Check to ensure report responses match the request

[Benjamin Tissoires]

On Mar 09 2026, Lee Jones wrote:
> It is possible for a malicious (or clumsy) device to respond to a
> specific report's feature request using a completely different report
> ID.  This can cause confusion in the HID core resulting in nasty
> side-effects such as OOB writes.
> 
> Add a check to ensure that the report ID in the response, matches the
> one that was requested.
> 
> Signed-off-by: Lee Jones <lee@xxxxxxxxxx>
> ---
> v2 -> v3: Cover more bases by moving the check up a layer from MT to HID Core
> 
> RFC query: Is this always okay?
>            Should the report number always match the request?
> 	   Are there legitimate times where the two would differ?

Technically, there is no reasons for a HID_SET_REPORT request to change
the incoming buffer. So that test might break it.

I prefered fixing the calling sites (hid-multitouch and others), because
here we are making decisions on the device behaviour which is not ours
to make. More specifically, such a test will prevent us to fix a bogus
device by plainly rejecting the call after the facts.

Cheers,
Benjamin

> 
>  drivers/hid/hid-core.c | 13 +++++++++++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
> index da9231ca42bc..da4078554331 100644
> --- a/drivers/hid/hid-core.c
> +++ b/drivers/hid/hid-core.c
> @@ -2490,8 +2490,17 @@ int __hid_hw_raw_request(struct hid_device *hdev,
>  	if (ret)
>  		return ret;
>  
> -	return hdev->ll_driver->raw_request(hdev, reportnum, buf, len,
> -					    rtype, reqtype);
> +	ret = hdev->ll_driver->raw_request(hdev, reportnum, buf, len,
> +					   rtype, reqtype);
> +	if (ret)
> +		return ret;
> +
> +	if (reportnum != buf[0]) {
> +		hid_err(hdev, "Returned feature report did not match the request\n");
> +		return -EINVAL;
> +	}
> +
> +	return 0;
>  }
>  
>  /**
> -- 
> 2.53.0.473.g4a7958ca14-goog
> 
>