Re: [PATCH v3] HID: logitech-hidpp: add native touchpad support for K400 Plus
flat view
From: sashiko-bot@kernel.org
Date: 2026-08-24 18:18:24
Thank you for your contribution! Sashiko AI review found 6 potential issue(s) to consider: New issues: - [High] The K400 Plus touchpad is erroneously advertised as a clickpad (buttonpad) without emitting a left button event, breaking userspace interaction. - [High] Dangling `wd->input` pointer leads to a Use-After-Free if `input_register_device()` fails for `CLASS_WTP` devices. - [Medium] Missing cleanup of devres-managed memory (`input_dev` and `devm_name`) in the error paths of `hidpp_connect_event()`. - [Medium] The KBD_WTP touchpad input device gets assigned a generic receiver name instead of the actual human-readable device name. - [Medium] Data race due to missing `READ_ONCE()` on `wd->input` in event handlers. Pre-existing issues: - [High] Dangling `hidpp->input` pointer leads to a Use-After-Free if `input_register_device()` fails inside the HID core. --
--- Patch [1]: [PATCH v3] HID: logitech-hidpp: add native touchpad support for K400 Plus ---commit 0b206b299e2d55ee7d52e893ea117f7035ac35a4 Author: Dmitriy Geels [off-list ref] Subject: HID: logitech-hidpp: add native touchpad support for K400 Plus The Logitech K400 Plus (WPID 0x404d) exposes its touchpad through the HID++ TouchpadRawXY feature, but currently operates as an emulated mouse. Add support for the native raw touchpad reports by creating a separate multitouch input device. Link: https://lore.kernel.org/linux-input/20260824173042.13679-1-dmitriy.geels@gmail.com/ (local)
quoted hunk ↗ jump to hunk
diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c --- a/drivers/hid/hid-logitech-hidpp.c +++ b/drivers/hid/hid-logitech-hidpp.c
[ ... ]
quoted hunk ↗ jump to hunk
@@ -2963,8 +2966,13 @@ static void wtp_populate_input(struct hidpp_device *hidpp, input_set_abs_params(input_dev, ABS_MT_POSITION_Y, 0, wd->y_size, 0, 0); input_abs_set_res(input_dev, ABS_MT_POSITION_Y, wd->resolution); - /* Max pressure is not given by the devices, pick one */ - input_set_abs_params(input_dev, ABS_MT_PRESSURE, 0, 50, 0, 0); + /* + * The driver exposes contact area as pressure. Do not advertise a + * pressure axis when the device does not report contact area; userspace + * may otherwise interpret a permanently-zero pressure value as hover. + */ + if (wd->area_range) + input_set_abs_params(input_dev, ABS_MT_PRESSURE, 0, 50, 0, 0); input_set_capability(input_dev, EV_KEY, BTN_LEFT); if (hidpp->quirks & HIDPP_QUIRK_WTP_PHYSICAL_BUTTONS) input_set_capability(input_dev, EV_KEY, BTN_RIGHT); else __set_bit(INPUT_PROP_BUTTONPAD, input_dev->propbit);
[Severity: High] The stated intent of this patch is to leave physical button reports on the existing HID input device. However, since HIDPP_QUIRK_WTP_PHYSICAL_BUTTONS is not set for the K400 Plus, does this code incorrectly advertise BTN_LEFT and INPUT_PROP_BUTTONPAD for the new touchpad device? Userspace libraries like libinput might expect mechanical clicks directly on the touchpad since it's advertised as a clickpad, but those events are explicitly suppressed in wtp_send_raw_xy_event() for CLASS_KBD_WTP. Could this break click-and-drag functionality? [ ... ]
quoted hunk ↗ jump to hunk
@@ -3066,8 +3079,13 @@ static int wtp_raw_event(struct hid_device *hdev, u8 *data, int size) struct wtp_data *wd = hidpp->private_data; struct hidpp_report *report = (struct hidpp_report *)data; struct hidpp_touchpad_raw_xy raw; + struct input_dev *input; - if (!wd || !hidpp->input) + if (!wd) + return 1; + + input = wd->input; + if (!input) return 1;
[Severity: Medium] The wd->input pointer is published in hidpp_connect_event() using WRITE_ONCE(wd->input, input). Should this reader side use READ_ONCE(wd->input) to prevent potential load tearing or compiler reordering? [ ... ]
quoted hunk ↗ jump to hunk
@@ -4064,14 +4091,22 @@ static int hidpp_input_mapped(struct hid_device *hdev, struct hid_input *hi, } -static void hidpp_populate_input(struct hidpp_device *hidpp, +static int hidpp_populate_input(struct hidpp_device *hidpp, struct input_dev *input) { + int ret; + hidpp->input = input;
[Severity: High] This is a pre-existing issue, but assigning hidpp->input here before the device is registered can lead to a use-after-free. If input_register_device() fails later inside the HID core (e.g., in hidinput_connect()), the core frees the input_dev, but hidpp->input remains populated with the freed pointer. Can this cause raw event handlers to dereference the dangling pointer on incoming reports? [ ... ]
quoted hunk ↗ jump to hunk
@@ -4524,7 +4562,54 @@ static void hidpp_connect_event(struct work_struct *work) return; } - if (hidpp->quirks & HIDPP_QUIRK_CLASS_WTP) { + if (hidpp->quirks & HIDPP_QUIRK_CLASS_KBD_WTP) { + struct wtp_data *wd = hidpp->private_data; + + if (!wd->input) { + ret = wtp_get_config(hidpp); + if (ret) { + hid_err(hdev, "cannot get WTP config: %d\n", ret); + return; + } + + input = hidpp_allocate_input(hdev); + if (!input) { + hid_err(hdev, "cannot allocate touchpad input device\n"); + return; + } + + devm_name = devm_kasprintf(&hdev->dev, GFP_KERNEL, + "%s Touchpad", hidpp->name);
[Severity: Medium] Does this format the input device name using the generic receiver name (e.g., "Logitech USB Receiver Touchpad") rather than the actual device name? The actual device name is fetched using hidpp_get_device_name() and assigned to hidpp->name further down in hidpp_connect_event(), which happens after this registration. Could this break userspace configuration tools or libinput quirks that rely on name matching?
quoted hunk ↗ jump to hunk
+ if (!devm_name) + return; + + input->name = devm_name; + + ret = wtp_populate_input(hidpp, input); + if (ret) { + hid_err(hdev, + "cannot initialize touchpad input device: %d\n", + ret); + input_free_device(input); + return; + }
[Severity: Medium] If wtp_populate_input() or input_register_device() fails, we call input_free_device() but return without cleaning up devm_name. Since hidpp_connect_event() runs in a workqueue triggered by wireless connection events, could repeated connection initialization failures leak the devm_kasprintf() allocations on the parent device's devres list? [ ... ]
quoted hunk ↗ jump to hunk
@@ -4615,7 +4700,12 @@ static void hidpp_connect_event(struct work_struct *work) return; } - hidpp_populate_input(hidpp, input); + ret = hidpp_populate_input(hidpp, input); + if (ret) { + hidpp->input = NULL; + input_free_device(input); + return; + } ret = input_register_device(input); if (ret) { hidpp->input = NULL; input_free_device(input); return; }
[Severity: High] If input_register_device() fails here for a CLASS_WTP device, we free the input device and clear hidpp->input. However, wtp_populate_input() already saved a copy of this pointer in wd->input. Does this leave wd->input pointing to freed memory? If a hardware report arrives shortly after, wtp_raw_event() could bypass its "!wd->input" check and dereference the pointer, causing a use-after-free. Should wd->input also be cleared in these error paths? -- Sashiko AI review · https://sashiko.dev/#/patchset/20260824180425.55809-1-dmitriy.geels@gmail.com?part=1