* [PATCH v8 4/7] Input: synaptics-rmi4 - f55: handle zero electrode count
From: David Heidelberg via B4 Relay @ 2026-03-24 19:40 UTC (permalink / raw)
To: Kaustabh Chakraborty, Dmitry Torokhov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jason A. Donenfeld,
Matthias Schiffer, Vincent Huang, Casey Connolly
Cc: David Heidelberg, linux-input, devicetree, linux-kernel,
phone-devel
In-Reply-To: <20260324-synaptics-rmi4-v8-0-2168d2df68f5@ixit.cz>
From: Kaustabh Chakraborty <kauschluss@disroot.org>
Some third party ICs claim to support f55 but report an electrode count
of 0. Catch this and bail out early so that we don't confuse the i2c bus
with 0 sized reads.
Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
[simplify code, adjust wording]
Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
Signed-off-by: David Heidelberg <david@ixit.cz>
---
drivers/input/rmi4/rmi_f55.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/input/rmi4/rmi_f55.c b/drivers/input/rmi4/rmi_f55.c
index 488adaca4dd00..776c915b82e72 100644
--- a/drivers/input/rmi4/rmi_f55.c
+++ b/drivers/input/rmi4/rmi_f55.c
@@ -52,6 +52,11 @@ static int rmi_f55_detect(struct rmi_function *fn)
f55->num_rx_electrodes = f55->qry[F55_NUM_RX_OFFSET];
f55->num_tx_electrodes = f55->qry[F55_NUM_TX_OFFSET];
+ if (!f55->num_rx_electrodes || !f55->num_tx_electrodes) {
+ dev_err(&fn->dev, "%s: F55 query returned no electrodes, giving up\n",
+ __func__);
+ return -EINVAL;
+ }
f55->cfg_num_rx_electrodes = f55->num_rx_electrodes;
f55->cfg_num_tx_electrodes = f55->num_rx_electrodes;
--
2.53.0
^ permalink raw reply related
* [PATCH v8 3/7] Input: synaptics-rmi4 - f12: use hardcoded values for aftermarket touch ICs
From: David Heidelberg via B4 Relay @ 2026-03-24 19:40 UTC (permalink / raw)
To: Kaustabh Chakraborty, Dmitry Torokhov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jason A. Donenfeld,
Matthias Schiffer, Vincent Huang, Casey Connolly
Cc: David Heidelberg, linux-input, devicetree, linux-kernel,
phone-devel
In-Reply-To: <20260324-synaptics-rmi4-v8-0-2168d2df68f5@ixit.cz>
From: Kaustabh Chakraborty <kauschluss@disroot.org>
Some replacement displays include third-party touch ICs which are
devoid of register descriptors. Create a fake data register descriptor
for such ICs and provide hardcoded default values.
It isn't possible to reliably determine if the touch IC is original or
not, so these fallback values are offered as an alternative to the error
path when register descriptors aren't available.
Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
[changes for readability / codeflow, checkpatch fixes]
Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
Signed-off-by: David Heidelberg <david@ixit.cz>
---
drivers/input/rmi4/rmi_f12.c | 117 +++++++++++++++++++++++++++++++++----------
1 file changed, 91 insertions(+), 26 deletions(-)
diff --git a/drivers/input/rmi4/rmi_f12.c b/drivers/input/rmi4/rmi_f12.c
index 8246fe77114bb..1a103cc5f2235 100644
--- a/drivers/input/rmi4/rmi_f12.c
+++ b/drivers/input/rmi4/rmi_f12.c
@@ -218,6 +218,41 @@ static void rmi_f12_process_objects(struct f12_data *f12, u8 *data1, int size)
rmi_2d_sensor_abs_report(sensor, &sensor->objs[i], i);
}
+static void rmi_f12_set_hardcoded_desc(struct rmi_function *fn, struct f12_data *f12)
+{
+ struct rmi_2d_sensor *sensor = &f12->sensor;
+ struct rmi_register_desc_item *reg_desc;
+
+ /* We have no f12->data_reg_desc, so the pkt_size is 0, override it with
+ * a somewhat sensible default (this corresponds to 10 fingers).
+ */
+ sensor->pkt_size = 88;
+
+ /*
+ * There are no register descriptors to get these values from.
+ * We set them to high values to either be overwritten by the clip
+ * properties from devicetree, or to just not get in the way.
+ */
+ sensor->max_x = 65535;
+ sensor->max_y = 65535;
+
+ /*
+ * Create the Data1 register descriptor so that touch events
+ * can work properly.
+ */
+ reg_desc = devm_kcalloc(&fn->dev, 1,
+ sizeof(struct rmi_register_desc_item), GFP_KERNEL);
+ reg_desc->reg = 1;
+ reg_desc->reg_size = 80;
+ reg_desc->num_subpackets = 10;
+
+ f12->data1 = reg_desc;
+ f12->data1_offset = 0;
+ sensor->nbr_fingers = reg_desc->num_subpackets;
+ sensor->report_abs = 1;
+ sensor->attn_size += reg_desc->reg_size;
+}
+
static irqreturn_t rmi_f12_attention(int irq, void *ctx)
{
int retval;
@@ -338,6 +373,40 @@ static int rmi_f12_config(struct rmi_function *fn)
return 0;
}
+static int rmi_f12_sensor_init(struct rmi_function *fn, struct f12_data *f12)
+{
+ struct rmi_2d_sensor *sensor = &f12->sensor;
+
+ sensor->fn = fn;
+ f12->data_addr = fn->fd.data_base_addr;
+
+ /* On quirky devices that don't have a data_reg_desc we hardcode the packet
+ * in rmi_f12_set_hardcoded_desc(). Make sure not to set it to 0 here.
+ */
+ if (!sensor->pkt_size)
+ sensor->pkt_size = rmi_register_desc_calc_size(&f12->data_reg_desc);
+
+ sensor->axis_align =
+ f12->sensor_pdata.axis_align;
+
+ sensor->x_mm = f12->sensor_pdata.x_mm;
+ sensor->y_mm = f12->sensor_pdata.y_mm;
+ sensor->dribble = f12->sensor_pdata.dribble;
+
+ if (sensor->sensor_type == rmi_sensor_default)
+ sensor->sensor_type =
+ f12->sensor_pdata.sensor_type;
+
+ rmi_dbg(RMI_DEBUG_FN, &fn->dev, "%s: data packet size: %d\n", __func__,
+ sensor->pkt_size);
+
+ sensor->data_pkt = devm_kzalloc(&fn->dev, sensor->pkt_size, GFP_KERNEL);
+ if (!sensor->data_pkt)
+ return -ENOMEM;
+
+ return 0;
+}
+
static int rmi_f12_probe(struct rmi_function *fn)
{
struct f12_data *f12;
@@ -351,6 +420,7 @@ static int rmi_f12_probe(struct rmi_function *fn)
struct rmi_driver_data *drvdata = dev_get_drvdata(&rmi_dev->dev);
u16 data_offset = 0;
int mask_size;
+ bool hardcoded_desc_quirk = false;
rmi_dbg(RMI_DEBUG_FN, &fn->dev, "%s\n", __func__);
@@ -365,9 +435,9 @@ static int rmi_f12_probe(struct rmi_function *fn)
++query_addr;
if (!(buf & BIT(0))) {
- dev_err(&fn->dev,
- "Behavior of F12 without register descriptors is undefined.\n");
- return -ENODEV;
+ rmi_dbg(RMI_DEBUG_FN, &fn->dev,
+ "No register descriptors defined for F12, using fallback\n");
+ hardcoded_desc_quirk = true;
}
f12 = devm_kzalloc(&fn->dev, sizeof(struct f12_data) + mask_size * 2,
@@ -375,6 +445,8 @@ static int rmi_f12_probe(struct rmi_function *fn)
if (!f12)
return -ENOMEM;
+ dev_set_drvdata(&fn->dev, f12);
+
f12->abs_mask = (unsigned long *)((char *)f12
+ sizeof(struct f12_data));
f12->rel_mask = (unsigned long *)((char *)f12
@@ -393,6 +465,18 @@ static int rmi_f12_probe(struct rmi_function *fn)
f12->sensor_pdata = pdata->sensor_pdata;
}
+ sensor = &f12->sensor;
+
+ if (hardcoded_desc_quirk) {
+ rmi_f12_set_hardcoded_desc(fn, f12);
+
+ ret = rmi_f12_sensor_init(fn, f12);
+ if (ret)
+ return ret;
+
+ goto skip_register_desc;
+ }
+
ret = rmi_read_register_desc(rmi_dev, query_addr,
&f12->query_reg_desc);
if (ret) {
@@ -423,29 +507,9 @@ static int rmi_f12_probe(struct rmi_function *fn)
}
query_addr += 3;
- sensor = &f12->sensor;
- sensor->fn = fn;
- f12->data_addr = fn->fd.data_base_addr;
- sensor->pkt_size = rmi_register_desc_calc_size(&f12->data_reg_desc);
-
- sensor->axis_align =
- f12->sensor_pdata.axis_align;
-
- sensor->x_mm = f12->sensor_pdata.x_mm;
- sensor->y_mm = f12->sensor_pdata.y_mm;
- sensor->dribble = f12->sensor_pdata.dribble;
-
- if (sensor->sensor_type == rmi_sensor_default)
- sensor->sensor_type =
- f12->sensor_pdata.sensor_type;
-
- rmi_dbg(RMI_DEBUG_FN, &fn->dev, "%s: data packet size: %d\n", __func__,
- sensor->pkt_size);
- sensor->data_pkt = devm_kzalloc(&fn->dev, sensor->pkt_size, GFP_KERNEL);
- if (!sensor->data_pkt)
- return -ENOMEM;
-
- dev_set_drvdata(&fn->dev, f12);
+ ret = rmi_f12_sensor_init(fn, f12);
+ if (ret)
+ return ret;
ret = rmi_f12_read_sensor_tuning(f12);
if (ret)
@@ -543,6 +607,7 @@ static int rmi_f12_probe(struct rmi_function *fn)
data_offset += item->reg_size;
}
+skip_register_desc:
/* allocate the in-kernel tracking buffers */
sensor->tracking_pos = devm_kcalloc(&fn->dev,
sensor->nbr_fingers, sizeof(struct input_mt_pos),
--
2.53.0
^ permalink raw reply related
* [PATCH v8 1/7] dt-bindings: input: syna,rmi4: Document syna,rmi4-s3706b
From: David Heidelberg via B4 Relay @ 2026-03-24 19:40 UTC (permalink / raw)
To: Kaustabh Chakraborty, Dmitry Torokhov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jason A. Donenfeld,
Matthias Schiffer, Vincent Huang, Casey Connolly
Cc: David Heidelberg, linux-input, devicetree, linux-kernel,
phone-devel, Krzysztof Kozlowski
In-Reply-To: <20260324-synaptics-rmi4-v8-0-2168d2df68f5@ixit.cz>
From: David Heidelberg <david@ixit.cz>
Mostly irrelevant for authentic Synaptics touchscreens, but very important
for applying workarounds to cheap TS knockoffs.
These knockoffs work well with the downstream driver, and since the user
has no way to distinguish them, later in this patch set, we introduce
workarounds to ensure they function as well as possible.
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: David Heidelberg <david@ixit.cz>
---
Documentation/devicetree/bindings/input/syna,rmi4.yaml | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/input/syna,rmi4.yaml b/Documentation/devicetree/bindings/input/syna,rmi4.yaml
index 8685ef4481f4a..fb4804ac3544d 100644
--- a/Documentation/devicetree/bindings/input/syna,rmi4.yaml
+++ b/Documentation/devicetree/bindings/input/syna,rmi4.yaml
@@ -18,9 +18,14 @@ description: |
properties:
compatible:
- enum:
- - syna,rmi4-i2c
- - syna,rmi4-spi
+ oneOf:
+ - enum:
+ - syna,rmi4-i2c
+ - syna,rmi4-spi
+ - items:
+ - enum:
+ - syna,rmi4-s3706b # OnePlus 6/6T
+ - const: syna,rmi4-i2c
reg:
maxItems: 1
--
2.53.0
^ permalink raw reply related
* [PATCH v8 2/7] Input: synaptics-rmi4 - handle duplicate/unknown PDT entries
From: David Heidelberg via B4 Relay @ 2026-03-24 19:40 UTC (permalink / raw)
To: Kaustabh Chakraborty, Dmitry Torokhov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jason A. Donenfeld,
Matthias Schiffer, Vincent Huang, Casey Connolly
Cc: David Heidelberg, linux-input, devicetree, linux-kernel,
phone-devel
In-Reply-To: <20260324-synaptics-rmi4-v8-0-2168d2df68f5@ixit.cz>
From: Casey Connolly <casey.connolly@linaro.org>
Some third party rmi4-compatible ICs don't expose their PDT entries
very well. Add a few checks to skip duplicate entries as well as entries
for unsupported functions.
This is required to support some phones with third party displays.
Validated on a stock OnePlus 6T (original parts):
manufacturer: Synaptics, product: S3706B, fw id: 2852315
Co-developed-by: Kaustabh Chakraborty <kauschluss@disroot.org>
Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
Co-developed-by: David Heidelberg <david@ixit.cz>
Signed-off-by: David Heidelberg <david@ixit.cz>
---
drivers/input/rmi4/rmi_driver.c | 41 +++++++++++++++++++++++++++++++++++------
drivers/input/rmi4/rmi_driver.h | 7 +++++++
2 files changed, 42 insertions(+), 6 deletions(-)
diff --git a/drivers/input/rmi4/rmi_driver.c b/drivers/input/rmi4/rmi_driver.c
index ccd9338a44dbe..dea04cf076eb4 100644
--- a/drivers/input/rmi4/rmi_driver.c
+++ b/drivers/input/rmi4/rmi_driver.c
@@ -494,12 +494,38 @@ static void rmi_driver_copy_pdt_to_fd(const struct pdt_entry *pdt,
fd->function_version = pdt->function_version;
}
+static bool rmi_pdt_entry_is_valid(struct rmi_device *rmi_dev,
+ struct pdt_scan_state *state, u8 fn)
+{
+ switch (fn) {
+ case 0x01:
+ case 0x03:
+ case 0x11:
+ case 0x12:
+ case 0x30:
+ case 0x34:
+ case 0x3a:
+ case 0x54:
+ case 0x55:
+ if (state->pdts[fn] == true)
+ return false;
+ break;
+ default:
+ rmi_dbg(RMI_DEBUG_CORE, &rmi_dev->dev,
+ "PDT has unknown function number %#02x\n", fn);
+ return false;
+ }
+
+ state->pdts[fn] = true;
+ return true;
+}
+
#define RMI_SCAN_CONTINUE 0
#define RMI_SCAN_DONE 1
static int rmi_scan_pdt_page(struct rmi_device *rmi_dev,
int page,
- int *empty_pages,
+ struct pdt_scan_state *state,
void *ctx,
int (*callback)(struct rmi_device *rmi_dev,
void *ctx,
@@ -522,6 +548,9 @@ static int rmi_scan_pdt_page(struct rmi_device *rmi_dev,
if (RMI4_END_OF_PDT(pdt_entry.function_number))
break;
+ if (!rmi_pdt_entry_is_valid(rmi_dev, state, pdt_entry.function_number))
+ continue;
+
retval = callback(rmi_dev, ctx, &pdt_entry);
if (retval != RMI_SCAN_CONTINUE)
return retval;
@@ -532,11 +561,11 @@ static int rmi_scan_pdt_page(struct rmi_device *rmi_dev,
* or more is found, stop scanning.
*/
if (addr == pdt_start)
- ++*empty_pages;
+ ++state->empty_pages;
else
- *empty_pages = 0;
+ state->empty_pages = 0;
- return (data->bootloader_mode || *empty_pages >= 2) ?
+ return (data->bootloader_mode || state->empty_pages >= 2) ?
RMI_SCAN_DONE : RMI_SCAN_CONTINUE;
}
@@ -545,11 +574,11 @@ int rmi_scan_pdt(struct rmi_device *rmi_dev, void *ctx,
void *ctx, const struct pdt_entry *entry))
{
int page;
- int empty_pages = 0;
+ struct pdt_scan_state state = {0, 0, {0}};
int retval = RMI_SCAN_DONE;
for (page = 0; page <= RMI4_MAX_PAGE; page++) {
- retval = rmi_scan_pdt_page(rmi_dev, page, &empty_pages,
+ retval = rmi_scan_pdt_page(rmi_dev, page, &state,
ctx, callback);
if (retval != RMI_SCAN_CONTINUE)
break;
diff --git a/drivers/input/rmi4/rmi_driver.h b/drivers/input/rmi4/rmi_driver.h
index e84495caab151..2c47373c3d177 100644
--- a/drivers/input/rmi4/rmi_driver.h
+++ b/drivers/input/rmi4/rmi_driver.h
@@ -46,6 +46,13 @@ struct pdt_entry {
u8 function_number;
};
+#define RMI_PDT_MAX 0x55
+
+struct pdt_scan_state {
+ u8 empty_pages;
+ bool pdts[RMI_PDT_MAX + 1];
+};
+
#define RMI_REG_DESC_PRESENSE_BITS (32 * BITS_PER_BYTE)
#define RMI_REG_DESC_SUBPACKET_BITS (37 * BITS_PER_BYTE)
--
2.53.0
^ permalink raw reply related
* [PATCH v8 0/7] Input: synaptics-rmi4 - add quirks for third party touchscreen controllers
From: David Heidelberg via B4 Relay @ 2026-03-24 19:40 UTC (permalink / raw)
To: Kaustabh Chakraborty, Dmitry Torokhov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jason A. Donenfeld,
Matthias Schiffer, Vincent Huang, Casey Connolly
Cc: David Heidelberg, linux-input, devicetree, linux-kernel,
phone-devel, Krzysztof Kozlowski
With the growing popularity of running upstream Linux on mobile devices,
we're beginning to run into more and more edgecases. The OnePlus 6 is a
fairly well supported 2018 era smartphone, selling over a million units
in it's first 22 days. With this level of popularity, it's almost
inevitable that we get third party replacement displays, and as a
result, replacement touchscreen controllers.
The OnePlus 6 shipped with an extremely usecase specific touchscreen
driver, it implemented only the bare minimum parts of the highly generic
rmi4 protocol, instead hardcoding most of the register addresses.
As a result, the third party touchscreen controllers that are often
found in replacement screens, implement only the registers that the
downstream driver reads from. They additionally have other restrictions
such as heavy penalties on unaligned reads.
This series attempts to implement the necessary workaround to support
some of these chips with the rmi4 driver. Although it's worth noting
that at the time of writing there are other unofficial controllers in
the wild that don't work even with these patches.
We have been shipping these patches in postmarketOS for the last several
years, and they are known to not cause any regressions on the OnePlus
6/6T (with the official Synaptics controller), however I don't own any
other rmi4 hardware to further validate this.
The series is also available (until merged) at
https://codeberg.org/sdm845/linux/commits/b4/synaptics-rmi4
---
Changes in v8:
- The pdt_scan_state->pdts array should actually be of size
(RMI_PDT_MAX+1). (Casey)
- Move the pdt_count introduction to the relevant patch. (Casey)
- Link to v7: https://lore.kernel.org/r/20260320-synaptics-rmi4-v7-0-379360de18d0@ixit.cz
Changes in v7:
- Rebased on top of next-20260320, no other changes.
- Link to v6: https://lore.kernel.org/r/20251113-synaptics-rmi4-v6-0-d9836afab801@ixit.cz
Changes in v6:
- Rebased on top of next-20251113.
- No other change since the Rob Herring comment.
- Link to v5: https://lore.kernel.org/r/20250410-synaptics-rmi4-v5-0-b41bb90f78b9@ixit.cz
Changes in v5:
- Removed -i2c suffix from rmi4-s3706b-i2c (Krzysztof).
- Link to v4: https://lore.kernel.org/r/20250402-synaptics-rmi4-v4-0-1bb95959e564@ixit.cz
Changes in v4:
- Replaced patch "dt-bindings: input: syna,rmi4: document syna,pdt-fallback-desc"
with patch documenting specific touchscreen model used in OnePlus 6 and 6T.
- Fixed zero electrode return code (Dmitry).
- Switched the duplicate detection algo to bitmap (Dmitry).
- Optimized rmi_device_platform_data struct to avoid unnecessary
padding.
- Changed fallback_size from int to unsigned int.
- Changed SoB from nickname and old address (methanal <baclofen@tuta.io>) to
Kaustabh Chakraborty <kauschluss@disroot.org>.
Verified ownership through the sdm845 chatroom on Matrix.
- Link to v3: https://lore.kernel.org/r/20250308-synaptics-rmi4-v3-0-215d3e7289a2@ixit.cz
Changes in v3:
- reworded dt-bindings property description
- fixed the rmi_driver_of_probe definition for non device-tree builds.
- fixed some indentation issues reported by checkpatch
- change rmi_pdt_entry_is_valid() variable to unsigned
- Link to v2: https://lore.kernel.org/all/20230929-caleb-rmi4-quirks-v2-0-b227ac498d88@linaro.org
Changes in v2:
- Improve dt-bindings patch (thanks Rob)
- Add missing cast in patch 5 to fix the pointer arithmetic
- Link to v1: https://lore.kernel.org/r/20230929-caleb-rmi4-quirks-v1-0-cc3c703f022d@linaro.org
---
Casey Connolly (1):
Input: synaptics-rmi4 - handle duplicate/unknown PDT entries
David Heidelberg (1):
dt-bindings: input: syna,rmi4: Document syna,rmi4-s3706b
Kaustabh Chakraborty (5):
Input: synaptics-rmi4 - f12: use hardcoded values for aftermarket touch ICs
Input: synaptics-rmi4 - f55: handle zero electrode count
Input: synaptics-rmi4 - don't do unaligned reads in IRQ context
Input: synaptics-rmi4 - read product ID on aftermarket touch ICs
Input: synaptics-rmi4 - support fallback values for PDT descriptor bytes
.../devicetree/bindings/input/syna,rmi4.yaml | 11 +-
drivers/input/rmi4/rmi_driver.c | 124 +++++++++++++++++----
drivers/input/rmi4/rmi_driver.h | 10 ++
drivers/input/rmi4/rmi_f01.c | 14 +++
drivers/input/rmi4/rmi_f12.c | 117 ++++++++++++++-----
drivers/input/rmi4/rmi_f55.c | 5 +
include/linux/rmi.h | 3 +
7 files changed, 234 insertions(+), 50 deletions(-)
---
base-commit: 85964cdcad0fac9a0eb7b87a0f9d88cc074b854c
change-id: 20250308-synaptics-rmi4-c832b2f73ceb
Best regards,
--
David Heidelberg <david@ixit.cz>
^ permalink raw reply
* [PATCH] HID: hid-lenovo-go: fix LEDS dependencies
From: Arnd Bergmann @ 2026-03-24 19:20 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires, Derek J. Clark, Mark Pearson,
Mario Limonciello, Ethan Tidmore
Cc: Arnd Bergmann, Aditya Garg, Jonathan Denose, Geert Uytterhoeven,
linux-input, linux-kernel
From: Arnd Bergmann <arnd@arndb.de>
The newly added hid-lenovo-go and hid-lenovo-go-s drivers attempt to
'select LEDS_CLASS', which has a dependency on NEW_LEDS, causing a build
failure when NEW_LEDS itself it disabled:
WARNING: unmet direct dependencies detected for LEDS_CLASS
Depends on [n]: NEW_LEDS [=n]
Selected by [m]:
- HID_LENOVO_GO [=m] && HID_SUPPORT [=y] && HID [=m] && USB_HID [=m]
- HID_LENOVO_GO_S [=m] && HID_SUPPORT [=y] && HID [=m] && USB_HID [=m]
WARNING: unmet direct dependencies detected for LEDS_CLASS_MULTICOLOR
Depends on [n]: NEW_LEDS [=n] && LEDS_CLASS [=m]
Selected by [m]:
- HID_LENOVO_GO [=m] && HID_SUPPORT [=y] && HID [=m] && USB_HID [=m]
- HID_LENOVO_GO_S [=m] && HID_SUPPORT [=y] && HID [=m] && USB_HID [=m]
ERROR: modpost: "led_set_brightness_nopm" [drivers/leds/led-class.ko] undefined!
ERROR: modpost: "led_set_brightness" [drivers/leds/led-class.ko] undefined!
ERROR: modpost: "led_get_color_name" [drivers/leds/led-class-multicolor.ko] undefined!
ERROR: modpost: "led_set_brightness" [drivers/leds/led-class-multicolor.ko] undefined!
Device drivers generally should not select other subsystems like this, as
that tends to cause dependency problems including loops in the dependency
graph.
Change these two and the older hid-lenovo driver to behave the same way as all
other HID drivers and use 'depends on LEDS_CLASS' or 'depends on LEDS_CLASS_MULTICOLOR'
instead, which itself has NEW_LEDS and LEDS_CLASS as dependencies.
Fixes: a23f3497bf20 ("HID: hid-lenovo-go-s: Add Lenovo Legion Go S Series HID Driver")
Fixes: d69ccfcbc955 ("HID: hid-lenovo-go: Add Lenovo Legion Go Series HID Driver")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/hid/Kconfig | 9 +++------
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
index 10c12d8e6557..f658ed0168ea 100644
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
@@ -610,8 +610,7 @@ config HID_LED
config HID_LENOVO
tristate "Lenovo / Thinkpad devices"
- select NEW_LEDS
- select LEDS_CLASS
+ depends on LEDS_CLASS
help
Support for IBM/Lenovo devices that are not fully compliant with HID standard.
@@ -626,8 +625,7 @@ config HID_LENOVO
config HID_LENOVO_GO
tristate "HID Driver for Lenovo Legion Go Series Controllers"
depends on USB_HID
- select LEDS_CLASS
- select LEDS_CLASS_MULTICOLOR
+ depends on LEDS_CLASS_MULTICOLOR
help
Support for Lenovo Legion Go devices with detachable controllers.
@@ -638,8 +636,7 @@ config HID_LENOVO_GO
config HID_LENOVO_GO_S
tristate "HID Driver for Lenovo Legion Go S Controller"
depends on USB_HID
- select LEDS_CLASS
- select LEDS_CLASS_MULTICOLOR
+ depends on LEDS_CLASS_MULTICOLOR
help
Support for Lenovo Legion Go S Handheld Console Controller.
--
2.39.5
^ permalink raw reply related
* [PATCH] HID: ft260: validate report size in raw_event handler
From: Sebastian Josue Alba Vives @ 2026-03-24 17:35 UTC (permalink / raw)
To: michael.zaidman, jikos, bentiss
Cc: linux-i2c, linux-input, linux-kernel, stable,
Sebastian Josue Alba Vives
ft260_raw_event() casts the raw data buffer to a
ft260_i2c_input_report struct and accesses its fields without
validating the size parameter. Since __hid_input_report() invokes
the driver's raw_event callback before hid_report_raw_event()
performs its own report-size validation, a device sending a
truncated HID report can cause out-of-bounds heap reads in the
kernel.
In the I2C response path, xfer->length (data[1]) is used as the
length for a memcpy into dev->read_buf. While xfer->length is
checked against dev->read_len, there is no check that size is large
enough to actually contain xfer->length bytes of data starting at
offset 2. A malicious USB device could therefore cause an OOB read
from the kernel heap, with the result accessible from userspace via
the I2C read interface.
FT260 devices use 64-byte HID reports. Add a check at the top of
the handler to reject any report shorter than expected, and log a
warning to aid debugging.
Cc: stable@vger.kernel.org
Signed-off-by: Sebastian Josue Alba Vives <sebasjosue84@gmail.com>
---
drivers/hid/hid-ft260.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/hid/hid-ft260.c b/drivers/hid/hid-ft260.c
index 333341e80..7ca323992 100644
--- a/drivers/hid/hid-ft260.c
+++ b/drivers/hid/hid-ft260.c
@@ -1068,6 +1068,12 @@ static int ft260_raw_event(struct hid_device *hdev, struct hid_report *report,
struct ft260_device *dev = hid_get_drvdata(hdev);
struct ft260_i2c_input_report *xfer = (void *)data;
+ /* FT260 always sends 64-byte reports */
+ if (size < 64) {
+ hid_warn(hdev, "report too short: %d < 64\n", size);
+ return 0;
+ }
+
if (xfer->report >= FT260_I2C_REPORT_MIN &&
xfer->report <= FT260_I2C_REPORT_MAX) {
ft260_dbg("i2c resp: rep %#02x len %d\n", xfer->report,
--
2.43.0
^ permalink raw reply related
* [PATCH v2] HID: mcp2221: validate report size in raw_event handler
From: Sebastian Josue Alba Vives @ 2026-03-24 17:06 UTC (permalink / raw)
To: gupt21, jikos, bentiss
Cc: linux-i2c, linux-input, linux-kernel, stable,
Sebastian Josue Alba Vives
In-Reply-To: <20260324062403.341855-1-sebasjosue84@gmail.com>
mcp2221_raw_event() accesses the data buffer at offsets up to 55
without validating the size parameter. Since __hid_input_report()
invokes the driver's raw_event callback before
hid_report_raw_event() performs its own report-size validation, a
device sending a truncated HID report can cause out-of-bounds heap
reads in the kernel.
The most critical access is the memcpy from data[50] into
mcp->adc_values (6 bytes) when CONFIG_IIO is reachable. Other
unchecked accesses include data[20] and a memcpy at data[22].
Additionally, a memcpy with device-controlled length (data[3],
up to 60 bytes) from data[4] does not verify that size is large
enough to cover the copy.
MCP2221 devices use 64-byte HID reports. Add a check at the top of
the handler to reject any report shorter than expected, and log a
warning to aid debugging.
Cc: stable@vger.kernel.org
Signed-off-by: Sebastian Josue Alba Vives <sebasjosue84@gmail.com>
---
drivers/hid/hid-mcp2221.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/hid/hid-mcp2221.c b/drivers/hid/hid-mcp2221.c
index ef3b5c77c..770c305d8 100644
--- a/drivers/hid/hid-mcp2221.c
+++ b/drivers/hid/hid-mcp2221.c
@@ -850,6 +850,11 @@ static int mcp2221_raw_event(struct hid_device *hdev,
{
u8 *buf;
struct mcp2221 *mcp = hid_get_drvdata(hdev);
+ /* MCP2221 always sends 64-byte reports */
+ if (size < 64) {
+ hid_warn(hdev, "report too short: %d < 64\n", size);
+ return 0;
+ }
switch (data[0]) {
--
2.43.0
^ permalink raw reply related
* [PATCH v2 2/2] HID: logitech-dj: Prevent REPORT_ID_DJ_SHORT related user initiated OOB write
From: Lee Jones @ 2026-03-24 14:36 UTC (permalink / raw)
To: lee, Filipe Laíns, Jiri Kosina, Benjamin Tissoires,
linux-input, linux-kernel
In-Reply-To: <20260324143651.342273-1-lee@kernel.org>
logi_dj_recv_send_report() assumes that all incoming REPORT_ID_DJ_SHORT
reports are 14 Bytes (DJREPORT_SHORT_LENGTH - 1) long. It uses that
assumption to load the associated field's 'value' array with 14 Bytes of
data. However, if a malicious user only sends say 1 Byte of data,
'report_count' will be 1 and only 1 Byte of memory will be allocated to
the 'value' Byte array. When we come to populate 'value[1-13]' we will
experience an OOB write.
Signed-off-by: Lee Jones <lee@kernel.org>
---
v1 => v2: Move handling to .probe()
drivers/hid/hid-logitech-dj.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/hid/hid-logitech-dj.c b/drivers/hid/hid-logitech-dj.c
index 32139b2561c0..a8082199d13d 100644
--- a/drivers/hid/hid-logitech-dj.c
+++ b/drivers/hid/hid-logitech-dj.c
@@ -1859,6 +1859,7 @@ static int logi_dj_probe(struct hid_device *hdev,
const struct hid_device_id *id)
{
struct hid_report_enum *input_report_enum;
+ struct hid_report_enum *output_report_enum;
struct hid_report *rep;
struct dj_receiver_dev *djrcv_dev;
struct usb_interface *intf;
@@ -1903,6 +1904,15 @@ static int logi_dj_probe(struct hid_device *hdev,
}
}
+ output_report_enum = &hdev->report_enum[HID_OUTPUT_REPORT];
+ rep = output_report_enum->report_id_hash[REPORT_ID_DJ_SHORT];
+
+ if (rep->maxfield < 1 || rep->field[0]->report_count != DJREPORT_SHORT_LENGTH - 1) {
+ hid_err(hdev, "Expected size of DJ short report is %d, but got %d",
+ DJREPORT_SHORT_LENGTH - 1, rep->field[0]->report_count);
+ return -EINVAL;
+ }
+
input_report_enum = &hdev->report_enum[HID_INPUT_REPORT];
/* no input reports, bail out */
--
2.53.0.983.g0bb29b3bc5-goog
^ permalink raw reply related
* [PATCH v2 1/2] HID: logitech-dj: Standardise hid_report_enum variable nomenclature
From: Lee Jones @ 2026-03-24 14:36 UTC (permalink / raw)
To: lee, Filipe Laíns, Jiri Kosina, Benjamin Tissoires,
linux-input, linux-kernel
Since we will need to differentiate between the two report_enum types
soon, let's unify the naming conventions now to save confusion and/or
unnecessary/unrelated changes in upcoming commits.
{input,output}_report_enum is used in other places to let's conform.
Signed-off-by: Lee Jones <lee@kernel.org>
---
v1 => v2: New patch
drivers/hid/hid-logitech-dj.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/hid/hid-logitech-dj.c b/drivers/hid/hid-logitech-dj.c
index 44b716697510..32139b2561c0 100644
--- a/drivers/hid/hid-logitech-dj.c
+++ b/drivers/hid/hid-logitech-dj.c
@@ -1858,7 +1858,7 @@ static int logi_dj_raw_event(struct hid_device *hdev,
static int logi_dj_probe(struct hid_device *hdev,
const struct hid_device_id *id)
{
- struct hid_report_enum *rep_enum;
+ struct hid_report_enum *input_report_enum;
struct hid_report *rep;
struct dj_receiver_dev *djrcv_dev;
struct usb_interface *intf;
@@ -1903,10 +1903,10 @@ static int logi_dj_probe(struct hid_device *hdev,
}
}
- rep_enum = &hdev->report_enum[HID_INPUT_REPORT];
+ input_report_enum = &hdev->report_enum[HID_INPUT_REPORT];
/* no input reports, bail out */
- if (list_empty(&rep_enum->report_list))
+ if (list_empty(&input_report_enum->report_list))
return -ENODEV;
/*
@@ -1914,7 +1914,7 @@ static int logi_dj_probe(struct hid_device *hdev,
* Note: we should theoretically check for HID++ and DJ
* collections, but this will do.
*/
- list_for_each_entry(rep, &rep_enum->report_list, list) {
+ list_for_each_entry(rep, &input_report_enum->report_list, list) {
if (rep->application == 0xff000001)
has_hidpp = true;
}
@@ -1927,7 +1927,7 @@ static int logi_dj_probe(struct hid_device *hdev,
return -ENODEV;
/* get the current application attached to the node */
- rep = list_first_entry(&rep_enum->report_list, struct hid_report, list);
+ rep = list_first_entry(&input_report_enum->report_list, struct hid_report, list);
djrcv_dev = dj_get_receiver_dev(hdev, id->driver_data,
rep->application, has_hidpp);
if (!djrcv_dev) {
@@ -1935,7 +1935,7 @@ static int logi_dj_probe(struct hid_device *hdev,
return -ENOMEM;
}
- if (!rep_enum->numbered)
+ if (!input_report_enum->numbered)
djrcv_dev->unnumbered_application = rep->application;
/* Starts the usb device and connects to upper interfaces hiddev and
--
2.53.0.983.g0bb29b3bc5-goog
^ permalink raw reply related
* Re: [PATCH v2 00/19] tracepoint: Avoid double static_branch evaluation at guarded call sites
From: Steven Rostedt @ 2026-03-24 14:28 UTC (permalink / raw)
To: Vineeth Pillai (Google)
Cc: Peter Zijlstra, Dmitry Ilvokhin, Masami Hiramatsu,
Mathieu Desnoyers, Ingo Molnar, Jens Axboe, io-uring,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Alexei Starovoitov, Daniel Borkmann, Marcelo Ricardo Leitner,
Xin Long, Jon Maloy, Aaron Conole, Eelco Chaudron, Ilya Maximets,
netdev, bpf, linux-sctp, tipc-discussion, dev, Jiri Pirko,
Oded Gabbay, Koby Elbaz, dri-devel, Rafael J. Wysocki,
Viresh Kumar, Gautham R. Shenoy, Huang Rui, Mario Limonciello,
Len Brown, Srinivas Pandruvada, linux-pm, MyungJoo Ham,
Kyungmin Park, Chanwoo Choi, Christian König, Sumit Semwal,
linaro-mm-sig, Eddie James, Andrew Jeffery, Joel Stanley,
linux-fsi, David Airlie, Simona Vetter, Alex Deucher,
Danilo Krummrich, Matthew Brost, Philipp Stanner, Harry Wentland,
Leo Li, amd-gfx, Jiri Kosina, Benjamin Tissoires, linux-input,
Wolfram Sang, linux-i2c, Mark Brown, Michael Hennerich,
Nuno Sá, linux-spi, James E.J. Bottomley, Martin K. Petersen,
linux-scsi, Chris Mason, David Sterba, linux-btrfs,
Thomas Gleixner, Andrew Morton, SeongJae Park, linux-mm,
Borislav Petkov, Dave Hansen, x86, linux-trace-kernel,
linux-kernel
In-Reply-To: <20260323160052.17528-1-vineeth@bitbyteword.org>
On Mon, 23 Mar 2026 12:00:19 -0400
"Vineeth Pillai (Google)" <vineeth@bitbyteword.org> wrote:
> When a caller already guards a tracepoint with an explicit enabled check:
>
> if (trace_foo_enabled() && cond)
> trace_foo(args);
Thanks Vineeth!
I'm going to start pulling in this series. I'll take the first patch, and
then any patch that has an Acked-by or Reviewed-by from the maintainer.
For patches without acks, I'll leave alone and then after the first patch
gets merged into mainline, the maintainers could pull in their own patches
at their own convenience. Unless of course they speak up now if they want
me to take them ;-)
-- Steve
^ permalink raw reply
* [PATCH] hid: usbhid: fix deadlock in hid_post_reset()
From: Oliver Neukum @ 2026-03-24 14:24 UTC (permalink / raw)
To: bentiss, jikos, linux-input, linux-usb; +Cc: Oliver Neukum
You can build a USB device that includes a HID component
and a storage or UAS component. The components can be reset
only together. That means that hid_pre_reset() and hid_post_reset()
are in the block IO error handling. Hence no memory allocation
used in them may do block IO because the IO can deadlock
on the mutex held while resetting a device and calling the
interface drivers.
Use GFP_NOIO for all allocations in them.
Fixes: dc3c78e434690 ("HID: usbhid: Check HID report descriptor contents after device reset")
Signed-off-by: Oliver Neukum <oneukum@suse.com>
---
drivers/hid/usbhid/hid-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
index ddd5d77fb5a5..fd3e1aedc5cb 100644
--- a/drivers/hid/usbhid/hid-core.c
+++ b/drivers/hid/usbhid/hid-core.c
@@ -1552,7 +1552,7 @@ static int hid_post_reset(struct usb_interface *intf)
* configuration descriptors passed, we already know that
* the size of the HID report descriptor has not changed.
*/
- rdesc = kmalloc(hid->dev_rsize, GFP_KERNEL);
+ rdesc = kmalloc(hid->dev_rsize, GFP_NOIO);
if (!rdesc)
return -ENOMEM;
--
2.53.0
^ permalink raw reply related
* Re: [PATCH 2/3] Input: adafruit-seesaw - add interrupt support
From: Charles Dias @ 2026-03-24 13:59 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Anshul Dalal, Shuah Khan, Brigham Campbell, linux-input,
linux-kernel, Charles Dias
In-Reply-To: <acDLSiujizhuYfOt@google.com>
On Mon, Mar 23, 2026 at 2:12 AM Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
>
> Hi Charles,
>
> On Sat, Mar 21, 2026 at 05:24:45PM -0300, charles.embedded@gmail.com wrote:
> > @@ -289,6 +341,19 @@ static int seesaw_probe(struct i2c_client *client)
> > input_set_max_poll_interval(seesaw->input_dev, SEESAW_GAMEPAD_POLL_MAX);
> > input_set_min_poll_interval(seesaw->input_dev, SEESAW_GAMEPAD_POLL_MIN);
> >
> > + if (client->irq) {
> > + err = seesaw_register_write_u32(client, SEESAW_GPIO_INTENSET, SEESAW_BUTTON_MASK);
> > + if (err)
> > + return dev_err_probe(&client->dev, err,
> > + "failed to enable hardware interrupts\n");
>
> Maybe this should be in seesaw_open()?
>
> Thanks.
>
> --
> Dmitry
Hi Dmitry. Thank you for your review!
Since this is a one-time setup, I believe it should remain as is
within the seesaw_probe() function, similar to other pin
configurations.
Please let me know if I'm missing any point here.
Best regards,
Charles Dias
^ permalink raw reply
* Re: [PATCH v2] Input: penmount: bound packet buffer indices in IRQ path
From: Andy Shevchenko @ 2026-03-24 13:47 UTC (permalink / raw)
To: Pengpeng Hou; +Cc: dmitry.torokhov, kees, linux-input, linux-kernel
In-Reply-To: <20260324131442.27632-1-pengpeng@iscas.ac.cn>
On Tue, Mar 24, 2026 at 09:14:42PM +0800, Pengpeng Hou wrote:
> pm_interrupt() stores each incoming byte into pm->data[] before the
> packet parser gets a chance to reset pm->idx. If the incoming serial
> stream never matches one of the expected packet headers, pm->idx can
> advance past the fixed receive buffer and the next IRQ will write beyond
> PM_MAX_LENGTH.
>
> Reset stale indices before storing the next byte. Once pm->idx has
> already moved past the valid packet buffer state, the current partial
> packet can no longer be trusted, so the smallest local recovery is to
> drop that stale state and resynchronize from the current byte instead of
> carrying the invalid index into the next interrupt.
>
> Found by static code analysis.
Missed blank line here. No need to resend until maintainers ask explicitly for
that.
...
The explanation sounds sane, but I'm not familiar enough with how this device
works. In case others consider this good, feel free to add
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: Question regarding error handling in usbhid
From: Alan Stern @ 2026-03-24 13:40 UTC (permalink / raw)
To: Oliver Neukum; +Cc: USB list, linux-input@vger.kernel.org
In-Reply-To: <8d665258-6dd6-404a-85e0-a2f3420cd992@suse.com>
On Tue, Mar 24, 2026 at 10:57:16AM +0100, Oliver Neukum wrote:
> Hi,
>
> hid_io_error(), in case it decides that a reset is necessary,
> schedules reset_work(). reset_work() in turn calls usb_queue_reset_device().
> Why? Is there a reason usb_queue_reset_device() is not used directly
> in hid_io_error()?
This is partly explained in the changelog for commit 8f507ef522d5 ("HID:
usbhid: improve handling of Clear-Halt and reset"):
The way resets are carried out is also changed. Now the driver will
call usb_queue_reset_device() instead of calling usb_reset_device()
directly. This avoids a deadlock that would arise when a device is
unplugged: The hid_reset() routine runs as a workqueue item, a reset
attempt after the device has been unplugged will fail, failure will
cause usbhid to be unbound, and the disconnect routine will try to do
cancel_work_sync(). The usb_queue_reset_device() implementation is
carefully written to handle scenarios like this one properly.
The other part of the explanation is that the reset code was added to
hid_io_error() before usb_queue_reset_device() existed (2006 vs 2008).
Alan Stern
^ permalink raw reply
* [PATCH v2] Input: penmount: bound packet buffer indices in IRQ path
From: Pengpeng Hou @ 2026-03-24 13:14 UTC (permalink / raw)
To: dmitry.torokhov
Cc: andriy.shevchenko, kees, linux-input, linux-kernel, pengpeng
In-Reply-To: <20260323121715.74954-1-pengpeng@iscas.ac.cn>
pm_interrupt() stores each incoming byte into pm->data[] before the
packet parser gets a chance to reset pm->idx. If the incoming serial
stream never matches one of the expected packet headers, pm->idx can
advance past the fixed receive buffer and the next IRQ will write beyond
PM_MAX_LENGTH.
Reset stale indices before storing the next byte. Once pm->idx has
already moved past the valid packet buffer state, the current partial
packet can no longer be trusted, so the smallest local recovery is to
drop that stale state and resynchronize from the current byte instead of
carrying the invalid index into the next interrupt.
Found by static code analysis.
Fixes: 98b013eb7a94 ("Input: penmount - rework handling of different protocols")
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
v2:
- note that the issue was found by static code analysis
- explain why resetting the stale index is the preferred resynchronization path
- add a Fixes tag
drivers/input/touchscreen/penmount.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/input/touchscreen/penmount.c b/drivers/input/touchscreen/penmount.c
index 4b57b6664e37..ba09096c6573 100644
--- a/drivers/input/touchscreen/penmount.c
+++ b/drivers/input/touchscreen/penmount.c
@@ -163,6 +163,9 @@ static irqreturn_t pm_interrupt(struct serio *serio,
{
struct pm *pm = serio_get_drvdata(serio);
+ if (pm->idx >= pm->packetsize || pm->idx >= PM_MAX_LENGTH)
+ pm->idx = 0;
+
pm->data[pm->idx] = data;
pm->parse_packet(pm);
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* Re: [PATCH] Input: penmount: bound packet buffer indices in IRQ path
From: Andy Shevchenko @ 2026-03-24 12:11 UTC (permalink / raw)
To: Pengpeng Hou; +Cc: andy, hansg, mchehab, gregkh, linux-kernel, linux-input
In-Reply-To: <20260324022950.456-1-pengpeng@iscas.ac.cn>
On Tue, Mar 24, 2026 at 10:29:50AM +0800, Pengpeng Hou wrote:
>
> This was found during static code analysis of the packet receive path.
>
> About the fix: my reasoning was that once pm->idx has already moved past
> the valid packet buffer state, the current partial packet is no longer
> usable, so the safest local recovery is to drop that stale state and
> resynchronize from the current byte. That is why I reset the index before
> storing the next byte.
>
> I did not choose to ignore the IRQ entirely because the interrupt has
> already delivered a byte, and simply returning without resetting the stale
> state would leave the parser in the same invalid condition for the next
> interrupt. Resetting the index seemed like the smallest change that both
> prevents the out-of-bounds write and lets the parser recover cleanly.
Good, (summary of) this should be in the commit message in the first place.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH AUTOSEL 6.19-5.10] HID: multitouch: Check to ensure report responses match the request
From: Sasha Levin @ 2026-03-24 11:19 UTC (permalink / raw)
To: patches, stable
Cc: Lee Jones, Benjamin Tissoires, Sasha Levin, jikos, linux-input,
linux-kernel
In-Reply-To: <20260324111931.3257972-1-sashal@kernel.org>
From: Lee Jones <lee@kernel.org>
[ Upstream commit e716edafedad4952fe3a4a273d2e039a84e8681a ]
It is possible for a malicious (or clumsy) device to respond to a
specific report's feature request using a completely different report
ID. This can cause confusion in the HID core resulting in nasty
side-effects such as OOB writes.
Add a check to ensure that the report ID in the response, matches the
one that was requested. If it doesn't, omit reporting the raw event and
return early.
Signed-off-by: Lee Jones <lee@kernel.org>
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
As Tissoires noted, `hid-vivaldi-common.c` has the same vulnerable
pattern. `wacom_sys.c` also has it. This confirms the bug is systemic.
Record: Same vulnerable pattern exists in hid-vivaldi-common.c and
wacom_sys.c. This is a known systemic issue.
## PHASE 6: CROSS-REFERENCING AND STABLE TREE ANALYSIS
### Step 6.1: DOES THE BUGGY CODE EXIST IN STABLE TREES?
The buggy code was introduced in commit `6d4f5440a3a2bb` from
2015-10-07, which is approximately kernel v4.4. This means the
vulnerable code exists in **ALL active stable trees** (5.4.y, 5.10.y,
5.15.y, 6.1.y, 6.6.y, 6.12.y, etc.).
Record: Buggy code exists in all active stable trees. Very wide
exposure.
### Step 6.2: CHECK FOR BACKPORT COMPLICATIONS
The fix is 7 lines added to a single function. The function has been
stable since 2015 with only minor modifications (2018 `ret` variable and
`hid_report_len` changes). The patch should apply cleanly to all stable
trees or with trivial context adjustments.
Record: Expected backport difficulty: clean apply or trivial conflicts.
### Step 6.3: CHECK IF RELATED FIXES ARE ALREADY IN STABLE
No related fixes for this specific issue found in any stable tree.
## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT
### Step 7.1: IDENTIFY THE SUBSYSTEM AND ITS CRITICALITY
- **Subsystem**: HID (Human Interface Devices) — drivers/hid/
- **Criticality**: IMPORTANT — HID affects all USB input devices (mice,
keyboards, touchscreens, touchpads). Multitouch is used by virtually
all modern laptops and tablets.
- **Security aspect**: USB devices are a common physical attack vector.
A malicious USB device can be plugged into any machine.
Record: [HID/multitouch] [IMPORTANT - affects all multitouch devices,
USB attack vector]
### Step 7.2: ASSESS SUBSYSTEM ACTIVITY
Active subsystem with regular commits. The HID maintainer (Benjamin
Tissoires) actively reviews and merges patches.
Record: Active subsystem, responsive maintainer.
## PHASE 8: IMPACT AND RISK ASSESSMENT
### Step 8.1: DETERMINE WHO IS AFFECTED
Any system using HID multitouch devices (virtually all laptops, tablets,
kiosks, and touchscreen-equipped systems). The vulnerability is
triggerable via a malicious USB device.
Record: Affected user population: universal (any system with USB ports
and HID multitouch support).
### Step 8.2: DETERMINE THE TRIGGER CONDITIONS
- **Trigger**: A USB device sends a HID feature report response with a
report ID different from the one requested
- **Attack scenario**: Malicious USB device (BadUSB-style attack) — plug
in a crafted USB device
- **Also possible**: Buggy/clumsy device firmware (accidental trigger)
- **Privilege**: Physical access to USB port required (no unprivileged
userspace trigger)
- **Reproducibility**: Deterministic — controlled by the device firmware
Record: Physical access via USB required. Deterministic trigger from
device side. No unprivileged software trigger.
### Step 8.3: DETERMINE THE FAILURE MODE SEVERITY
- **Failure mode**: Out-of-bounds memory write in kernel space
- **Consequences**: Memory corruption, potential kernel crash, potential
privilege escalation
- **Severity**: **CRITICAL** — OOB write is one of the most serious
vulnerability classes
Record: [OOB write / memory corruption] [Severity: CRITICAL]
### Step 8.4: CALCULATE RISK-BENEFIT RATIO
- **BENEFIT**: Very high — prevents OOB kernel memory corruption from
malicious USB devices
- **RISK**: Very low — 7 lines, simple ID comparison check, only affects
feature report processing in multitouch driver
- **Ratio**: Excellent — high benefit, minimal risk
Record: [Benefit: VERY HIGH] [Risk: VERY LOW] [Ratio: strongly favors
backporting]
## PHASE 9: FINAL SYNTHESIS
### Step 9.1: COMPILE THE EVIDENCE
**FOR backporting:**
- Fixes OOB write (CRITICAL severity security vulnerability)
- Exploitable via malicious USB device (physical attack vector)
- Fix is 7 lines, obviously correct (simple ID comparison)
- Accepted by HID maintainer Benjamin Tissoires
- Buggy code exists in ALL stable trees (since 2015, kernel v4.4)
- No dependencies on other patches (standalone fix)
- Clean backport expected
- Verified the OOB mechanism in `hid_report_raw_event()` — the `memset`
at line 2062 can write beyond buffer bounds
**AGAINST backporting:**
- Part of a 2-patch series, but patch 1/2 is independent (different
file, different issue)
- No explicit Cc: stable from author or reviewer (expected, that's why
we're reviewing)
- Requires physical USB access (not remotely exploitable)
**UNRESOLVED:**
- None significant — the bug mechanism is clearly verified
### Step 9.2: APPLY THE STABLE RULES CHECKLIST
1. **Obviously correct and tested?** YES — simple comparison of
report->id vs buf[0], reviewed and accepted by HID maintainer
2. **Fixes a real bug that affects users?** YES — OOB write from
malicious/buggy USB devices
3. **Important issue?** YES — memory corruption / security vulnerability
(CRITICAL)
4. **Small and contained?** YES — 7 lines in one function in one file
5. **No new features or APIs?** YES — purely validation logic
6. **Can apply to stable trees?** YES — code has been stable since 2015
### Step 9.3: CHECK FOR EXCEPTION CATEGORIES
Not an exception category — this is a standard security bug fix, which
is the primary use case for stable.
### Step 9.4: MAKE YOUR DECISION
This is a clear YES. It's a small, obviously correct security fix that
prevents OOB writes from malicious USB devices. The fix has been
reviewed and accepted by the HID maintainer. It affects all stable trees
and has minimal regression risk.
## Verification
- [Phase 1] Parsed tags: Signed-off-by Lee Jones (author), Signed-off-by
Benjamin Tissoires (HID maintainer). No Fixes/Reported-by/Cc:stable
tags.
- [Phase 2] Diff analysis: 7 lines added to `mt_get_feature()` in hid-
multitouch.c, adds report ID validation check before calling
`hid_report_raw_event()`
- [Phase 3] git blame: Buggy code introduced in commit `6d4f5440a3a2bb`
(2015-10-07, ~v4.4), present in ALL active stable trees
- [Phase 3] git log: No previous related fixes for this issue found
- [Phase 4] lore.kernel.org: Found patch submission at
`20260227163031.1166560-2-lee@kernel.org`. Patch 2/2 of series; patch
1/2 is independent (different file). Benjamin Tissoires reviewed and
accepted. He noted same bug exists in hid-vivaldi-common.c.
- [Phase 4] RFC v3: Tissoires NACK'd core-level fix, preferred per-
driver fixes like this one — confirming this is the maintainer's
preferred approach.
- [Phase 5] Callers: `mt_get_feature()` called from
`mt_feature_mapping()` at 3 sites during device enumeration — standard
path for multitouch devices
- [Phase 5] Verified OOB mechanism: `hid_report_raw_event()` at hid-
core.c:2040 uses `data[0]` (buf[0]) to look up report; at line 2062,
`memset(cdata + csize, 0, rsize - csize)` writes beyond buffer if
looked-up report is larger than the buffer allocated for the requested
report
- [Phase 5] Same vulnerable pattern confirmed in hid-vivaldi-common.c:87
and wacom_sys.c:397
- [Phase 6] Code exists in all active stable trees (v4.4+), fix should
apply cleanly
- [Phase 7] HID subsystem: IMPORTANT criticality, affects all multitouch
USB devices
- [Phase 8] Failure mode: OOB kernel memory write, severity CRITICAL.
Trigger: malicious USB device (physical access required).
**YES**
drivers/hid/hid-multitouch.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
index b8a748bbf0fd8..e82a3c4e5b44e 100644
--- a/drivers/hid/hid-multitouch.c
+++ b/drivers/hid/hid-multitouch.c
@@ -526,12 +526,19 @@ static void mt_get_feature(struct hid_device *hdev, struct hid_report *report)
dev_warn(&hdev->dev, "failed to fetch feature %d\n",
report->id);
} else {
+ /* The report ID in the request and the response should match */
+ if (report->id != buf[0]) {
+ hid_err(hdev, "Returned feature report did not match the request\n");
+ goto free;
+ }
+
ret = hid_report_raw_event(hdev, HID_FEATURE_REPORT, buf,
size, 0);
if (ret)
dev_warn(&hdev->dev, "failed to report feature\n");
}
+free:
kfree(buf);
}
--
2.51.0
^ permalink raw reply related
* [PATCH AUTOSEL 6.19-6.18] HID: core: Mitigate potential OOB by removing bogus memset()
From: Sasha Levin @ 2026-03-24 11:19 UTC (permalink / raw)
To: patches, stable
Cc: Lee Jones, Benjamin Tissoires, Sasha Levin, jikos, linux-input,
linux-kernel
In-Reply-To: <20260324111931.3257972-1-sashal@kernel.org>
From: Lee Jones <lee@kernel.org>
[ Upstream commit 0a3fe972a7cb1404f693d6f1711f32bc1d244b1c ]
The memset() in hid_report_raw_event() has the good intention of
clearing out bogus data by zeroing the area from the end of the incoming
data string to the assumed end of the buffer. However, as we have
previously seen, doing so can easily result in OOB reads and writes in
the subsequent thread of execution.
The current suggestion from one of the HID maintainers is to remove the
memset() and simply return if the incoming event buffer size is not
large enough to fill the associated report.
Suggested-by Benjamin Tissoires <bentiss@kernel.org>
Signed-off-by: Lee Jones <lee@kernel.org>
[bentiss: changed the return value]
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
Now I have all the information needed to complete the analysis. Let me
compile the full assessment.
---
## PHASE 1: COMMIT MESSAGE FORENSICS
**Step 1.1: Subject Line**
- Subsystem: `HID: core:`
- Action verb: "Mitigate" (fix-oriented)
- Summary: Removes a memset() that causes OOB reads/writes when incoming
HID event data is shorter than expected report size.
- Record: [HID core] [Mitigate/fix] [Remove memset that causes OOB
memory corruption]
**Step 1.2: Tags**
- `Suggested-by: Benjamin Tissoires <bentiss@kernel.org>` — HID co-
maintainer suggested the approach
- `Signed-off-by: Lee Jones <lee@kernel.org>` — author
- `[bentiss: changed the return value]` — maintainer modified the return
value
- `Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>` — applied by
HID maintainer
- No Fixes: tag (expected for candidates)
- No Cc: stable (expected)
- No Reported-by tag
- Record: Suggested and accepted by the HID co-maintainer. Strong
endorsement.
**Step 1.3: Commit Body**
- Bug: The `memset()` in `hid_report_raw_event()` zeros from `cdata +
csize` to `cdata + rsize` when `csize < rsize`. However, the actual
buffer may not be `rsize` bytes — it could be smaller, causing OOB
writes.
- "as we have previously seen" — acknowledges a history of OOB issues
from this code.
- The fix: reject short reports entirely with -EINVAL instead of zero-
padding.
- Record: OOB writes from memset writing past actual buffer boundary.
Longstanding known issue class.
**Step 1.4: Hidden Bug Fix Detection**
- Not hidden — explicitly describes an OOB vulnerability fix. The word
"mitigate" and "OOB" make it clear.
## PHASE 2: DIFF ANALYSIS
**Step 2.1: Inventory**
- Files: `drivers/hid/hid-core.c` (+4/-3 lines)
- Function: `hid_report_raw_event()`
- Scope: Single-file, single-function surgical fix
- Record: [1 file, net +1 line] [hid_report_raw_event()] [Single-file
surgical fix]
**Step 2.2: Code Flow Change**
- BEFORE: When `csize < rsize`, the code logs a debug message and calls
`memset(cdata + csize, 0, rsize - csize)` to zero-pad the buffer, then
continues processing.
- AFTER: When `csize < rsize`, the code logs a rate-limited warning and
returns `-EINVAL` via `goto out`, rejecting the short report entirely.
- Record: [Short report path: zero-pad and continue → reject and return
-EINVAL]
**Step 2.3: Bug Mechanism**
- Category: **Buffer overflow / OOB write** (memory safety)
- Mechanism: `memset(cdata + csize, 0, rsize - csize)` writes zeros from
the end of the actual received data to position `rsize`. But the
underlying buffer (allocated by the transport layer) may only be
`csize` bytes, meaning the memset writes past the buffer boundary.
- Additionally, subsequent code (like `hid_process_report`) reads up to
`rsize` bytes from the buffer, causing OOB reads.
- Record: [OOB write from memset] [Buffer may be smaller than rsize,
memset writes past end]
**Step 2.4: Fix Quality**
- Obviously correct: rejecting a too-short report is safer than
attempting to zero-pad a buffer of unknown size.
- Minimal: 4 lines changed, net +1 line.
- Regression risk: Some devices that send short reports and relied on
zero-padding will now have those reports rejected. Tissoires
acknowledged this ("let's go with it and say sorry if we break some
devices later on"), meaning the maintainer accepted this tradeoff.
- Record: [High quality, minimal fix] [Low regression risk, maintainer-
accepted tradeoff]
## PHASE 3: GIT HISTORY INVESTIGATION
**Step 3.1: Blame**
- The buggy memset line traces to `85cdaf524b7dda` ("HID: make a bus
from hid code") from 2008-05-16.
- This code has been present since Linux 2.6.26 — it exists in ALL
active stable trees.
- Record: [Buggy code from 2008, present in all stable trees]
**Step 3.2: Fixes Tag**
- No Fixes: tag present. However, the memset dates to 85cdaf524b7dda
(2008).
**Step 3.3: File History — Related Changes**
- 966922f26c7fb (2011): Fixed crash from rsize being too large
(536870912) causing memset crash
- 5ebdffd250988 (2020): Fixed off-by-one in rsize calculation causing
OOB memset
- b1a37ed00d790 (2023): Added `max_buffer_size` attribute to cap rsize
- ec61b41918587 (2022): Fixed shift-out-of-bounds in the processing
after the memset
- Record: **Long history of OOB/crash bugs from this exact memset**.
This is the definitive fix.
**Step 3.4: Author**
- Lee Jones is a prolific kernel contributor and has previously worked
on HID buffer size hardening (b1a37ed00d790).
- Fix was suggested by and applied by Benjamin Tissoires, HID co-
maintainer.
- Record: [Experienced author, maintainer-endorsed fix]
**Step 3.5: Dependencies**
- The fix uses `hid_warn_ratelimited`, introduced in commit
1d64624243af8, which only entered v6.18.
- For stable trees < 6.18, this would need trivial adaptation (use
`hid_warn` or `dev_warn_ratelimited` instead).
- The companion patch `e716edafedad4` (hid-multitouch report ID check)
is independent — it adds a defense at the caller level, not a
prerequisite.
- Record: [Minor dependency on hid_warn_ratelimited macro for older
trees, trivially resolvable]
## PHASE 4: MAILING LIST RESEARCH
From the lore.kernel.org investigation:
- **v1 (2026-02-27)**: Initial version simply removed the memset
entirely.
- **Tissoires review (2026-03-02)**: Pushed back — removing memset alone
isn't enough because `hid_process_report()` would still read OOB.
Suggested rejecting short reports entirely.
- **v3 (2026-03-09)**: Revised per Tissoires's feedback — now returns
early with warning.
- **Tissoires final review (2026-03-16)**: Endorsed, changed return to
-EINVAL, noted "works in 99% of cases" since transport layers allocate
big enough buffers.
- Applied 2026-03-16, merged to Linus 2026-03-17.
- No explicit stable nomination, but no objections to backporting
either.
- Record: [Thorough review by HID maintainer, iterated to correct
approach, accepted]
## PHASE 5: CODE SEMANTIC ANALYSIS
**Step 5.1: Functions Modified**
- `hid_report_raw_event()` — the core HID report processing function.
**Step 5.2: Callers**
- `__hid_input_report()` in hid-core.c (line 2144) — **THE main HID
input path** for all HID devices
- `wacom_sys.c` — 3 call sites (Wacom tablet driver)
- `hid-gfrm.c` — Google Fiber Remote
- `hid-logitech-hidpp.c` — Logitech HID++
- `hid-primax.c` — Primax keyboards
- `hid-multitouch.c` — multitouch devices
- `hid-vivaldi-common.c` — Vivaldi keyboard
- Record: [Called from core HID input path and multiple drivers — very
high impact surface]
**Step 5.3-5.4: Call Chain**
- USB HID: `hid_irq_in()` → `hid_input_report()` →
`__hid_input_report()` → `hid_report_raw_event()`
- This is reachable from any USB HID device event — keyboards, mice,
touchscreens, gamepads, etc.
- Also reachable from I2C-HID, BT-HID, and other transports.
- Record: [Reachable from any HID device input — universal impact]
## PHASE 6: STABLE TREE ANALYSIS
**Step 6.1: Buggy Code in Stable?**
- The memset dates to 2008. Present in every stable tree.
- Record: [ALL active stable trees contain the buggy code]
**Step 6.2: Backport Complications**
- `hid_warn_ratelimited` only in v6.18+. For older stable trees, trivial
substitution needed (e.g., `hid_warn`).
- The rest of the code context (csize, rsize, max_buffer_size, goto out)
is identical in recent stable trees (verified: max_buffer_size was
added in b1a37ed00d790 from 2023, present in 6.6+).
- Record: [Minor adaptation needed for < 6.18, clean apply otherwise]
**Step 6.3: Related Fixes in Stable**
- Previous mitigations (max_buffer_size capping, off-by-one fix) are in
stable but didn't eliminate the fundamental OOB risk.
- Record: [No equivalent fix already in stable — this is the definitive
solution]
## PHASE 7: SUBSYSTEM CONTEXT
**Step 7.1: Subsystem Criticality**
- HID core — every keyboard, mouse, touchscreen, gamepad, etc. goes
through this code.
- Criticality: **IMPORTANT** (affects virtually all desktop/laptop
systems and many embedded devices)
**Step 7.2: Subsystem Activity**
- Very active — multiple fixes per release cycle.
## PHASE 8: IMPACT AND RISK ASSESSMENT
**Step 8.1: Affected Users**
- Every system with HID devices (USB, Bluetooth, I2C) — essentially
universal for desktops/laptops.
**Step 8.2: Trigger Conditions**
- A HID device sends a report shorter than the expected report size.
- Can be triggered by: malicious USB devices, faulty/buggy HID devices,
or specific device configurations.
- Potentially exploitable via USB (e.g., BadUSB attacks).
- Record: [Trigger: short HID report] [Moderate likelihood for
accidental, high for deliberate]
**Step 8.3: Failure Mode**
- **OOB write**: memset writes past buffer boundary → memory corruption,
potential code execution
- **OOB read**: subsequent `hid_process_report()` reads past buffer →
info leak or crash
- Severity: **CRITICAL** (OOB writes = security vulnerability, potential
crash/corruption)
**Step 8.4: Risk-Benefit**
- Benefit: **VERY HIGH** — prevents OOB writes in a core, universally-
used kernel path. Addresses a class of bugs that has caused multiple
CVEs/crashes historically.
- Risk: **VERY LOW** — 4-line change, simple logic (reject vs. pad),
maintainer acknowledged 99% of cases won't be affected, accepted the
tradeoff.
- Ratio: Strongly favors backporting.
## PHASE 9: FINAL SYNTHESIS
**Step 9.1: Evidence Summary**
FOR backporting:
- Fixes OOB writes and reads (security-critical memory safety bug)
- In HID core — affects all HID users (universal impact)
- Very small change: 4 lines, single function, single file
- Bug exists since 2008 — present in ALL stable trees
- Long history of crashes/CVEs from this exact memset (966922f, 5ebdffd,
ec61b41)
- Reviewed and applied by HID co-maintainer (Tissoires)
- Suggested by the maintainer himself
- Fix is the definitive solution after years of band-aid fixes
AGAINST backporting:
- Uses `hid_warn_ratelimited` not available before v6.18 (trivially
adaptable)
- Tissoires noted potential for breaking devices relying on zero-padding
(accepted risk)
- No explicit stable nomination (expected for candidates)
**Step 9.2: Stable Rules Checklist**
1. Obviously correct and tested? **YES** — reviewed by maintainer,
iterated through 3 versions
2. Fixes a real bug? **YES** — OOB write/read in HID core
3. Important issue? **YES** — security vulnerability (OOB write),
potential crash/corruption
4. Small and contained? **YES** — 4 lines, single function
5. No new features or APIs? **YES** — behavior change only (reject
instead of pad)
6. Can apply to stable? **YES** — with trivial adaptation for
hid_warn_ratelimited
**Step 9.3: Exception Categories**
- Not an exception category — this is a standard critical bug fix.
**Step 9.4: Decision**
This is a clear YES. A 4-line fix to a critical OOB write vulnerability
in the core HID input path, present since 2008, with a long history of
related crashes, endorsed by the HID co-maintainer.
## Verification
- [Phase 1] Parsed tags: Suggested-by Tissoires, SOB by Lee Jones and
Tissoires (maintainer applied)
- [Phase 2] Diff analysis: +4/-3 lines in hid_report_raw_event(),
replaces memset+dbg_hid with warn+return -EINVAL
- [Phase 3] git blame: buggy memset from commit 85cdaf524b7dda (2008,
v2.6.26), present in all stable trees
- [Phase 3] git log: found 3 prior fixes to same memset area (966922f,
5ebdffd, b1a37ed) — confirms recurring issue
- [Phase 3] Author: Lee Jones authored the max_buffer_size hardening
(b1a37ed), experienced with this code
- [Phase 4] lore.kernel.org: v1 reviewed by Tissoires who requested
stronger approach; v3 accepted with -EINVAL return; maintainer noted
"works in 99% of cases"
- [Phase 5] Callers: hid_report_raw_event() called from
__hid_input_report() (core path) and 6+ drivers
- [Phase 6] hid_warn_ratelimited introduced in v6.18 (1d64624243af8) —
verified not in v6.12/6.14/6.15/6.16/6.17; needs trivial adaptation
for older trees
- [Phase 6] Companion patch e716edafedad4 is independent (hid-
multitouch.c report ID check), not a prerequisite
- [Phase 8] Failure mode: OOB writes via memset → memory corruption,
severity CRITICAL
- UNVERIFIED: Exact behavior with specific HID devices that send
intentionally short reports (Tissoires accepted the risk)
**YES**
drivers/hid/hid-core.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index a5b3a8ca2fcbc..f5587b786f875 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -2057,9 +2057,10 @@ int hid_report_raw_event(struct hid_device *hid, enum hid_report_type type, u8 *
rsize = max_buffer_size;
if (csize < rsize) {
- dbg_hid("report %d is too short, (%d < %d)\n", report->id,
- csize, rsize);
- memset(cdata + csize, 0, rsize - csize);
+ hid_warn_ratelimited(hid, "Event data for report %d was too short (%d vs %d)\n",
+ report->id, rsize, csize);
+ ret = -EINVAL;
+ goto out;
}
if ((hid->claimed & HID_CLAIMED_HIDDEV) && hid->hiddev_report_event)
--
2.51.0
^ permalink raw reply related
* [PATCH AUTOSEL 6.19-6.12] HID: logitech-hidpp: Enable MX Master 4 over bluetooth
From: Sasha Levin @ 2026-03-24 11:19 UTC (permalink / raw)
To: patches, stable
Cc: Adrian Freund, Jiri Kosina, Sasha Levin, jikos, bentiss,
linux-input, linux-kernel
In-Reply-To: <20260324111931.3257972-1-sashal@kernel.org>
From: Adrian Freund <adrian@freund.io>
[ Upstream commit 70031e70ca15ede6a39db4d978e53a6cc720d454 ]
The Logitech MX Master 4 can be connected over bluetooth or through a
Logitech Bolt receiver. This change adds support for non-standard HID
features, such as high resolution scrolling when the mouse is connected
over bluetooth.
Because no Logitech Bolt receiver driver exists yet those features
won't be available when the mouse is connected through the receiver.
Signed-off-by: Adrian Freund <adrian@freund.io>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
The table has grown but the addition is at the end before the terminator
`{}`. It should apply cleanly or with trivial context adjustment to any
stable tree.
Record: [Clean apply expected — insertion point is at end of table
before terminator]
### Step 6.3: RELATED FIXES IN STABLE
No related fixes — this is new hardware support.
## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT
### Step 7.1
- **Subsystem**: HID (Human Interface Devices) — input peripherals
- **Criticality**: IMPORTANT — mice are core input devices for desktop
users
### Step 7.2
The HID subsystem and this driver specifically are actively maintained
with regular device ID additions.
## PHASE 8: IMPACT AND RISK ASSESSMENT
### Step 8.1: WHO IS AFFECTED
Users who own an MX Master 4 mouse and connect it via Bluetooth on
stable kernels. Without this patch, they don't get high-resolution
scrolling and other hidpp features.
### Step 8.2: TRIGGER CONDITIONS
Any user who connects an MX Master 4 over Bluetooth is affected.
### Step 8.3: FAILURE MODE
Without the patch: missing features (high-res scrolling). With the
patch: device works with full feature set. No crash, no security issue —
hardware enablement.
### Step 8.4: RISK-BENEFIT
- **Benefit**: MEDIUM — enables features for popular Logitech mouse (MX
Master line is very popular)
- **Risk**: VERY LOW — 2-line device ID table addition, zero chance of
regression
- **Ratio**: Favorable
## PHASE 9: FINAL SYNTHESIS
### Step 9.1: EVIDENCE
**FOR backporting:**
- This is a NEW DEVICE ID addition — an explicit exception category for
stable
- Trivially small (2 lines), obviously correct, follows exact pattern of
dozens of prior entries
- Zero regression risk — only affects users who have this specific
hardware
- MX Master 4 is a popular consumer mouse; users on stable kernels would
benefit
- The same author successfully added MX Master 3 previously
- Merged by the HID subsystem maintainer (Jiri Kosina)
**AGAINST backporting:**
- This is not a bug fix — it's enabling new hardware support
- The mouse still works as a basic HID device without this; only
advanced features are missing
- Strictly speaking, this adds new functionality rather than fixing a
bug
### Step 9.2: STABLE RULES CHECKLIST
1. Obviously correct and tested? **YES** — trivial pattern match, merged
by maintainer
2. Fixes a real bug? **NO** — enables hardware features, not a bug fix
3. Important issue? **N/A** — not a bug, but important for hardware
support
4. Small and contained? **YES** — 2 lines
5. No new features? **This adds a device ID, which is an allowed
exception**
6. Can apply to stable? **YES** — clean apply expected
### Step 9.3: EXCEPTION CATEGORIES
**YES — Device ID addition to existing driver.** This falls squarely
into the "NEW DEVICE IDs" exception category. Adding device IDs to
existing drivers is explicitly allowed in stable trees because they are
trivial additions that enable hardware support with zero risk.
### Step 9.4: DECISION
This is a textbook device ID addition — 2 lines adding a Bluetooth
product ID for the Logitech MX Master 4 to an existing, well-established
driver. The stable kernel rules explicitly allow this pattern. The risk
is essentially zero, and users with this popular mouse benefit from full
feature support.
## Verification
- [Phase 1] Parsed tags: Author Adrian Freund, merged by HID maintainer
Jiri Kosina
- [Phase 2] Diff analysis: +2 lines adding HID_BLUETOOTH_DEVICE entry
(0xb042) to hidpp_devices[] table
- [Phase 3] git blame: Device ID table exists since 2014, continuously
expanded with similar entries
- [Phase 3] git log --author: Author previously added MX Master 3
(commit 04bd68171e018)
- [Phase 3] git log: File actively maintained, 19+ changes since v6.6
- [Phase 5] No functions modified — pure data table addition
- [Phase 6] Driver exists in all active stable trees (since 2014)
- [Phase 7] HID subsystem, actively maintained, IMPORTANT criticality
- [Phase 8] Risk: VERY LOW (2-line table entry), Benefit: MEDIUM
(popular hardware)
**YES**
drivers/hid/hid-logitech-hidpp.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index 02d83c3bd73d4..c3d53250a7604 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -4668,6 +4668,8 @@ static const struct hid_device_id hidpp_devices[] = {
HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb038) },
{ /* Slim Solar+ K980 Keyboard over Bluetooth */
HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb391) },
+ { /* MX Master 4 mouse over Bluetooth */
+ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb042) },
{}
};
--
2.51.0
^ permalink raw reply related
* [PATCH AUTOSEL 6.19-5.10] HID: wacom: fix out-of-bounds read in wacom_intuos_bt_irq
From: Sasha Levin @ 2026-03-24 11:19 UTC (permalink / raw)
To: patches, stable
Cc: Benoît Sevens, Jason Gerecke, Jiri Kosina, Sasha Levin,
ping.cheng, jikos, bentiss, linux-input, linux-kernel
In-Reply-To: <20260324111931.3257972-1-sashal@kernel.org>
From: Benoît Sevens <bsevens@google.com>
[ Upstream commit 2f1763f62909ccb6386ac50350fa0abbf5bb16a9 ]
The wacom_intuos_bt_irq() function processes Bluetooth HID reports
without sufficient bounds checking. A maliciously crafted short report
can trigger an out-of-bounds read when copying data into the wacom
structure.
Specifically, report 0x03 requires at least 22 bytes to safely read
the processed data and battery status, while report 0x04 (which
falls through to 0x03) requires 32 bytes.
Add explicit length checks for these report IDs and log a warning if
a short report is received.
Signed-off-by: Benoît Sevens <bsevens@google.com>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.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 for a complete analysis. Let me compile
everything.
---
## PHASE 1: COMMIT MESSAGE FORENSICS
### Step 1.1: Subject Line
- **Subsystem:** HID: wacom (HID subsystem, Wacom tablet driver)
- **Action verb:** "fix" — explicit bug fix
- **Summary:** Fix out-of-bounds read in wacom_intuos_bt_irq when
processing short Bluetooth HID reports
### Step 1.2: Tags
- **Signed-off-by:** Benoît Sevens <bsevens@google.com> (author, Google
— security researcher based on commit history)
- **Reviewed-by:** Jason Gerecke <jason.gerecke@wacom.com> (Wacom
subsystem maintainer — strong endorsement)
- **Signed-off-by:** Jiri Kosina <jkosina@suse.com> (HID subsystem
maintainer — merged the patch)
- **No Fixes: tag** — expected for commits under review
- **No Cc: stable** — expected
- **No Reported-by** — likely found through code audit/fuzzing by the
Google security team
Record: Author is a Google security researcher (has other OOB fix
commits: ALSA, UVC). Reviewed by Wacom maintainer. Merged by HID
maintainer.
### Step 1.3: Commit Body
The bug: `wacom_intuos_bt_irq()` processes Bluetooth HID reports without
checking `len`. A short report causes out-of-bounds reads:
- Report 0x03 needs at least 22 bytes (offset 1 + 10 + 10 + 1 = 22)
- Report 0x04 needs at least 32 bytes (offset 1 + 10 + 10 + 10 + 1 = 32,
due to fallthrough)
- The commit explicitly mentions "maliciously crafted short report" —
security implication
Record: Clear security bug — a malicious Bluetooth device can trigger
OOB read. Failure mode is memory disclosure or crash.
### Step 1.4: Hidden Bug Fix Detection
Not hidden — explicitly labeled as a fix for out-of-bounds read. The
author even describes the exact byte thresholds.
---
## PHASE 2: DIFF ANALYSIS
### Step 2.1: Inventory
- **Files changed:** 1 (`drivers/hid/wacom_wac.c`)
- **Lines:** +10 added (two bounds-check blocks with `dev_warn` +
`break`)
- **Functions modified:** `wacom_intuos_bt_irq`
- **Scope:** Single-file, single-function surgical fix
### Step 2.2: Code Flow Change
**Hunk 1 (case 0x04):**
- Before: Immediately calls `wacom_intuos_bt_process_data(wacom, data +
1)` regardless of `len`
- After: Checks `len < 32`, warns and breaks if too short
**Hunk 2 (case 0x03):**
- Before: Immediately processes data at offset `i` regardless of `len`
- After: Checks `i == 1 && len < 22` (only when entering directly as
0x03, not via fallthrough from 0x04), warns and breaks if too short
### Step 2.3: Bug Mechanism
**Category:** Buffer overflow / out-of-bounds read (memory safety)
The function accesses `data[i]` where `i` increments by 10 through
multiple `wacom_intuos_bt_process_data` calls. For report 0x03 (direct
entry, i=1): accesses up to data[21]. For report 0x04 (falls through):
accesses up to data[31]. If `len` is smaller than these values, this
reads beyond the allocated buffer.
With current code (post-5e013ad), `data = kmemdup(wacom->data, len,
GFP_KERNEL)` — heap OOB read.
With old code (pre-5e013ad), `unsigned char data[WACOM_PKGLEN_MAX]` +
`memcpy(data, wacom->data, len)` — reads uninitialized stack data beyond
`len`.
### Step 2.4: Fix Quality
- **Obviously correct:** Yes — the length checks match the exact data
access patterns
- **Minimal:** Yes — 10 lines, only adds bounds checks
- **Regression risk:** Extremely low — only rejects malformed short
reports
- **No red flags:** Single function, no API changes, no locking changes
---
## PHASE 3: GIT HISTORY INVESTIGATION
### Step 3.1: Blame
The vulnerable code was introduced in commit `81af7e61a774e6` ("Input:
wacom - handle Intuos 4 BT in wacom.ko") by Benjamin Tissoires on
2014-08-06. This code was first released in **v3.18**. The bug has been
present for **~12 years** in every kernel version since.
### Step 3.2: Fixes Tag
No Fixes: tag present. The implicit fix target is 81af7e61a774e6 from
2014.
### Step 3.3: File History
The recent commit `5e013ad206895` ("HID: wacom: Remove static
WACOM_PKGLEN_MAX limit") went into v6.15 and changed the function from
using a stack buffer to `kmemdup`. This changes the context for the fix.
Stable trees v6.14 and earlier have the old stack-buffer code.
### Step 3.4: Author
Benoît Sevens (bsevens@google.com) has other security-fix commits:
- `b909df18ce2a9` "ALSA: usb-audio: Fix potential out-of-bound accesses
for Extigy and Mbox devices"
- `ecf2b43018da9` "media: uvcvideo: Skip parsing frames of type
UVC_VS_UNDEFINED"
- `082dd785e2086` "media: uvcvideo: Refactor frame parsing code"
This is consistent with a Google security researcher systematically
finding OOB bugs.
### Step 3.5: Dependencies
The fix itself is standalone — it only adds `if (len < N) break;`
checks. However, for stable trees prior to v6.15, the context will
differ (stack buffer vs kmemdup). The fix should still apply with minor
context adjustment.
---
## PHASE 4: MAILING LIST RESEARCH
### Step 4.1: Lore Search
Found the patch at `https://lore.kernel.org/all/20260303135828.2374069-
1-bsevens@google.com/`. Replies from Jason Gerecke (2026-03-06) and Jiri
Kosina (2026-03-09). No Cc: stable in the original submission. The patch
was accepted and included in a HID pull request for 7.0-rc5 (i.e.,
6.19-rc5).
### Step 4.2: Bug Report
No separate bug report link — this appears to be found through code
audit by the Google security team.
### Step 4.3-4.4: Related Patches / Stable Discussion
This is a standalone single-patch fix. No evidence of related series or
prior stable discussion.
---
## PHASE 5: CODE SEMANTIC ANALYSIS
### Step 5.1: Functions Modified
- `wacom_intuos_bt_irq` — the only function modified
### Step 5.2: Callers
`wacom_intuos_bt_irq` is called from one location:
- `drivers/hid/wacom_wac.c:3490` in the `INTUOS4WL` case of the main
wacom IRQ handler
This is the Bluetooth HID report interrupt handler for the Wacom Intuos
4 Wireless tablet. It's triggered every time the device sends a
Bluetooth HID report.
### Step 5.3-5.4: Call Chain
The call chain is: HID subsystem receives BT report → `wacom_raw_event`
→ `wacom_wac_irq` → `wacom_intuos_bt_irq`. This is directly reachable
from any Bluetooth HID device claiming to be an Intuos 4 WL tablet. A
malicious BT device can send arbitrary short reports to trigger this.
### Step 5.5: Similar Patterns
Other wacom IRQ handlers (like `wacom_intuos_irq`) may have similar
issues but are not addressed by this commit.
---
## PHASE 6: STABLE TREE ANALYSIS
### Step 6.1: Buggy Code in Stable Trees
The buggy code (81af7e61a774e6) has been in the kernel since v3.18
(2014). It exists in **ALL** active stable trees (5.10.y, 5.15.y, 6.1.y,
6.6.y, 6.12.y, 6.14.y).
### Step 6.2: Backport Complications
- For v6.15+ stable trees: the fix should apply cleanly (same kmemdup
code)
- For v6.14 and earlier: the surrounding context differs (stack buffer
`unsigned char data[WACOM_PKGLEN_MAX]` + `memcpy` instead of
`kmemdup`). The bounds-check additions themselves are the same, but
the diff context won't match. Minor adaptation needed.
### Step 6.3: Related Fixes
No prior fix for this issue in any stable tree.
---
## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT
### Step 7.1: Subsystem
- **Subsystem:** HID / Wacom driver (drivers/hid/)
- **Criticality:** IMPORTANT — Wacom tablets are widely used by artists,
designers, and professionals. Bluetooth variant is common for wireless
tablets.
### Step 7.2: Activity
The wacom driver is actively maintained by Jason Gerecke, with regular
commits. 43 commits since v5.15.
---
## PHASE 8: IMPACT AND RISK ASSESSMENT
### Step 8.1: Who Is Affected
Users of Wacom Intuos 4 Wireless (Bluetooth) tablets. Also any system
with Bluetooth HID enabled where a malicious device could pair.
### Step 8.2: Trigger Conditions
- A malicious or malfunctioning Bluetooth HID device sends a short
report (< 22 or < 32 bytes) with report ID 0x03 or 0x04
- This can be triggered by an unprivileged attacker within Bluetooth
range
- No special configuration needed — just BT HID enabled (very common)
### Step 8.3: Failure Mode Severity
- **Heap OOB read** (current mainline code with kmemdup) → potential
info disclosure, crash → **CRITICAL**
- **Uninitialized stack data use** (older code with stack buffer) →
potential info disclosure, incorrect behavior → **HIGH**
- This is a security-relevant vulnerability exploitable via Bluetooth
proximity
### Step 8.4: Risk-Benefit
- **Benefit:** HIGH — fixes a security-relevant OOB read reachable via
Bluetooth, present for 12 years
- **Risk:** VERY LOW — 10 lines of bounds checking, obviously correct,
no behavioral change for well-formed reports
- **Ratio:** Strongly favorable for backport
---
## PHASE 9: FINAL SYNTHESIS
### Step 9.1: Evidence
**FOR backporting:**
- Fixes out-of-bounds read — memory safety / security bug
- Bug present since v3.18 (2014) — affects all stable trees
- Exploitable via Bluetooth by any nearby device
- Author is a Google security researcher with track record of finding
OOB bugs
- Reviewed by the Wacom subsystem maintainer (Jason Gerecke)
- Merged by the HID subsystem maintainer (Jiri Kosina)
- Fix is tiny (10 lines), obviously correct, zero regression risk
- No behavioral change for valid reports
**AGAINST backporting:**
- For stable trees < v6.15, minor context adaptation needed (stack
buffer vs kmemdup) — manageable
- No explicit Cc: stable in original patch — expected for commits under
review
### Step 9.2: Stable Rules Checklist
1. **Obviously correct and tested?** YES — simple bounds checks matching
exact data access patterns, reviewed by maintainer
2. **Fixes a real bug?** YES — out-of-bounds read / security
vulnerability
3. **Important issue?** YES — memory safety bug exploitable via
Bluetooth
4. **Small and contained?** YES — 10 lines, single function, single file
5. **No new features or APIs?** Correct — only adds validation
6. **Can apply to stable?** YES for v6.15+; needs minor context
adaptation for older trees
### Step 9.3: Exception Categories
Not an exception category — this is a standard security bug fix (the
primary category for stable).
### Step 9.4: Decision
This is a clear, small, security-relevant fix for an out-of-bounds read
in a Bluetooth HID handler. It has been present for 12 years, is
exploitable by a nearby attacker, was reviewed by the subsystem
maintainer, and carries essentially zero regression risk.
---
## Verification
- [Phase 1] Parsed tags: Reviewed-by Jason Gerecke (Wacom maintainer),
SOB Jiri Kosina (HID maintainer), author from Google
- [Phase 1] Author commit history: confirmed 3 other OOB/security fix
commits (ALSA, UVC)
- [Phase 2] Diff analysis: +10 lines, two bounds checks in
`wacom_intuos_bt_irq()`, adds `if (len < 32) break;` and `if (i == 1
&& len < 22) break;`
- [Phase 2] Verified math: report 0x04 accesses data[1] through data[31]
(1+10+10+10+1=32); report 0x03 accesses data[1] through data[21]
(1+10+10+1=22)
- [Phase 3] git blame: buggy code introduced in 81af7e61a774e6
(2014-08-06), confirmed in v3.18
- [Phase 3] git show 5e013ad206895: confirmed this changed stack buffer
to kmemdup, went into v6.15; stable trees have old code
- [Phase 3] Confirmed 5e013ad not in v6.12, v6.13, v6.14 (via merge-
base)
- [Phase 4] Lore: found patch at
20260303135828.2374069-1-bsevens@google.com, accepted with replies
from Gerecke and Kosina
- [Phase 5] Grep callers: `wacom_intuos_bt_irq` called from line 3490 in
INTUOS4WL case — BT HID interrupt path
- [Phase 6] Bug exists in all stable trees (code from 2014)
- [Phase 8] Failure mode: heap OOB read (mainline) or uninitialized
stack read (stable), severity CRITICAL/HIGH
**YES**
drivers/hid/wacom_wac.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/hid/wacom_wac.c b/drivers/hid/wacom_wac.c
index 9b2c710f8da18..da1f0ea85625d 100644
--- a/drivers/hid/wacom_wac.c
+++ b/drivers/hid/wacom_wac.c
@@ -1208,10 +1208,20 @@ static int wacom_intuos_bt_irq(struct wacom_wac *wacom, size_t len)
switch (data[0]) {
case 0x04:
+ if (len < 32) {
+ dev_warn(wacom->pen_input->dev.parent,
+ "Report 0x04 too short: %zu bytes\n", len);
+ break;
+ }
wacom_intuos_bt_process_data(wacom, data + i);
i += 10;
fallthrough;
case 0x03:
+ if (i == 1 && len < 22) {
+ dev_warn(wacom->pen_input->dev.parent,
+ "Report 0x03 too short: %zu bytes\n", len);
+ break;
+ }
wacom_intuos_bt_process_data(wacom, data + i);
i += 10;
wacom_intuos_bt_process_data(wacom, data + i);
--
2.51.0
^ permalink raw reply related
* [PATCH AUTOSEL 6.19-6.12] HID: logitech-hidpp: Prevent use-after-free on force feedback initialisation failure
From: Sasha Levin @ 2026-03-24 11:19 UTC (permalink / raw)
To: patches, stable
Cc: Lee Jones, Günther Noack, Benjamin Tissoires, Sasha Levin,
jikos, linux-input, linux-kernel
In-Reply-To: <20260324111931.3257972-1-sashal@kernel.org>
From: Lee Jones <lee@kernel.org>
[ Upstream commit f7a4c78bfeb320299c1b641500fe7761eadbd101 ]
Presently, if the force feedback initialisation fails when probing the
Logitech G920 Driving Force Racing Wheel for Xbox One, an error number
will be returned and propagated before the userspace infrastructure
(sysfs and /dev/input) has been torn down. If userspace ignores the
errors and continues to use its references to these dangling entities, a
UAF will promptly follow.
We have 2 options; continue to return the error, but ensure that all of
the infrastructure is torn down accordingly or continue to treat this
condition as a warning by emitting the message but returning success.
It is thought that the original author's intention was to emit the
warning but keep the device functional, less the force feedback feature,
so let's go with that.
Signed-off-by: Lee Jones <lee@kernel.org>
Reviewed-by: Günther Noack <gnoack@google.com>
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
The same bug exists in v6.6 - `hidpp_ff_init` failure leads to `ret`
being non-zero and the function returning error after userspace
interfaces are exported. The fix would need minor adaptation for v6.6
(the code structure is slightly different but the same logic applies).
Record: [Bug exists in all stable trees (v5.15+). In v6.6 and older, the
code structure is slightly different (g920_get_config is called
earlier), but the same hidpp_ff_init failure → error return path exists.
Backport may need minor adaptation for older trees.]
### Step 6.2: BACKPORT COMPLICATIONS
For v6.12 and later, the patch should apply cleanly (same code
structure). For v6.6 and v6.1, the code is slightly different but the
same fix (setting `ret = 0` after the warning) applies to the same
logical block.
Record: [Clean apply for 6.12.y; minor context adaptation needed for
6.6.y and older]
## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT
### Step 7.1: IDENTIFY THE SUBSYSTEM AND ITS CRITICALITY
- **Subsystem**: HID (Human Interface Devices) - specifically the
Logitech HID++ driver
- **Criticality**: IMPORTANT - USB input devices are common consumer
hardware. The G920/G923 are popular gaming wheels.
- **Maintainer**: Benjamin Tissoires (who signed off on this patch)
Record: [HID/logitech-hidpp, IMPORTANT criticality, signed off by
subsystem maintainer]
## PHASE 8: IMPACT AND RISK ASSESSMENT
### Step 8.1: DETERMINE WHO IS AFFECTED
Users of the Logitech G920 Driving Force Racing Wheel and G923 Xbox
version wheel. These are popular gaming peripherals.
Record: [Driver-specific: users of Logitech G920/G923 gaming wheels]
### Step 8.2: DETERMINE THE TRIGGER CONDITIONS
- **Trigger**: Force feedback initialization fails during device probe.
This can happen due to communication issues with the device, firmware
quirks, or timing issues.
- **How common**: Not every plug-in, but not rare either (the original
commit notes this is about a real failure path)
- **Unprivileged trigger**: Yes - plugging in a USB device or having it
connected at boot
Record: [Triggered when FF init fails during probe; can happen during
normal device use; unprivileged (USB plug-in)]
### Step 8.3: DETERMINE THE FAILURE MODE SEVERITY
- **UAF**: Use-after-free when userspace continues to use dangling
sysfs/input nodes after probe failure
- **Severity**: HIGH - UAF can lead to crashes, undefined behavior, and
potentially security issues (exploitable from userspace via USB
device)
Record: [Use-after-free → CRITICAL/HIGH severity. Can cause crashes,
potential security implications]
### Step 8.4: CALCULATE RISK-BENEFIT RATIO
- **BENEFIT**: HIGH - Prevents UAF for users of popular gaming hardware.
Simple fix that also improves user experience (device works without FF
instead of failing entirely).
- **RISK**: VERY LOW - 2 lines changed. Setting `ret = 0` is obviously
correct. No new code paths, no locking changes, no API changes. Worst
case: device appears to work but has no force feedback (which is the
intended behavior stated in the commit message).
Record: [Benefit: HIGH (prevents UAF, improves UX). Risk: VERY LOW
(2-line change, obviously correct). Ratio: strongly favorable]
## PHASE 9: FINAL SYNTHESIS
### Step 9.1: COMPILE THE EVIDENCE
**Evidence FOR backporting:**
- Fixes a use-after-free vulnerability (HIGH severity bug)
- Extremely small and surgical fix (2 lines: braces + `ret = 0;`)
- Obviously correct - matches the original author's intent
- Reviewed by Google engineer, signed off by HID subsystem maintainer
- Bug has existed since v5.5 (~6 years), affecting all active stable
trees
- Affects real consumer hardware (Logitech G920/G923 gaming wheels)
- UAF is reachable from userspace (USB device plug-in)
- No regression risk - device remains functional, just without FF on
failure
- Clean separation from other changes - standalone fix
**Evidence AGAINST backporting:**
- No explicit Cc: stable tag (expected for review candidates)
- No Fixes: tag (but the bug origin is clear from blame)
- May need minor context adaptation for older stable trees (6.6.y and
earlier)
**UNRESOLVED QUESTIONS:**
- None significant
### Step 9.2: APPLY THE STABLE RULES CHECKLIST
1. **Obviously correct and tested?** YES - reviewed, applied by
maintainer, included in 7.0-rc5
2. **Fixes a real bug that affects users?** YES - UAF on G920/G923 probe
failure
3. **Important issue?** YES - use-after-free (crash, potential security
issue)
4. **Small and contained?** YES - 2 lines in 1 file
5. **No new features or APIs?** CORRECT - no new features
6. **Can apply to stable trees?** YES - cleanly for 6.12.y, with minor
adaptation for older
### Step 9.3: CHECK FOR EXCEPTION CATEGORIES
Not an exception category - this is a straightforward bug fix that meets
the core stable criteria.
### Step 9.4: MAKE YOUR DECISION
This is a clear YES. A 2-line fix for a use-after-free vulnerability in
a popular USB gaming peripheral driver, reviewed by the subsystem
maintainer, with essentially zero regression risk.
## Verification
- [Phase 1] Parsed subject: "HID: logitech-hidpp:" subsystem, "Prevent"
verb, UAF fix for FF init failure
- [Phase 1] Tags: Reviewed-by Günther Noack (Google), Signed-off-by
Benjamin Tissoires (HID maintainer). No Fixes:, no Cc: stable
(expected)
- [Phase 1] Commit body explicitly describes UAF scenario: error return
after hid_connect() exports userspace interfaces
- [Phase 2] Diff: +3/-1 lines in drivers/hid/hid-logitech-hidpp.c,
hidpp_probe() function. Adds braces + `ret = 0;`
- [Phase 2] Before: FF init failure → non-zero ret → probe returns error
→ userspace interfaces not torn down → UAF. After: FF init failure →
ret=0 → probe succeeds → device works without FF
- [Phase 3] git blame: buggy pattern introduced in abdd3d0b344fdf (v5.5,
2019-10-17), present in all active stable trees
- [Phase 3] git merge-base: confirmed abdd3d0b344fdf is ancestor of
v5.5; 219ccfb60003a4 (refactored form) is in v6.7+ but not v6.6
- [Phase 3] Verified the same bug pattern exists in v6.6 by reading
v6.6:drivers/hid/hid-logitech-hidpp.c lines 4538-4546
- [Phase 3] Author Lee Jones is a prolific kernel contributor with
multiple HID patches
- [Phase 4] Lore: patch submitted 2026-02-27, reviewed without
objections, applied by maintainer
- [Phase 5] HIDPP_QUIRK_CLASS_G920 applies to G920 (0xC262) and G923
Xbox (matching 2 USB device entries)
- [Phase 5] hidpp_probe() is the standard USB device probe path, called
during device enumeration
- [Phase 6] Bug exists in all stable trees (v5.15.y through v6.12.y).
Code context differs slightly in v6.6 and older
- [Phase 7] HID subsystem, IMPORTANT criticality. Maintainer Benjamin
Tissoires signed off
- [Phase 8] Severity: HIGH (UAF). Trigger: FF init failure during device
probe. Risk: VERY LOW (2-line fix)
**YES**
drivers/hid/hid-logitech-hidpp.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index c3d53250a7604..65bfad405ac5b 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -4487,10 +4487,12 @@ static int hidpp_probe(struct hid_device *hdev, const struct hid_device_id *id)
if (!ret)
ret = hidpp_ff_init(hidpp, &data);
- if (ret)
+ if (ret) {
hid_warn(hidpp->hid_dev,
"Unable to initialize force feedback support, errno %d\n",
ret);
+ ret = 0;
+ }
}
/*
--
2.51.0
^ permalink raw reply related
* Question regarding error handling in usbhid
From: Oliver Neukum @ 2026-03-24 9:57 UTC (permalink / raw)
To: Alan Stern; +Cc: USB list, linux-input@vger.kernel.org
Hi,
hid_io_error(), in case it decides that a reset is necessary,
schedules reset_work(). reset_work() in turn calls usb_queue_reset_device().
Why? Is there a reason usb_queue_reset_device() is not used directly
in hid_io_error()?
Regards
Oliver
^ permalink raw reply
* Fwd: Internal keyboard non-functional on linux on Medion Laptop - NTC816 (Intel IPF) has no driver, PS/2 fallback produces corrupted scancodes
From: Ian Jensen @ 2026-03-24 8:38 UTC (permalink / raw)
To: linux-kernel, linux-input
In-Reply-To: <CAJ0oKySkr2x3qgy4nj0S9bEAXsT08uWKeuy_cM4zp-9CmBkkrA@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 2617 bytes --]
Hello, I have been advised to send you an email regarding an issue about a
missing driver that causes the internal keyboard on my laptop to be totally
useless.
Hardware: Medion Signium S1 OLED (MSN 30040793)
Kernel: 6.19.6-200.fc43.x86_64
Distro: Fedora Workstation 43
The internal keyboard does not work at all in Linux, not even the
capslock button works. The keyboard works in Windows and in GRUB and
the touchpad works fine. An external keyboard also works fine.
On Windows, the keyboard is exposed through this device chain:
INTC816 (Intel Innovation Platform Framework)
-> ButtonConverter\ConvertedDevice
-> HID keyboard (kbdhid driver)
DEVPKEY_Device_Service: kbdhid
DEVPKEY_Device_Stack: \Driver\kbdclass, \Driver\kbdhid, \Driver\mshidkmdf
On Linux INTC816 does not appear to have a driver. It does not appear
in /sys/bus/acpi/devices/ or /sys/bus/ishtp/devices/. The Intel ISH
modules are loaded (intel_ishtp_hid, intel_ish_ipc, intel_ishtp), but
only a sensor hub (8087:0AC2) is present on the ISHTP bus. The
keyboard is not enumerated there.
ACPI devices with INTC prefix: INTC1001, INTC1046, INTC1048, INTC1055,
INTC1078, INTC1092, INTC109C, INTC10A0-A5. No INTC816.
The BIOS presents a PS/2 emulator via i8042, but it produces corrupted
scancodes. Examples:
- H shows 0x20 (Set 1: D)
- A shows 0x03 (undefined in Set 1)
The corruption is not a simple offset and does not match any known
scancode set. This appears to be a firmware bug in the scancode
translation.
IRQ 1 is not showing an interrupt storm (~10 interrupts per keypress),
so this is not a stuck interrupt.
Boot parameters tested:
i8042.nopnp=1 i8042.direct=1 -> corrupted input
i8042.nopnp=1 i8042.direct=1 atkbd.set=1 -> corrupted input
i8042.nopnp=1 i8042.direct=1 atkbd.set=2 -> corrupted input
i8042.nopnp=1 i8042.nomux=1 i8042.reset=1 i8042.notimeout=1 -> no input
acpi_osi=! acpi_osi="Windows 2013" -> no input
dmesg:
i8042: PNP detection disabled
i8042: Warning: Keylock active
serio: i8042 KBD port at 0x60,0x64 irq 1
input: AT Translated Set 2 keyboard as
/devices/platform/i8042/serio0/input/input3
intel-hid INTC1078:00: failed to enable HID power button
ish-hid {33AECD58-B679-4E54-9BD9-A04D34F0C226}: enum_devices_done
OK, num_hid_devices=1
The closest existing driver in-tree is
drivers/platform/x86/intel/hid.c (handles INTC1078 and similar).
INTC816 would presumably need a similar ACPI driver that enumerates
the child HID device and routes it through the input subsystem
I have attached my systems info
[-- Attachment #1.2: Type: text/html, Size: 3019 bytes --]
[-- Attachment #2: System Kernel 6 19 7 200 (1).txt --]
[-- Type: text/plain, Size: 6788 bytes --]
System:
Kernel: 6.19.7-200.fc43.x86_64 arch: x86_64 bits: 64 compiler: gcc v: 15.2.1
clocksource: tsc avail: acpi_pm
parameters: BOOT_IMAGE=(hd0,gpt6)/vmlinuz-6.19.7-200.fc43.x86_64
root=UUID=8f93217f-0035-437e-97fa-51e1da289bec ro rootflags=subvol=root
rhgb quiet
Desktop: GNOME v: 49.4 tk: GTK v: 3.24.51 wm: gnome-shell
tools: gsd-screensaver-proxy dm: GDM v: 49.2 Distro: Fedora Linux 43
(Workstation Edition)
Machine:
Type: Laptop System: MEDION product: 14 S1 OLED v: N/A
serial: <superuser required> Chassis: type: 10 serial: <superuser required>
Mobo: MEDION model: NM14RPL v: 1.0 serial: <superuser required>
part-nu: ML-230007 40091772 uuid: <superuser required> Firmware: UEFI
vendor: American Megatrends LLC. v: RPL336_S_V0.13 date: 04/15/2025
Battery:
ID-1: BAT0 charge: 42.9 Wh (78%) condition: 55/55 Wh (100%) power: 14.8 W
volts: 11.55 min: N/A model: Medion SR Real Battery type: Unknown
serial: <filter> charging: status: discharging cycles: N/A
CPU:
Info: model: Intel Core 5 120U bits: 64 type: MST AMCP arch: Raptor Lake
level: v3 note: check built: 2022+ process: Intel 7 (10nm) family: 6
model-id: 0xBA (186) stepping: 3 microcode: 0x6134
Topology: cpus: 1x dies: 1 clusters: 4 cores: 10 threads: 12 mt: 2 tpc: 2
st: 8 smt: enabled cache: L1: 928 KiB desc: d-8x32 KiB, 2x48 KiB; i-2x32
KiB, 8x64 KiB L2: 6.5 MiB desc: 2x1.2 MiB, 2x2 MiB L3: 12 MiB
desc: 1x12 MiB
Speed (MHz): avg: 2200 min/max: 400/5000:3800 scaling:
driver: intel_pstate governor: powersave cores: 1: 2200 2: 2200 3: 2200
4: 2200 5: 2200 6: 2200 7: 2200 8: 2200 9: 2200 10: 2200 11: 2200 12: 2200
bogomips: 59904
Flags-basic: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx
Vulnerabilities:
Type: gather_data_sampling status: Not affected
Type: ghostwrite status: Not affected
Type: indirect_target_selection status: Not affected
Type: itlb_multihit status: Not affected
Type: l1tf status: Not affected
Type: mds status: Not affected
Type: meltdown status: Not affected
Type: mmio_stale_data status: Not affected
Type: old_microcode status: Not affected
Type: reg_file_data_sampling mitigation: Clear Register File
Type: retbleed status: Not affected
Type: spec_rstack_overflow status: Not affected
Type: spec_store_bypass mitigation: Speculative Store Bypass disabled via
prctl
Type: spectre_v1 mitigation: usercopy/swapgs barriers and __user pointer
sanitization
Type: spectre_v2 mitigation: Enhanced / Automatic IBRS; IBPB:
conditional; PBRSB-eIBRS: SW sequence; BHI: BHI_DIS_S
Type: srbds status: Not affected
Type: tsa status: Not affected
Type: tsx_async_abort status: Not affected
Type: vmscape mitigation: IBPB before exit to userspace
Graphics:
Device-1: Intel Raptor Lake-U [Intel Graphics] vendor: Emdoor Digital
driver: i915 v: kernel alternate: xe arch: Xe process: Intel 7 (10nm)
built: 2022+ ports: active: eDP-1 empty: DP-1,DP-2,HDMI-A-1
bus-ID: 00:02.0 chip-ID: 8086:a7ac class-ID: 0300
Device-2: Sonix USB2.0 FHD UVC WebCam driver: uvcvideo type: USB rev: 2.0
speed: 480 Mb/s lanes: 1 mode: 2.0 bus-ID: 3-5:2 chip-ID: 3277:00be
class-ID: fe01 serial: <filter>
Display: wayland server: X.Org v: 24.1.9 with: Xwayland v: 24.1.9
compositor: gnome-shell driver: dri: iris gpu: i915 display-ID: :0
screens: 1
Screen-1: 0 s-res: 3456x2160 s-dpi: 96 s-size: 914x571mm (35.98x22.48")
s-diag: 1078mm (42.43")
Monitor-1: eDP-1 model-id: EDO 0x1428 built: 2024 res: mode: 3456x2160
hz: 120 scale: 100% (1) dpi: 293 gamma: 1.2 size: 300x190mm (11.81x7.48")
diag: 355mm (14") modes: 2880x1800
API: OpenGL v: 4.6 vendor: intel mesa v: 25.3.6 glx-v: 1.4 es-v: 3.2
direct-render: yes renderer: Mesa Intel Graphics (RPL-U)
device-ID: 8086:a7ac memory: 14.99 GiB unified: yes
API: EGL Message: EGL data requires eglinfo. Check --recommends.
Info: Tools: api: glxinfo x11: xdriinfo, xdpyinfo, xprop, xrandr
Audio:
Device-1: Intel Raptor Lake-P/U/H cAVS vendor: Emdoor Digital
driver: snd_hda_intel v: kernel alternate: snd_soc_avs,snd_sof_pci_intel_tgl
bus-ID: 00:1f.3 chip-ID: 8086:51ca class-ID: 0403
API: ALSA v: k6.19.7-200.fc43.x86_64 status: kernel-api
tools: alsactl,alsamixer,amixer
Server-1: PipeWire v: 1.4.10 status: active with: 1: pipewire-pulse
status: active 2: wireplumber status: active 3: pipewire-alsa type: plugin
4: pw-jack type: plugin tools: pactl,pw-cat,pw-cli,wpctl
Network:
Device-1: Intel Raptor Lake PCH CNVi WiFi driver: iwlwifi v: kernel
bus-ID: 00:14.3 chip-ID: 8086:51f1 class-ID: 0280
IF: wlo1 state: up mac: <filter>
Info: services: NetworkManager,wpa_supplicant
Bluetooth:
Device-1: Intel AX201 Bluetooth driver: btusb v: 0.8 type: USB rev: 2.0
speed: 12 Mb/s lanes: 1 mode: 1.1 bus-ID: 3-10:3 chip-ID: 8087:0026
class-ID: e001
Report: btmgmt ID: hci0 rfk-id: 0 state: up address: <filter> bt-v: 5.2
lmp-v: 11 status: discoverable: no pairing: no class-ID: 7c010c
Drives:
Local Storage: total: 476.94 GiB used: 5.53 GiB (1.2%)
SMART Message: Unable to run smartctl. Root privileges required.
ID-1: /dev/nvme0n1 maj-min: 259:0 model: RS512GSSD710 size: 476.94 GiB
block-size: physical: 512 B logical: 512 B speed: 63.2 Gb/s lanes: 4
tech: SSD serial: <filter> fw-rev: PM02077B temp: 36.9 C scheme: GPT
Partition:
ID-1: / raw-size: 168.9 GiB size: 168.9 GiB (100.00%) used: 4.98 GiB (3.0%)
fs: btrfs dev: /dev/nvme0n1p7 maj-min: 259:7
ID-2: /boot raw-size: 2 GiB size: 1.9 GiB (95.01%) used: 505.7 MiB (26.0%)
fs: ext4 dev: /dev/nvme0n1p6 maj-min: 259:6
ID-3: /boot/efi raw-size: 100 MiB size: 96 MiB (96.00%)
used: 50.7 MiB (52.8%) fs: vfat dev: /dev/nvme0n1p1 maj-min: 259:1
ID-4: /home raw-size: 168.9 GiB size: 168.9 GiB (100.00%)
used: 4.98 GiB (3.0%) fs: btrfs dev: /dev/nvme0n1p7 maj-min: 259:7
Swap:
Kernel: swappiness: 60 (default) cache-pressure: 100 (default) zswap: no
ID-1: swap-1 type: zram size: 8 GiB used: 0 KiB (0.0%) priority: 100
comp: lzo-rle avail: lzo,lz4,lz4hc,zstd,deflate,842 dev: /dev/zram0
Sensors:
System Temperatures: cpu: 53.0 C mobo: N/A
Fan Speeds (rpm): N/A
Info:
Memory: total: 16 GiB note: est. available: 15.35 GiB used: 2.36 GiB (15.3%)
Processes: 376 Power: uptime: 1m states: freeze,mem,disk suspend: s2idle
avail: deep wakeups: 0 hibernate: platform avail: shutdown, reboot,
suspend, test_resume image: 6.08 GiB services: gsd-power,thermald,upowerd
Init: systemd v: 258 default: graphical tool: systemctl
Packages: pm: rpm pkgs: N/A note: see --rpm tools: dnf,gnome-software,yum
pm: flatpak pkgs: 0 Compilers: N/A Shell: Bash v: 5.3.0
running-in: ptyxis-agent inxi: 3.3.40
^ permalink raw reply
* [PATCH] HID: cp2112: validate report size in raw_event handler
From: Sebastian Josue Alba Vives @ 2026-03-24 6:43 UTC (permalink / raw)
To: jikos, bentiss
Cc: linux-input, linux-kernel, stable, Sebastian Josue Alba Vives
cp2112_raw_event() casts the raw data buffer to a
cp2112_xfer_status_report struct and accesses data at offsets up to
data[3+61] without validating the size parameter. Since
__hid_input_report() invokes the driver's raw_event callback before
hid_report_raw_event() performs its own report-size validation, a
device sending a truncated HID report can cause out-of-bounds heap
reads in the kernel.
Specifically, in the CP2112_DATA_READ_RESPONSE case, data[2] is used
as a length (capped at 61 bytes) for a memcpy from data[3] into
dev->read_data. This data is subsequently accessible from userspace
through the I2C read interface. A malicious USB device could
therefore leak up to 61 bytes of kernel heap memory.
CP2112 devices use 64-byte HID reports. Add a check at the top of
the handler to reject any report shorter than expected.
Cc: stable@vger.kernel.org
Signed-off-by: Sebastian Josue Alba Vives <sebasjosue84@gmail.com>
---
drivers/hid/hid-cp2112.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/hid/hid-cp2112.c b/drivers/hid/hid-cp2112.c
index 803b883ae..b86631163 100644
--- a/drivers/hid/hid-cp2112.c
+++ b/drivers/hid/hid-cp2112.c
@@ -1387,6 +1387,10 @@ static int cp2112_raw_event(struct hid_device *hdev, struct hid_report *report,
struct cp2112_device *dev = hid_get_drvdata(hdev);
struct cp2112_xfer_status_report *xfer = (void *)data;
+ /* CP2112 always sends 64-byte reports */
+ if (size < 64)
+ return 0;
+
switch (data[0]) {
case CP2112_TRANSFER_STATUS_RESPONSE:
hid_dbg(hdev, "xfer status: %02x %02x %04x %04x\n",
--
2.43.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