From: Lee Jones <lee@kernel.org>
To: Benjamin Tissoires <bentiss@kernel.org>
Cc: "Jiri Kosina" <jikos@kernel.org>,
"Filipe Laíns" <lains@riseup.net>,
"Bastien Nocera" <hadess@hadess.net>,
"Ping Cheng" <ping.cheng@wacom.com>,
"Jason Gerecke" <jason.gerecke@wacom.com>,
"Viresh Kumar" <vireshk@kernel.org>,
"Johan Hovold" <johan@kernel.org>,
"Alex Elder" <elder@kernel.org>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Icenowy Zheng" <uwu@icenowy.me>,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
greybus-dev@lists.linaro.org, linux-staging@lists.linux.dev,
linux-usb@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH v3 0/4] HID: Proper fix for OOM in hid-core
Date: Tue, 12 May 2026 11:17:23 +0100 [thread overview]
Message-ID: <20260512101723.GU305027@google.com> (raw)
In-Reply-To: <20260506091606.GB305027@google.com>
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.
--
Lee Jones
next prev parent reply other threads:[~2026-05-12 10:17 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-04 8:47 [PATCH v3 0/4] HID: Proper fix for OOM in hid-core Benjamin Tissoires
2026-05-04 8:47 ` [PATCH v3 1/4] HID: pass the buffer size to hid_report_raw_event Benjamin Tissoires
2026-05-04 9:31 ` Johan Hovold
2026-05-04 12:21 ` Greg Kroah-Hartman
2026-05-04 8:47 ` [PATCH v3 2/4] HID: core: introduce hid_safe_input_report() Benjamin Tissoires
2026-05-04 8:47 ` [PATCH v3 3/4] HID: multitouch: use __free(kfree) to clean up temporary buffers Benjamin Tissoires
2026-05-04 8:47 ` [PATCH v3 4/4] HID: wacom: " Benjamin Tissoires
2026-05-04 23:15 ` Dmitry Torokhov
2026-05-06 9:16 ` [PATCH v3 0/4] HID: Proper fix for OOM in hid-core Lee Jones
2026-05-12 10:17 ` Lee Jones [this message]
2026-05-12 16:04 ` Jiri Kosina
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260512101723.GU305027@google.com \
--to=lee@kernel.org \
--cc=bentiss@kernel.org \
--cc=elder@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=greybus-dev@lists.linaro.org \
--cc=hadess@hadess.net \
--cc=jason.gerecke@wacom.com \
--cc=jikos@kernel.org \
--cc=johan@kernel.org \
--cc=lains@riseup.net \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-staging@lists.linux.dev \
--cc=linux-usb@vger.kernel.org \
--cc=ping.cheng@wacom.com \
--cc=stable@vger.kernel.org \
--cc=uwu@icenowy.me \
--cc=vireshk@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox