Re: [PATCH v3] HID: logitech-hidpp: add native touchpad support for K400 Plus

[sashiko-bot@kernel.org]

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 <dmitriy.geels@gmail.com>
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/

> 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

[ ... ]

> @@ -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?

[ ... ]

> @@ -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?

[ ... ]

> @@ -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?

[ ... ]

> @@ -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?

> +			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?

[ ... ]

> @@ -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