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

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

[Matteo Croce]

From: Matteo Croce <teknoraver@meta.com>

The log level for short  messages was changed from debug to warning,
flooding syslog on systems with devices that regularly send
short reports, in my case an UPS:

    $ dmesg |grep -c 'Event data for report .* was too short'
    35

Demote it back to debug level.

Fixes: 0a3fe972a7cb ("HID: core: Mitigate potential OOB by removing bogus memset()")
Signed-off-by: Matteo Croce <teknoraver@meta.com>
---
 drivers/hid/hid-core.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 41a79e43c82b..503b9bfa5d37 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;
 	}
 
-- 
2.50.1

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

[sashiko-bot]

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

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

[Matteo Croce]

Il giorno sab 23 mag 2026 alle ore 13:04 <sashiko-bot@kernel.org> ha scritto:
>
> 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

Commit 0a3fe972a7cb changed the level from debug to warning.
This is too noisy, I'm just reverting to the original behaviour.

-- 
Matteo Croce

perl -e 'for($t=0;;$t++){print chr($t*($t>>8|$t>>13)&255)}' |aplay

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

[Jiri Kosina]

On Sat, 23 May 2026, Matteo Croce wrote:

> From: Matteo Croce <teknoraver@meta.com>
> 
> The log level for short  messages was changed from debug to warning,
> flooding syslog on systems with devices that regularly send
> short reports, in my case an UPS:
> 
>     $ dmesg |grep -c 'Event data for report .* was too short'
>     35
> 
> Demote it back to debug level.
> 
> Fixes: 0a3fe972a7cb ("HID: core: Mitigate potential OOB by removing bogus memset()")
> Signed-off-by: Matteo Croce <teknoraver@meta.com>

Applied, thanks.

-- 
Jiri Kosina
SUSE Labs

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

[Lee Jones]

On Wed, 10 Jun 2026, Jiri Kosina wrote:

> On Sat, 23 May 2026, Matteo Croce wrote:
> 
> > From: Matteo Croce <teknoraver@meta.com>
> > 
> > The log level for short  messages was changed from debug to warning,
> > flooding syslog on systems with devices that regularly send
> > short reports, in my case an UPS:
> > 
> >     $ dmesg |grep -c 'Event data for report .* was too short'
> >     35
> > 
> > Demote it back to debug level.
> > 
> > Fixes: 0a3fe972a7cb ("HID: core: Mitigate potential OOB by removing bogus memset()")
> > Signed-off-by: Matteo Croce <teknoraver@meta.com>
> 
> Applied, thanks.

FWIW, I'd like to contest this patch.

The warning is real.  It means that the HID report was rejected and as
such something on the system will be now be non-functional.  Silencing
the warning is not helpful.  It does not fix the issue, and now the user
/ admin has no idea that its even happening.

This warning has caught a bunch of genuine issues related to testing
infrastructure and incorrectly coded firmware that have subsequently
been rectified.

Please don't hide this issue.  Fix the root cause instead.

-- 
Lee Jones

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

[Benjamin Tissoires]

On Aug 24 2026, Lee Jones wrote:
> On Wed, 10 Jun 2026, Jiri Kosina wrote:
> 
> > On Sat, 23 May 2026, Matteo Croce wrote:
> > 
> > > From: Matteo Croce <teknoraver@meta.com>
> > > 
> > > The log level for short  messages was changed from debug to warning,
> > > flooding syslog on systems with devices that regularly send
> > > short reports, in my case an UPS:
> > > 
> > >     $ dmesg |grep -c 'Event data for report .* was too short'
> > >     35
> > > 
> > > Demote it back to debug level.
> > > 
> > > Fixes: 0a3fe972a7cb ("HID: core: Mitigate potential OOB by removing bogus memset()")
> > > Signed-off-by: Matteo Croce <teknoraver@meta.com>
> > 
> > Applied, thanks.
> 
> FWIW, I'd like to contest this patch.
> 
> The warning is real.  It means that the HID report was rejected and as
> such something on the system will be now be non-functional.  Silencing
> the warning is not helpful.  It does not fix the issue, and now the user
> / admin has no idea that its even happening.
> 
> This warning has caught a bunch of genuine issues related to testing
> infrastructure and incorrectly coded firmware that have subsequently
> been rectified.
> 
> Please don't hide this issue.  Fix the root cause instead.

