* Re: [PATCH v2] HID: ft260: validate report size and payload length in raw_event
From: Michael Zaidman @ 2026-04-09 18:24 UTC (permalink / raw)
To: Jiri Kosina
Cc: Sebastian Josue Alba Vives, Benjamin Tissoires, linux-i2c,
linux-input, linux-kernel, stable
In-Reply-To: <2o8np813-n9n6-32sn-922p-6qnrq45s7rs7@xreary.bet>
On Thu, Apr 9, 2026 at 6:50 PM Jiri Kosina <jikos@kernel.org> wrote:
>
> On Tue, 24 Mar 2026, Sebastian Josue Alba Vives wrote:
>
> > ft260_raw_event() casts the raw data buffer to a
> > ft260_i2c_input_report struct and accesses its fields without
> > validating the size parameter. Since __hid_input_report() invokes
> > the driver's raw_event callback before hid_report_raw_event()
> > performs its own report-size validation, a device sending a
> > truncated HID report can cause out-of-bounds heap reads.
> >
> > Additionally, even with a full-sized report, a corrupted
> > xfer->length field can cause memcpy to read beyond the report
> > buffer. The existing check only validates against the destination
> > buffer size, not the source data available in the report.
> >
> > Add two checks: reject reports shorter than FT260_REPORT_MAX_LENGTH,
> > and verify that xfer->length does not exceed the actual data
> > available in the report. Log warnings to aid debugging.
> >
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Sebastian Josue Alba Vives <sebasjosue84@gmail.com>
> > ---
> > drivers/hid/hid-ft260.c | 11 +++++++++++
> > 1 file changed, 11 insertions(+)
> >
> > diff --git a/drivers/hid/hid-ft260.c b/drivers/hid/hid-ft260.c
> > index 333341e80..68008a423 100644
> > --- a/drivers/hid/hid-ft260.c
> > +++ b/drivers/hid/hid-ft260.c
> > @@ -1068,6 +1068,17 @@ static int ft260_raw_event(struct hid_device *hdev, struct hid_report *report,
> > struct ft260_device *dev = hid_get_drvdata(hdev);
> > struct ft260_i2c_input_report *xfer = (void *)data;
> >
> > + if (size < FT260_REPORT_MAX_LENGTH) {
> > + hid_warn(hdev, "short report: %d\n", size);
> > + return 0;
>
> Michael, can you please confirm whether the device can never legitimately
> send shorter than FT260_REPORT_MAX_LENGTH reports?
>
> Thanks,
>
> --
> Jiri Kosina
> SUSE Labs
>
Hi Jiri,
The FT260 uses different report IDs (0xD0 through 0xDE) for different payload
lengths, with each report ID defining a different report size in the HID
descriptor. So yes, the device can legitimately send reports shorter than
FT260_REPORT_MAX_LENGTH, and a blanket size < 64 check would break valid
short transfers.
Looking at __hid_input_report(), the HID core could validate size against
hid_compute_report_size(report) before the raw_event call - essentially
moving the check that hid_report_raw_event() already does to happen earlier.
That would handle truncated reports generically for all HID drivers. However,
such a change would affect all HID drivers and require broad testing, so that
is your call.
What the HID core cannot validate is driver-specific payload semantics. In
ft260, the I2C input report has a length field at byte 1 that indicates the
payload size, and the driver uses it as the memcpy length without checking
it against the actual report size or against the expected data capacity for
the specific report ID.
I will submit a per-driver fix with two checks, both essential:
First, a minimum size check before accessing any header fields. Currently,
the HID core does not validate report size before calling raw_event, so a
1-byte report would cause an OOB read just from accessing the length field
at byte 1. This check is necessary regardless of the second check.
Second, a validation of xfer->length against the expected data capacity for
the given report ID. Each I2C input report ID defines a specific data capacity
(report 0xD0 holds up to 4 bytes, 0xDE up to 60 bytes). A corrupted length
field exceeding this capacity would cause an OOB read from the source buffer
during memcpy, even if the report itself is full-sized. Only the driver knows
these per-report-ID limits.
I have the hardware to test this change. I will credit Sebastian with
Reported-by for identifying the issue.
Thanks,
Michael
^ permalink raw reply
* Re: [PATCH 00/61] treewide: Use IS_ERR_OR_NULL over manual NULL check - refactor
From: Al Viro @ 2026-04-09 18:16 UTC (permalink / raw)
To: Philipp Hahn
Cc: amd-gfx, apparmor, bpf, ceph-devel, cocci, dm-devel, dri-devel,
gfs2, intel-gfx, intel-wired-lan, iommu, kvm, linux-arm-kernel,
linux-block, linux-bluetooth, linux-btrfs, linux-cifs, linux-clk,
linux-erofs, linux-ext4, linux-fsdevel, linux-gpio, linux-hyperv,
linux-input, linux-kernel, linux-leds, linux-media, linux-mips,
linux-mm, linux-modules, linux-mtd, linux-nfs, linux-omap,
linux-phy, linux-pm, linux-rockchip, linux-s390, linux-scsi,
linux-sctp, linux-security-module, linux-sh, linux-sound,
linux-stm32, linux-trace-kernel, linux-usb, linux-wireless,
netdev, ntfs3, samba-technical, sched-ext, target-devel,
tipc-discussion, v9fs, Julia Lawall, Nicolas Palix, Chris Mason,
David Sterba, Ilya Dryomov, Alex Markuze, Viacheslav Dubeyko,
Theodore Ts'o, Andreas Dilger, Steve French, Paulo Alcantara,
Ronnie Sahlberg, Shyam Prasad N, Tom Talpey, Bharath SM,
Eric Van Hensbergen, Latchesar Ionkov, Dominique Martinet,
Christian Schoenebeck, Gao Xiang, Chao Yu, Yue Hu, Jeffle Xu,
Sandeep Dhavale, Hongbo Li, Chunhai Guo, Miklos Szeredi,
Konstantin Komarov, Andreas Gruenbacher, Kees Cook, Tony Luck,
Guilherme G. Piccoli, Jan Kara, Phillip Lougher,
Christian Brauner, Jan Kara, Steven Rostedt, Masami Hiramatsu,
Mathieu Desnoyers, Tejun Heo, David Vernet, Andrea Righi,
Changwoo Min, Ingo Molnar, Peter Zijlstra, Juri Lelli,
Vincent Guittot, Dietmar Eggemann, Ben Segall, Mel Gorman,
Valentin Schneider, Luis Chamberlain, Petr Pavlu, Daniel Gomez,
Sami Tolvanen, Aaron Tomlin, Sylwester Nawrocki, Liam Girdwood,
Mark Brown, Jaroslav Kysela, Takashi Iwai, Max Filippov,
Paolo Bonzini, John Johansen, Paul Moore, James Morris,
Serge E. Hallyn, Andrew Morton, Alasdair Kergon, Mike Snitzer,
Mikulas Patocka, Benjamin Marzinski, David S. Miller, David Ahern,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman,
Marcel Holtmann, Johan Hedberg, Luiz Augusto von Dentz,
Alexei Starovoitov, Daniel Borkmann, Jesper Dangaard Brouer,
John Fastabend, Stanislav Fomichev, Jamal Hadi Salim, Jiri Pirko,
Marcelo Ricardo Leitner, Xin Long, Trond Myklebust,
Anna Schumaker, Chuck Lever, Jeff Layton, NeilBrown,
Olga Kornievskaia, Dai Ngo, Jon Maloy, Johannes Berg,
Catalin Marinas, Russell King, John Crispin, Thomas Bogendoerfer,
Yoshinori Sato, Rich Felker, John Paul Adrian Glaubitz,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Zhenyu Wang,
Zhi Wang, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
Tvrtko Ursulin, Alex Deucher, Christian König, Sandy Huang,
Heiko Stübner, Andy Yan, Igor Russkikh, Andrew Lunn,
Pavan Chebbi, Michael Chan, Potnuri Bharat Teja, Tony Nguyen,
Przemek Kitszel, Taras Chornyi, Maxime Coquelin, Alexandre Torgue,
Iyappan Subramanian, Keyur Chudgar, Quan Nguyen, Heiner Kallweit,
Marc Zyngier, Thomas Gleixner, Andrew Lunn, Gregory Clement,
Sebastian Hesselbarth, Vinod Koul, Linus Walleij, Ulf Hansson,
Heiko Carstens, Vasily Gorbik, Alexander Gordeev,
Christian Borntraeger, Sven Schnelle, Martin K. Petersen,
Eduardo Valentin, Keerthy, Rafael J. Wysocki, Daniel Lezcano,
Zhang Rui, Lukasz Luba, Alex Williamson, Mark Greer,
Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
Shuah Khan, Kieran Bingham, Mauro Carvalho Chehab, Joerg Roedel,
Will Deacon, Robin Murphy, Lee Jones, Pavel Machek, Dave Penkler,
K. Y. Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li,
Justin Sanders, Jens Axboe, Georgi Djakov, Michael Turquette,
Stephen Boyd, Philipp Zabel, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Pali Rohár, Dmitry Torokhov
In-Reply-To: <20260310-b4-is_err_or_null-v1-0-bd63b656022d@avm.de>
On Tue, Mar 10, 2026 at 12:48:26PM +0100, Philipp Hahn wrote:
> While doing some static code analysis I stumbled over a common pattern,
> where IS_ERR() is combined with a NULL check. For that there is
> IS_ERR_OR_NULL().
... and valid uses of IS_ERR_OR_NULL are rare as hen teeth.
Most of those are "I'm not sure how this function returns an
error, let's use that just in case".
Please, do not introduce more of that crap.
^ permalink raw reply
* Re: [PATCH] HID: logitech-hidpp: fix race condition when accessing stale stack pointer
From: Jiri Kosina @ 2026-04-09 17:26 UTC (permalink / raw)
To: Benoit Sevens
Cc: Filipe Laíns, Bastien Nocera, Benjamin Tissoires,
linux-input, linux-kernel
In-Reply-To: <20260401144811.1242722-1-bsevens@google.com>
On Wed, 1 Apr 2026, Benoit Sevens wrote:
> From: Beno=C3=AEt Sevens <bsevens@google.com>
>
> The driver uses hidpp->send_receive_buf to point to a stack-allocated
> buffer in the synchronous command path (__do_hidpp_send_message_sync).
> However, this pointer is not cleared when the function returns.
>
> If an event is processed (e.g. by a different thread) while the
> send_mutex is held by a new command, but before that command has
> updated send_receive_buf, the handler (hidpp_raw_hidpp_event) will
> observe that the mutex is locked and dereference the stale pointer.
>
> This results in an out-of-bounds access on a different thread's kernel
> stack (or a NULL pointer dereference on the very first command).
>
> Fix this by:
> 1. Clearing hidpp->send_receive_buf to NULL before releasing the mutex
> in the synchronous command path.
> 2. Moving the assignment of the local 'question' and 'answer' pointers
> inside the mutex_is_locked() block in the handler, and adding
> a NULL check before dereferencing.
Now applied.
Benjamin had some ideas on further cleanup (allocating with __free__
instead of using stack pointer), but that'd be a little bigger cleanup, so
let's keep that separate.
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v3 09/11] dt-bindings: input: Document hid-over-spi DT schema
From: Dmitry Torokhov @ 2026-04-09 17:16 UTC (permalink / raw)
To: Conor Dooley
Cc: Jingyuan Liang, Jiri Kosina, Benjamin Tissoires, Jonathan Corbet,
Mark Brown, Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-input,
linux-doc, linux-kernel, linux-spi, linux-trace-kernel,
devicetree, hbarnor, tfiga, Dmitry Antipov, Jarrett Schultz
In-Reply-To: <20260409-defuse-thank-4b038128fac5@spud>
On Thu, Apr 09, 2026 at 05:02:11PM +0100, Conor Dooley wrote:
> On Thu, Apr 02, 2026 at 01:59:46AM +0000, Jingyuan Liang wrote:
> > Documentation describes the required and optional properties for
> > implementing Device Tree for a Microsoft G6 Touch Digitizer that
> > supports HID over SPI Protocol 1.0 specification.
> >
> > The properties are common to HID over SPI.
> >
> > Signed-off-by: Dmitry Antipov <dmanti@microsoft.com>
> > Signed-off-by: Jarrett Schultz <jaschultz@microsoft.com>
> > Signed-off-by: Jingyuan Liang <jingyliang@chromium.org>
> > ---
> > .../devicetree/bindings/input/hid-over-spi.yaml | 126 +++++++++++++++++++++
> > 1 file changed, 126 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/input/hid-over-spi.yaml b/Documentation/devicetree/bindings/input/hid-over-spi.yaml
> > new file mode 100644
> > index 000000000000..d1b0a2e26c32
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/input/hid-over-spi.yaml
> > @@ -0,0 +1,126 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/input/hid-over-spi.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: HID over SPI Devices
> > +
> > +maintainers:
> > + - Benjamin Tissoires <benjamin.tissoires@redhat.com>
> > + - Jiri Kosina <jkosina@suse.cz>
>
> Why them and not you, the developers of the series?
>
> > +
> > +description: |+
> > + HID over SPI provides support for various Human Interface Devices over the
> > + SPI bus. These devices can be for example touchpads, keyboards, touch screens
> > + or sensors.
> > +
> > + The specification has been written by Microsoft and is currently available
> > + here: https://www.microsoft.com/en-us/download/details.aspx?id=103325
> > +
> > + If this binding is used, the kernel module spi-hid will handle the
> > + communication with the device and the generic hid core layer will handle the
> > + protocol.
>
> This is not relevant to the binding, please remove it.
>
> > +
> > +allOf:
> > + - $ref: /schemas/input/touchscreen/touchscreen.yaml#
> > +
> > +properties:
> > + compatible:
> > + oneOf:
> > + - items:
> > + - enum:
> > + - microsoft,g6-touch-digitizer
> > + - const: hid-over-spi
> > + - description: Just "hid-over-spi" alone is allowed, but not recommended.
> > + const: hid-over-spi
>
> Why is it allowed but not recommended? Seems to me like we should
> require device-specific compatibles.
Why would we want to change the driver code to add a new compatible each
time a vendor decides to create a chip that is fully hid-spi-protocol
compliant? Or is the plan to still allow "hid-over-spi" fallback but
require device-specific compatible that will be ignored unless there is
device-specific quirk needed?
>
> > +
> > + reg:
> > + maxItems: 1
> > +
> > + interrupts:
> > + maxItems: 1
> > +
> > + reset-gpios:
> > + maxItems: 1
> > + description:
> > + GPIO specifier for the digitizer's reset pin (active low). The line must
> > + be flagged with GPIO_ACTIVE_LOW.
> > +
> > + vdd-supply:
> > + description:
> > + Regulator for the VDD supply voltage.
> > +
> > + input-report-header-address:
> > + $ref: /schemas/types.yaml#/definitions/uint32
> > + minimum: 0
> > + maximum: 0xffffff
> > + description:
> > + A value to be included in the Read Approval packet, listing an address of
> > + the input report header to be put on the SPI bus. This address has 24
> > + bits.
> > +
> > + input-report-body-address:
> > + $ref: /schemas/types.yaml#/definitions/uint32
> > + minimum: 0
> > + maximum: 0xffffff
> > + description:
> > + A value to be included in the Read Approval packet, listing an address of
> > + the input report body to be put on the SPI bus. This address has 24 bits.
> > +
> > + output-report-address:
> > + $ref: /schemas/types.yaml#/definitions/uint32
> > + minimum: 0
> > + maximum: 0xffffff
> > + description:
> > + A value to be included in the Output Report sent by the host, listing an
> > + address where the output report on the SPI bus is to be written to. This
> > + address has 24 bits.
> > +
> > + read-opcode:
> > + $ref: /schemas/types.yaml#/definitions/uint8
> > + description:
> > + Value to be used in Read Approval packets. 1 byte.
> > +
> > + write-opcode:
> > + $ref: /schemas/types.yaml#/definitions/uint8
> > + description:
> > + Value to be used in Write Approval packets. 1 byte.
>
> Why can none of these things be determined from the device's compatible?
> On the surface, they like the kinds of things that could/should be.
Why would we want to keep tables of these values in the kernel and again
have to update the driver for each new chip? It also probably
firmware-dependent.
Thanks.
--
Dmitry
^ permalink raw reply
* [PATCH] HID: drop 'default !EXPERT' from HID_PICOLCD symbols
From: Thomas Weißschuh @ 2026-04-09 16:32 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires
Cc: linux-input, linux-kernel, Thomas Weißschuh
The 'EXPERT' configuration is meant to make advanced kconfig options
configurable. It is not meant to actively change these options.
In the case of the HID_PICOLCD suboptions the intention seems to be that
normal users always expect these options to be enabled for the driver.
So 'EXPERT' is enabled, these options should stay enabled and not
automatically and suddenly become disabled. Switch them to 'default y'
to match the intention of a normal user. EXPERT users then can disable
them if needed.
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
---
drivers/hid/Kconfig | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
index c1d9f7c6a5f2..1ef4fe3debf2 100644
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
@@ -938,7 +938,7 @@ config HID_PICOLCD
config HID_PICOLCD_FB
bool "Framebuffer support" if EXPERT
- default !EXPERT
+ default y
depends on HID_PICOLCD
depends on HID_PICOLCD=FB || FB=y
select FB_SYSMEM_HELPERS_DEFERRED
@@ -948,7 +948,7 @@ config HID_PICOLCD_FB
config HID_PICOLCD_BACKLIGHT
bool "Backlight control" if EXPERT
- default !EXPERT
+ default y
depends on HID_PICOLCD
depends on HID_PICOLCD=BACKLIGHT_CLASS_DEVICE || BACKLIGHT_CLASS_DEVICE=y
help
@@ -957,7 +957,7 @@ config HID_PICOLCD_BACKLIGHT
config HID_PICOLCD_LCD
bool "Contrast control" if EXPERT
- default !EXPERT
+ default y
depends on HID_PICOLCD
depends on HID_PICOLCD=LCD_CLASS_DEVICE || LCD_CLASS_DEVICE=y
help
@@ -965,7 +965,7 @@ config HID_PICOLCD_LCD
config HID_PICOLCD_LEDS
bool "GPO via leds class" if EXPERT
- default !EXPERT
+ default y
depends on HID_PICOLCD
depends on HID_PICOLCD=LEDS_CLASS || LEDS_CLASS=y
help
@@ -973,7 +973,7 @@ config HID_PICOLCD_LEDS
config HID_PICOLCD_CIR
bool "CIR via RC class" if EXPERT
- default !EXPERT
+ default y
depends on HID_PICOLCD
depends on HID_PICOLCD=RC_CORE || RC_CORE=y
help
---
base-commit: 7f87a5ea75f011d2c9bc8ac0167e5e2d1adb1594
change-id: 20260409-hid-picolcd-1b6d7eac5795
Best regards,
--
Thomas Weißschuh <linux@weissschuh.net>
^ permalink raw reply related
* Re: [PATCH v3] HID: winwing: Enable rumble effects
From: Jiri Kosina @ 2026-04-09 16:10 UTC (permalink / raw)
To: Ivan Gorinov; +Cc: linux-input, linux-kernel
In-Reply-To: <20260307052246.GA21987@altimeter-info>
On Sat, 7 Mar 2026, Ivan Gorinov wrote:
> Enable rumble motor control on TGRIP-15E and TGRIP-15EX throttle grips
> by sending haptic feedback commands (EV_FF events) to the input device.
>
> Signed-off-by: Ivan Gorinov <linux-kernel@altimeter.info>
> ---
>
> Changes since v2:
> - Add comments about USB requests for LED and rumble control
>
> Changes since v1:
> - Fix possible NULL pointer dereference
Now applied to hid.git#for-7.1/winwing, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v3 09/11] dt-bindings: input: Document hid-over-spi DT schema
From: Conor Dooley @ 2026-04-09 16:02 UTC (permalink / raw)
To: Jingyuan Liang
Cc: Jiri Kosina, Benjamin Tissoires, Jonathan Corbet, Mark Brown,
Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-input, linux-doc, linux-kernel, linux-spi,
linux-trace-kernel, devicetree, hbarnor, tfiga, Dmitry Antipov,
Jarrett Schultz
In-Reply-To: <20260402-send-upstream-v3-9-6091c458d357@chromium.org>
[-- Attachment #1: Type: text/plain, Size: 5441 bytes --]
On Thu, Apr 02, 2026 at 01:59:46AM +0000, Jingyuan Liang wrote:
> Documentation describes the required and optional properties for
> implementing Device Tree for a Microsoft G6 Touch Digitizer that
> supports HID over SPI Protocol 1.0 specification.
>
> The properties are common to HID over SPI.
>
> Signed-off-by: Dmitry Antipov <dmanti@microsoft.com>
> Signed-off-by: Jarrett Schultz <jaschultz@microsoft.com>
> Signed-off-by: Jingyuan Liang <jingyliang@chromium.org>
> ---
> .../devicetree/bindings/input/hid-over-spi.yaml | 126 +++++++++++++++++++++
> 1 file changed, 126 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/input/hid-over-spi.yaml b/Documentation/devicetree/bindings/input/hid-over-spi.yaml
> new file mode 100644
> index 000000000000..d1b0a2e26c32
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/hid-over-spi.yaml
> @@ -0,0 +1,126 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/input/hid-over-spi.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: HID over SPI Devices
> +
> +maintainers:
> + - Benjamin Tissoires <benjamin.tissoires@redhat.com>
> + - Jiri Kosina <jkosina@suse.cz>
Why them and not you, the developers of the series?
> +
> +description: |+
> + HID over SPI provides support for various Human Interface Devices over the
> + SPI bus. These devices can be for example touchpads, keyboards, touch screens
> + or sensors.
> +
> + The specification has been written by Microsoft and is currently available
> + here: https://www.microsoft.com/en-us/download/details.aspx?id=103325
> +
> + If this binding is used, the kernel module spi-hid will handle the
> + communication with the device and the generic hid core layer will handle the
> + protocol.
This is not relevant to the binding, please remove it.
> +
> +allOf:
> + - $ref: /schemas/input/touchscreen/touchscreen.yaml#
> +
> +properties:
> + compatible:
> + oneOf:
> + - items:
> + - enum:
> + - microsoft,g6-touch-digitizer
> + - const: hid-over-spi
> + - description: Just "hid-over-spi" alone is allowed, but not recommended.
> + const: hid-over-spi
Why is it allowed but not recommended? Seems to me like we should
require device-specific compatibles.
> +
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + maxItems: 1
> +
> + reset-gpios:
> + maxItems: 1
> + description:
> + GPIO specifier for the digitizer's reset pin (active low). The line must
> + be flagged with GPIO_ACTIVE_LOW.
> +
> + vdd-supply:
> + description:
> + Regulator for the VDD supply voltage.
> +
> + input-report-header-address:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + minimum: 0
> + maximum: 0xffffff
> + description:
> + A value to be included in the Read Approval packet, listing an address of
> + the input report header to be put on the SPI bus. This address has 24
> + bits.
> +
> + input-report-body-address:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + minimum: 0
> + maximum: 0xffffff
> + description:
> + A value to be included in the Read Approval packet, listing an address of
> + the input report body to be put on the SPI bus. This address has 24 bits.
> +
> + output-report-address:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + minimum: 0
> + maximum: 0xffffff
> + description:
> + A value to be included in the Output Report sent by the host, listing an
> + address where the output report on the SPI bus is to be written to. This
> + address has 24 bits.
> +
> + read-opcode:
> + $ref: /schemas/types.yaml#/definitions/uint8
> + description:
> + Value to be used in Read Approval packets. 1 byte.
> +
> + write-opcode:
> + $ref: /schemas/types.yaml#/definitions/uint8
> + description:
> + Value to be used in Write Approval packets. 1 byte.
Why can none of these things be determined from the device's compatible?
On the surface, they like the kinds of things that could/should be.
Cheers,
Conor.
> +
> +required:
> + - compatible
> + - interrupts
> + - reset-gpios
> + - vdd-supply
> + - input-report-header-address
> + - input-report-body-address
> + - output-report-address
> + - read-opcode
> + - write-opcode
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/irq.h>
> + #include <dt-bindings/gpio/gpio.h>
> +
> + spi {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + hid@0 {
> + compatible = "microsoft,g6-touch-digitizer", "hid-over-spi";
> + reg = <0x0>;
> + interrupts-extended = <&gpio 42 IRQ_TYPE_EDGE_FALLING>;
> + reset-gpios = <&gpio 27 GPIO_ACTIVE_LOW>;
> + vdd-supply = <&pm8350c_l3>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&ts_d6_int_bias>;
> + input-report-header-address = <0x1000>;
> + input-report-body-address = <0x1004>;
> + output-report-address = <0x2000>;
> + read-opcode = /bits/ 8 <0x0b>;
> + write-opcode = /bits/ 8 <0x02>;
> + };
> + };
>
> --
> 2.53.0.1185.g05d4b7b318-goog
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH] HID: core: do not allow parsing 0-sized reports
From: Jiri Kosina @ 2026-04-09 16:00 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Benjamin Tissoires, Peter Hutterer, Kees Cook, Alan Stern,
Charles Keepax, linux-input, linux-kernel
In-Reply-To: <acy1QWcu-yfd_kAu@google.com>
On Tue, 31 Mar 2026, Dmitry Torokhov wrote:
> Commit d7db259bd6df ("HID: core: factor out hid_parse_collections()")
> reworked collection parsing code and inadvertently allowed returning
> "success" when parsing 0-sized reports where old code returned -EINVAL.
Ah, good catch, I've missed that.
Applied on top, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: usbhid: refactor endpoint lookup
From: Jiri Kosina @ 2026-04-09 15:58 UTC (permalink / raw)
To: Johan Hovold; +Cc: Benjamin Tissoires, linux-usb, linux-input, linux-kernel
In-Reply-To: <20260330095034.1662231-1-johan@kernel.org>
On Mon, 30 Mar 2026, Johan Hovold wrote:
> Use the common USB helper for looking up interrupt-in endpoints instead
> of open coding.
Good catch, thanks Johan. Now applied to hid.git#for-7.1/core-v2.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: huawei: fix CD30 keyboard report descriptor issue
From: Jiri Kosina @ 2026-04-09 15:57 UTC (permalink / raw)
To: Miao Li; +Cc: bentiss, linux-input, linux-kernel, Miao Li
In-Reply-To: <20260318091249.217283-1-limiao870622@163.com>
On Wed, 18 Mar 2026, Miao Li wrote:
> From: Miao Li <limiao@kylinos.cn>
>
> When the Huawei CD30 USB keyboard undergoes 500 reboot cycles,
> initialization may fail due to a report descriptor problem.
Oh wow, that's a novelty I think.
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: playstation: validate num_touch_reports in DualShock 4 reports
From: Jiri Kosina @ 2026-04-09 15:55 UTC (permalink / raw)
To: FirstName LastName
Cc: Roderick Colenbrander, Benjamin Tissoires, linux-input,
linux-kernel
In-Reply-To: <20260323124737.3223129-1-bsevens@google.com>
Dear FirstName LastName,
there seems to be a way to fix in your mail setup configuration :)
On Mon, 23 Mar 2026, FirstName LastName wrote:
> From: Beno=C3=AEt Sevens <bsevens@google.com>
>
> The DualShock 4 HID driver fails to validate the num_touch_reports field
> received from the device in both USB and Bluetooth input reports.
> A malicious device could set this field to a value larger than the
> allocated size of the touch_reports array (3 for USB, 4 for Bluetooth),
> leading to an out-of-bounds read in dualshock4_parse_report().
>
> This can result in kernel memory disclosure when processing malicious
> HID reports.
>
> Validate num_touch_reports against the array size for the respective
> connection types before processing the touch data.
>
> Signed-off-by: Beno=C3=AEt Sevens <bsevens@google.com>
Applied now to hid.git#for-7.0/upstream-fixes, thanks!
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: drop 'default !EXPERT' from tristate symbols
From: Jiri Kosina @ 2026-04-09 15:53 UTC (permalink / raw)
To: Thomas Weißschuh; +Cc: Benjamin Tissoires, linux-input, linux-kernel
In-Reply-To: <20260321-hid-expert-v1-1-4a6d81b4f3ac@weissschuh.net>
On Sat, 21 Mar 2026, Thomas Weißschuh wrote:
> There is no reason to build random drivers for obscure hardware into the
> core kernel by default.
This is from the time when invididual drivers have been extracted from
monolithing hid.o, and there was a general fear that it would cause
regressions for people, because the generic driver wouldn't work any more
and they'd have to look for fixing that by enabling particular driver.
That ship has sailed ages ago though, so I agree we could just remove it.
> The usages of 'default !EXPERT' for the HID_PICOLCD suboptions are kept,
> as these make some sense, although they probably should use 'default y'.
There are very few fans of 'default y' :)
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v2] HID: ft260: validate report size and payload length in raw_event
From: Jiri Kosina @ 2026-04-09 15:50 UTC (permalink / raw)
To: Sebastian Josue Alba Vives
Cc: michael.zaidman, Benjamin Tissoires, linux-i2c, linux-input,
linux-kernel, stable
In-Reply-To: <20260324201858.46591-1-sebasjosue84@gmail.com>
On Tue, 24 Mar 2026, Sebastian Josue Alba Vives wrote:
> ft260_raw_event() casts the raw data buffer to a
> ft260_i2c_input_report struct and accesses its fields without
> validating the size parameter. Since __hid_input_report() invokes
> the driver's raw_event callback before hid_report_raw_event()
> performs its own report-size validation, a device sending a
> truncated HID report can cause out-of-bounds heap reads.
>
> Additionally, even with a full-sized report, a corrupted
> xfer->length field can cause memcpy to read beyond the report
> buffer. The existing check only validates against the destination
> buffer size, not the source data available in the report.
>
> Add two checks: reject reports shorter than FT260_REPORT_MAX_LENGTH,
> and verify that xfer->length does not exceed the actual data
> available in the report. Log warnings to aid debugging.
>
> Cc: stable@vger.kernel.org
> Signed-off-by: Sebastian Josue Alba Vives <sebasjosue84@gmail.com>
> ---
> drivers/hid/hid-ft260.c | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/drivers/hid/hid-ft260.c b/drivers/hid/hid-ft260.c
> index 333341e80..68008a423 100644
> --- a/drivers/hid/hid-ft260.c
> +++ b/drivers/hid/hid-ft260.c
> @@ -1068,6 +1068,17 @@ static int ft260_raw_event(struct hid_device *hdev, struct hid_report *report,
> struct ft260_device *dev = hid_get_drvdata(hdev);
> struct ft260_i2c_input_report *xfer = (void *)data;
>
> + if (size < FT260_REPORT_MAX_LENGTH) {
> + hid_warn(hdev, "short report: %d\n", size);
> + return 0;
Michael, can you please confirm whether the device can never legitimately
send shorter than FT260_REPORT_MAX_LENGTH reports?
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] hid: usbhid: fix deadlock in hid_post_reset()
From: Jiri Kosina @ 2026-04-09 15:48 UTC (permalink / raw)
To: Oliver Neukum; +Cc: bentiss, linux-input, linux-usb
In-Reply-To: <036cb81b-ae6e-4dcd-8f97-593e754279d1@suse.com>
On Mon, 30 Mar 2026, Oliver Neukum wrote:
> > Did you find this just by code inspection, or was this reported with a
> > real device?
>
> Pure inspection. We are looking at USB error handling
> in general right now.
OK, thanks. Now queued in hid.git.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: apple: ensure the keyboard backlight is off if suspending
From: Jiri Kosina @ 2026-04-09 15:46 UTC (permalink / raw)
To: Aditya Garg
Cc: Benjamin Tissoires, linux-input, linux-kernel, stable,
André Eikmeyer
In-Reply-To: <MAUPR01MB115467C51E492BD620ED390B6B85FA@MAUPR01MB11546.INDPRD01.PROD.OUTLOOK.COM>
On Sat, 4 Apr 2026, Aditya Garg wrote:
> Some users reported that upon suspending their keyboard backlight
> remained on. Fix this by adding the missing LED_CORE_SUSPENDRESUME flag.
>
> Cc: stable@vger.kernel.org
> Fixes: 394ba612f941 ("HID: apple: Add support for magic keyboard backlight on T2 Macs")
> Fixes: 9018eacbe623 ("HID: apple: Add support for keyboard backlight on certain T2 Macs.")
> Reported-by: André Eikmeyer <andre.eikmeyer@gmail.com>
> Tested-by: André Eikmeyer <andre.eikmeyer@gmail.com>
> Signed-off-by: Aditya Garg <gargaditya08@live.com>
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: quirks: Set ALWAYS_POLL for LOGITECH_BOLT_RECEIVER
From: Jiri Kosina @ 2026-04-09 15:45 UTC (permalink / raw)
To: Nícolas F. R. A. Prado
Cc: Benjamin Tissoires, kernel, linux-input, linux-kernel
In-Reply-To: <20260407-logi-bolt-hid-quirk-always-poll-v1-1-4dae0fda344e@collabora.com>
On Tue, 7 Apr 2026, Nícolas F. R. A. Prado wrote:
> The Logitech Bolt receiver once connected to a wireless device will
> generate data on interface 2. If this data isn't polled, when the USB
> port it is connected to gets suspended (and if that happens within 5
> minutes of the last input from the wireless device), it will trigger a
> remote wakeup 3 seconds later, which will result in a spurious system
> wakeup if the port was suspended as part of system sleep.
>
> Set the ALWAYS_POLL quirk for this device to ensure interface 2 is
> always polled and this spurious wakeup never happens.
>
> With this change in place the system can be suspended with the receiver
> plugged in and the system can be woken up when an input is sent from the
> wireless device.
>
> Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
> ---
> Hi,
>
> Given that the polling only needs to happen before the device goes into
> suspend, I wonder if it might make sense to introduce a new quirk type
> that only does a poll before the device goes into suspend (both for
> system sleep and runtime suspend). It would reduce the extra bit of USB
> traffic that ends up happening in this case with ALWAYS_POLL every time
> a wireless device connects to the receiver.
I don't think it's worth the hassle, but if you feel strongly about it, I
wouldn't object too strongly.
In the meantime, I am applying this one. Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: winwing: add support for URSA MINOR combat joysticks
From: Jiri Kosina @ 2026-04-09 15:43 UTC (permalink / raw)
To: René Onier; +Cc: linux-input, bentiss, ivan.gorinov
In-Reply-To: <20260404172641.195619-1-rene.onier@gmail.com>
On Sat, 4 Apr 2026, René Onier wrote:
> Add device IDs for the Winwing URSA MINOR Combat Joystick L (0xbc29)
> and R (0xbc2a). These joysticks declare 128 buttons in their HID
> report descriptor, causing the generic HID driver to reject buttons
> above KEY_MAX (767) with "Invalid code" errors.
>
> The URSA MINOR joysticks use buttons in the 33-64 range for grip
> controls including the index trigger, so map_more_buttons is set
> to 1 to enable the extended KEY_MACRO mapping.
>
> Tested with both left and right URSA MINOR joysticks on kernel 6.19.
>
> Signed-off-by: René Onier <rene.onier@gmail.com>
> ---
> hid-winwing.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/hid-winwing.c b/hid-winwing.c
> index ab65dc1..f3e6ea0 100644
> --- a/hid-winwing.c
> +++ b/hid-winwing.c
Thanks for the patch!
You seem to have generated it however without a full path, so it can't be
applied using standard patch -p1 way ... could you please fix that up and
resend?
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: alps: fix NULL pointer dereference in alps_raw_event()
From: Jiri Kosina @ 2026-04-09 15:37 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-input, linux-kernel, stable, Benjamin Tissoires, Masaki Ota
In-Reply-To: <2026040624-overjoyed-impart-6fa4@gregkh>
On Mon, 6 Apr 2026, Greg Kroah-Hartman wrote:
> Commit ecfa6f34492c ("HID: Add HID_CLAIMED_INPUT guards in raw_event
> callbacks missing them") attempted to fix up the HID drivers that had
> missed the previous fix that was done in 2ff5baa9b527 ("HID: appleir:
> Fix potential NULL dereference at raw event handle"), but the alps
> driver was missed.
>
> Fix this up by properly checking in the hid-alps driver that it had been
> claimed correctly before attempting to process the raw event.
>
> Fixes: 73196ebe134d ("HID: alps: add support for Alps T4 Touchpad device")
> Cc: stable <stable@kernel.org>
> Cc: Jiri Kosina <jikos@kernel.org>
> Cc: Benjamin Tissoires <bentiss@kernel.org>
> Cc: Masaki Ota <masaki.ota@jp.alps.com>
> Cc: linux-input@vger.kernel.org
> Assisted-by: gregkh_clanker_t1000
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v2 1/2] HID: logitech-dj: Standardise hid_report_enum variable nomenclature
From: Jiri Kosina @ 2026-04-09 15:36 UTC (permalink / raw)
To: Lee Jones
Cc: Filipe Laíns, Benjamin Tissoires, linux-input, linux-kernel
In-Reply-To: <20260407135955.GQ3795166@google.com>
On Tue, 7 Apr 2026, Lee Jones wrote:
> > Since we will need to differentiate between the two report_enum types
> > soon, let's unify the naming conventions now to save confusion and/or
> > unnecessary/unrelated changes in upcoming commits.
> >
> > {input,output}_report_enum is used in other places to let's conform.
> >
> > Signed-off-by: Lee Jones <lee@kernel.org>
> > ---
> > v1 => v2: New patch
> >
> > drivers/hid/hid-logitech-dj.c | 12 ++++++------
> > 1 file changed, 6 insertions(+), 6 deletions(-)
>
> During a previous submission you indicated that you preferred pings over
> [RESEND]s - so this is it.
>
> This submission was posted 2 weeks ago. Could someone take a look please?
Sorry for the delay. Now applied. Thanks!
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: sony: update module description
From: Jiri Kosina @ 2026-04-09 15:34 UTC (permalink / raw)
To: Rosalie Wanders; +Cc: Benjamin Tissoires, linux-input, linux-kernel
In-Reply-To: <20260402155915.17745-2-rosalie@mailbox.org>
On Thu, 2 Apr 2026, Rosalie Wanders wrote:
> This commit updates the hid-sony module description to make it correct
> with the recent hid-sony changes alongside making it more consistent.
>
> Signed-off-by: Rosalie Wanders <rosalie@mailbox.org>
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: logitech-hidpp: Check bounds when deleting force-feedback effects
From: Jiri Kosina @ 2026-04-09 15:27 UTC (permalink / raw)
To: Günther Noack
Cc: Filipe Laíns, Bastien Nocera, Benjamin Tissoires, Lee Jones,
linux-input, linux-kernel
In-Reply-To: <20260331074052.194064-1-gnoack@google.com>
On Tue, 31 Mar 2026, Günther Noack wrote:
> Without this bounds check, this might otherwise overwrite index -1.
>
> Triggering this condition requires action both from the USB device and from
> userspace, which reduces the scenarios in which it can be exploited.
>
> Cc: Lee Jones <lee@kernel.org>
> Signed-off-by: G=C3=BCnther Noack <gnoack@google.com>
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH 2/2] arm64: dts: qcom: sdm845-oneplus: Update compatible to include model
From: David Heidelberg @ 2026-04-09 15:19 UTC (permalink / raw)
To: Konrad Dybcio, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jason A. Donenfeld, Matthias Schiffer,
Vincent Huang, Bjorn Andersson, Konrad Dybcio
Cc: linux-input, devicetree, linux-kernel, linux-arm-msm, phone-devel,
Krzysztof Kozlowski
In-Reply-To: <80067706-1857-46a0-a281-7f4ff3937468@oss.qualcomm.com>
On 09/04/2026 14:41, Konrad Dybcio wrote:
> On 4/8/26 7:34 PM, David Heidelberg via B4 Relay wrote:
>> From: David Heidelberg <david@ixit.cz>
>>
>> We know the driver is reporting s3706b, introduce the compatible so we
>
> via Google search AI summary:
> "Bon Chef S3706B is a black dinner fork (Roman Euro Dinner Fork)" - the
> more you know!
Oh no, that's definitely not compatible hardware! Maybe it's some fork... :P
^ permalink raw reply
* Re: [PATCH] Docs: hid: intel-ish-hid: make long URL usable
From: Jonathan Corbet @ 2026-04-09 14:42 UTC (permalink / raw)
To: Randy Dunlap, linux-kernel
Cc: Randy Dunlap, Jiri Kosina, Benjamin Tissoires,
Srinivas Pandruvada, linux-input, Shuah Khan, linux-doc
In-Reply-To: <20260321230934.435020-1-rdunlap@infradead.org>
Randy Dunlap <rdunlap@infradead.org> writes:
> The '\' line continuation character in this long URL
> doesn't help anything. There is no documentation tooling that
> handles the line continuation character to join the 2 lines
> to make a usable URL. Web browsers terminate the URL just
> before the '\' character so that the second line of the URL
> is lost. See:
> https://docs.kernel.org/hid/intel-ish-hid.html
>
> Join the 2 lines together so that the URL is usable.
>
> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
> ---
> Cc: Jiri Kosina <jikos@kernel.org>
> Cc: Benjamin Tissoires <bentiss@kernel.org>
> Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
> Cc: linux-input@vger.kernel.org
> Cc: Jonathan Corbet <corbet@lwn.net>
> Cc: Shuah Khan <skhan@linuxfoundation.org>
> Cc: linux-doc@vger.kernel.org
>
> Documentation/hid/intel-ish-hid.rst | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> --- linux-next-20260320.orig/Documentation/hid/intel-ish-hid.rst
> +++ linux-next-20260320/Documentation/hid/intel-ish-hid.rst
> @@ -163,8 +163,8 @@ The transport layer is a bi-directional
> - A flow control mechanism to avoid buffer overflows
>
> This protocol resembles bus messages described in the following document:
> -http://www.intel.com/content/dam/www/public/us/en/documents/technical-\
> -specifications/dcmi-hi-1-0-spec.pdf "Chapter 7: Bus Message Layer"
> +http://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/dcmi-hi-1-0-spec.pdf
> +"Chapter 7: Bus Message Layer".
Applied, thanks.
jon
^ permalink raw reply
* Re: [PATCH 2/2] arm64: dts: qcom: sdm845-oneplus: Update compatible to include model
From: Konrad Dybcio @ 2026-04-09 12:41 UTC (permalink / raw)
To: david, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jason A. Donenfeld, Matthias Schiffer,
Vincent Huang, Bjorn Andersson, Konrad Dybcio
Cc: linux-input, devicetree, linux-kernel, linux-arm-msm, phone-devel,
Krzysztof Kozlowski
In-Reply-To: <20260408-synaptics-rmi4-dt-v1-2-2d32bacce673@ixit.cz>
On 4/8/26 7:34 PM, David Heidelberg via B4 Relay wrote:
> From: David Heidelberg <david@ixit.cz>
>
> We know the driver is reporting s3706b, introduce the compatible so we
via Google search AI summary:
"Bon Chef S3706B is a black dinner fork (Roman Euro Dinner Fork)" - the
more you know!
> can more easily introduce quirks for weird touchscreen replacements in
> followup series.
>
> Signed-off-by: David Heidelberg <david@ixit.cz>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH 0/2] HID: multitouch: Add support for Dell Pro Rugged 12 Tablet RA02260
From: buingoc67 @ 2026-04-09 5:13 UTC (permalink / raw)
To: jikos; +Cc: bentiss, buingoc67, linux-input, linux-kernel
In-Reply-To: <4op5533p-s086-55sr-oso5-30qsnqpq407n@xreary.bet>
Hi, I don't understand why it take my email "buingoc67" instead
of the git user.name that I set as "hmtheboy154". Is there any way
that I can change this ? Or else I'll submit the changes under my
org email (hmtheboy154@blisslabs.org) if that's ok.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox