This is a problem encountered with the latest security update of the
kernel for bullseye, aka oldoldstable.  I'm not sure exactly where or
how to report it.

Immediately after upgrading the kernel with the latest security fixes,
[UPGRADE] linux-image-amd64:amd64 5.10.257-1 -> 5.10.259-1
in aptitude.log, the logs started filling with more than one complaint
a second like

Jul  3 13:17:31 barley kernel: [  102.564459] hid-generic 0003:051D:0002.0002: Event data for report 22 was too short (4 vs 2)
Jul  3 13:17:31 barley kernel: [  102.567155] hid-generic 0003:051D:0002.0002: Event data for report 22 was too short (4 vs 2)
Jul  3 13:17:37 barley kernel: [  107.883143] hid_report_raw_event: 27 callbacks suppressed
Jul  3 13:17:37 barley kernel: [  107.883171] hid-generic 0003:051D:0002.0002: Event data for report 22 was too short (4 v 2)

According to Google AI, 0003:051D is an APC UPS connected via USB; I
do have one connected that way.  I don't know that the
hid_report_raw_event messages are for the same device, though that
seems likely.

I did not get these errors with any previous version of the kernel.

Significance
============

If there actually is a problem communicating with the UPS this would
affect system reliability.  The KDE battery tool show the UPS is not
present (that is, the device is listed and the status is not present),
so there may be an actual issue.

The huge number of messages makes it hard to see anything else in the
logs.  They may degrade performance or add extra disk fragmentation.

logcheck email reports are now huge; like the regular logs, it is hard
to pick out anything from the noise.


Workarounds
===========
I added the following patterns to /etc/logcheck/ignore.d.server/local:

^\w{3} [ :0-9]{11} barley kernel: \[[[:blank:]]*[0-9.]+[[:blank:]]*\] hid-generic 0003:051D:0002.0002: Event data for report 22 was too short \(4 vs 2\)[[:blank:]]*$
^\w{3} [ :0-9]{11} barley kernel: \[[[:blank:]]*[0-9.]+[[:blank:]]*\] hid_report_raw_event: [0-9]+ callbacks? suppressed[[:blank:]]*$

This fixes the size and interpretability of the logcheck emails,
without addressing the fact that the underlying logs are still filling
and I may not have communication with the UPS.

Another alternative would be to boot the previous kernel; this seems a
bit risky given that it has known vulnerabilities.  It might be
worthwhile at least to verify that this is not a hardware failure that
just happened to coincide with the restart of the new kernel.

Finally, I should upgrade the whole system, but that's too big a
project for now.

- -- System Information:
Debian Release: 11.11
  APT prefers oldoldstable-security
  APT policy: (500, 'oldoldstable-security'), (500, 'oldoldstable-proposed-updates-debug'), (500, 'oldoldstable-debug'), (500, 'oldoldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-45-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages linux-image-amd64 depends on:
ii  linux-image-5.10.0-45-amd64  5.10.259-1

linux-image-amd64 recommends no packages.

linux-image-amd64 suggests no packages.

- -- no debconf information
-----BEGIN PGP SIGNATURE-----

iQFSBAEBCgA8FiEEreS674/HIyV9gBfdnAYPmOsbK2AFAmpIof8eHHJvc3Nib3ls
YW5Ac3RhbmZvcmRhbHVtbmkub3JnAAoJEJwGD5jrGytgoEYH/A5uCUtP0PfSS4hR
xqGuZjs2Z4By9HZd5t4cNoTpWJCOBOPPFEM7iLTi+uqEifG/vEOpXRrR/Bd3RBnY
gTU64WvRwKN1MIlKeDu3mLb835z010fmyHEk+z6Q2AayBFqIDg67bmEDGebz9Gh5
eE2hA0x5YIkH858yQVJfw31AEKZ371vvB92Kk6Rn2n+zz1/Ppc52x9gHL0U9tzm6
8ZFltjgNm9q9ceKH9Zr7QGlhfJslBZJ9u+TKLQps0yX/dEo4pYTIolIY30AXStPL
neHzNUonRu0HWmSQEEEfb7wKsWlekr9w/zP/wU1ZIcEW5BGZRiJMhqpLFfTWsRSw
/FFW5yA=
=JFo+
-----END PGP SIGNATURE-----

Additional diagnostic information:

1. Disconnecting the USB cable from the UPS to the computer stopped
the error messages (both kinds).
2. With the cable disconnected the KDE battery applet no longer showed
anything.  Which suggests some information, specifically the UPS model
was getting through.
3. Reverting to the previous kernel, 5.10.0-44-amd64 (from `uname -a`)
and reconnecting the cable also results in no errors.

Conclusion:
1. The problem is specific to the 5.10.0-45 kernel.
2. It is caused by the connection to the UPS.

I have not tested if plugging the cable into a different port on the
computer makes a difference.  Some of the USB ports on the front of
the computer do seem to have failed.  The UPS and most everything else
is connected to the back.

1. I also see this with linux-image-5.10.0-46-amd64, which I think is
v 5.10.262-1 under the covers.
2. Switching ports (to a USB 3.0 port) did not quiet the warnings.  So
if there is a hardware problem it is not specific to one particular
port, or even one port type.

Ross

This was fixed in the linux-input tree by:

commit d0ff08d946c83b51359a8063c41e9f5af067e628
Author: Matteo Croce <teknoraver@meta.com>
Date:   Sat May 23 12:55:45 2026 +0200

    HID: core: demote warning to debug level

but unfortunately that was lost in merge commit:

commit aa776949fb77462ee712eee28bc54a9ce95c5b40
Merge: 6df6b1f2c496 12b7731995ca
Author: Jiri Kosina <jikos@kernel.org>
Date:   Tue Jun 16 21:47:16 2026 +0200

    Merge branch 'for-7.2/wiimote' into for-linus

(WTF?)

TIL I can use "git log --remerge-diff" to show all merge conflicts that
were resolved, whereas I previously used "git log --cc" which hides this
kind of mismerge.  But it is much slower.

Ben.

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>
[bwh: Re-sending this fix which was applied and then lost in a mis-
 merge.  Add a second Fixes trailer so this should reach all stable
 branches that have the warning.]
Fixes: 2c85c61d1332 ("HID: pass the buffer size to hid_report_raw_event")
Cc: stable@vger.kernel.org
Signed-off-by: Ben Hutchings <benh@debian.org>
---
This was originally posted at
<https://lore.kernel.org/linux-input/20260523105545.68079-1-technoboy85@gmail.com/>
and applied to the hid tree as commit d0ff08d946c8, but then it was
lost in merge commit aa776949fb77 "Merge branch 'for-7.2/wiimote' into
for-linus".

Ben.

 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 cf123347a2af..605530ec2e9c 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -2079,8 +2079,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;
 	}

Sorry, but, NACK.

See the discussion with Lee ATM on the LKML[0]

That intermediate "fix" was wrong and got merged while I was working
on a proper solution, which is now upstream.

Cheers,
Benjamin

[0] https://lore.kernel.org/linux-input/aoxcpDR8jnuUA1nF@beelink/T/#t