Please have a look at the actual code in the tree first. That patch was
applied by Jiri, yes, but IIRC it was dropped in a merge commit and is
not included in any trees AFAICT.

Cheers,
Benjamin

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

[Lee Jones]

On Mon, 24 Aug 2026, Benjamin Tissoires wrote:

> On Aug 24 2026, Lee Jones wrote:
> > On Wed, 10 Jun 2026, Jiri Kosina wrote:
> > 
> > > On Sat, 23 May 2026, Matteo Croce wrote:
> > > 
> > > > From: Matteo Croce <teknoraver@meta.com>
> > > > 
> > > > The log level for short  messages was changed from debug to warning,
> > > > flooding syslog on systems with devices that regularly send
> > > > short reports, in my case an UPS:
> > > > 
> > > >     $ dmesg |grep -c 'Event data for report .* was too short'
> > > >     35
> > > > 
> > > > Demote it back to debug level.
> > > > 
> > > > Fixes: 0a3fe972a7cb ("HID: core: Mitigate potential OOB by removing bogus memset()")
> > > > Signed-off-by: Matteo Croce <teknoraver@meta.com>
> > > 
> > > Applied, thanks.
> > 
> > FWIW, I'd like to contest this patch.
> > 
> > The warning is real.  It means that the HID report was rejected and as
> > such something on the system will be now be non-functional.  Silencing
> > the warning is not helpful.  It does not fix the issue, and now the user
> > / admin has no idea that its even happening.
> > 
> > This warning has caught a bunch of genuine issues related to testing
> > infrastructure and incorrectly coded firmware that have subsequently
> > been rectified.
> > 
> > Please don't hide this issue.  Fix the root cause instead.
> 
> Please have a look at the actual code in the tree first. That patch was
> applied by Jiri, yes, but IIRC it was dropped in a merge commit and is
> not included in any trees AFAICT.

Sure, but there was an attempt to have it reapplied [0].

My plea goes out to both submissions.

[0] https://lore.kernel.org/all/aoF-jIn9gk9kJ7Pz@decadent.org.uk/

-- 
Lee Jones

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

[Benjamin Tissoires]

On Aug 24 2026, Lee Jones wrote:
> On Mon, 24 Aug 2026, Benjamin Tissoires wrote:
> 
> > On Aug 24 2026, Lee Jones wrote:
> > > On Wed, 10 Jun 2026, Jiri Kosina wrote:
> > > 
> > > > On Sat, 23 May 2026, Matteo Croce wrote:
> > > > 
> > > > > From: Matteo Croce <teknoraver@meta.com>
> > > > > 
> > > > > The log level for short  messages was changed from debug to warning,
> > > > > flooding syslog on systems with devices that regularly send
> > > > > short reports, in my case an UPS:
> > > > > 
> > > > >     $ dmesg |grep -c 'Event data for report .* was too short'
> > > > >     35
> > > > > 
> > > > > Demote it back to debug level.
> > > > > 
> > > > > Fixes: 0a3fe972a7cb ("HID: core: Mitigate potential OOB by removing bogus memset()")
> > > > > Signed-off-by: Matteo Croce <teknoraver@meta.com>
> > > > 
> > > > Applied, thanks.
> > > 
> > > FWIW, I'd like to contest this patch.
> > > 
> > > The warning is real.  It means that the HID report was rejected and as
> > > such something on the system will be now be non-functional.  Silencing
> > > the warning is not helpful.  It does not fix the issue, and now the user
> > > / admin has no idea that its even happening.
> > > 
> > > This warning has caught a bunch of genuine issues related to testing
> > > infrastructure and incorrectly coded firmware that have subsequently
> > > been rectified.
> > > 
> > > Please don't hide this issue.  Fix the root cause instead.
> > 
> > Please have a look at the actual code in the tree first. That patch was
> > applied by Jiri, yes, but IIRC it was dropped in a merge commit and is
> > not included in any trees AFAICT.
> 
> Sure, but there was an attempt to have it reapplied [0].
> 
> My plea goes out to both submissions.
> 
> [0] https://lore.kernel.org/all/aoF-jIn9gk9kJ7Pz@decadent.org.uk/

