* Re: [PATCH v5 4/4] Input: charlieplex_keypad: add GPIO charlieplex keypad
From: Dmitry Torokhov @ 2026-04-20 17:16 UTC (permalink / raw)
To: Hugo Villeneuve
Cc: robin, andy, geert, robh, krzk+dt, conor+dt, hvilleneuve,
mkorpershoek, matthias.bgg, angelogioacchino.delregno, lee,
alexander.sverdlin, marek.vasut, akurz, devicetree, linux-kernel,
linux-input, linux-arm-kernel, linux-mediatek
In-Reply-To: <20260420110159.29ccb815eb584bca18a407ac@hugovil.com>
On Mon, Apr 20, 2026 at 11:01:59AM -0400, Hugo Villeneuve wrote:
> I tested it on the real hardware and all is good.
Thank you for testing the changes.
>
> So I imagine that it can still go into 7.1 since it is a new driver
> and not a modification of an existing one?
Yes, since this is a new driver I will include it in 7.1 pull request.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v2] iio: magnetometer: hid-sensor-magn-3d: prefer 'unsigned int'
From: Andy Shevchenko @ 2026-04-20 16:50 UTC (permalink / raw)
To: srinivas pandruvada
Cc: Joshua Crofts, jikos, jic23, dlechner, nuno.sa, andy, linux-input,
linux-iio, linux-kernel
In-Reply-To: <4e84f9cc258676ed038e1f932137f10f34064aca.camel@linux.intel.com>
On Mon, Apr 20, 2026 at 08:46:57AM -0700, srinivas pandruvada wrote:
> On Sun, 2026-04-19 at 20:05 +0200, Joshua Crofts wrote:
> > Use 'u32' instead of bare 'unsigned' to resolve checkpatch.pl
> > warnings
> > and correct type use as defined in the hid_sensor_hub_callbacks
> > struct.
> >
> > No functional change.
> >
> > Signed-off-by: Joshua Crofts <joshua.crofts1@gmail.com>
>
> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
The Subject needs to be adjusted as well.
> > ---
> > v2:
> > - changed 'unsigned int' to 'u32' per struct definition
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH] Input: usbtouchscreen - clamp NEXIO data_len/x_len to URB buffer size
From: Greg Kroah-Hartman @ 2026-04-20 16:00 UTC (permalink / raw)
To: linux-input; +Cc: linux-kernel, Greg Kroah-Hartman, Dmitry Torokhov, stable
nexio_read_data() pulls data_len and x_len from a packed __be16 header
in the device's interrupt packet and then walks packet->data[0..x_len)
and packet->data[x_len..data_len) comparing each byte against a
threshold.
Both fields are 16-bit on the wire (max 65535). The existing
adjustments shave at most 0x100 / 0x80 off, so the loop bound can still
reach roughly 0xfeff. The URB transfer buffer for NEXIO is rept_size
(1024) bytes from usb_alloc_coherent(), with the first 7 occupied by the
packed header — so packet->data[] has 1017 valid bytes. read_data()
callbacks are not given urb->actual_length, and nothing else bounds the
walk.
A device that lies about its length can get a ~64 KiB out-of-bounds read
past the coherent DMA allocation. The first index whose byte exceeds
NEXIO_THRESHOLD lands in begin_x / begin_y and from there into the
reported touch coordinates, so adjacent kernel memory contents leak to
userspace as ABS_X / ABS_Y events. Far enough out, the read can also
hit an unmapped page and fault.
Fix this all by clamping data_len to the buffer's data[] capacity and
x_len to data_len.
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Fixes: 5197424cdccc ("Input: usbtouchscreen - add NEXIO (or iNexio) support")
Cc: stable <stable@kernel.org>
Assisted-by: gkh_clanker_t1000
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/input/touchscreen/usbtouchscreen.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/input/touchscreen/usbtouchscreen.c b/drivers/input/touchscreen/usbtouchscreen.c
index 657555c8796c..866d4a7fbe42 100644
--- a/drivers/input/touchscreen/usbtouchscreen.c
+++ b/drivers/input/touchscreen/usbtouchscreen.c
@@ -1070,6 +1070,11 @@ static int nexio_read_data(struct usbtouch_usb *usbtouch, unsigned char *pkt)
if (x_len > 0xff)
x_len -= 0x80;
+ if (data_len > usbtouch->data_size - sizeof(*packet))
+ data_len = usbtouch->data_size - sizeof(*packet);
+ if (x_len > data_len)
+ x_len = data_len;
+
/* send ACK */
ret = usb_submit_urb(priv->ack, GFP_ATOMIC);
if (ret)
--
2.53.0
^ permalink raw reply related
* [PATCH] Input: xpad - reject short Xbox One packets before len-relative share-button index
From: Greg Kroah-Hartman @ 2026-04-20 15:53 UTC (permalink / raw)
To: linux-input; +Cc: linux-kernel, Greg Kroah-Hartman, Dmitry Torokhov, stable
xpadone_process_packet() receives len directly from urb->actual_length
and uses it to index the share-button byte at data[len - 18] or
data[len - 26]. Since both len and data[0] are under the device's
control, a broken controller can send a GIP_CMD_INPUT packet with
actual_length < 18 (e.g. 5 bytes) and reach this code path, causing
accesses beyond the actual array.
Since len is u32, 5 - 26 wraps to 0xFFFFFFEB, and data[0xFFFFFFEB] can
dereference about 4 GiB past the 64-byte usb_alloc_coherent() idata
buffer. On a KASAN system this is an immediate splat otherwise the read
will either fault on an unmapped page (DoS) or pull a bit from arbitrary
kernel memory and report it as KEY_RECORD.
Fix this all up by properly bounds checking the value provided by the
device.
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Fixes: 4ef46367073b ("Input: xpad - fix Share button on Xbox One controllers")
Cc: stable <stable@kernel.org>
Assisted-by: gkh_clanker_t1000
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/input/joystick/xpad.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
index d6fc3d6006bb..7d99fe0ecf91 100644
--- a/drivers/input/joystick/xpad.c
+++ b/drivers/input/joystick/xpad.c
@@ -1110,10 +1110,13 @@ static void xpadone_process_packet(struct usb_xpad *xpad, u16 cmd, unsigned char
input_report_key(dev, BTN_START, data[4] & BIT(2));
input_report_key(dev, BTN_SELECT, data[4] & BIT(3));
if (xpad->mapping & MAP_SHARE_BUTTON) {
- if (xpad->mapping & MAP_SHARE_OFFSET)
- input_report_key(dev, KEY_RECORD, data[len - 26] & BIT(0));
- else
- input_report_key(dev, KEY_RECORD, data[len - 18] & BIT(0));
+ if (xpad->mapping & MAP_SHARE_OFFSET) {
+ if (len >= 26)
+ input_report_key(dev, KEY_RECORD, data[len - 26] & BIT(0));
+ } else {
+ if (len >= 18)
+ input_report_key(dev, KEY_RECORD, data[len - 18] & BIT(0));
+ }
}
/* buttons A,B,X,Y */
--
2.53.0
^ permalink raw reply related
* [PATCH 6.12 098/162] HID: core: clamp report_size in s32ton() to avoid undefined shift
From: Greg Kroah-Hartman @ 2026-04-20 15:42 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, stable, Jiri Kosina,
Benjamin Tissoires, linux-input, Jiri Kosina
In-Reply-To: <20260420153927.006696811@linuxfoundation.org>
6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 69c02ffde6ed4d535fa4e693a9e572729cad3d0d upstream.
s32ton() shifts by n-1 where n is the field's report_size, a value that
comes directly from a HID device. The HID parser bounds report_size
only to <= 256, so a broken HID device can supply a report descriptor
with a wide field that triggers shift exponents up to 256 on a 32-bit
type when an output report is built via hid_output_field() or
hid_set_field().
Commit ec61b41918587 ("HID: core: fix shift-out-of-bounds in
hid_report_raw_event") added the same n > 32 clamp to the function
snto32(), but s32ton() was never given the same fix as I guess syzbot
hadn't figured out how to fuzz a device the same way.
Fix this up by just clamping the max value of n, just like snto32()
does.
Cc: stable <stable@kernel.org>
Cc: Jiri Kosina <jikos@kernel.org>
Cc: Benjamin Tissoires <bentiss@kernel.org>
Cc: linux-input@vger.kernel.org
Assisted-by: gregkh_clanker_t1000
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/hid/hid-core.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -71,6 +71,9 @@ static u32 s32ton(__s32 value, unsigned
if (!value || !n)
return 0;
+ if (n > 32)
+ n = 32;
+
a = value >> (n - 1);
if (a && a != -1)
return value < 0 ? 1 << (n - 1) : (1 << (n - 1)) - 1;
^ permalink raw reply
* [PATCH 6.12 097/162] HID: alps: fix NULL pointer dereference in alps_raw_event()
From: Greg Kroah-Hartman @ 2026-04-20 15:42 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, stable, Jiri Kosina,
Benjamin Tissoires, Masaki Ota, linux-input, Jiri Kosina
In-Reply-To: <20260420153927.006696811@linuxfoundation.org>
6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1badfc4319224820d5d890f8eab6aa52e4e83339 upstream.
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>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/hid/hid-alps.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/hid/hid-alps.c
+++ b/drivers/hid/hid-alps.c
@@ -437,6 +437,9 @@ static int alps_raw_event(struct hid_dev
int ret = 0;
struct alps_dev *hdata = hid_get_drvdata(hdev);
+ if (!(hdev->claimed & HID_CLAIMED_INPUT) || !hdata->input)
+ return 0;
+
switch (hdev->product) {
case HID_PRODUCT_ID_T4_BTNLESS:
ret = t4_raw_event(hdata, data, size);
^ permalink raw reply
* [PATCH 6.18 127/198] HID: core: clamp report_size in s32ton() to avoid undefined shift
From: Greg Kroah-Hartman @ 2026-04-20 15:41 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, stable, Jiri Kosina,
Benjamin Tissoires, linux-input, Jiri Kosina
In-Reply-To: <20260420153935.605963767@linuxfoundation.org>
6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 69c02ffde6ed4d535fa4e693a9e572729cad3d0d upstream.
s32ton() shifts by n-1 where n is the field's report_size, a value that
comes directly from a HID device. The HID parser bounds report_size
only to <= 256, so a broken HID device can supply a report descriptor
with a wide field that triggers shift exponents up to 256 on a 32-bit
type when an output report is built via hid_output_field() or
hid_set_field().
Commit ec61b41918587 ("HID: core: fix shift-out-of-bounds in
hid_report_raw_event") added the same n > 32 clamp to the function
snto32(), but s32ton() was never given the same fix as I guess syzbot
hadn't figured out how to fuzz a device the same way.
Fix this up by just clamping the max value of n, just like snto32()
does.
Cc: stable <stable@kernel.org>
Cc: Jiri Kosina <jikos@kernel.org>
Cc: Benjamin Tissoires <bentiss@kernel.org>
Cc: linux-input@vger.kernel.org
Assisted-by: gregkh_clanker_t1000
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/hid/hid-core.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -71,6 +71,9 @@ static u32 s32ton(__s32 value, unsigned
if (!value || !n)
return 0;
+ if (n > 32)
+ n = 32;
+
a = value >> (n - 1);
if (a && a != -1)
return value < 0 ? 1 << (n - 1) : (1 << (n - 1)) - 1;
^ permalink raw reply
* [PATCH 6.18 126/198] HID: alps: fix NULL pointer dereference in alps_raw_event()
From: Greg Kroah-Hartman @ 2026-04-20 15:41 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, stable, Jiri Kosina,
Benjamin Tissoires, Masaki Ota, linux-input, Jiri Kosina
In-Reply-To: <20260420153935.605963767@linuxfoundation.org>
6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1badfc4319224820d5d890f8eab6aa52e4e83339 upstream.
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>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/hid/hid-alps.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/hid/hid-alps.c
+++ b/drivers/hid/hid-alps.c
@@ -437,6 +437,9 @@ static int alps_raw_event(struct hid_dev
int ret = 0;
struct alps_dev *hdata = hid_get_drvdata(hdev);
+ if (!(hdev->claimed & HID_CLAIMED_INPUT) || !hdata->input)
+ return 0;
+
switch (hdev->product) {
case HID_PRODUCT_ID_T4_BTNLESS:
ret = t4_raw_event(hdata, data, size);
^ permalink raw reply
* [PATCH 6.19 145/220] HID: core: clamp report_size in s32ton() to avoid undefined shift
From: Greg Kroah-Hartman @ 2026-04-20 15:41 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, stable, Jiri Kosina,
Benjamin Tissoires, linux-input, Jiri Kosina
In-Reply-To: <20260420153934.013228280@linuxfoundation.org>
6.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 69c02ffde6ed4d535fa4e693a9e572729cad3d0d upstream.
s32ton() shifts by n-1 where n is the field's report_size, a value that
comes directly from a HID device. The HID parser bounds report_size
only to <= 256, so a broken HID device can supply a report descriptor
with a wide field that triggers shift exponents up to 256 on a 32-bit
type when an output report is built via hid_output_field() or
hid_set_field().
Commit ec61b41918587 ("HID: core: fix shift-out-of-bounds in
hid_report_raw_event") added the same n > 32 clamp to the function
snto32(), but s32ton() was never given the same fix as I guess syzbot
hadn't figured out how to fuzz a device the same way.
Fix this up by just clamping the max value of n, just like snto32()
does.
Cc: stable <stable@kernel.org>
Cc: Jiri Kosina <jikos@kernel.org>
Cc: Benjamin Tissoires <bentiss@kernel.org>
Cc: linux-input@vger.kernel.org
Assisted-by: gregkh_clanker_t1000
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/hid/hid-core.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -71,6 +71,9 @@ static u32 s32ton(__s32 value, unsigned
if (!value || !n)
return 0;
+ if (n > 32)
+ n = 32;
+
a = value >> (n - 1);
if (a && a != -1)
return value < 0 ? 1 << (n - 1) : (1 << (n - 1)) - 1;
^ permalink raw reply
* [PATCH 6.19 144/220] HID: alps: fix NULL pointer dereference in alps_raw_event()
From: Greg Kroah-Hartman @ 2026-04-20 15:41 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, stable, Jiri Kosina,
Benjamin Tissoires, Masaki Ota, linux-input, Jiri Kosina
In-Reply-To: <20260420153934.013228280@linuxfoundation.org>
6.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1badfc4319224820d5d890f8eab6aa52e4e83339 upstream.
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>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/hid/hid-alps.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/hid/hid-alps.c
+++ b/drivers/hid/hid-alps.c
@@ -437,6 +437,9 @@ static int alps_raw_event(struct hid_dev
int ret = 0;
struct alps_dev *hdata = hid_get_drvdata(hdev);
+ if (!(hdev->claimed & HID_CLAIMED_INPUT) || !hdata->input)
+ return 0;
+
switch (hdev->product) {
case HID_PRODUCT_ID_T4_BTNLESS:
ret = t4_raw_event(hdata, data, size);
^ permalink raw reply
* Re: [PATCH v2] iio: orientation: hid-sensor-rotation: use ext_scan_type
From: srinivas pandruvada @ 2026-04-20 15:45 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner, Lixu Zhang
Cc: Jiri Kosina, Nuno Sá, Andy Shevchenko, linux-input,
linux-iio, linux-kernel
In-Reply-To: <20260412152643.68c8f065@jic23-huawei>
+Lixu
On Sun, 2026-04-12 at 15:26 +0100, Jonathan Cameron wrote:
> On Sun, 01 Mar 2026 17:46:48 -0600
> David Lechner <dlechner@baylibre.com> wrote:
>
> > Make use of ext_scan_type to handle the dynamic realbits size of
> > the
> > quaternion data. This lets us implement it using static data rather
> > than
> > having to duplicate the channel info for each driver instance.
> >
> > Signed-off-by: David Lechner <dlechner@baylibre.com>
> > ---
> I'm going to apply this now, but would welcome any additional
> feedback
> from Srinivas or others.
>
> Note, given this is next cycle material now I'll only push the tree
> out
> as testing until I can rebase on rc1.
>
In real world I think report size is always 16 copying from spec.
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Thanks,
Srinivas
> Thanks,
>
> Jonathan
>
> > This is something I noticed we could do while looking at an
> > unrelated
> > bug. I've tested this using the same script from [1] and confirmed
> > that
> > that the scan type didn't change. Before and after are both:
> >
> > $ cat in_rot_quaternion_type
> > le:s16/32X4>>0
> >
> > [1]:
> > https://lore.kernel.org/linux-iio/20260301-iio-fix-timestamp-alignment-v1-1-1a54980bfb90@baylibre.com/
> > ---
> > Changes in v2:
> > - Dropped DEV_ROT_SCAN_TYPE_8BIT.
> > - Tested using /dev/uhid.
> > - Link to v1:
> > https://lore.kernel.org/r/20260214-iio-hid-sensor-rotation-cleanup-v1-1-3aec9a533c0f@baylibre.com
> > ---
> > drivers/iio/orientation/hid-sensor-rotation.c | 71
> > ++++++++++++++++-----------
> > 1 file changed, 43 insertions(+), 28 deletions(-)
> >
> > diff --git a/drivers/iio/orientation/hid-sensor-rotation.c
> > b/drivers/iio/orientation/hid-sensor-rotation.c
> > index e759f91a710a..3cfd0b323514 100644
> > --- a/drivers/iio/orientation/hid-sensor-rotation.c
> > +++ b/drivers/iio/orientation/hid-sensor-rotation.c
> > @@ -34,6 +34,27 @@ static const u32
> > rotation_sensitivity_addresses[] = {
> > HID_USAGE_SENSOR_ORIENT_QUATERNION,
> > };
> >
> > +enum {
> > + DEV_ROT_SCAN_TYPE_16BIT,
> > + DEV_ROT_SCAN_TYPE_32BIT,
> > +};
> > +
> > +static const struct iio_scan_type dev_rot_scan_types[] = {
> > + [DEV_ROT_SCAN_TYPE_16BIT] = {
> > + .sign = 's',
> > + .realbits = 16,
> > + /* Storage bits has to stay 32 to not break
> > userspace. */
> > + .storagebits = 32,
> > + .repeat = 4,
> > + },
> > + [DEV_ROT_SCAN_TYPE_32BIT] = {
> > + .sign = 's',
> > + .realbits = 32,
> > + .storagebits = 32,
> > + .repeat = 4,
> > + },
> > +};
> > +
> > /* Channel definitions */
> > static const struct iio_chan_spec dev_rot_channels[] = {
> > {
> > @@ -45,23 +66,14 @@ static const struct iio_chan_spec
> > dev_rot_channels[] = {
> > BIT(IIO_CHAN_INFO_OFFSET)
> > |
> > BIT(IIO_CHAN_INFO_SCALE) |
> > BIT(IIO_CHAN_INFO_HYSTERES
> > IS),
> > - .scan_index = 0
> > + .scan_index = 0,
> > + .has_ext_scan_type = 1,
> > + .ext_scan_type = dev_rot_scan_types,
> > + .num_ext_scan_type =
> > ARRAY_SIZE(dev_rot_scan_types),
> > },
> > IIO_CHAN_SOFT_TIMESTAMP(1)
> > };
> >
> > -/* Adjust channel real bits based on report descriptor */
> > -static void dev_rot_adjust_channel_bit_mask(struct iio_chan_spec
> > *chan,
> > - int size)
> > -{
> > - chan->scan_type.sign = 's';
> > - /* Real storage bits will change based on the report desc.
> > */
> > - chan->scan_type.realbits = size * 8;
> > - /* Maximum size of a sample to capture is u32 */
> > - chan->scan_type.storagebits = sizeof(u32) * 8;
> > - chan->scan_type.repeat = 4;
> > -}
> > -
> > /* Channel read_raw handler */
> > static int dev_rot_read_raw(struct iio_dev *indio_dev,
> > struct iio_chan_spec const *chan,
> > @@ -136,9 +148,25 @@ static int dev_rot_write_raw(struct iio_dev
> > *indio_dev,
> > return ret;
> > }
> >
> > +static int dev_rot_get_current_scan_type(const struct iio_dev
> > *indio_dev,
> > + const struct
> > iio_chan_spec *chan)
> > +{
> > + struct dev_rot_state *rot_state = iio_priv(indio_dev);
> > +
> > + switch (rot_state->quaternion.size / 4) {
> > + case sizeof(s16):
> > + return DEV_ROT_SCAN_TYPE_16BIT;
> > + case sizeof(s32):
> > + return DEV_ROT_SCAN_TYPE_32BIT;
> > + default:
> > + return -EINVAL;
> > + }
> > +}
> > +
> > static const struct iio_info dev_rot_info = {
> > .read_raw_multi = &dev_rot_read_raw,
> > .write_raw = &dev_rot_write_raw,
> > + .get_current_scan_type = &dev_rot_get_current_scan_type,
> > };
> >
> > /* Callback handler to send event after all samples are received
> > and captured */
> > @@ -196,7 +224,6 @@ static int dev_rot_capture_sample(struct
> > hid_sensor_hub_device *hsdev,
> > /* Parse report which is specific to an usage id*/
> > static int dev_rot_parse_report(struct platform_device *pdev,
> > struct hid_sensor_hub_device
> > *hsdev,
> > - struct iio_chan_spec *channels,
> > unsigned usage_id,
> > struct dev_rot_state *st)
> > {
> > @@ -210,9 +237,6 @@ static int dev_rot_parse_report(struct
> > platform_device *pdev,
> > if (ret)
> > return ret;
> >
> > - dev_rot_adjust_channel_bit_mask(&channels[0],
> > - st->quaternion.size / 4);
> > -
> > dev_dbg(&pdev->dev, "dev_rot %x:%x\n", st-
> > >quaternion.index,
> > st->quaternion.report_id);
> >
> > @@ -271,22 +295,13 @@ static int hid_dev_rot_probe(struct
> > platform_device *pdev)
> > return ret;
> > }
> >
> > - indio_dev->channels = devm_kmemdup(&pdev->dev,
> > dev_rot_channels,
> > -
> > sizeof(dev_rot_channels),
> > - GFP_KERNEL);
> > - if (!indio_dev->channels) {
> > - dev_err(&pdev->dev, "failed to duplicate
> > channels\n");
> > - return -ENOMEM;
> > - }
> > -
> > - ret = dev_rot_parse_report(pdev, hsdev,
> > - (struct iio_chan_spec
> > *)indio_dev->channels,
> > - hsdev->usage, rot_state);
> > + ret = dev_rot_parse_report(pdev, hsdev, hsdev->usage,
> > rot_state);
> > if (ret) {
> > dev_err(&pdev->dev, "failed to setup
> > attributes\n");
> > return ret;
> > }
> >
> > + indio_dev->channels = dev_rot_channels;
> > indio_dev->num_channels = ARRAY_SIZE(dev_rot_channels);
> > indio_dev->info = &dev_rot_info;
> > indio_dev->name = name;
> >
> > ---
> > base-commit: 3fa5e5702a82d259897bd7e209469bc06368bf31
> > change-id: 20260214-iio-hid-sensor-rotation-cleanup-84e8410926ef
> >
> > Best regards,
^ permalink raw reply
* Re: [PATCH v2] iio: magnetometer: hid-sensor-magn-3d: prefer 'unsigned int'
From: srinivas pandruvada @ 2026-04-20 15:46 UTC (permalink / raw)
To: Joshua Crofts, jikos, jic23
Cc: dlechner, nuno.sa, andy, linux-input, linux-iio, linux-kernel
In-Reply-To: <20260419180523.37396-1-joshua.crofts1@gmail.com>
On Sun, 2026-04-19 at 20:05 +0200, Joshua Crofts wrote:
> Use 'u32' instead of bare 'unsigned' to resolve checkpatch.pl
> warnings
> and correct type use as defined in the hid_sensor_hub_callbacks
> struct.
>
> No functional change.
>
> Signed-off-by: Joshua Crofts <joshua.crofts1@gmail.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
> ---
> v2:
> - changed 'unsigned int' to 'u32' per struct definition
>
> drivers/iio/magnetometer/hid-sensor-magn-3d.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/iio/magnetometer/hid-sensor-magn-3d.c
> b/drivers/iio/magnetometer/hid-sensor-magn-3d.c
> index c673f9323e..b01dd53eb1 100644
> --- a/drivers/iio/magnetometer/hid-sensor-magn-3d.c
> +++ b/drivers/iio/magnetometer/hid-sensor-magn-3d.c
> @@ -280,7 +280,7 @@ static const struct iio_info magn_3d_info = {
>
> /* Callback handler to send event after all samples are received and
> captured */
> static int magn_3d_proc_event(struct hid_sensor_hub_device *hsdev,
> - unsigned usage_id,
> + u32 usage_id,
> void *priv)
> {
> struct iio_dev *indio_dev = platform_get_drvdata(priv);
> @@ -302,7 +302,7 @@ static int magn_3d_proc_event(struct
> hid_sensor_hub_device *hsdev,
>
> /* Capture samples in local storage */
> static int magn_3d_capture_sample(struct hid_sensor_hub_device
> *hsdev,
> - unsigned usage_id,
> + u32 usage_id,
> size_t raw_len, char *raw_data,
> void *priv)
> {
> @@ -350,7 +350,7 @@ static int magn_3d_parse_report(struct
> platform_device *pdev,
> struct hid_sensor_hub_device *hsdev,
> struct iio_chan_spec **channels,
> int *chan_count,
> - unsigned usage_id,
> + u32 usage_id,
> struct magn_3d_state *st)
> {
> int i;
^ permalink raw reply
* [PATCH 7.0 07/76] HID: core: clamp report_size in s32ton() to avoid undefined shift
From: Greg Kroah-Hartman @ 2026-04-20 15:41 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, stable, Jiri Kosina,
Benjamin Tissoires, linux-input, Jiri Kosina
In-Reply-To: <20260420153910.810034134@linuxfoundation.org>
7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 69c02ffde6ed4d535fa4e693a9e572729cad3d0d upstream.
s32ton() shifts by n-1 where n is the field's report_size, a value that
comes directly from a HID device. The HID parser bounds report_size
only to <= 256, so a broken HID device can supply a report descriptor
with a wide field that triggers shift exponents up to 256 on a 32-bit
type when an output report is built via hid_output_field() or
hid_set_field().
Commit ec61b41918587 ("HID: core: fix shift-out-of-bounds in
hid_report_raw_event") added the same n > 32 clamp to the function
snto32(), but s32ton() was never given the same fix as I guess syzbot
hadn't figured out how to fuzz a device the same way.
Fix this up by just clamping the max value of n, just like snto32()
does.
Cc: stable <stable@kernel.org>
Cc: Jiri Kosina <jikos@kernel.org>
Cc: Benjamin Tissoires <bentiss@kernel.org>
Cc: linux-input@vger.kernel.org
Assisted-by: gregkh_clanker_t1000
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/hid/hid-core.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -71,6 +71,9 @@ static u32 s32ton(__s32 value, unsigned
if (!value || !n)
return 0;
+ if (n > 32)
+ n = 32;
+
a = value >> (n - 1);
if (a && a != -1)
return value < 0 ? 1 << (n - 1) : (1 << (n - 1)) - 1;
^ permalink raw reply
* [PATCH 7.0 06/76] HID: alps: fix NULL pointer dereference in alps_raw_event()
From: Greg Kroah-Hartman @ 2026-04-20 15:41 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, stable, Jiri Kosina,
Benjamin Tissoires, Masaki Ota, linux-input, Jiri Kosina
In-Reply-To: <20260420153910.810034134@linuxfoundation.org>
7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1badfc4319224820d5d890f8eab6aa52e4e83339 upstream.
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>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/hid/hid-alps.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/hid/hid-alps.c
+++ b/drivers/hid/hid-alps.c
@@ -437,6 +437,9 @@ static int alps_raw_event(struct hid_dev
int ret = 0;
struct alps_dev *hdata = hid_get_drvdata(hdev);
+ if (!(hdev->claimed & HID_CLAIMED_INPUT) || !hdata->input)
+ return 0;
+
switch (hdev->product) {
case HID_PRODUCT_ID_T4_BTNLESS:
ret = t4_raw_event(hdata, data, size);
^ permalink raw reply
* Re: [PATCH v5 4/4] Input: charlieplex_keypad: add GPIO charlieplex keypad
From: Hugo Villeneuve @ 2026-04-20 15:01 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: robin, andy, geert, robh, krzk+dt, conor+dt, hvilleneuve,
mkorpershoek, matthias.bgg, angelogioacchino.delregno, lee,
alexander.sverdlin, marek.vasut, akurz, devicetree, linux-kernel,
linux-input, linux-arm-kernel, linux-mediatek
In-Reply-To: <aeWtDA7snjJmiF9K@google.com>
Hi Dmitry,
On Sun, 19 Apr 2026 21:47:40 -0700
Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
> Hi Hugo,
>
> On Thu, Mar 12, 2026 at 02:00:58PM -0400, Hugo Villeneuve wrote:
> > +
> > +static void charlieplex_keypad_report_key(struct input_dev *input)
> > +{
> > + struct charlieplex_keypad *keypad = input_get_drvdata(input);
> > + const unsigned short *keycodes = input->keycode;
> > +
> > + if (keypad->current_code > 0) {
> > + input_event(input, EV_MSC, MSC_SCAN, keypad->current_code);
> > + input_report_key(input, keycodes[keypad->current_code], 0);
>
> This needs input_sync() as otherwise userspace is free to only recognize
> the last MSC_SCAN event.
Ok, now I get it, my code would have been be working only if it was an
if/else.
>
> > + }
> > +
> > + if (keypad->debounce_code) {
> > + input_event(input, EV_MSC, MSC_SCAN, keypad->debounce_code);
> > + input_report_key(input, keycodes[keypad->debounce_code], 1);
> > + }
> > +
> > + input_sync(input);
> > + keypad->current_code = keypad->debounce_code;
> > +}
> > +
> > +static void charlieplex_keypad_check_switch_change(struct input_dev *input,
> > + int code)
> > +{
> > + struct charlieplex_keypad *keypad = input_get_drvdata(input);
> > +
> > + if (code != keypad->debounce_code) {
> > + keypad->debounce_count = 0;
> > + keypad->debounce_code = code;
> > + } else if (keypad->debounce_count < keypad->debounce_threshold) {
>
> This does not work if debouncing is disabled (debounce threshold is 0).
Yes.
>
> > + keypad->debounce_count++;
> > +
> > + if (keypad->debounce_count >= keypad->debounce_threshold &&
> > + keypad->debounce_code != keypad->current_code)
> > + charlieplex_keypad_report_key(input);
> > + }
> > +}
> > +
> > +static void charlieplex_keypad_poll(struct input_dev *input)
> > +{
> > + struct charlieplex_keypad *keypad = input_get_drvdata(input);
> > + int code;
> > +
> > + code = 0;
> > + for (unsigned int oline = 0; oline < keypad->nlines; oline++) {
> > + DECLARE_BITMAP(values, MATRIX_MAX_ROWS);
> > + int err;
> > +
> > + /* Activate only one line as output at a time. */
> > + gpiod_direction_output(keypad->line_gpios->desc[oline], 1);
> > +
> > + if (keypad->settling_time_us)
> > + fsleep(keypad->settling_time_us);
> > +
> > + /* Read input on all other lines. */
> > + err = gpiod_get_array_value_cansleep(keypad->line_gpios->ndescs,
> > + keypad->line_gpios->desc,
> > + keypad->line_gpios->info, values);
> > + if (err)
> > + return;
>
> We need to deactivate the line on error too.
Yer, good catch.
>
> > +
> > + for (unsigned int iline = 0; iline < keypad->nlines; iline++) {
> > + if (iline == oline)
> > + continue; /* Do not read active output line. */
> > +
> > + /* Check if GPIO is asserted. */
> > + if (test_bit(iline, values)) {
> > + code = MATRIX_SCAN_CODE(oline, iline,
> > + get_count_order(keypad->nlines));
> > + /*
> > + * Exit loop immediately since we cannot detect
> > + * more than one key press at a time.
> > + */
> > + break;
> > + }
> > + }
> > +
> > + gpiod_direction_input(keypad->line_gpios->desc[oline]);
> > +
> > + if (code)
> > + break;
> > + }
> > +
> > + charlieplex_keypad_check_switch_change(input, code);
> > +}
> > +
> > +static int charlieplex_keypad_init_gpio(struct platform_device *pdev,
> > + struct charlieplex_keypad *keypad)
> > +{
> > + char **pin_names;
> > + char label[32];
> > +
> > + snprintf(label, sizeof(label), "%s-pin", pdev->name);
> > +
> > + keypad->line_gpios = devm_gpiod_get_array(&pdev->dev, "line", GPIOD_IN);
> > + if (IS_ERR(keypad->line_gpios))
> > + return PTR_ERR(keypad->line_gpios);
> > +
> > + keypad->nlines = keypad->line_gpios->ndescs;
> > +
> > + if (keypad->nlines > MATRIX_MAX_ROWS)
> > + return -EINVAL;
> > +
> > + pin_names = devm_kasprintf_strarray(&pdev->dev, label, keypad->nlines);
> > + if (IS_ERR(pin_names))
> > + return PTR_ERR(pin_names);
> > +
> > + for (unsigned int i = 0; i < keypad->line_gpios->ndescs; i++)
> > + gpiod_set_consumer_name(keypad->line_gpios->desc[i], pin_names[i]);
> > +
> > + return 0;
> > +}
> > +
> > +static int charlieplex_keypad_probe(struct platform_device *pdev)
> > +{
> > + struct charlieplex_keypad *keypad;
> > + unsigned int debounce_interval_ms;
> > + unsigned int poll_interval_ms;
> > + struct input_dev *input_dev;
> > + int err;
> > +
> > + keypad = devm_kzalloc(&pdev->dev, sizeof(*keypad), GFP_KERNEL);
> > + if (!keypad)
> > + return -ENOMEM;
> > +
> > + input_dev = devm_input_allocate_device(&pdev->dev);
> > + if (!input_dev)
> > + return -ENOMEM;
> > +
> > + keypad->input_dev = input_dev;
> > +
> > + device_property_read_u32(&pdev->dev, "poll-interval", &poll_interval_ms);
> > + device_property_read_u32(&pdev->dev, "debounce-delay-ms", &debounce_interval_ms);
> > + device_property_read_u32(&pdev->dev, "settling-time-us", &keypad->settling_time_us);
>
> Not all of these are required properties. If they are missing the driver
> will operate on garbage values.
Yes.
>
> > +
> > + keypad->current_code = -1;
> > + keypad->debounce_code = -1;
> > + keypad->debounce_threshold = DIV_ROUND_UP(debounce_interval_ms, poll_interval_ms);
>
> This will bomb if poll interval is 0.
Yes.
>
> > +
> > + err = charlieplex_keypad_init_gpio(pdev, keypad);
> > + if (err)
> > + return err;
> > +
> > + input_dev->name = pdev->name;
> > + input_dev->id.bustype = BUS_HOST;
> > +
> > + err = matrix_keypad_build_keymap(NULL, NULL, keypad->nlines,
> > + keypad->nlines, NULL, input_dev);
> > + if (err)
> > + dev_err_probe(&pdev->dev, -ENOMEM, "failed to build keymap\n");
>
> Missing "return".
>
> > +
> > + if (device_property_read_bool(&pdev->dev, "autorepeat"))
> > + __set_bit(EV_REP, input_dev->evbit);
> > +
> > + input_set_capability(input_dev, EV_MSC, MSC_SCAN);
> > +
> > + err = input_setup_polling(input_dev, charlieplex_keypad_poll);
> > + if (err)
> > + dev_err_probe(&pdev->dev, err, "unable to set up polling\n");
>
> Missing "return".
Ok for both.
> I fixed it up and applied, please take a look in my 'next' branch and
> tell me if I messed up.
Thank you for the review and the fixes.
I tested it on the real hardware and all is good.
So I imagine that it can still go into 7.1 since it is a new driver
and not a modification of an existing one?
--
Hugo Villeneuve
^ permalink raw reply
* [dtor-input:next] BUILD SUCCESS 2ca45e57ea027fffe3350ae5e21ad9cecb0dce74
From: kernel test robot @ 2026-04-20 14:06 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git next
branch HEAD: 2ca45e57ea027fffe3350ae5e21ad9cecb0dce74 Input: charlieplex_keypad - add GPIO charlieplex keypad
elapsed time: 723m
configs tested: 150
configs skipped: 13
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-15.2.0
alpha allyesconfig gcc-15.2.0
alpha defconfig gcc-15.2.0
arc allmodconfig gcc-15.2.0
arc allnoconfig gcc-15.2.0
arc allyesconfig gcc-15.2.0
arc defconfig gcc-15.2.0
arc randconfig-001-20260420 gcc-8.5.0
arc randconfig-002-20260420 gcc-14.3.0
arm allnoconfig clang-23
arm allyesconfig gcc-15.2.0
arm defconfig clang-23
arm randconfig-001-20260420 gcc-8.5.0
arm randconfig-002-20260420 gcc-12.5.0
arm randconfig-003-20260420 clang-23
arm randconfig-004-20260420 clang-23
arm64 allmodconfig clang-19
arm64 allnoconfig gcc-15.2.0
arm64 defconfig gcc-15.2.0
arm64 randconfig-001-20260420 clang-23
arm64 randconfig-002-20260420 clang-23
arm64 randconfig-003-20260420 gcc-8.5.0
arm64 randconfig-004-20260420 gcc-15.2.0
csky allmodconfig gcc-15.2.0
csky allnoconfig gcc-15.2.0
csky defconfig gcc-15.2.0
csky randconfig-001-20260420 gcc-9.5.0
csky randconfig-002-20260420 gcc-10.5.0
hexagon allmodconfig clang-17
hexagon allnoconfig clang-23
hexagon defconfig clang-23
hexagon randconfig-001-20260420 clang-20
hexagon randconfig-002-20260420 clang-23
i386 allmodconfig gcc-14
i386 allnoconfig gcc-14
i386 allyesconfig gcc-14
i386 buildonly-randconfig-001-20260420 clang-20
i386 buildonly-randconfig-002-20260420 gcc-14
i386 buildonly-randconfig-003-20260420 clang-20
i386 buildonly-randconfig-004-20260420 clang-20
i386 buildonly-randconfig-005-20260420 gcc-14
i386 buildonly-randconfig-006-20260420 gcc-14
i386 defconfig clang-20
i386 randconfig-011-20260420 clang-20
i386 randconfig-012-20260420 gcc-14
i386 randconfig-013-20260420 gcc-14
i386 randconfig-014-20260420 clang-20
i386 randconfig-015-20260420 clang-20
i386 randconfig-016-20260420 gcc-14
i386 randconfig-017-20260420 clang-20
loongarch allmodconfig clang-19
loongarch allnoconfig clang-23
loongarch randconfig-001-20260420 gcc-15.2.0
loongarch randconfig-002-20260420 clang-18
m68k allmodconfig gcc-15.2.0
m68k allnoconfig gcc-15.2.0
m68k allyesconfig gcc-15.2.0
microblaze allnoconfig gcc-15.2.0
microblaze allyesconfig gcc-15.2.0
mips allmodconfig gcc-15.2.0
mips allnoconfig gcc-15.2.0
mips allyesconfig gcc-15.2.0
nios2 allmodconfig gcc-11.5.0
nios2 allnoconfig gcc-11.5.0
nios2 randconfig-001-20260420 gcc-8.5.0
nios2 randconfig-002-20260420 gcc-8.5.0
openrisc allmodconfig gcc-15.2.0
openrisc allnoconfig gcc-15.2.0
openrisc defconfig gcc-15.2.0
parisc alldefconfig gcc-15.2.0
parisc allmodconfig gcc-15.2.0
parisc allnoconfig gcc-15.2.0
parisc allyesconfig gcc-15.2.0
parisc defconfig gcc-15.2.0
parisc randconfig-001-20260420 gcc-11.5.0
parisc randconfig-002-20260420 gcc-8.5.0
powerpc allmodconfig gcc-15.2.0
powerpc allnoconfig gcc-15.2.0
powerpc randconfig-001-20260420 gcc-8.5.0
powerpc randconfig-002-20260420 clang-16
powerpc64 randconfig-001-20260420 clang-19
powerpc64 randconfig-002-20260420 clang-18
riscv allmodconfig clang-23
riscv allnoconfig gcc-15.2.0
riscv allyesconfig clang-16
riscv defconfig clang-23
riscv randconfig-001-20260420 gcc-14.3.0
riscv randconfig-002-20260420 gcc-9.5.0
s390 allmodconfig clang-18
s390 allnoconfig clang-23
s390 allyesconfig gcc-15.2.0
s390 defconfig clang-23
s390 randconfig-001-20260420 clang-23
s390 randconfig-002-20260420 gcc-11.5.0
sh allmodconfig gcc-15.2.0
sh allnoconfig gcc-15.2.0
sh allyesconfig gcc-15.2.0
sh defconfig gcc-15.2.0
sh randconfig-001-20260420 gcc-14.3.0
sh randconfig-002-20260420 gcc-11.5.0
sparc allnoconfig gcc-15.2.0
sparc defconfig gcc-15.2.0
sparc randconfig-001-20260420 gcc-15.2.0
sparc randconfig-002-20260420 gcc-8.5.0
sparc sparc64_defconfig gcc-15.2.0
sparc64 allmodconfig clang-23
sparc64 defconfig clang-20
sparc64 randconfig-001-20260420 gcc-9.5.0
sparc64 randconfig-002-20260420 clang-23
um allmodconfig clang-19
um allnoconfig clang-23
um allyesconfig gcc-14
um defconfig clang-23
um i386_defconfig gcc-14
um randconfig-001-20260420 clang-23
um randconfig-002-20260420 gcc-14
um x86_64_defconfig clang-23
x86_64 allmodconfig clang-20
x86_64 allnoconfig clang-20
x86_64 allyesconfig clang-20
x86_64 buildonly-randconfig-001-20260420 gcc-14
x86_64 buildonly-randconfig-002-20260420 clang-20
x86_64 buildonly-randconfig-003-20260420 gcc-14
x86_64 buildonly-randconfig-004-20260420 gcc-14
x86_64 buildonly-randconfig-005-20260420 gcc-14
x86_64 buildonly-randconfig-006-20260420 gcc-14
x86_64 defconfig gcc-14
x86_64 randconfig-001-20260420 clang-20
x86_64 randconfig-002-20260420 clang-20
x86_64 randconfig-003-20260420 gcc-13
x86_64 randconfig-004-20260420 gcc-14
x86_64 randconfig-005-20260420 clang-20
x86_64 randconfig-006-20260420 gcc-14
x86_64 randconfig-011-20260420 gcc-14
x86_64 randconfig-012-20260420 gcc-14
x86_64 randconfig-013-20260420 clang-20
x86_64 randconfig-014-20260420 gcc-14
x86_64 randconfig-015-20260420 clang-20
x86_64 randconfig-016-20260420 clang-20
x86_64 randconfig-071-20260420 gcc-14
x86_64 randconfig-072-20260420 gcc-14
x86_64 randconfig-073-20260420 gcc-14
x86_64 randconfig-074-20260420 gcc-14
x86_64 randconfig-075-20260420 clang-20
x86_64 randconfig-076-20260420 gcc-12
x86_64 rhel-9.4-rust clang-20
xtensa allnoconfig gcc-15.2.0
xtensa allyesconfig gcc-15.2.0
xtensa randconfig-001-20260420 gcc-11.5.0
xtensa randconfig-002-20260420 gcc-9.5.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: input: Add PixArt PAJ7620 gesture sensor
From: Krzysztof Kozlowski @ 2026-04-20 13:59 UTC (permalink / raw)
To: Harpreet Saini
Cc: Rob Herring, linux-input, devicetree, linux-kernel,
Dmitry Torokhov, Krzysztof Kozlowski, Conor Dooley
In-Reply-To: <20260418062241.104697-2-sainiharpreet29@yahoo.com>
On Sat, Apr 18, 2026 at 02:22:32AM -0400, Harpreet Saini wrote:
> The binding include mandatory power supplies (vdd, vbus, vled)
Drop this part
> and optional GPIO controller properties to describe the hardware's
> ability to repurpose SPI pins opeating in I2C mode.
And just explain what is the purpose of GPIO controller - is this a GPIO
controller?
Plus language typo, run spell check.
>
> Signed-off-by: Harpreet Saini <sainiharpreet29@yahoo.com>
> ---
> .../bindings/input/pixart,paj7620.yaml | 79 +++++++++++++++++++
> .../devicetree/bindings/vendor-prefixes.yaml | 2 +
> 2 files changed, 81 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/input/pixart,paj7620.yaml
>
> diff --git a/Documentation/devicetree/bindings/input/pixart,paj7620.yaml b/Documentation/devicetree/bindings/input/pixart,paj7620.yaml
> new file mode 100644
> index 000000000000..ad051cf641a6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/pixart,paj7620.yaml
> @@ -0,0 +1,79 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/input/pixart,paj7620.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: PixArt PAJ7620 Gesture Sensor
> +
> +maintainers:
> + - Harpreet Saini <sainiharpreet29@yahoo.com>
> +
> +description: |
Do not need '|' unless you need to preserve formatting.
> + The PixArt PAJ7620 is a gesture recognition sensor with an integrated
> + infrared LED and CMOS array. It communicates over an I2C interface and
> + provides gesture data via a dedicated interrupt pin.
> +
> +properties:
> + compatible:
> + const: pixart,paj7620
> +
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + maxItems: 1
> +
> + vdd-supply:
> + description: Main power supply.
> +
> + vbus-supply:
> + description: I/O and I2C bus power supply.
> +
> + vled-supply:
> + description: Power for the integrated IR LED.
> +
> + linux,keycodes:
> + minItems: 9
> + maxItems: 9
> + description: |
Do not need '|' unless you need to preserve formatting.
> + List of keycodes mapping to the 9 supported gestures.
> +
> + gpio-controller: true
> +
> + "#gpio-cells":
> + const: 2
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - vdd-supply
> + - vbus-supply
> + - vled-supply
> +
Missing allOf: with $ref to input.yaml schema. You use its properties.
Commit description said SPI, so missing ref to spi-peripheral-props.
> +additionalProperties: false
And this should be then unevaluatedProperties: false.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH AUTOSEL 6.18] HID: quirks: add HID_QUIRK_ALWAYS_POLL for 8BitDo Pro 3
From: Sasha Levin @ 2026-04-20 13:22 UTC (permalink / raw)
To: patches, stable
Cc: leo vriska, Jiri Kosina, Sasha Levin, jikos, bentiss, linux-input,
linux-kernel
In-Reply-To: <20260420132314.1023554-1-sashal@kernel.org>
From: leo vriska <leo@60228.dev>
[ Upstream commit 532743944324a873bbaf8620fcabcd0e69e30c36 ]
According to a mailing list report [1], this controller's predecessor
has the same issue. However, it uses the xpad driver instead of HID, so
this quirk wouldn't apply.
[1]: https://lore.kernel.org/linux-input/unufo3$det$1@ciao.gmane.io/
Signed-off-by: leo vriska <leo@60228.dev>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
Error: Failed to generate final synthesis
drivers/hid/hid-ids.h | 3 +++
drivers/hid/hid-quirks.c | 1 +
2 files changed, 4 insertions(+)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index d9d354f1b8847..a245928933454 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -22,6 +22,9 @@
#define USB_DEVICE_ID_3M2256 0x0502
#define USB_DEVICE_ID_3M3266 0x0506
+#define USB_VENDOR_ID_8BITDO 0x2dc8
+#define USB_DEVICE_ID_8BITDO_PRO_3 0x6009
+
#define USB_VENDOR_ID_A4TECH 0x09da
#define USB_DEVICE_ID_A4TECH_WCP32PU 0x0006
#define USB_DEVICE_ID_A4TECH_X5_005D 0x000a
diff --git a/drivers/hid/hid-quirks.c b/drivers/hid/hid-quirks.c
index 3217e436c052c..f6be3ffee0232 100644
--- a/drivers/hid/hid-quirks.c
+++ b/drivers/hid/hid-quirks.c
@@ -25,6 +25,7 @@
*/
static const struct hid_device_id hid_quirks[] = {
+ { HID_USB_DEVICE(USB_VENDOR_ID_8BITDO, USB_DEVICE_ID_8BITDO_PRO_3), HID_QUIRK_ALWAYS_POLL },
{ HID_USB_DEVICE(USB_VENDOR_ID_AASHIMA, USB_DEVICE_ID_AASHIMA_GAMEPAD), HID_QUIRK_BADPAD },
{ HID_USB_DEVICE(USB_VENDOR_ID_AASHIMA, USB_DEVICE_ID_AASHIMA_PREDATOR), HID_QUIRK_BADPAD },
{ HID_USB_DEVICE(USB_VENDOR_ID_ADATA_XPG, USB_VENDOR_ID_ADATA_XPG_WL_GAMING_MOUSE), HID_QUIRK_ALWAYS_POLL },
--
2.53.0
^ permalink raw reply related
* [PATCH AUTOSEL 7.0-6.6] HID: playstation: validate num_touch_reports in DualShock 4 reports
From: Sasha Levin @ 2026-04-20 13:21 UTC (permalink / raw)
To: patches, stable
Cc: Benoît Sevens, Jiri Kosina, Sasha Levin,
roderick.colenbrander, jikos, bentiss, linux-input, linux-kernel
In-Reply-To: <20260420132314.1023554-1-sashal@kernel.org>
From: Benoît Sevens <bsevens@google.com>
[ Upstream commit 82a4fc46330910b4c1d9b189561439d468e3ff11 ]
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ît Sevens <bsevens@google.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
Now I have enough information to make my analysis. Let me compile the
complete assessment.
## PHASE 1: COMMIT MESSAGE FORENSICS
**Step 1.1: Subject line parse**
Record: `[HID: playstation:]` `[validate]` - validates
`num_touch_reports` in DualShock 4 USB and Bluetooth input reports to
prevent out-of-bounds reads from malicious HID devices.
**Step 1.2: Commit message tags**
Record:
- `Signed-off-by: Benoît Sevens <bsevens@google.com>` - author from
Google (security researcher who has found and fixed multiple HID/USB
vulnerabilities)
- `Signed-off-by: Jiri Kosina <jkosina@suse.com>` - HID subsystem
maintainer applied it
- **No** `Fixes:`, `Reported-by:`, `Reviewed-by:`, `Tested-by:`,
`Link:`, or `Cc: stable` tags (expected absence of stable tag - that's
why review is needed)
**Step 1.3: Commit body analysis**
Record: The commit explicitly describes a security vulnerability: a
malicious HID device can set `num_touch_reports` in the input report
payload to an arbitrary u8 value (0-255). Since the `touch_reports[]`
arrays are fixed at size 3 (USB) and 4 (Bluetooth), values >3/4 cause
out-of-bounds reads in `dualshock4_parse_report()`, leading to **kernel
memory disclosure**. Root cause: missing bounds check on device-supplied
count.
**Step 1.4: Hidden bug fix detection**
Record: Not hidden - the commit is explicitly a security fix. The
language "validate" + "malicious device" + "kernel memory disclosure" +
"out-of-bounds read" is textbook security fix vocabulary.
## PHASE 2: DIFF ANALYSIS
**Step 2.1: Inventory**
Record: 1 file (`drivers/hid/hid-playstation.c`), 12 lines added, 0
removed. Modifies one function: `dualshock4_parse_report()`.
Classification: single-file surgical fix.
**Step 2.2: Code flow change**
Record:
- Before: Code blindly trusted `usb->num_touch_reports` and
`bt->num_touch_reports` from device, used them as loop bound for
`touch_reports[]` array access at line 2482.
- After: Validates both fields against `ARRAY_SIZE(touch_reports)`
before use; returns `-EINVAL` with `hid_err()` log on bogus values.
**Step 2.3: Bug mechanism**
Record: Category (f) memory safety / bounds check fix. The
`num_touch_reports` is a u8 field in the HID report, attacker-controlled
(up to 255). The later loop `for (i = 0; i < num_touch_reports; i++) {
struct dualshock4_touch_report *touch_report = &touch_reports[i]; ...}`
dereferences each `touch_report` and reads `.contact`, `.x_hi`, `.x_lo`,
`.y_hi`, `.y_lo` fields, then feeds them into `input_report_abs()`. With
`num_touch_reports=255` (u8 max) × 9 bytes per `dualshock4_touch_report`
= up to 2,295 bytes of OOB read beyond the 64-byte USB (or 78-byte BT)
report buffer. Disclosed content can potentially leak to userspace via
the resulting input events.
**Step 2.4: Fix quality**
Record: Obviously correct - `ARRAY_SIZE()` is the canonical sizeof-based
macro, the comparison is unsigned-safe, and the return path properly
propagates the error. Zero regression risk: only an early return when
invalid input is detected; valid devices (which set num_touch_reports ≤
3 or ≤ 4) are completely unaffected. No locking, memory, or API changes.
## PHASE 3: GIT HISTORY INVESTIGATION
**Step 3.1: Blame**
Record: The buggy loop `for (i = 0; i < num_touch_reports; i++)` was
introduced in commit `752038248808a` ("HID: playstation: add DualShock4
touchpad support") by Roderick Colenbrander, 2022-10-29. The BT path
(`bt->num_touch_reports = ...`) was added in `2d77474a239294` same day.
`git describe --contains 752038248808a7` returns `v6.2-rc1~115^2~2^2~11`
— so the bug landed in **v6.2**.
**Step 3.2: Fixes: tag**
Record: No Fixes: tag present. However, git blame clearly points to
`752038248808a` (v6.2) and `2d77474a239294` (v6.2) as the introducing
commits. Neither exists in pre-6.2 stable trees (5.15.y, 5.10.y, 4.19.y,
etc.).
**Step 3.3: File history**
Record: File has seen churn (cleanup commits from Cristian Ciocaltea in
2025-06: u8 migration `134a40c9d6d9b`, alignment fixes `56d7f285bfaa38`,
guard/scoped_guard refactoring `a38d070ffe338`), but none that would
significantly affect the specific hunks modified by this patch. The
`num_touch_reports` access pattern and struct layout are unchanged since
v6.2.
**Step 3.4: Author's other commits**
Record:
```
d802d848308b3 HID: roccat: fix use-after-free in roccat_report_event
2f1763f62909c HID: wacom: fix out-of-bounds read in wacom_intuos_bt_irq
082dd785e2086 media: uvcvideo: Refactor frame parsing code...
b909df18ce2a9 ALSA: usb-audio: Fix potential out-of-bound accesses for
Extigy and Mbox
ecf2b43018da9 media: uvcvideo: Skip parsing frames of type
UVC_VS_UNDEFINED
```
Record: Benoît Sevens is a Google security researcher. His HID/USB bug
fixes (e.g., wacom OOB) have been AUTOSEL'd into stable 5.10–6.19.
Strong trust indicator.
**Step 3.5: Dependencies**
Record: Standalone patch. Uses only `ARRAY_SIZE()`, `hid_err()`, and
struct fields that have existed since v6.2. No prerequisites.
## PHASE 4: MAILING LIST RESEARCH
**Step 4.1: Original submission**
Record: `b4 dig -c 82a4fc4633091` found it immediately at `https://lore.
kernel.org/all/20260323124737.3223129-1-bsevens@google.com/`. Only v1
exists — no review iterations.
**Step 4.2: Recipients**
Record: `b4 dig -w` shows To: Roderick Colenbrander (original DS4
author, Sony), Jiri Kosina (HID maintainer, jikos@kernel.org), Benjamin
Tissoires (HID co-maintainer, bentiss@kernel.org), Cc: linux-input,
linux-kernel. Maintainer-appropriate recipient list.
**Step 4.3: Discussion thread**
Record: Thread saved to `/tmp/playstation-thread.mbox`. Only one reply -
from Jiri Kosina:
> "Applied now to hid.git#for-7.0/upstream-fixes, thanks!"
Applied to the "upstream-fixes" branch, i.e., treated as a bug fix for
the current merge window, not "next". No NAK, no concerns raised. No
explicit stable nomination in the thread, but the maintainer considered
it an urgent fix (upstream-fixes branch).
**Step 4.4: Related series**
Record: Not part of a series - single standalone patch.
**Step 4.5: Stable list history**
Record: No prior stable discussion found for this specific bug. Similar
sibling fix (`HID: wacom: fix out-of-bounds read in wacom_intuos_bt_irq`
by the same author) was AUTOSEL'd to stable 5.10-6.19 per public archive
— same author, same class of fix, same quality profile.
## PHASE 5: CODE SEMANTIC ANALYSIS
**Step 5.1: Functions modified**
Record: Only `dualshock4_parse_report()`.
**Step 5.2: Callers**
Record: `dualshock4_parse_report` is assigned to `ps_dev->parse_report`
(line 2720) and called via the dongle path at line 2603 and ultimately
from `ps_raw_event` (line 2824-2825) which is the `.raw_event` callback
in `ps_driver` (line 2923). The chain is: HID core `hid_input_report()`
→ driver's `.raw_event` → `ps_raw_event` → `dualshock4_parse_report`.
This is called for **every input report** from any device matching Sony
PS4 controller USB/BT IDs.
**Step 5.3: Callees**
Record: Inside the loop, `input_mt_slot()`,
`input_mt_report_slot_state()`, `input_report_abs()` consume data read
from `touch_reports[i]`. Reading OOB does not crash directly (these are
arithmetic operations on u8 fields) but the leaked data flows as input
coordinates and touchpoint activity to userspace input event consumers.
**Step 5.4: Reachability**
Record: Triggerable by any device that enumerates with USB VID/PID or BT
identification matching `USB_VENDOR_ID_SONY` +
`USB_DEVICE_ID_SONY_PS4_CONTROLLER[_2]` (list at lines 2893-2903).
Attacker scenarios:
- Physical USB plug of a crafted device
- Bluetooth-proximate attacker masquerading as a DualShock 4
No root privileges required - kernel trusts device-reported data.
**Step 5.5: Similar patterns**
Record: Other HID drivers have similar validation patterns added
recently (wacom_intuos_bt_irq length checks, `HID: multitouch: Check to
ensure report responses match the request`). Same author has
systematically audited HID drivers for malicious-device OOB reads. This
fits the established pattern.
## PHASE 6: STABLE TREE ANALYSIS
**Step 6.1: Code presence in stable**
Record: Verified with `git cat-file -p v6.2:drivers/hid/hid-
playstation.c` through `v6.15`. All versions from v6.2 onward contain
the identical vulnerable code (`num_touch_reports` usage). `v6.1` does
NOT contain DS4 support in this file. Affected stable trees: **6.6.y,
6.12.y, 6.15.y, 6.16.y, 6.17.y and any active stable ≥ 6.2**. NOT
affected: 6.1.y, 5.15.y, 5.10.y, 4.19.y.
**Step 6.2: Backport difficulty**
Record: Minor context differences — in pre-2025 stable trees (e.g.,
v6.6), the `u32` is spelled `uint32_t` and `u8` is spelled `uint8_t`.
The actual changed lines (`if (usb->num_touch_reports >
ARRAY_SIZE(usb->touch_reports))`) use only struct field names and
`ARRAY_SIZE`, which are identical across all affected stable trees.
Expected to apply cleanly with a tiny fuzz or minor manual adjustment.
In v6.12+, structs already use `u8` so the patch applies 1:1.
**Step 6.3: Related fixes in stable**
Record: No prior fix for this specific issue in stable.
## PHASE 7: SUBSYSTEM CONTEXT
**Step 7.1: Subsystem**
Record: `drivers/hid/` - HID subsystem, specifically the generic `hid-
playstation` driver covering a widely-used gaming controller family.
IMPORTANT criticality (widely used on desktops, laptops, SteamOS/Steam
Deck, and gaming setups). Security-relevant because HID devices can be
hot-plugged by untrusted users.
**Step 7.2: Subsystem activity**
Record: Active subsystem — 69 commits to this file since initial
addition. Regular fixes and feature additions. Maintainer is responsive
(applied patch within weeks).
## PHASE 8: IMPACT AND RISK ASSESSMENT
**Step 8.1: Affected users**
Record: Anyone with `CONFIG_HID_PLAYSTATION=m/y` (common default in
distros) who connects a DualShock 4 — real or attacker-crafted. Applies
across USB and Bluetooth. Config-dependent but the config is widely
enabled.
**Step 8.2: Trigger conditions**
Record: A device that identifies as Sony PS4 controller (USB VID 0x054C
+ PID 0x05C4/0x09CC, or BT equivalent) sends a crafted input report with
`num_touch_reports > 3` (USB) or `> 4` (BT). Unprivileged attacker can
trigger via physical USB access or Bluetooth proximity + pairing. No
local privileges needed.
**Step 8.3: Severity**
Record: **HIGH severity**. Out-of-bounds read of ~2 KB of adjacent
kernel memory per malicious report. Consequences:
- Kernel memory disclosure (KASLR bypass via pointer leakage, leaking
kernel data structures, potentially credentials/secrets if mapped
nearby)
- No direct crash (no memory writes, no deref of wild pointers) but
information leak is a well-recognized security class
- Sets the stage for chained exploitation
**Step 8.4: Risk-benefit**
Record:
- BENEFIT: High - fixes an exploitable kernel information disclosure in
a widely-deployed driver
- RISK: Very low - 12 lines added, pure input validation, no behavior
change for valid devices, no locking/memory model changes, returns
-EINVAL which drops the report (graceful)
- Ratio: Strongly favors backporting.
## PHASE 9: SYNTHESIS
**Step 9.1: Evidence**
FOR:
- Explicit security fix (kernel memory disclosure) from a Google
security researcher
- Trivially correct input validation (compared with compile-time
ARRAY_SIZE)
- Zero regression risk: only drops malformed reports that already would
have led to OOB reads
- Maintainer applied to `for-7.0/upstream-fixes` (treated as fix-track,
not feature)
- Same author's sibling HID fixes (wacom OOB) have been AUTOSEL'd into
stable
- Reachable by unprivileged users via USB/BT
- Affects all stable trees ≥ 6.2
AGAINST: None material. (Lack of Cc: stable / Fixes: tag is expected and
not a negative signal per the instructions.)
UNRESOLVED: None of substance.
**Step 9.2: Stable rules check**
1. Obviously correct/tested: YES — code is trivially correct; maintainer
applied it
2. Real bug affecting users: YES — any malicious/broken HID device
triggers it
3. Important issue: YES — kernel information disclosure, security-
relevant
4. Small and contained: YES — 12 lines, single file, single function
5. No new features/APIs: YES — pure validation
6. Applies to stable: YES — minor context adjustments for uint8_t/u8 in
older trees, otherwise clean
**Step 9.3: Exception category**
Record: Security fix for existing, shipped, widely-deployed driver -
meets the "fixes a real bug" criterion directly; not needed as a special
exception.
**Step 9.4: Decision**
Backport recommended.
## Explanation
The commit fixes a real kernel information disclosure vulnerability in
the `hid-playstation` driver. A malicious USB or Bluetooth device
advertising Sony PS4 controller IDs can provide a `num_touch_reports`
value larger than the fixed `touch_reports[3]` (USB) or
`touch_reports[4]` (BT) arrays in the HID report struct. The subsequent
loop in `dualshock4_parse_report()` reads up to ~2 KB of adjacent kernel
memory and feeds it to userspace input events, leaking kernel data.
The fix is textbook stable material: 12 lines of added input validation,
zero behavioral change for legitimate devices, no locking/memory model
changes, and no new APIs. The author (Benoît Sevens, Google) has a track
record of similar HID fixes (roccat UAF, wacom OOB) where comparable
fixes have been AUTOSEL'd into stable 5.10–6.19. The HID maintainer
(Jiri Kosina) applied the patch to the upstream-fixes branch, signaling
he considers it a fix rather than a feature.
The buggy code landed in v6.2 (commits `752038248808a`,
`2d77474a239294`), so stable trees ≥ 6.2 (6.6.y, 6.12.y, etc.) are all
affected and should receive this fix. The patch should apply cleanly
with only minor context fuzz in pre-`u8` stable branches.
## Verification
- [Phase 1] Parsed tags: only SoB tags, no Reported-by/Fixes/Cc:stable.
Verified by reading commit message.
- [Phase 2] Diff analysis: verified 12 added lines in
`dualshock4_parse_report()` - two parallel `if (usb->num_touch_reports
> ARRAY_SIZE(usb->touch_reports))` / `... bt->... >
ARRAY_SIZE(bt->touch_reports)` checks with `hid_err()` + `return
-EINVAL`.
- [Phase 2] Verified struct layouts: `struct
dualshock4_input_report_usb.touch_reports[3]` (line 482), `struct
dualshock4_input_report_bt.touch_reports[4]` (line 492),
`num_touch_reports` is u8 (lines 481, 491).
- [Phase 2] Verified consumer loop at line 2482: `for (i = 0; i <
num_touch_reports; i++) { struct dualshock4_touch_report *touch_report
= &touch_reports[i]; ... }` confirms OOB read.
- [Phase 3] `git blame -L 2482,2483` confirmed buggy loop introduced by
commit `752038248808a7` (Roderick Colenbrander, 2022-10-29).
- [Phase 3] `git blame -L 2380,2396` confirmed BT path introduced by
`2d77474a239294`.
- [Phase 3] `git describe --contains 752038248808a7` =
`v6.2-rc1~115^2~2^2~11`; `2d77474a239294` = `v6.2-rc1~115^2~2^2~4` —
both are pre-v6.2 rc1, so land in v6.2.
- [Phase 3] Author commit list: `git log --author="bsevens"` shows
roccat UAF, wacom OOB, ALSA Extigy OOB - consistent security fix
pattern.
- [Phase 4] `b4 dig -c 82a4fc4633091` found submission at `https://lore.
kernel.org/all/20260323124737.3223129-1-bsevens@google.com/`.
- [Phase 4] `b4 dig -a`: only v1 - no review iterations.
- [Phase 4] `b4 dig -w`: recipients = Roderick Colenbrander (Sony), Jiri
Kosina, Benjamin Tissoires, linux-input. Appropriate.
- [Phase 4] `b4 dig -m` + read /tmp/playstation-thread.mbox: Jiri Kosina
reply confirms "Applied now to hid.git#for-7.0/upstream-fixes,
thanks!" - treated as fix.
- [Phase 4] Web search confirmed sibling `HID: wacom: fix out-of-bounds
read in wacom_intuos_bt_irq` was AUTOSEL'd to 5.10-6.19 stable.
- [Phase 5] Verified call chain: `.raw_event = ps_raw_event` (line 2923)
→ `ps_raw_event` (2819) → `dev->parse_report` (2825) assigned to
`dualshock4_parse_report` at line 2720.
- [Phase 5] Verified ID table at lines 2893-2903 (Sony PS4 USB + BT
IDs).
- [Phase 6] `git cat-file -p vX:drivers/hid/hid-playstation.c | grep
num_touch_reports` for v6.2-v6.15 each returned 6 matches — consistent
code present across all post-v6.2 trees; v6.1 returned 0 (driver path
absent).
- [Phase 6] Verified v6.6 struct definitions (uint8_t spelling) — patch
would need trivial context refit for pre-2025 stable trees but target
lines are identical.
- UNVERIFIED: Whether the raw HID buffer passed into `raw_event` in
practice is always exactly 64/78 bytes or larger (irrelevant to
decision — even at 64+7 bytes, 255 touch entries still far exceeds the
buffer, so the security impact holds).
**YES**
drivers/hid/hid-playstation.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/hid/hid-playstation.c b/drivers/hid/hid-playstation.c
index 3c0db8f93c829..c43caac20b61b 100644
--- a/drivers/hid/hid-playstation.c
+++ b/drivers/hid/hid-playstation.c
@@ -2377,6 +2377,12 @@ static int dualshock4_parse_report(struct ps_device *ps_dev, struct hid_report *
struct dualshock4_input_report_usb *usb =
(struct dualshock4_input_report_usb *)data;
+ if (usb->num_touch_reports > ARRAY_SIZE(usb->touch_reports)) {
+ hid_err(hdev, "DualShock4 USB input report has invalid num_touch_reports=%d\n",
+ usb->num_touch_reports);
+ return -EINVAL;
+ }
+
ds4_report = &usb->common;
num_touch_reports = usb->num_touch_reports;
touch_reports = usb->touch_reports;
@@ -2391,6 +2397,12 @@ static int dualshock4_parse_report(struct ps_device *ps_dev, struct hid_report *
return -EILSEQ;
}
+ if (bt->num_touch_reports > ARRAY_SIZE(bt->touch_reports)) {
+ hid_err(hdev, "DualShock4 BT input report has invalid num_touch_reports=%d\n",
+ bt->num_touch_reports);
+ return -EINVAL;
+ }
+
ds4_report = &bt->common;
num_touch_reports = bt->num_touch_reports;
touch_reports = bt->touch_reports;
--
2.53.0
^ permalink raw reply related
* [PATCH AUTOSEL 6.18] HID: Intel-thc-hid: Intel-quickspi: Add NVL Device IDs
From: Sasha Levin @ 2026-04-20 13:21 UTC (permalink / raw)
To: patches, stable
Cc: Even Xu, Jiri Kosina, Sasha Levin, xinpeng.sun, jikos, bentiss,
linux-input, linux-kernel
In-Reply-To: <20260420132314.1023554-1-sashal@kernel.org>
From: Even Xu <even.xu@intel.com>
[ Upstream commit 48e91af0cbe942d50ef6257d850accdca1d01378 ]
Add Nova Lake THC QuickSPI device IDs to support list.
Signed-off-by: Even Xu <even.xu@intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
Error: Failed to generate final synthesis
drivers/hid/intel-thc-hid/intel-quickspi/pci-quickspi.c | 6 ++++++
drivers/hid/intel-thc-hid/intel-quickspi/quickspi-dev.h | 2 ++
2 files changed, 8 insertions(+)
diff --git a/drivers/hid/intel-thc-hid/intel-quickspi/pci-quickspi.c b/drivers/hid/intel-thc-hid/intel-quickspi/pci-quickspi.c
index 14cabd5dc6ddb..f0830a56d556b 100644
--- a/drivers/hid/intel-thc-hid/intel-quickspi/pci-quickspi.c
+++ b/drivers/hid/intel-thc-hid/intel-quickspi/pci-quickspi.c
@@ -37,6 +37,10 @@ struct quickspi_driver_data arl = {
.max_packet_size_value = MAX_PACKET_SIZE_VALUE_MTL,
};
+struct quickspi_driver_data nvl = {
+ .max_packet_size_value = MAX_PACKET_SIZE_VALUE_LNL,
+};
+
/* THC QuickSPI ACPI method to get device properties */
/* HIDSPI Method: {6e2ac436-0fcf-41af-a265-b32a220dcfab} */
static guid_t hidspi_guid =
@@ -984,6 +988,8 @@ static const struct pci_device_id quickspi_pci_tbl[] = {
{PCI_DEVICE_DATA(INTEL, THC_WCL_DEVICE_ID_SPI_PORT2, &ptl), },
{PCI_DEVICE_DATA(INTEL, THC_ARL_DEVICE_ID_SPI_PORT1, &arl), },
{PCI_DEVICE_DATA(INTEL, THC_ARL_DEVICE_ID_SPI_PORT2, &arl), },
+ {PCI_DEVICE_DATA(INTEL, THC_NVL_H_DEVICE_ID_SPI_PORT1, &nvl), },
+ {PCI_DEVICE_DATA(INTEL, THC_NVL_H_DEVICE_ID_SPI_PORT2, &nvl), },
{}
};
MODULE_DEVICE_TABLE(pci, quickspi_pci_tbl);
diff --git a/drivers/hid/intel-thc-hid/intel-quickspi/quickspi-dev.h b/drivers/hid/intel-thc-hid/intel-quickspi/quickspi-dev.h
index c30e1a42eb098..bf5e18f5a5f42 100644
--- a/drivers/hid/intel-thc-hid/intel-quickspi/quickspi-dev.h
+++ b/drivers/hid/intel-thc-hid/intel-quickspi/quickspi-dev.h
@@ -23,6 +23,8 @@
#define PCI_DEVICE_ID_INTEL_THC_WCL_DEVICE_ID_SPI_PORT2 0x4D4B
#define PCI_DEVICE_ID_INTEL_THC_ARL_DEVICE_ID_SPI_PORT1 0x7749
#define PCI_DEVICE_ID_INTEL_THC_ARL_DEVICE_ID_SPI_PORT2 0x774B
+#define PCI_DEVICE_ID_INTEL_THC_NVL_H_DEVICE_ID_SPI_PORT1 0xD349
+#define PCI_DEVICE_ID_INTEL_THC_NVL_H_DEVICE_ID_SPI_PORT2 0xD34B
/* HIDSPI special ACPI parameters DSM methods */
#define ACPI_QUICKSPI_REVISION_NUM 2
--
2.53.0
^ permalink raw reply related
* [PATCH AUTOSEL 7.0-5.15] HID: quirks: Set ALWAYS_POLL for LOGITECH_BOLT_RECEIVER
From: Sasha Levin @ 2026-04-20 13:19 UTC (permalink / raw)
To: patches, stable
Cc: Nícolas F. R. A. Prado, Jiri Kosina, Sasha Levin, jikos,
bentiss, linux-input, linux-kernel
In-Reply-To: <20260420132314.1023554-1-sashal@kernel.org>
From: Nícolas F. R. A. Prado <nfraprado@collabora.com>
[ Upstream commit d4229fc0cb50c52b385538d072c5fc8827b287a9 ]
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>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
Now I have all the information needed. Let me compile the analysis.
## PHASE 1: COMMIT MESSAGE FORENSICS
**Step 1.1: Subject Line Parse**
- Subsystem prefix: `HID: quirks:`
- Action verb: "Set" (adds a quirk entry - this is effectively fixing
broken hardware behavior)
- Record: HID subsystem; adding `HID_QUIRK_ALWAYS_POLL` for the Logitech
Bolt Receiver.
**Step 1.2: All Tags**
- `Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>`
(author)
- `Signed-off-by: Jiri Kosina <jkosina@suse.com>` (HID subsystem
maintainer)
- No Fixes:, no Cc: stable, no Reported-by:, no Link: (expected — that's
why it needs review)
- Record: Applied by HID maintainer directly; concise author-maintainer
chain.
**Step 1.3: Body Analysis**
- Bug mechanism: Once a wireless device connects to the Bolt receiver,
interface 2 generates data. If not polled and the USB port is
suspended within 5 min of last wireless input, the device triggers a
remote wakeup 3 seconds later, causing a spurious system wakeup when
suspended as part of system sleep.
- Symptom: **System spontaneously wakes from suspend** when Bolt
receiver is attached.
- Author confirms testing: "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."
- Record: Real, observed, user-visible issue (spurious wake-from-
suspend); root cause clearly identified (device emits data on
interface 2 that triggers remote wakeup).
**Step 1.4: Hidden Bug Fix Detection**
- "Set ALWAYS_POLL" — this is a hardware workaround/quirk. Functionally,
it is a **bug fix** for buggy hardware behavior that breaks system
suspend for affected users.
- Record: This is a classic hardware quirk bug fix.
## PHASE 2: DIFF ANALYSIS
**Step 2.1: Inventory**
- Files: `drivers/hid/hid-quirks.c` only, +1/-0 lines.
- Functions: none — adds a single table entry to `hid_quirks[]`.
- Classification: trivial, single-file, surgical quirk table entry.
**Step 2.2: Code Flow**
- Before: device matched only by default HID logic → `usbhid_open()` and
related code treated it like any normal device (autosuspend-enabled,
sets `needs_remote_wakeup = 1`).
- After: the quirk flag makes `usbhid/hid-core.c` paths at lines 689,
752, 756, 1185, 1234 bypass autosuspend/remote wakeup logic —
`needs_remote_wakeup` stays 0 and interface 2 is always polled.
- Record: exactly the change documented in commit message.
**Step 2.3: Bug Mechanism**
- Category: (h) Hardware workaround / quirk table entry for buggy device
behavior.
- Mechanism: `HID_QUIRK_ALWAYS_POLL` is an established mechanism used by
many Logitech, Lenovo, Microsoft, Chicony mice/dongles for exactly
this kind of problem (preventing spurious wakeups / keeping endpoint
pollable). The Bolt receiver exhibits the same pattern.
**Step 2.4: Fix Quality**
- Obviously correct: trivial one-line addition to an existing quirk
table.
- Minimal and surgical: yes.
- Regression risk: essentially zero — the quirk only affects devices
matching vendor=0x046d, product=0xc548. All other devices are
untouched.
- Risk introduced by the fix itself: slight extra USB traffic for Bolt
receiver users (acknowledged by author). This is well within
acceptable for the quirk behavior that's applied to many devices
already.
## PHASE 3: GIT HISTORY INVESTIGATION
**Step 3.1: Blame**
- `USB_DEVICE_ID_LOGITECH_BOLT_RECEIVER` define added in commit
`526748b925185` ("HID: multitouch: Add quirk for Logitech Bolt
receiver w/ Casa touchpad") — first shipped in **v6.12**.
- Record: buggy hardware behavior exists since device was first
supported; device ID is present in stable 6.12.y and later.
**Step 3.2: Fixes Tag**
- No Fixes: tag (device behavior is a hardware issue, not a regression
from a specific commit). Not applicable.
**Step 3.3: File History**
- `drivers/hid/hid-quirks.c` receives quirk additions routinely (VRS
steering wheel, Cooler Master MM712, Apple keyboards,
Lenovo/Edifier/etc.). This is the normal pattern.
- Record: no prerequisite patches; standalone one-line addition.
**Step 3.4: Author**
- Author is a Collabora Mediatek/Genio/thermal/kernel developer (regular
upstream contributor). Applied by HID maintainer Jiri Kosina directly.
- Record: normal maintainer acceptance path.
**Step 3.5: Dependencies**
- Uses `USB_VENDOR_ID_LOGITECH` (long-existing) and
`USB_DEVICE_ID_LOGITECH_BOLT_RECEIVER` (added in v6.12). No other
dependencies.
- Record: applies cleanly to any stable tree ≥ 6.12. Older trees (6.6,
6.1, 5.15, 5.10, 5.4) do not have the device ID define; backport would
need the `hid-ids.h` define too — likely not worth doing given the
device ID was added in 6.12.
## PHASE 4: MAILING LIST
**Step 4.1: Original thread**
- `b4 dig -c d4229fc0cb50c` → https://lore.kernel.org/all/20260407-logi-
bolt-hid-quirk-always-poll-v1-1-4dae0fda344e@collabora.com/
- Single revision (v1). Applied as submitted.
**Step 4.2: Reviewers**
- Thread saved to mbox. Jiri Kosina (HID maintainer, `jikos@kernel.org`)
replied: "In the meantime, I am applying this one. Thanks,"
- Author proposed possible future improvement (a "poll-before-suspend
only" quirk) but Jiri didn't object to the current approach.
- Recipients: Jiri Kosina, Benjamin Tissoires, linux-
input@vger.kernel.org, linux-kernel@vger.kernel.org,
kernel@collabora.com.
- Record: patch reviewed and applied by the subsystem maintainer with no
objections; no stable nomination request was made but also no concerns
raised.
**Step 4.3: Bug Report**
- No Link: tag, but commit message and author's reply indicate this is a
directly-observed reproducible issue.
**Step 4.4: Series context**
- `b4 dig -a`: only v1 exists. Standalone single patch.
**Step 4.5: Stable discussion**
- None found in thread.
## PHASE 5: CODE SEMANTIC ANALYSIS
**Step 5.1: Functions modified**
- None. Adds one table entry to `hid_quirks[]` consumed by
`usbhid_exists_squirk()` / `hid_lookup_quirk()`.
**Step 5.2: Callers of quirk**
- `drivers/hid/usbhid/hid-core.c`: lines 689, 752, 756, 1185, 1234 all
check `HID_QUIRK_ALWAYS_POLL` and branch accordingly in `usbhid_open`,
`usbhid_close`, `usbhid_start`, `usbhid_stop` (standard HID USB device
lifecycle).
- Record: well-established, widely-used quirk path.
**Step 5.3: Callees**
- N/A — this is a data table entry.
**Step 5.4: Reachability**
- Reached for any system with the Bolt receiver plugged in during device
enumeration — every affected user.
**Step 5.5: Similar patterns**
- Many similar quirk additions in same file (Apple keyboard
c55092187d9ad, Dell KM5221W 62cc9c3cb3ec1, VRS R295 1141ed52348d3,
Cooler Master MM712 0be4253bf878d, Lenovo PixArt mice, etc.). This is
a recurring, well-accepted pattern.
## PHASE 6: STABLE TREE ANALYSIS
**Step 6.1: Code exists in stable?**
- The device ID `USB_DEVICE_ID_LOGITECH_BOLT_RECEIVER = 0xc548` is in
stable 6.12.y and later (added by commit 526748b925185 before v6.12).
- The `hid_quirks[]` table exists in all stable trees.
- Record: backport applicable to 6.12.y, 6.13.y, 6.14.y, 6.15.y (current
active trees that carry the define). Not applicable to older LTS
(6.6.y, 6.1.y, 5.15.y, 5.10.y) unless the device ID define is
backported along.
**Step 6.2: Backport complications**
- Mainline hunk context includes neighboring entries added later (8BitDo
Pro 3, Edifier QR30). Fuzz/minor context adjustment likely sufficient;
any stable tree with the `LOGITECH_BOLT_RECEIVER` define will accept
this addition trivially — the surrounding entries have been stable for
years.
- Record: clean apply with possibly trivial fuzz on older-than-mainline
stable.
**Step 6.3: Related fixes in stable?**
- None found.
## PHASE 7: SUBSYSTEM CONTEXT
**Step 7.1: Subsystem**
- `drivers/hid/` — device drivers (HID, USB input).
- Criticality: IMPORTANT — keyboards, mice, and wireless receivers are
common desktop/laptop hardware. Suspend/resume breakage affects user-
visible laptop power management.
**Step 7.2: Activity**
- Very active file; routine quirk additions merged frequently.
## PHASE 8: IMPACT AND RISK
**Step 8.1: Affected users**
- Owners of Logitech Bolt receivers (a fairly popular wireless receiver
used with Logitech MX-family peripherals and modern wireless
keyboards/mice) who suspend their systems.
**Step 8.2: Trigger**
- Occurs every system suspend within 5 minutes of wireless input
activity. Very easy to trigger on any laptop using this receiver.
**Step 8.3: Severity**
- Failure mode: **spurious wake-from-suspend** → battery drain, system
not actually suspending, potential data/security exposure on machines
users thought were asleep. Severity: **MEDIUM-HIGH** (not a crash, but
a serious user-visible regression of the suspend feature; affects
laptop battery life and sleep reliability).
**Step 8.4: Risk-benefit**
- Benefit: clear, reproducible user-facing fix for laptop suspend/resume
with a common wireless receiver.
- Risk: one-line table entry for a specific (vendor,product) tuple;
cannot affect other devices. Extra URB polling for the one device —
the same trade-off accepted for dozens of similar quirks. Very low
risk.
- Record: benefit >> risk.
## PHASE 9: FINAL SYNTHESIS
**Step 9.1: Evidence**
- FOR: one-line surgical quirk; applied by HID maintainer; established
pattern (dozens of similar entries); fixes real user-visible suspend
misbehavior; author tested both suspend and wakeup paths.
- AGAINST: none material. Adds a tiny bit of USB traffic for the one
device (acknowledged).
- Unresolved: backport to pre-6.12 trees would additionally need the
`hid-ids.h` define from commit 526748b925185 — but active stable trees
(6.12.y+) already contain it.
**Step 9.2: Stable Rules Checklist**
1. Obviously correct? **YES** — matches existing pattern, maintainer-
applied.
2. Fixes real bug affecting users? **YES** — spurious wake from suspend.
3. Important issue? **YES** — suspend/resume reliability on common
hardware.
4. Small and contained? **YES** — 1 line, 1 file.
5. No new features/APIs? **YES** — quirk entry only.
6. Applies to stable? **YES** — for trees containing the device ID
define (v6.12+).
**Step 9.3: Exception Category**
- Fits the explicit "QUIRKS and WORKAROUNDS" exception and "NEW DEVICE
IDs / device-specific quirks to existing drivers" exception in stable
rules.
**Step 9.4: Decision**
- This is a textbook stable candidate: a minimal, targeted hardware
quirk that fixes a reproducible suspend issue for a common piece of
hardware, applied by the subsystem maintainer, matching dozens of
prior similar backported quirks.
## Verification
- [Phase 1] Parsed commit message: confirmed no
Fixes/Cc:stable/Link/Reported-by; two Signed-off-bys (author + HID
maintainer Jiri Kosina).
- [Phase 2] Diff inspection: verified the change is exactly `+1` line in
`drivers/hid/hid-quirks.c` adding a `HID_QUIRK_ALWAYS_POLL` entry for
`USB_VENDOR_ID_LOGITECH`/`USB_DEVICE_ID_LOGITECH_BOLT_RECEIVER`.
- [Phase 2] Confirmed quirk semantics via `drivers/hid/usbhid/hid-
core.c` lines 689, 752, 756, 1185, 1234 — flag bypasses
autosuspend/remote-wakeup paths.
- [Phase 2] Verified `HID_QUIRK_ALWAYS_POLL = BIT(10)` in
`include/linux/hid.h:406`.
- [Phase 3] `git log` on `drivers/hid/hid-quirks.c` + `rg
USB_DEVICE_ID_LOGITECH_BOLT_RECEIVER` → identified define introduced
in commit `526748b925185`.
- [Phase 3] `git tag --contains 526748b925185` → device ID first shipped
in v6.12.
- [Phase 3] `git log --oneline --grep="ALWAYS_POLL"` → verified many
similar one-line quirk additions historically.
- [Phase 4] `b4 dig -c d4229fc0cb50c` → found original thread at
lore.kernel.org/all/20260407-logi-bolt-hid-quirk-always-
poll-v1-1-4dae0fda344e@collabora.com/.
- [Phase 4] `b4 dig -a` → single v1, applied as-is.
- [Phase 4] `b4 dig -m /tmp/bolt-thread.mbx` → read full thread: Jiri
Kosina (HID maintainer) applied the patch; author confirmed testing;
no NAKs.
- [Phase 5] Confirmed `hid_quirks[]` entries are consumed by the
standard USB HID core paths — impact scope is exactly the one matched
device.
- [Phase 6] Device ID present in mainline and 6.12.y+ stable branches.
- [Phase 7] `drivers/hid/` is IMPORTANT subsystem — affects HID input on
desktops/laptops.
- [Phase 8] Failure mode: spurious system wake from suspend, confirmed
by commit message text.
- UNVERIFIED: I did not check every LTS stable tree file-by-file for
divergent context around the insertion point, but given this is a
sorted alphabetical table and the neighboring Logitech entries
(`LOGITECH_C007`, `LOGITECH_C077`, `LOGITECH_KEYBOARD_G710_PLUS`) have
been present for many years, a clean backport is essentially
guaranteed for 6.12+ trees.
Single-line hardware quirk entry that fixes a real, reproducible
suspend/wakeup bug affecting owners of the Logitech Bolt receiver.
Matches the "quirks and workarounds" stable exception exactly, is
maintainer-applied, carries negligible regression risk, and applies
cleanly to stable trees that carry the device ID (v6.12+).
**YES**
drivers/hid/hid-quirks.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/hid/hid-quirks.c b/drivers/hid/hid-quirks.c
index 02f7db5c10564..eb811b1fb80f9 100644
--- a/drivers/hid/hid-quirks.c
+++ b/drivers/hid/hid-quirks.c
@@ -134,6 +134,7 @@ static const struct hid_device_id hid_quirks[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_LENOVO, USB_DEVICE_ID_LENOVO_PIXART_USB_MOUSE_6019), HID_QUIRK_ALWAYS_POLL },
{ HID_USB_DEVICE(USB_VENDOR_ID_LENOVO, USB_DEVICE_ID_LENOVO_PIXART_USB_MOUSE_602E), HID_QUIRK_ALWAYS_POLL },
{ HID_USB_DEVICE(USB_VENDOR_ID_LENOVO, USB_DEVICE_ID_LENOVO_PIXART_USB_MOUSE_6093), HID_QUIRK_ALWAYS_POLL },
+ { HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_BOLT_RECEIVER), HID_QUIRK_ALWAYS_POLL },
{ HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_C007), HID_QUIRK_ALWAYS_POLL },
{ HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_C077), HID_QUIRK_ALWAYS_POLL },
{ HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_KEYBOARD_G710_PLUS), HID_QUIRK_NOGET },
--
2.53.0
^ permalink raw reply related
* [PATCH AUTOSEL 6.18] HID: roccat: fix use-after-free in roccat_report_event
From: Sasha Levin @ 2026-04-20 13:18 UTC (permalink / raw)
To: patches, stable
Cc: Benoît Sevens, Silvan Jegen, Jiri Kosina, Sasha Levin,
erazor_de, jikos, bentiss, linux-input, linux-kernel
In-Reply-To: <20260420132314.1023554-1-sashal@kernel.org>
From: Benoît Sevens <bsevens@google.com>
[ Upstream commit d802d848308b35220f21a8025352f0c0aba15c12 ]
roccat_report_event() iterates over the device->readers list without
holding the readers_lock. This allows a concurrent roccat_release() to
remove and free a reader while it's still being accessed, leading to a
use-after-free.
Protect the readers list traversal with the readers_lock mutex.
Signed-off-by: Benoît Sevens <bsevens@google.com>
Reviewed-by: Silvan Jegen <s.jegen@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
Error: Failed to generate final synthesis
drivers/hid/hid-roccat.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/hid/hid-roccat.c b/drivers/hid/hid-roccat.c
index c7f7562e22e56..e413662f75082 100644
--- a/drivers/hid/hid-roccat.c
+++ b/drivers/hid/hid-roccat.c
@@ -257,6 +257,7 @@ int roccat_report_event(int minor, u8 const *data)
if (!new_value)
return -ENOMEM;
+ mutex_lock(&device->readers_lock);
mutex_lock(&device->cbuf_lock);
report = &device->cbuf[device->cbuf_end];
@@ -279,6 +280,7 @@ int roccat_report_event(int minor, u8 const *data)
}
mutex_unlock(&device->cbuf_lock);
+ mutex_unlock(&device->readers_lock);
wake_up_interruptible(&device->wait);
return 0;
--
2.53.0
^ permalink raw reply related
* [PATCH AUTOSEL 6.18] HID: amd_sfh: don't log error when device discovery fails with -EOPNOTSUPP
From: Sasha Levin @ 2026-04-20 13:16 UTC (permalink / raw)
To: patches, stable
Cc: Maximilian Pezzullo, Casey Croy, Basavaraj Natikar, Jiri Kosina,
Sasha Levin, basavaraj.natikar, jikos, bentiss, linux-input,
linux-kernel
In-Reply-To: <20260420132314.1023554-1-sashal@kernel.org>
From: Maximilian Pezzullo <maximilianpezzullo@gmail.com>
[ Upstream commit 743677a8cb30b09f16a7f167f497c2c927891b5a ]
When sensor discovery fails on systems without AMD SFH sensors, the
code already emits a warning via dev_warn() in amd_sfh_hid_client_init().
The subsequent dev_err() in sfh_init_work() for the same -EOPNOTSUPP
return value is redundant and causes unnecessary alarm.
Suppress the dev_err() for -EOPNOTSUPP to avoid confusing users who
have no AMD SFH sensors.
Fixes: 2105e8e00da4 ("HID: amd_sfh: Improve boot time when SFH is available")
Reported-by: Casey Croy <ccroy@bugzilla.kernel.org>
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221099
Signed-off-by: Maximilian Pezzullo <maximilianpezzullo@gmail.com>
Acked-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
Error: Failed to generate final synthesis
drivers/hid/amd-sfh-hid/amd_sfh_pcie.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/hid/amd-sfh-hid/amd_sfh_pcie.c b/drivers/hid/amd-sfh-hid/amd_sfh_pcie.c
index 1d9f955573aa4..4b81cebdc3359 100644
--- a/drivers/hid/amd-sfh-hid/amd_sfh_pcie.c
+++ b/drivers/hid/amd-sfh-hid/amd_sfh_pcie.c
@@ -413,7 +413,8 @@ static void sfh_init_work(struct work_struct *work)
rc = amd_sfh_hid_client_init(mp2);
if (rc) {
amd_sfh_clear_intr(mp2);
- dev_err(&pdev->dev, "amd_sfh_hid_client_init failed err %d\n", rc);
+ if (rc != -EOPNOTSUPP)
+ dev_err(&pdev->dev, "amd_sfh_hid_client_init failed err %d\n", rc);
return;
}
--
2.53.0
^ permalink raw reply related
* [PATCH AUTOSEL 7.0-6.18] HID: logitech-hidpp: Check bounds when deleting force-feedback effects
From: Sasha Levin @ 2026-04-20 13:08 UTC (permalink / raw)
To: patches, stable
Cc: Günther Noack, Lee Jones, Jiri Kosina, Sasha Levin, jikos,
bentiss, linux-input, linux-kernel
In-Reply-To: <20260420131539.986432-1-sashal@kernel.org>
From: Günther Noack <gnoack@google.com>
[ Upstream commit e606d8329be1e19b7eb3e0c6c72a73cbbb25ae3d ]
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ünther Noack <gnoack@google.com>
Reviewed-by: Lee Jones <lee@kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
## Analysis
### PHASE 1: COMMIT MESSAGE FORENSICS
**Step 1.1: Parse subject line**
Record: Subsystem `HID: logitech-hidpp:`, action verb `Check` (adding a
missing check). Summary: add missing bounds-check when deleting force-
feedback effects.
**Step 1.2: Parse commit message tags**
Record:
- `Cc: Lee Jones <lee@kernel.org>` (HID area reviewer, not stable)
- `Signed-off-by: Günther Noack <gnoack@google.com>` (author - Google
security engineer)
- `Reviewed-by: Lee Jones <lee@kernel.org>`
- `Signed-off-by: Jiri Kosina <jkosina@suse.com>` (HID maintainer)
- **NOT** present: `Cc: stable@vger.kernel.org`, `Fixes:`, `Reported-
by:`, `Link:`
- No syzbot, no user bug report, no sanitizer report
**Step 1.3: Analyze commit body**
Record: Author describes a missing bounds check that "might otherwise
overwrite index -1". Explicitly notes reduced exploitability:
"Triggering this condition requires action both from the USB device and
from userspace, which reduces the scenarios in which it can be
exploited." This is a security-hardening fix with an author-acknowledged
limited attack surface.
**Step 1.4: Hidden bug fix?**
Record: Not hidden at all - clearly a bug fix (missing bounds check
preventing OOB write). The "Check bounds" phrasing is classic stable-
style bug fix language.
### PHASE 2: DIFF ANALYSIS
**Step 2.1: Inventory**
Record: 1 file modified: `drivers/hid/hid-logitech-hidpp.c`. 9 lines
added, 6 removed. Single function modified: `hidpp_ff_work_handler()`,
single switch case: `HIDPP_FF_DESTROY_EFFECT`. Classification: single-
file surgical fix.
**Step 2.2: Code flow change**
Record:
- BEFORE: In `HIDPP_FF_DESTROY_EFFECT`, unconditionally writes
`data->effect_ids[wd->params[0]-1] = -1` when `effect_id >= 0`. No
bounds check on `wd->params[0]`.
- AFTER: First reads `slot = wd->params[0]`, then wraps the writes in
`if (slot > 0 && slot <= data->num_effects)`.
- This is an error-path / invalid-state handling fix, but on a normal
runtime path.
**Step 2.3: Bug mechanism**
Record: Category (f) Memory safety - bounds check added. Specific
mechanism: `wd->params[0]` is set by `hidpp_ff_find_effect()` (line
2478), which returns 0 when the requested `effect_id` is not present in
`data->effect_ids[]`. For `HIDPP_FF_EFFECTID_AUTOCENTER`, it's set to
`data->slot_autocenter` (initially 0 before autocenter is uploaded).
When `params[0] == 0`, the expression `params[0] - 1` promotes through
int arithmetic to `-1`, causing `data->effect_ids[-1] = -1` - an out-of-
bounds write of a fixed value `-1` at index `-1` of a
`kzalloc`-allocated `int*` array. The analogous
`HIDPP_FF_DOWNLOAD_EFFECT` case (lines 2493-2502) already contains the
exact same defensive check `if (slot > 0 && slot <= data->num_effects)`
- this fix restores symmetry.
**Step 2.4: Fix quality**
Record: Obviously correct - mirrors existing defensive check from the
same function's DOWNLOAD case. Minimal/surgical. Zero regression risk:
the added condition only suppresses an invalid index write; it doesn't
restrict any legitimate behavior. No red flags.
### PHASE 3: GIT HISTORY INVESTIGATION
**Step 3.1: git blame**
Record: The buggy `HIDPP_FF_DESTROY_EFFECT` handler was introduced by
commit `ff21a635dd1a9c` (Edwin Velds, 2016-01-11) "HID: logitech-hidpp:
Force feedback support for the Logitech G920". `git describe --contains`
places it at `v4.6-rc1~107^2^4~1` - first appeared in v4.6. The code has
been stable for ~10 years and is present in every supported stable tree.
**Step 3.2: Follow Fixes: tag**
Record: No `Fixes:` tag in the commit, but git blame identifies the
introducing commit as `ff21a635dd1a9c` (v4.6). That original commit is
in all stable trees that fork from ≥v4.6, which is every currently-
supported stable tree (5.4, 5.10, 5.15, 6.1, 6.6, 6.12, 6.19).
**Step 3.3: Related recent changes**
Record: Recent related work:
- `f7a4c78bfeb32` (Feb 2026) - Lee Jones, "Prevent use-after-free on
force feedback initialisation failure" - UAF fix in same FF path, no
`Cc: stable`.
- `1547d41f9f19d` (Jan 2026) - Günther Noack, "Check maxfield in
hidpp_get_report_length()" - hardening fix, **has** `Cc: stable`.
- This commit is standalone and self-contained; not part of a series (b4
dig -a shows only v1).
**Step 3.4: Author's other commits**
Record: Günther Noack (Google) has been actively hardening HID drivers
against malicious/fake USB devices: `HID: asus: avoid memory leak`,
`HID: magicmouse: Do not crash on missing msc->input` (+Cc stable),
`HID: prodikeys: Check presence of pm->input_ep82` (+Cc stable), `HID:
logitech-hidpp: Check maxfield in hidpp_get_report_length()` (+Cc
stable). Author is credible, security-focused, and knows stable
conventions.
**Step 3.5: Dependencies**
Record: No dependencies. Standalone, self-contained fix.
### PHASE 4: MAILING LIST / EXTERNAL RESEARCH
**Step 4.1: b4 dig original submission**
Record: `b4 dig -c e606d8329be1e` returned a single-message thread at `h
ttps://lore.kernel.org/all/20260331074052.194064-1-gnoack@google.com/`.
`b4 dig -a` confirms only v1 was posted - no revision history.
**Step 4.2: Recipients**
Record: `b4 dig -w` shows patch was sent to Filipe Laíns, Bastien
Nocera, Jiri Kosina (HID maintainer), Benjamin Tissoires (HID co-
maintainer), Lee Jones, linux-input@vger.kernel.org, linux-
kernel@vger.kernel.org. Appropriate audience.
**Step 4.3: Bug report**
Record: No bug report referenced; no syzbot/KASAN/KMSAN tag. Appears to
be a code-audit / hardening finding by the author.
**Step 4.4: Thread discussion**
Record: Thread saved to `/tmp/hidpp_thread.mbox`. Contents:
- Lee Jones: "LGTM. Reviewed-by: Lee Jones <lee@kernel.org>"
- Jiri Kosina: "Applied, thanks."
- **No reviewer suggested `Cc: stable`**. No NAKs, no concerns raised.
**Step 4.5: Stable-list discussion**
Record: No evidence of prior stable-list discussion for this particular
bug.
### PHASE 5: CODE SEMANTIC ANALYSIS
**Step 5.1: Functions in diff**
Record: Only `hidpp_ff_work_handler()` (switch case
`HIDPP_FF_DESTROY_EFFECT`).
**Step 5.2: Callers / trigger path**
Record: `hidpp_ff_work_handler` is the workqueue callback scheduled by
`hidpp_ff_queue_work()`. The DESTROY path is queued by
`hidpp_ff_erase_effect()` (line 2712), which is assigned to `ff->erase`
(line 2877). `ff->erase` is the standard input-layer callback invoked
when userspace calls `EVIOCRMFF` ioctl on `/dev/input/eventX` of the FF
device. So the buggy code is reachable via a standard userspace ioctl on
any user with access to the device node (typically needs `input` group
membership, or root).
**Step 5.3: Callees**
Record: `hidpp_ff_find_effect()` iterates `data->effect_ids[]` and
returns `i+1` if found, `0` otherwise. The return value `0` directly
causes the `params[0]-1 = -1` OOB when the destroy command proceeds.
**Step 5.4: Reachability**
Record: Buggy path is reachable from userspace: `EVIOCRMFF` ioctl →
`ff->erase` → `hidpp_ff_erase_effect` →
`hidpp_ff_queue_work(HIDPP_FF_DESTROY_EFFECT)` → workqueue →
`hidpp_ff_work_handler`. Needs a Logitech HID++ FF-capable device (e.g.,
G920 wheel) and a userspace condition that erases an effect not present
in the driver's tracking array (race between operations, stale
effect_id, or autocenter destroy before upload).
**Step 5.5: Similar patterns**
Record: The same function already has the correct pattern in
`HIDPP_FF_DOWNLOAD_EFFECT` (lines 2494-2502): `slot =
response.fap.params[0]; if (slot > 0 && slot <= data->num_effects) { ...
}`. This fix brings DESTROY into symmetry with DOWNLOAD.
### PHASE 6: CROSS-REFERENCING AND STABLE TREE ANALYSIS
**Step 6.1: Buggy code in stable trees?**
Record: The buggy code was added in v4.6 (Jan 2016) and is virtually
unchanged since then (blame shows only a whitespace/comment tweak in
2024). Present in every supported stable tree: 5.4.y, 5.10.y, 5.15.y,
6.1.y, 6.6.y, 6.12.y, 6.19.y.
**Step 6.2: Backport complications**
Record: Minimal. Recent churn in the function: Yan Zhen (2024, comment
typo fix) and Lee Jones (2026, adjacent UAF fix in init path - not this
function). The switch statement body targeted by this patch is identical
to what has been in the tree since 2016. Clean apply expected on all
stable branches, modulo trivial context adjustments.
**Step 6.3: Related fixes in stable**
Record: No prior fix for this specific OOB. Some adjacent FF hardening
(UAF fix `f7a4c78bfeb32`) exists in mainline but also lacks Cc: stable.
### PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT
**Step 7.1: Subsystem criticality**
Record: `drivers/hid/hid-logitech-hidpp.c` - HID driver for specific
Logitech HID++ devices (G920 wheel, MX mice, etc.). Classification:
PERIPHERAL (hardware-specific driver), but FF is a userspace-reachable
subsystem where games commonly issue erase/upload ioctls, so realistic
number of users on systems with a G920/G923 wheel.
**Step 7.2: Subsystem activity**
Record: Actively developed, with a mix of feature additions (new device
support) and security hardening (see Günther Noack's string of commits).
Mature codebase.
### PHASE 8: IMPACT AND RISK ASSESSMENT
**Step 8.1: Affected users**
Record: Users of Logitech HID++ FF-capable devices (G920/G923 wheels and
similar). Not universal - driver-specific. Requires the device to be
plugged in and a userspace FF client (game, test tool, etc.).
**Step 8.2: Trigger conditions**
Record: Author states "requires action both from the USB device and from
userspace." In practice: userspace invokes `EVIOCRMFF` with an effect_id
that the driver cannot find in `data->effect_ids[]` (e.g., effect never
uploaded, already erased, or device returned unexpected slot) AND the
device responds successfully to the destroy command. Not triggerable by
an unprivileged attacker alone; requires access to the evdev node.
**Step 8.3: Failure mode**
Record: Out-of-bounds write of the fixed value `-1` (`0xFFFFFFFF`) at
index `-1` of the `kzalloc`ed `data->effect_ids[]` array (an `int *`).
This corrupts 4 bytes immediately before the allocation - likely slab
metadata / redzone or an adjacent slab object. Severity: HIGH (memory
corruption), but with limited exploitability because (a) both value and
offset are fixed (not attacker-controlled), (b) requires non-trivial
combination of device + userspace state. Not directly security-critical
as a remote/local privilege escalation primitive, but an unambiguous
memory-safety bug.
**Step 8.4: Benefit/risk**
Record:
- BENEFIT: Fixes a 10-year-old memory-corruption bug in a userspace-
reachable code path. Medium-low because the trigger is narrow, but
non-zero - silent slab corruption can manifest as hard-to-debug
crashes.
- RISK: Extremely low. 9-line purely additive bounds-check that mirrors
an existing check in the same function. Zero regression potential on
normal operation.
- Ratio: Low benefit but near-zero risk → favorable for stable.
### PHASE 9: FINAL SYNTHESIS
**Evidence FOR backporting:**
- Clear out-of-bounds memory write (OOB pattern - recognized stable
category).
- Bug present in all stable trees since v4.6 (2016).
- Fix is 9 lines, in a single function, obviously correct.
- Mirrors existing defensive check in the same function
(`HIDPP_FF_DOWNLOAD_EFFECT`).
- Reviewed by Lee Jones; applied by HID maintainer Jiri Kosina.
- Author is a security-focused developer doing ongoing HID hardening.
- Clean apply expected on all stable branches.
- Zero regression risk.
**Evidence AGAINST backporting:**
- Author explicitly noted reduced exploitability ("requires action both
from the USB device and from userspace").
- Author did NOT include `Cc: stable@vger.kernel.org`, despite including
it on several similar HID hardening commits in the same timeframe.
This is a deliberate signal from a stable-aware author.
- No `Fixes:` tag, no bug report, no syzbot/KASAN evidence of real-world
triggers.
- Trigger requires specific hardware (Logitech FF wheel) + specific
userspace sequence.
- Bug has been present 10 years without reported user impact.
**Stable rules checklist:**
1. Obviously correct and tested? YES - mirrors existing pattern;
reviewed and applied.
2. Fixes a real bug? YES - OOB write is a real memory-safety bug.
3. Important issue? BORDERLINE - memory corruption but with narrow, non-
attacker-controlled trigger.
4. Small and contained? YES - 9 insertions, 6 deletions, one function.
5. No new features? YES - pure defensive check.
6. Applies cleanly? YES - expected clean on all active stable branches.
**Exception categories:** Not applicable (not a device-
ID/quirk/DT/build/doc fix).
**Decision rationale:**
This is a borderline case. Technically, it is a legitimate memory-safety
fix for a bug in userspace-reachable code that has been in the tree for
a decade. The patch is small, obviously correct, and zero-risk. OOB
writes are a canonical stable-backport category per the rule set.
The strongest counter-signal is the author's deliberate omission of `Cc:
stable` while including it on peer hardening patches, combined with the
explicit statement about limited exploitability. However, per the task
instructions, the absence of `Cc: stable` is explicitly NOT a negative
signal, and the technical criteria for stable are met.
Weighing the risk (near-zero) against the benefit (fixes a real OOB
write, even if rarely triggered), this is the kind of defensive bounds-
check fix that stable trees routinely accept. Memory corruption with a
hardcoded value at a hardcoded offset is still memory corruption.
### Verification
- [Phase 1] Parsed tags from commit message: found Signed-off-by (Noack,
Kosina), Reviewed-by (Jones), Cc (Jones). No `Cc: stable`, no
`Fixes:`, no `Reported-by:`, no `Link:`.
- [Phase 2] Diff analysis: 9 lines added, 6 removed, single file, single
function (`hidpp_ff_work_handler`), single case
(`HIDPP_FF_DESTROY_EFFECT`). Confirmed by `git show e606d8329be1e`.
- [Phase 2] Confirmed symmetry with existing check in
`HIDPP_FF_DOWNLOAD_EFFECT` by reading `drivers/hid/hid-logitech-
hidpp.c` lines 2493-2511.
- [Phase 3] `git blame -L 2502,2515 drivers/hid/hid-logitech-hidpp.c`:
buggy code introduced by `ff21a635dd1a9c` (Edwin Velds, 2016-01-11).
- [Phase 3] `git describe --contains ff21a635dd1a9c`:
`v4.6-rc1~107^2^4~1` (present since v4.6, 2016).
- [Phase 3] `git log --author="gnoack@google.com" --oneline`: confirmed
author's pattern of HID hardening work, including `Cc: stable`-tagged
peer commits (`17abd396`, `cee8337e`, `1547d41f`).
- [Phase 4] `b4 dig -c e606d8329be1e`: matched single thread at
`lore.kernel.org/all/20260331074052.194064-1-gnoack@google.com/`.
- [Phase 4] `b4 dig -a`: only v1 was posted - no revisions.
- [Phase 4] `b4 dig -w`: recipients include HID maintainers (Kosina,
Tissoires) and linux-input.
- [Phase 4] Read saved mbox `/tmp/hidpp_thread.mbox`: Lee Jones gave
Reviewed-by, Jiri Kosina said "Applied, thanks." No stable request or
concerns raised.
- [Phase 5] Confirmed reachability: `hidpp_ff_erase_effect()` wired to
`ff->erase` (line 2877), reachable via `EVIOCRMFF` ioctl. Confirmed
`hidpp_ff_find_effect` returns 0 when effect not found (line 2457).
- [Phase 5] Confirmed the buggy `params[0]-1 = -1` path when the
returned slot is 0.
- [Phase 6] Confirmed `ff21a635dd1a9c` pre-dates all active stable
branches (branch points are all after v4.6).
- [Phase 7] Subsystem `drivers/hid/` - PERIPHERAL driver for specific
Logitech HID++ devices with FF.
- [Phase 8] Failure mode: OOB write of fixed value `-1` at fixed offset
`-1` → slab corruption, severity HIGH but limited exploitability
primitive.
- UNVERIFIED: Did not run per-branch apply test on each stable tree, but
the function body is unchanged since 2016 so clean apply is highly
likely.
- UNVERIFIED: Could not find any user-reported crash or bug report
pointing to this specific OOB (no bug-tracker links in the commit
message or on the mailing list).
The fix is small, obviously correct, low-risk, and addresses a real out-
of-bounds write in a userspace-reachable path. Even with the author's
deliberate omission of `Cc: stable`, the technical stable criteria are
met, and bounds-check fixes of this nature are routinely backported.
**YES**
drivers/hid/hid-logitech-hidpp.c | 15 +++++++++------
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index d1dea7297712d..5f63f1d2303a0 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -2502,12 +2502,15 @@ static void hidpp_ff_work_handler(struct work_struct *w)
}
break;
case HIDPP_FF_DESTROY_EFFECT:
- if (wd->effect_id >= 0)
- /* regular effect destroyed */
- data->effect_ids[wd->params[0]-1] = -1;
- else if (wd->effect_id >= HIDPP_FF_EFFECTID_AUTOCENTER)
- /* autocenter spring destroyed */
- data->slot_autocenter = 0;
+ slot = wd->params[0];
+ if (slot > 0 && slot <= data->num_effects) {
+ if (wd->effect_id >= 0)
+ /* regular effect destroyed */
+ data->effect_ids[slot-1] = -1;
+ else if (wd->effect_id >= HIDPP_FF_EFFECTID_AUTOCENTER)
+ /* autocenter spring destroyed */
+ data->slot_autocenter = 0;
+ }
break;
case HIDPP_FF_SET_GLOBAL_GAINS:
data->gain = (wd->params[0] << 8) + wd->params[1];
--
2.53.0
^ permalink raw reply related
* [PATCH AUTOSEL 7.0-6.6] HID: logitech-hidpp: fix race condition when accessing stale stack pointer
From: Sasha Levin @ 2026-04-20 13:08 UTC (permalink / raw)
To: patches, stable
Cc: Benoît Sevens, Jiri Kosina, Sasha Levin, jikos, bentiss,
linux-input, linux-kernel
In-Reply-To: <20260420131539.986432-1-sashal@kernel.org>
From: Benoît Sevens <bsevens@google.com>
[ Upstream commit e2aaf2d3ad92ac4a8afa6b69ad4c38e7747d3d6e ]
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.
Signed-off-by: Benoît Sevens <bsevens@google.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
Now I have enough information to make a thorough analysis. Let me
compile my findings.
## PHASE 1: COMMIT MESSAGE FORENSICS
**Step 1.1: Parse Subject Line**
- Record: Subsystem `HID: logitech-hidpp`, action verb `fix`, summary:
race condition when accessing stale stack pointer (clear bug fix).
**Step 1.2: Parse Tags**
- Record: `Signed-off-by: Benoît Sevens <bsevens@google.com>` (author)
and `Signed-off-by: Jiri Kosina <jkosina@suse.com>` (HID subsystem
maintainer). No Reported-by/Link/Fixes tags. No stable tag. Author is
a known Google security researcher (has other HID UAF/OOB fixes in
roccat and wacom).
**Step 1.3: Analyze Body**
- Record: Bug description: `hidpp->send_receive_buf` is assigned to
point at a stack-allocated response buffer inside
`__do_hidpp_send_message_sync()` but never cleared when the function
returns. Meanwhile `hidpp_raw_hidpp_event()` speculatively reads this
pointer whenever `send_mutex` is locked. The race:
1. Thread A finishes a command; leaves `send_receive_buf` pointing at
A's stack.
2. Thread B grabs `send_mutex`; there is a window before B writes
`send_receive_buf = response`.
3. Event handler fires (different thread), sees the mutex locked,
dereferences the stale pointer from A's stack. The handler even
performs `*answer = *report` — a WRITE to the stale stack pointer
using device-supplied data (potential stack corruption / info leak
/ exploit primitive).
4. On very first use, `send_receive_buf` is NULL → NULL deref.
Symptom: OOB stack access on a different thread or NULL deref on
first command.
**Step 1.4: Hidden Bug Detection**
- Record: Not hidden — commit title already says "fix race condition".
Classic race + UAF/stale-pointer bug.
## PHASE 2: DIFF ANALYSIS
**Step 2.1: Inventory**
- Record: One file changed (`drivers/hid/hid-logitech-hidpp.c`), +17/-7
lines. Two functions touched: `__do_hidpp_send_message_sync()` and
`hidpp_raw_hidpp_event()`. Classification: single-file surgical fix.
**Step 2.2: Code Flow Change**
- Record: Producer (`__do_hidpp_send_message_sync`): early returns
converted to `goto out`, new `out:` label clears
`hidpp->send_receive_buf = NULL` before returning. Consumer
(`hidpp_raw_hidpp_event`): `question/answer` assignments moved inside
the `mutex_is_locked()` block, plus `if (!question) return 0;` NULL
guard before use.
**Step 2.3: Bug Mechanism**
- Record: Category (b)+(d) — race / memory safety fix. Adds implicit
synchronization by ensuring the shared pointer is NULL'd while still
holding `send_mutex`, and adds a NULL check on the read side to close
the small window between mutex acquisition and pointer assignment.
Addresses two failure modes: stale stack pointer dereference (UAF of
stack memory) and NULL dereference on first use.
**Step 2.4: Fix Quality**
- Record: Obviously correct. Minimal. No new locks, no API/ABI changes.
Possible (extremely minor) regression risk: if a report raced in
between `mutex_lock` and the assignment, the early-out `return 0` will
now skip matching it against the question — but this was already
broken (it used a stale pointer) and the send path has a 5-second
timeout with retry, so the benign behavior is strictly safer. No
regression risk beyond that.
## PHASE 3: GIT HISTORY INVESTIGATION
**Step 3.1: Blame**
- Record: The stale-pointer pattern (`hidpp->send_receive_buf =
response;` and the speculative read `struct hidpp_report *question =
hidpp->send_receive_buf;`) dates to commit `2f31c52529103d` "HID:
Introduce hidpp" by Benjamin Tissoires, Sep 2014 (≈ v3.18). Bug is
therefore present in every stable tree from v3.18 through
v6.19/mainline.
**Step 3.2: Fixes: tag**
- Record: No `Fixes:` tag in the commit. Manually identified introducing
commit as `2f31c52529103d` (original driver introduction, 2014).
**Step 3.3: Related Changes to the File**
- Record: Recent file history shows actively maintained file (device ID
adds, quirks, other UAF fix `f7a4c78b` "Prevent use-after-free on
force feedback initialisation failure"). Function was split into
`__do_hidpp_send_message_sync`/`hidpp_send_message_sync` in
`60165ab774cb0c` (v6.7, Jul 2023). Before that split (v6.6 is the
earliest with `__do_hidpp_send_message_sync`), the logic lived inline
in `hidpp_send_message_sync`.
**Step 3.4: Author's Other Commits**
- Record: Benoît Sevens (Google) has prior HID security fixes:
`d802d848` (roccat UAF), `2f1763f6` (wacom OOB), plus similar fixes in
uvcvideo and ALSA. Consistent pattern of Google-originated kernel
security research. High trust.
**Step 3.5: Dependencies**
- Record: Self-contained, no prerequisites. Fix only touches one file
and two functions. For v6.1.y and older the function was not yet
split, so the fix requires trivial rewording to apply (move the NULL-
out before `mutex_unlock` in `hidpp_send_message_sync`), but the
change is mechanical.
## PHASE 4: MAILING LIST RESEARCH
**Step 4.1: Original Discussion**
- Record: `b4 dig -c e2aaf2d3ad92a` found the thread at https://lore.ker
nel.org/all/20260401144811.1242722-1-bsevens@google.com/. Only one
version (v1) was posted; no review-imposed revisions.
**Step 4.2: Reviewers**
- Record: `b4 dig -w`: patch CC'd `Filipe Laíns`, `Bastien Nocera`,
`Jiri Kosina`, `Benjamin Tissoires`, linux-input, linux-kernel — all
the correct maintainers. Merged by Jiri Kosina (subsystem maintainer)
with note: "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." Confirms
maintainer reviewed and accepted; any follow-up is an orthogonal
cleanup, not a fix correction.
**Step 4.3: Bug Reports**
- Record: No Reported-by or Link tags. Author is from Google — likely
discovered via internal audit/fuzzing. No public reproducer cited.
**Step 4.4: Related Series**
- Record: Single standalone patch, no series.
**Step 4.5: Stable ML**
- Record: Not searched; the patch was only posted April 1, 2026 and
applied soon after — too fresh for independent stable ML activity.
## PHASE 5: CODE SEMANTIC ANALYSIS
**Step 5.1: Key Functions**
- Record: `__do_hidpp_send_message_sync` (producer) and
`hidpp_raw_hidpp_event` (consumer).
**Step 5.2: Callers**
- Record: 45 call sites for `hidpp_send_*_sync` inside the driver —
every HID++ query (battery, connect, feature discovery, probe,
get_report_length, etc.). `hidpp_raw_hidpp_event` is invoked from
`hidpp_raw_event` (registered as `.raw_event` in `hid_ll_driver`),
reached from the HID core for every HID report coming from any
Logitech HID++ device (receivers, mice, keyboards, touchpads). Both
paths fire during normal operation — not rare.
**Step 5.3: Callees**
- Record: Sync path calls `__hidpp_send_report()` (USB/Bluetooth
transmit) and `wait_event_timeout()`. Event path does a struct-copy
`*answer = *report` — this is the dangerous write when `answer` is
stale.
**Step 5.4: Reachability**
- Record: The sync path runs in process context (probe, sysfs,
workqueue). The event path runs from HID input processing (URB
completion / BT callback, softirq or kthread depending on transport).
Different contexts on different CPUs → true concurrent race possible.
Triggers do not require privilege — any HID++ device that sends
unsolicited reports while a command is in flight can race. This is the
normal mode of operation for hidpp devices (connect events, battery
notifications, keypresses).
**Step 5.5: Similar Patterns**
- Record: Only one occurrence of `send_receive_buf` in the file; pattern
is unique to this driver.
## PHASE 6: STABLE TREE ANALYSIS
**Step 6.1: Buggy Code in Stable**
- Record: Verified via `git show <tag>:drivers/hid/hid-logitech-hidpp.c`
that the exact same vulnerable pattern (`send_receive_buf = response`
without clearing, `question = hidpp->send_receive_buf` read without
NULL check) exists in v4.19, v5.4, v5.10, v5.15, v6.1, v6.6. All
active stable trees are affected.
**Step 6.2: Backport Complications**
- Record: v6.6+ (and mainline): patch applies cleanly — identical
function structure. v6.1 and earlier: `__do_hidpp_send_message_sync`
does not yet exist; the logic is inline in `hidpp_send_message_sync`
which also holds/releases `send_mutex`. Backport requires mechanically
placing `hidpp->send_receive_buf = NULL;` before
`mutex_unlock(&hidpp->send_mutex)` in `hidpp_send_message_sync`, and
applying the event-handler hunk unchanged. Straightforward for the
stable maintainers.
**Step 6.3: Related Fixes in Stable**
- Record: No prior independent fix for this specific race is in stable.
Unrelated recent fixes (force-feedback UAF `f7a4c78b`) target other
paths.
## PHASE 7: SUBSYSTEM CONTEXT
**Step 7.1: Criticality**
- Record: Subsystem: `drivers/hid/` HID++ Logitech driver. Logitech
Unifying receivers/MX mice/keyboards are ubiquitous on laptops and
desktops; the driver ships on most distributions. Classification:
IMPORTANT (wide hardware user base), not CORE.
**Step 7.2: Activity**
- Record: Actively developed — multiple merges per release cycle (device
IDs, quirks, bug fixes). Mature core codepaths in the driver have been
stable for years.
## PHASE 8: IMPACT AND RISK ASSESSMENT
**Step 8.1: Who Is Affected**
- Record: Anyone with a Logitech HID++ device (mice, keyboards,
receivers, presenters) using the in-tree driver. Essentially most
laptop users with Logitech peripherals. Driver-specific but very
widespread hardware.
**Step 8.2: Trigger Conditions**
- Record: Requires concurrent activity: one thread invoking a sync
command while the device sends an asynchronous report. Races happen
during connect/disconnect, battery reporting, feature queries. The
very-first-use path yields NULL deref (no concurrency needed: any
async event before any sync command completes once) — but that path is
rare because probe typically drives the first sync command before any
report arrives. Attacker plane: a malicious or faulty HID device can
flood reports to widen the window — reachable from device-trust
boundary, relevant for BadUSB-style threat models.
**Step 8.3: Failure Mode Severity**
- Record: (a) NULL pointer dereference → kernel oops (CRITICAL: crash).
(b) Stale stack pointer read → OOB read (HIGH: info leak). (c) Stale
stack pointer WRITE via `*answer = *report` using device-controlled
data → stack corruption on an unrelated thread (CRITICAL: memory
corruption, potential privilege escalation/exploit primitive). Overall
severity: CRITICAL.
**Step 8.4: Risk/Benefit**
- Record: Benefit HIGH — closes a long-standing race with
crash/corruption potential in a widely-deployed driver. Risk LOW —
24-line surgical change, no new locking, no API change, reviewed and
applied by subsystem maintainer, only risk is a missed-answer timeout
that already has retry logic and a 5-second wait. Ratio clearly favors
backporting.
## PHASE 9: FINAL SYNTHESIS
**Step 9.1: Evidence**
- FOR: Fixes real race/UAF/NULL-deref, very widespread hardware, small
and surgical, author has security-fix track record, applied by
subsystem maintainer, bug is 10+ years old (present in every active
stable), failure modes include potential stack corruption from device-
controlled data (security-relevant).
- AGAINST: No Reported-by/Fixes/Cc: stable tag; no public reproducer;
for older stables (≤v6.1) a trivial mechanical adaptation is needed
because the function was later split.
- UNRESOLVED: Exact kernel trigger rate in the wild is not documented;
CVE status unknown.
**Step 9.2: Stable Rules**
1. Obviously correct & tested? Yes — tiny, mechanical; applied by
maintainer.
2. Fixes real bug? Yes — race + stale/NULL pointer deref with concrete
failure modes.
3. Important? Yes — kernel oops and potential stack corruption.
4. Small & contained? Yes — 24 lines, one file, two functions.
5. No new features/APIs? Correct — pure fix.
6. Applies to stable? v6.6+: clean. ≤v6.1: needs trivial adaptation.
**Step 9.3: Exceptions**
- Not an exception category; qualifies on normal bug-fix merit.
**Step 9.4: Decision**
- The commit is a textbook stable candidate: small, targeted race fix in
a broadly used driver, repairing a NULL-deref + stale-pointer write
that a faulty/malicious device can provoke.
### Verification
- [Phase 1] Read full commit message — no Fixes/Reported-by/Cc: stable
tags; identified bug description and two-step fix.
- [Phase 2] Read diff end-to-end; confirmed +17/-7 in one file, two
functions, classic NULL-out + NULL-check pattern with `goto out`.
- [Phase 3] `git blame` on both functions: pattern dates to
`2f31c52529103d` (2014, v3.18). Split into
`__do_hidpp_send_message_sync` at `60165ab774cb0c` (v6.7).
- [Phase 3] `git log --oneline -- drivers/hid/hid-logitech-hidpp.c`:
file is actively maintained.
- [Phase 3] `git log --oneline --author="Benoit Sevens\|Benoît Sevens"`:
confirmed author's pattern of HID/UVC/ALSA security fixes.
- [Phase 4] `b4 dig -c e2aaf2d3ad92a`: found lore thread at `https://lor
e.kernel.org/all/20260401144811.1242722-1-bsevens@google.com/`.
- [Phase 4] `b4 dig -w`: confirmed CC list includes Jiri Kosina,
Benjamin Tissoires, Filipe Laíns, Bastien Nocera, linux-input, linux-
kernel.
- [Phase 4] `b4 dig -a`: only v1 was posted; no further revisions.
- [Phase 4] Read `/tmp/hidpp_race.mbox`: confirmed maintainer Jiri
Kosina's "Now applied" reply and note about deferred cleanup idea from
Benjamin Tissoires.
- [Phase 5] `rg send_receive_buf`: confirmed only 4 references (struct
member + 1 write + 2 reads), no other use sites.
- [Phase 5] Read `hidpp_raw_event` caller: confirmed registered as
`.raw_event` and called for every HID++ short/long/very-long report
from the device.
- [Phase 6] `git show vX:drivers/hid/hid-logitech-hidpp.c` for v4.19,
v5.4, v5.10, v5.15, v6.1, v6.6: verified vulnerable pattern exists in
every stable tree.
- [Phase 6] Verified `__do_hidpp_send_message_sync` only exists from
v6.6 onward; older trees need trivial adaptation of the producer hunk.
- [Phase 8] Reviewed event handler body: `*answer = *report` is a write,
confirming the stack-corruption / write-primitive aspect (not merely
an info leak).
- UNVERIFIED: Whether a CVE was assigned; whether a public reproducer
exists; exact in-wild trigger rate.
The fix is small, surgical, reviewed by the HID maintainer, repairs a
long-standing race with crash and stack-corruption consequences
affecting extremely common Logitech hardware, and backports cleanly to
recent stables with only a mechanical adjustment needed for older ones.
**YES**
drivers/hid/hid-logitech-hidpp.c | 24 +++++++++++++++++-------
1 file changed, 17 insertions(+), 7 deletions(-)
diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index 5f63f1d2303a0..b1330d23bd2d0 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -306,21 +306,22 @@ static int __do_hidpp_send_message_sync(struct hidpp_device *hidpp,
if (ret) {
dbg_hid("__hidpp_send_report returned err: %d\n", ret);
memset(response, 0, sizeof(struct hidpp_report));
- return ret;
+ goto out;
}
if (!wait_event_timeout(hidpp->wait, hidpp->answer_available,
5*HZ)) {
dbg_hid("%s:timeout waiting for response\n", __func__);
memset(response, 0, sizeof(struct hidpp_report));
- return -ETIMEDOUT;
+ ret = -ETIMEDOUT;
+ goto out;
}
if (response->report_id == REPORT_ID_HIDPP_SHORT &&
response->rap.sub_id == HIDPP_ERROR) {
ret = response->rap.params[1];
dbg_hid("%s:got hidpp error %02X\n", __func__, ret);
- return ret;
+ goto out;
}
if ((response->report_id == REPORT_ID_HIDPP_LONG ||
@@ -328,10 +329,14 @@ static int __do_hidpp_send_message_sync(struct hidpp_device *hidpp,
response->fap.feature_index == HIDPP20_ERROR) {
ret = response->fap.params[1];
dbg_hid("%s:got hidpp 2.0 error %02X\n", __func__, ret);
- return ret;
+ goto out;
}
- return 0;
+ ret = 0;
+
+out:
+ hidpp->send_receive_buf = NULL;
+ return ret;
}
/*
@@ -3843,8 +3848,7 @@ static int hidpp_input_configured(struct hid_device *hdev,
static int hidpp_raw_hidpp_event(struct hidpp_device *hidpp, u8 *data,
int size)
{
- struct hidpp_report *question = hidpp->send_receive_buf;
- struct hidpp_report *answer = hidpp->send_receive_buf;
+ struct hidpp_report *question, *answer;
struct hidpp_report *report = (struct hidpp_report *)data;
int ret;
int last_online;
@@ -3854,6 +3858,12 @@ static int hidpp_raw_hidpp_event(struct hidpp_device *hidpp, u8 *data,
* previously sent command.
*/
if (unlikely(mutex_is_locked(&hidpp->send_mutex))) {
+ question = hidpp->send_receive_buf;
+ answer = hidpp->send_receive_buf;
+
+ if (!question)
+ return 0;
+
/*
* Check for a correct hidpp20 answer or the corresponding
* error
--
2.53.0
^ permalink raw reply related
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