Re: [PATCH v3 0/4] HID: Proper fix for OOM in hid-core

[Lee Jones <lee@kernel.org>]

On Tue, 19 May 2026, Benjamin Tissoires wrote:

> On May 19 2026, Greg Kroah-Hartman wrote:
> > On Tue, May 19, 2026 at 02:46:13PM +0200, Benjamin Tissoires wrote:
> > > On May 19 2026, Lee Jones wrote:
> > > > On Tue, 12 May 2026, Lee Jones wrote:
> > > > 
> > > > > On Wed, 06 May 2026, Lee Jones wrote:
> > > > > 
> > > > > > On Mon, 04 May 2026, Benjamin Tissoires wrote:
> > > > > > 
> > > > > > > Commit 0a3fe972a7cb ("HID: core: Mitigate potential OOB by removing
> > > > > > > bogus memset()") enforced the provided data to be at least the size of
> > > > > > > the declared buffer in the report descriptor to prevent a buffer
> > > > > > > overflow.
> > > > > > > 
> > > > > > > We only had corner cases of malicious devices exposing the OOM because
> > > > > > > in most cases, the buffer provided by the transport layer needs to be
> > > > > > > allocated at probe time and is large enough to handle all the possible
> > > > > > > reports.
> > > > > > > 
> > > > > > > However, the patch from above, which enforces the spec a little bit more
> > > > > > > introduced both regressions for devices not following the spec (not
> > > > > > > necesserally malicious), but also a stream of errors for those devices.
> > > > > > > 
> > > > > > > Let's revert to the old behavior by giving more information to HID core
> > > > > > > to be able to decide whether it can or not memset the rest of the buffer
> > > > > > > to 0 and continue the processing.
> > > > > > > 
> > > > > > > Note that the first commit makes an API change, but the callers are
> > > > > > > relatively limited, so it should be fine on its own. The second patch
> > > > > > > can't really make the same kind of API change because we have too many
> > > > > > > callers in various subsystems. We can switch them one by one to the safe
> > > > > > > approach when needed.
> > > > > > > 
> > > > > > > The last 2 patches are small cleanups I initially put together with the
> > > > > > > 2 first patches, but they can be applied on their own and don't need to
> > > > > > > be pulled in stable like the first 2.
> > > > > > > 
> > > > > > > Cheers,
> > > > > > > Benjamin
> > > > > > > 
> > > > > > > Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
> > > > > > > ---
> > > > > > > Changes in v3:
> > > > > > > - fixed ghib -> ghid in greybus
> > > > > > > - fixed i386 size_t debug size reported by kernel-bot
> > > > > > > - Link to v2: https://lore.kernel.org/r/20260416-wip-fix-core-v2-0-be92570e5627@kernel.org
> > > > > > > 
> > > > > > > Changes in v2:
> > > > > > > - added a small blurb explaining the difference between the safe and the
> > > > > > >   non safe version of hid_safe_input_report
> > > > > > > - Link to v1: https://lore.kernel.org/r/20260415-wip-fix-core-v1-0-ed3c4c823175@kernel.org
> > > > > > > 
> > > > > > > ---
> > > > > > > Benjamin Tissoires (4):
> > > > > > >       HID: pass the buffer size to hid_report_raw_event
> > > > > > >       HID: core: introduce hid_safe_input_report()
> > > > > > >       HID: multitouch: use __free(kfree) to clean up temporary buffers
> > > > > > >       HID: wacom: use __free(kfree) to clean up temporary buffers
> > > > > > > 
> > > > > > >  drivers/hid/bpf/hid_bpf_dispatch.c |  6 ++--
> > > > > > >  drivers/hid/hid-core.c             | 67 ++++++++++++++++++++++++++++++--------
> > > > > > >  drivers/hid/hid-gfrm.c             |  4 +--
> > > > > > >  drivers/hid/hid-logitech-hidpp.c   |  2 +-
> > > > > > >  drivers/hid/hid-multitouch.c       | 18 ++++------
> > > > > > >  drivers/hid/hid-primax.c           |  2 +-
> > > > > > >  drivers/hid/hid-vivaldi-common.c   |  2 +-
> > > > > > >  drivers/hid/i2c-hid/i2c-hid-core.c |  7 ++--
> > > > > > >  drivers/hid/usbhid/hid-core.c      | 11 ++++---
> > > > > > >  drivers/hid/wacom_sys.c            | 46 +++++++++-----------------
> > > > > > >  drivers/staging/greybus/hid.c      |  2 +-
> > > > > > >  include/linux/hid.h                |  6 ++--
> > > > > > >  include/linux/hid_bpf.h            | 14 +++++---
> > > > > > >  13 files changed, 109 insertions(+), 78 deletions(-)
> > > > > > 
> > > > > > What's the plan for this set Benjamin? -rcs or -next?
> > > > > 
> > > > > Are there any updates on this set please?
> > > > > 
> > > > > FYI, this set is still important to us.
> > > > > 
> > > > > Ideally, if all is well, it would go into the -rcs for v7.1.
> > > > 
> > > > I'm still actively tracking these.
> > > > 
> > > > It looks like Mark has been reverting them from -next and I'm getting
> > > > complaints from the Stable folks that they are causing build errors.
> > > > 
> > > >   drivers/hid/hid-core.c: In function 'hid_safe_input_report':
> > > >   drivers/hid/hid-core.c:2195:16: error: too many arguments to function '__hid_input_report'
> > > >     2195 |         return __hid_input_report(hid, type, data, bufsize, size, interrupt, 0,
> > > > 
> > > > Are you folks still working on this set?
> > > 
> > > Well, everything is in Linus' tree:
> > > 
> > > not yet in a released rc (taken yesterday by Linus directly):
> > > 
> > > 4d3a2a466b8d HID: core: Fix size_t specifier in hid_report_raw_event()
> > > 
> > > Already in 7.1-rc4:
> > > 
> > > 206342541fc8 HID: core: introduce hid_safe_input_report()
> > > 2c85c61d1332 HID: pass the buffer size to hid_report_raw_event
> > > 
> > > Not sure why the patches don't apply to stable, but from an upstream
> > > subsystem point of view, everything is in order.
> > 
> > We dropped them from stable because of the build breakage :(
> > 
> 
> If that was just the i386 size_t issue, then it has been fixed in Linus'
> tree. Could you try retaking them? Please?

Thanks for following-up on this, I really appreciate it.

It looks as though these are no longer reverted from today's -next. \o/

-- 
Lee Jones