[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

[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

[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, 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

[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