It would have been so much easier to reply to the bump instead of the
old original submission. The bump had all the references on the commit
shas where they were included and overwritten, which would have saved me
time.

FWIW, that bump doesn't show up in my public-inbox query, which is why I
did not saw it.

Cheers,
Benjamin

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

[Lee Jones]

On Mon, 24 Aug 2026, Benjamin Tissoires wrote:

> On Aug 24 2026, Lee Jones wrote:
> > On Mon, 24 Aug 2026, Benjamin Tissoires wrote:
> > 
> > > On Aug 24 2026, Lee Jones wrote:
> > > > On Wed, 10 Jun 2026, Jiri Kosina wrote:
> > > > 
> > > > > On Sat, 23 May 2026, Matteo Croce wrote:
> > > > > 
> > > > > > From: Matteo Croce <teknoraver@meta.com>
> > > > > > 
> > > > > > The log level for short  messages was changed from debug to warning,
> > > > > > flooding syslog on systems with devices that regularly send
> > > > > > short reports, in my case an UPS:
> > > > > > 
> > > > > >     $ dmesg |grep -c 'Event data for report .* was too short'
> > > > > >     35
> > > > > > 
> > > > > > Demote it back to debug level.
> > > > > > 
> > > > > > Fixes: 0a3fe972a7cb ("HID: core: Mitigate potential OOB by removing bogus memset()")
> > > > > > Signed-off-by: Matteo Croce <teknoraver@meta.com>
> > > > > 
> > > > > Applied, thanks.
> > > > 
> > > > FWIW, I'd like to contest this patch.
> > > > 
> > > > The warning is real.  It means that the HID report was rejected and as
> > > > such something on the system will be now be non-functional.  Silencing
> > > > the warning is not helpful.  It does not fix the issue, and now the user
> > > > / admin has no idea that its even happening.
> > > > 
> > > > This warning has caught a bunch of genuine issues related to testing
> > > > infrastructure and incorrectly coded firmware that have subsequently
> > > > been rectified.
> > > > 
> > > > Please don't hide this issue.  Fix the root cause instead.
> > > 
> > > Please have a look at the actual code in the tree first. That patch was
> > > applied by Jiri, yes, but IIRC it was dropped in a merge commit and is
> > > not included in any trees AFAICT.
> > 
> > Sure, but there was an attempt to have it reapplied [0].
> > 
> > My plea goes out to both submissions.
> > 
> > [0] https://lore.kernel.org/all/aoF-jIn9gk9kJ7Pz@decadent.org.uk/
> 
> It would have been so much easier to reply to the bump instead of the
> old original submission. The bump had all the references on the commit
> shas where they were included and overwritten, which would have saved me
> time.

It was 50/50 and I chose the original patch.

The important thing is that the point was made.

Sorry if it took you the extra cycles to work it all out.

> FWIW, that bump doesn't show up in my public-inbox query, which is why I
> did not saw it.

-- 
Lee Jones

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

[Matteo Croce]

Il giorno lun 24 ago 2026 alle ore 12:25 Lee Jones <lee@kernel.org> ha scritto:
>
> On Wed, 10 Jun 2026, Jiri Kosina wrote:
>
> > On Sat, 23 May 2026, Matteo Croce wrote:
> >
> > > From: Matteo Croce <teknoraver@meta.com>
> > >
> > > The log level for short  messages was changed from debug to warning,
> > > flooding syslog on systems with devices that regularly send
> > > short reports, in my case an UPS:
> > >
> > >     $ dmesg |grep -c 'Event data for report .* was too short'
> > >     35
> > >
> > > Demote it back to debug level.
> > >
> > > Fixes: 0a3fe972a7cb ("HID: core: Mitigate potential OOB by removing bogus memset()")
> > > Signed-off-by: Matteo Croce <teknoraver@meta.com>
> >
> > Applied, thanks.
>
> FWIW, I'd like to contest this patch.
>
> The warning is real.  It means that the HID report was rejected and as
> such something on the system will be now be non-functional.  Silencing
> the warning is not helpful.  It does not fix the issue, and now the user
> / admin has no idea that its even happening.
>
> This warning has caught a bunch of genuine issues related to testing
> infrastructure and incorrectly coded firmware that have subsequently
> been rectified.
>
> Please don't hide this issue.  Fix the root cause instead.
>
> --
> Lee Jones

Hi,

the message was debug long before and was promoted to warning during a refactor.
With my patch I just restored the previous priority.

Regards,
-- 
per aspera ad upstream

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

[Lee Jones]

On Mon, 24 Aug 2026, Matteo Croce wrote:

> Il giorno lun 24 ago 2026 alle ore 12:25 Lee Jones <lee@kernel.org> ha scritto:
> >
> > On Wed, 10 Jun 2026, Jiri Kosina wrote:
> >
> > > On Sat, 23 May 2026, Matteo Croce wrote:
> > >
> > > > From: Matteo Croce <teknoraver@meta.com>
> > > >
> > > > The log level for short  messages was changed from debug to warning,
> > > > flooding syslog on systems with devices that regularly send
> > > > short reports, in my case an UPS:
> > > >
> > > >     $ dmesg |grep -c 'Event data for report .* was too short'
> > > >     35
> > > >
> > > > Demote it back to debug level.
> > > >
> > > > Fixes: 0a3fe972a7cb ("HID: core: Mitigate potential OOB by removing bogus memset()")
> > > > Signed-off-by: Matteo Croce <teknoraver@meta.com>
> > >
> > > Applied, thanks.
> >
> > FWIW, I'd like to contest this patch.
> >
> > The warning is real.  It means that the HID report was rejected and as
> > such something on the system will be now be non-functional.  Silencing
> > the warning is not helpful.  It does not fix the issue, and now the user
> > / admin has no idea that its even happening.
> >
> > This warning has caught a bunch of genuine issues related to testing
> > infrastructure and incorrectly coded firmware that have subsequently
> > been rectified.
> >
> > Please don't hide this issue.  Fix the root cause instead.
> >
> > --
> > Lee Jones
> 
> Hi,
> 
> the message was debug long before and was promoted to warning during a refactor.
> With my patch I just restored the previous priority.

Sure.  I'm not contesting the logic.

My point still stands, however.  IMHO this deserves warning status.

-- 
Lee Jones

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

[Benjamin Tissoires]

On Aug 24 2026, Matteo Croce wrote:
> Il giorno lun 24 ago 2026 alle ore 12:25 Lee Jones <lee@kernel.org> ha scritto:
> >
> > On Wed, 10 Jun 2026, Jiri Kosina wrote:
> >
> > > On Sat, 23 May 2026, Matteo Croce wrote:
> > >
> > > > From: Matteo Croce <teknoraver@meta.com>
> > > >
> > > > The log level for short  messages was changed from debug to warning,
> > > > flooding syslog on systems with devices that regularly send
> > > > short reports, in my case an UPS:
> > > >
> > > >     $ dmesg |grep -c 'Event data for report .* was too short'
> > > >     35
> > > >
> > > > Demote it back to debug level.
> > > >
> > > > Fixes: 0a3fe972a7cb ("HID: core: Mitigate potential OOB by removing bogus memset()")
> > > > Signed-off-by: Matteo Croce <teknoraver@meta.com>
> > >
> > > Applied, thanks.
> >
> > FWIW, I'd like to contest this patch.
> >
> > The warning is real.  It means that the HID report was rejected and as
> > such something on the system will be now be non-functional.  Silencing
> > the warning is not helpful.  It does not fix the issue, and now the user
> > / admin has no idea that its even happening.
> >
> > This warning has caught a bunch of genuine issues related to testing
> > infrastructure and incorrectly coded firmware that have subsequently
> > been rectified.
> >
> > Please don't hide this issue.  Fix the root cause instead.
> >
> > --
> > Lee Jones
> 
> Hi,
> 
> the message was debug long before and was promoted to warning during a refactor.
> With my patch I just restored the previous priority.
> 

Sorry, but no. The new kernel code restored the old behavior: if the
incoming buffer is long enough but the incoming report has a shorter
size, we still have the dbg_hid() call, so it's transparent for users.

The hid_warns are now only emitted when there is an obvious error with
the report *that the kernel can not fix*.

So having this patch would do exactly what Lee said: this would prevent
users to understand why their device doesn't work.

This patch "fixed" a temporary wrong attempt at solving an OOB, the old
behavior is restored, we should not even have this type of arguments.

Cheers,
Benjamin