Re: [PATCH v2] HID: core: demote warning to debug level

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Demoting the `bsize < rsize` warning to debug level masks legacy API misuse and silently drops valid short reports.
--

commit c89b6cb8fc074729ec292f2ffe95d958722d1447
Author: Matteo Croce <teknoraver@meta.com>

HID: core: demote warning to debug level

This commit demotes the "Event data for report was too short" message from
a warning to a debug log to prevent syslog flooding from devices that
regularly send short reports.

> diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
> index 41a79e43c82b3..503b9bfa5d379 100644
> --- a/drivers/hid/hid-core.c
> +++ b/drivers/hid/hid-core.c
> @@ -2072,8 +2072,8 @@ int hid_report_raw_event(struct hid_device *hid, enum hid_report_type type, u8 *
>  		rsize = max_buffer_size;
>  
>  	if (bsize < rsize) {
> -		hid_warn_ratelimited(hid, "Event data for report %d was too short (%d vs %zu)\n",
> -				     report->id, rsize, bsize);
> +		hid_dbg_ratelimited(hid, "Event data for report %d was too short (%d vs %zu)\n",
> +				    report->id, rsize, bsize);
>  		return -EINVAL;
>  	}

[Severity: High]
Does demoting this warning to debug level mask legacy API misuse and silently
drop valid short reports?

The bsize < rsize check correctly returns -EINVAL to reject events where the
allocated buffer is too small, preventing out-of-bounds memory accesses.

If the UPS device triggers this warning because a core API or legacy driver
incorrectly uses the old hid_input_report() function, the legacy API
implicitly sets the allocated buffer size (bsize) equal to the received
payload size (csize). When the device sends a valid short report
(csize < rsize), bsize also becomes less than rsize, causing the HID core
to incorrectly conclude the buffer is too small, drop the report, and print
the warning.

Silencing this warning fails to fix the root cause. The valid short reports
are still incorrectly dropped, but now they are dropped silently, potentially
leaving the device broken. Furthermore, demoting this warning hides genuine
buffer under-allocation vulnerabilities in other HID drivers.

Should the caller be updated to use hid_safe_input_report() with the actual
allocated buffer length, so the short reports can be successfully processed
via zero-padding instead of returning -EINVAL?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260523105545.68079-1-technoboy85@gmail.com?part=1