From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6077B33AD85; Wed, 15 Apr 2026 09:38:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776245929; cv=none; b=bbgJ9f+ZAFI3sIw7JBp1gVmr9X0wQXMg91TcZzqneqOkT2Ki4ghReNAH3EVQnQTbmJpCl5aK0vFxJMksx7SW8t+FDKnYDbtxA++d8W4mVJiC4FQEP7z/w9MYyc2fXWA6c42J7T27LuPM8Y/tK/NjQrny9QiWixwy/ATITbK0GGA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776245929; c=relaxed/simple; bh=r5vc1JuI0NmO1ufLcnSujmQ430UsiCtxiof7usGgCuM=; h=From:Subject:Date:Message-Id:MIME-Version:Content-Type:To:Cc; b=bsmkvzi5yujBZzpcRwbj+4668DKYT4ptDSrfUXp1rbf/Yc0EgauhSBkMe+DYINA8STqPM0Wpy0WHMkIrpFLi3+UH155BApijonYMBwLIuvRxe7sHzOAc3RPoqQ9TOitQsLOoNjvOxShx3MBm90X7RPjq5qepTK4UmiqvMhwNOCM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=jZPr+B3H; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="jZPr+B3H" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 141A6C2BCB4; Wed, 15 Apr 2026 09:38:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1776245929; bh=r5vc1JuI0NmO1ufLcnSujmQ430UsiCtxiof7usGgCuM=; h=From:Subject:Date:To:Cc:From; b=jZPr+B3HsYd+hr9A+OTyz2y2Qq9/mSlpx+Y3rQBn0bX9iXAA8Kq+YQZD4oO/5WsTJ wsX6U12u+KWLAcvDZJAk6+C7etgNNsqXR94dURIf0F9W4RWKaIVEif5UFnLDbgwGLY Igf8rjwptq085OkTDDSgirkT/3rllZNVHGustb3S7Uj/KogefD63zjO8LCK2jLrT6D 4OU5RfJfgD/+dBIA+slguwXxLa6aRVy1It2hK3C+rtcaf/A11vF4V2HT4bWKkE5+aJ E0ZKsX/W+oypfijaOc7IML4Lilt4QF+4sBVP/NIqFY2ZAOIYSpiTV3KtIxC8apoJX4 drVLksX5TXXvQ== From: Benjamin Tissoires Subject: [PATCH 0/4] HID: Proper fix for OOM in hid-core Date: Wed, 15 Apr 2026 11:38:13 +0200 Message-Id: <20260415-wip-fix-core-v1-0-ed3c4c823175@kernel.org> Precedence: bulk X-Mailing-List: linux-usb@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-B4-Tracking: v=1; b=H4sIAAAAAAAC/x2MQQqAIBAAvyJ7bkEjTfpKdAjdai8qChWIf086D sNMhUKZqcAiKmS6uXAMHdQgwF17OAnZd4ZRjkZOSuPDCQ9+0cVMOHurndXKkJfQk5Spu3+3bq1 9oIjJHl4AAAA= X-Change-ID: 20260415-wip-fix-core-7d85c8516ed0 To: Jiri Kosina , =?utf-8?q?Filipe_La=C3=ADns?= , Bastien Nocera , Ping Cheng , Jason Gerecke , Viresh Kumar , Johan Hovold , Alex Elder , Greg Kroah-Hartman , Lee Jones Cc: 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, Benjamin Tissoires , stable@vger.kernel.org X-Mailer: b4 0.14.3 X-Developer-Signature: v=1; a=ed25519-sha256; t=1776245925; l=2605; i=bentiss@kernel.org; s=20230215; h=from:subject:message-id; bh=r5vc1JuI0NmO1ufLcnSujmQ430UsiCtxiof7usGgCuM=; b=AEVtDlGIETuRO7ZbHuSO1IbBMWRBRslLQwsR1ORqtNTPP4CHo2ExMTjVQlAguVTyl4lsnFMPZ qkPY2we0cJuCMY3TPltDvi+xnK5tuWvm4kNGP8xLzYkuGmOTwmsx7yP X-Developer-Key: i=bentiss@kernel.org; a=ed25519; pk=7D1DyAVh6ajCkuUTudt/chMuXWIJHlv2qCsRkIizvFw= 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 --- 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 | 63 +++++++++++++++++++++++++++++--------- 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, 105 insertions(+), 78 deletions(-) --- base-commit: 7df6572f1cb381d6b89ceed58e3b076c233c2cd0 change-id: 20260415-wip-fix-core-7d85c8516ed0 Best regards, -- Benjamin Tissoires