Linux Input/HID development
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Rong Zhang" <i@rong.moe>
Cc: linux-input@vger.kernel.org, dmitry.torokhov@gmail.com
Subject: Re: [PATCH 3/9] HID: haptic, multitouch: Check haptic prerequisite properly
Date: Sun, 01 Nov 2026 17:57:49 +0000	[thread overview]
Message-ID: <sashiko-outbox-192550@kernel.org> (raw)
In-Reply-To: <20261102-hid-haptic-kmod-v1-3-a3de5626dade@rong.moe>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] HID: haptic: hid_haptic_check_pressure_unit() misses non-force unit mismatch
- [Medium] HID: multitouch: one-way is_haptic_touchpad leaks state to other MT inputs
--

commit 8758bcd8ba263569bfbee87a3d749e9ff7ea4489
Author: Rong Zhang <i@rong.moe>

HID: haptic, multitouch: Check haptic prerequisite properly

This commit stores the HID_DG_TOUCHPAD input device and validates pressure
unit annotations across usages in hid_haptic_check_pressure_unit(), ensuring
hid_haptic_input_configured() only initializes haptics for the matching input
device. It also converts td->is_haptic_touchpad into a one-way flag and guards
probe-time hid_haptic_*() calls with td->haptic.

> diff --git a/drivers/hid/hid-haptic.c b/drivers/hid/hid-haptic.c
> index 9cbacc827dc9c..27cc8a2d9b595 100644
> --- a/drivers/hid/hid-haptic.c
> +++ b/drivers/hid/hid-haptic.c
> @@ -48,17 +48,40 @@ void hid_haptic_feature_mapping(struct hid_device *hdev,
>  }
>  EXPORT_SYMBOL_GPL(hid_haptic_feature_mapping);
>  
> -bool hid_haptic_check_pressure_unit(struct hid_haptic_device *haptic,
> +void hid_haptic_check_pressure_unit(struct hid_haptic_device *haptic,
>  				    struct hid_input *hi, struct hid_field *field)
>  {
> -	if (field->unit == HID_UNIT_GRAM || field->unit == HID_UNIT_NEWTON) {
> -		haptic->force_logical_minimum = field->logical_minimum;
> -		haptic->force_physical_minimum = field->physical_minimum;
> -		haptic->force_resolution = input_abs_get_res(hi->input,
> -							     ABS_MT_PRESSURE);
> -		return true;
> +	if (hi->application != HID_DG_TOUCHPAD)
> +		return;
> +
> +	/* Don't care about input devices with no pressure sensor. */
> +	if (field->unit != HID_UNIT_GRAM && field->unit != HID_UNIT_NEWTON)
> +		return;
> +
> +	if (IS_ERR(haptic->input_dev))
> +		return;
> +
> +	if (!haptic->input_dev) {
> +		haptic->input_dev = hi->input;
> +		haptic->pressure_field = field;
> +		haptic->force_resolution = input_abs_get_res(hi->input, ABS_MT_PRESSURE);
> +		return;
>  	}
> -	return false;
> +
> +	if (haptic->input_dev == hi->input &&
> +	    haptic->pressure_field->unit == field->unit &&
> +	    haptic->pressure_field->logical_minimum == field->logical_minimum &&
> +	    haptic->pressure_field->physical_minimum == field->physical_minimum &&
> +	    haptic->force_resolution == input_abs_get_res(hi->input, ABS_MT_PRESSURE))
> +		return;
> +
> +	/*
> +	 * Reject if:
> +	 * - there are multiple input devices with pressure sensors
> +	 * - the pressure annotation mismatches
> +	 */
> +	haptic->input_dev = ERR_PTR(-EPROTO);
> +	return;
>  }

[Severity: Medium]
What happens if a HID_DG_TOUCHPAD input device has multiple
HID_DG_TIPPRESSURE usages where some specify HID_UNIT_GRAM or HID_UNIT_NEWTON
and others have a non-force unit (such as 0)?

In mt_input_mapping() -> mt_touch_input_mapping():

	case HID_DG_TIPPRESSURE:
		set_abs(hi->input, ABS_MT_PRESSURE, field,
			cls->sn_pressure);
		if (td->haptic)
			hid_haptic_check_pressure_unit(td->haptic, hi, field);

Because hid_haptic_check_pressure_unit() returns early when field->unit is
neither HID_UNIT_GRAM nor HID_UNIT_NEWTON before checking haptic->input_dev:

1. If an earlier HID_DG_TIPPRESSURE usage on hi->input has a valid force unit
and a later usage on the same hi->input has unit 0, set_abs() overwrites
ABS_MT_PRESSURE parameters and resets its resolution to 0 on hi->input, while
hid_haptic_check_pressure_unit() returns early instead of setting
haptic->input_dev = ERR_PTR(-EPROTO).

2. Conversely, if the first HID_DG_TIPPRESSURE usage on hi->input has unit 0
and a subsequent usage has HID_UNIT_GRAM or HID_UNIT_NEWTON, the first usage
is ignored and the subsequent usage sees !haptic->input_dev and accepts the
device despite the mismatched annotations across usages.

Should hid_haptic_check_pressure_unit() reject the device when a non-force
unit is encountered on the same hi->input as a force unit?

[ ... ]

> diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
> index 4e19a0c4d2381..d744ccc3e0b0b 100644
> --- a/drivers/hid/hid-multitouch.c
> +++ b/drivers/hid/hid-multitouch.c

[ ... ]

> @@ -1955,14 +1956,11 @@ static int mt_input_configured(struct hid_device *hdev, struct hid_input *hi)
>  	struct hid_report *report;
>  	int ret;
>  
> -	if (td->is_haptic_touchpad && (td->mtclass.name == MT_CLS_WIN_8 ||
> -	    td->mtclass.name == MT_CLS_WIN_8_FORCE_MULTI_INPUT ||
> -	    td->mtclass.name == MT_CLS_WIN_8_KEEP_LATENCY_ON_CLOSE)) {
> -		if (hid_haptic_input_configured(hdev, td->haptic, hi) == 0)
> -			td->is_haptic_touchpad = false;
> -	} else {
> -		td->is_haptic_touchpad = false;
> -	}
> +	if (td->haptic && !td->is_haptic_touchpad &&
> +	    (td->mtclass.name == MT_CLS_WIN_8 ||
> +	     td->mtclass.name == MT_CLS_WIN_8_FORCE_MULTI_INPUT ||
> +	     td->mtclass.name == MT_CLS_WIN_8_KEEP_LATENCY_ON_CLOSE))
> +		td->is_haptic_touchpad = hid_haptic_input_configured(hdev, td->haptic, hi);
>  
>  	list_for_each_entry(report, &hi->reports, hidinput_list) {
>  		rdata = mt_find_report_data(td, report);

[Severity: Medium]
When a composite HID device has a haptic HID_DG_TOUCHPAD collection alongside
another multitouch application collection (such as a HID_DG_TOUCHSCREEN or a
second non-haptic HID_DG_TOUCHPAD without a pressure sensor), does latching
td->is_haptic_touchpad to true here affect the other multitouch inputs on the
same hid_device?

Once mt_input_configured() configures the haptic touchpad hid_input and sets
td->is_haptic_touchpad = true, any subsequent hid_input processed by
mt_input_configured() -> mt_touch_input_configured() will see:

	if (td->is_haptic_touchpad)
		app->mt_flags |= INPUT_MT_TOTAL_FORCE;

and set INPUT_MT_TOTAL_FORCE on that non-haptic application as well.

Similarly, at runtime, mt_process_slot() and mt_sync_frame() only check
td->is_haptic_touchpad rather than verifying whether input matches
td->haptic->input_dev:

	if (td->is_haptic_touchpad)
		hid_haptic_pressure_increase(td->haptic, *slot->p);

and:

	if (td->is_haptic_touchpad)
		hid_haptic_pressure_reset(td->haptic);

Could touches on a non-haptic multitouch input on the same HID device feed
into and reset td->haptic->pressure_sum?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261102-hid-haptic-kmod-v1-0-a3de5626dade@rong.moe?part=3

  reply	other threads:[~2026-11-01 17:57 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-01 17:41 [PATCH 0/9] HID: Add hid-plugin framework & convert haptic into a plugin Rong Zhang
2026-11-01 17:41 ` [PATCH 1/9] HID: haptic: Fix use-after-free when draining workqueue Rong Zhang
2026-11-01 17:41 ` [PATCH 2/9] HID: haptic: Get rid of input_ff_destroy() in error paths Rong Zhang
2026-11-01 17:41 ` [PATCH 3/9] HID: haptic, multitouch: Check haptic prerequisite properly Rong Zhang
2026-11-01 17:57   ` sashiko-bot [this message]
2026-11-01 17:41 ` [PATCH 4/9] HID: haptic, multitouch: Fix haptic device double-free and unnecessary allocation Rong Zhang
2026-11-01 17:41 ` [PATCH 5/9] HID: haptic: Postpone GET_REPORT to init Rong Zhang
2026-11-01 17:41 ` [PATCH 6/9] HID: haptic: Convert simple methods into static inline ones Rong Zhang
2026-11-01 17:41 ` [PATCH 7/9] HID: Add hid-plugin framework for loadable plugin modules Rong Zhang
2026-11-01 17:41 ` [PATCH 8/9] HID: haptic: Convert into a loadable plugin Rong Zhang
2026-11-01 17:41 ` [PATCH 9/9] HID: haptic: Remove stubs in favor of inlined dead code elimination Rong Zhang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=sashiko-outbox-192550@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=i@rong.moe \
    --cc=linux-input@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox