Re: [PATCH] HID: multitouch: Add report ID mismatch quirk for ASUS ROG Z13 Folio

Thank you for your contribution! Sashiko AI review found 2 potential issue(=
s) to consider:

Pre-existing issues:
- [Critical] Pre-existing Race Condition leading to Use-After-Free in `mt_r=
emove` due to incorrect teardown ordering.
- [High] Pre-existing logic error in `mt_probe` completely wipes out class-=
specific multitouch quirks if device axes are inverted.
--

--- Patch [1]: [PATCH] HID: multitouch: Add report ID mismatch quirk for AS=
US ROG Z13 Folio ---
commit de9eab2643b8e246b68084a8a0196cbe33c078cf
Author: Lovekesh Solanki <[email protected]>

HID: multitouch: Add report ID mismatch quirk for ASUS ROG Z13 Folio

This commit adds a quirk for the ASUS ROG Z13 Flow touchpad to tolerate
mismatched report IDs during feature fetches. This allows the device to
operate in full Touchpad Precision mode instead of falling back to a
limited mode.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=3D221774

> diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
> index edb37b4c867e4..de421ae47848b 100644
> --- a/drivers/hid/hid-multitouch.c
> +++ b/drivers/hid/hid-multitouch.c

[ ... ]

> @@ -405,6 +407,16 @@ static const struct mt_class mt_classes[] =3D {
>  		.quirks =3D MT_QUIRK_ALWAYS_VALID |
>  			MT_QUIRK_CONTACT_CNT_ACCURATE |
>  			MT_QUIRK_ASUS_CUSTOM_UP },
> +	{ .name =3D MT_CLS_ASUS_ROG_Z13_FOLIO,
> +		.quirks =3D MT_QUIRK_ALWAYS_VALID |
> +			MT_QUIRK_IGNORE_DUPLICATES |
> +			MT_QUIRK_HOVERING |
> +			MT_QUIRK_CONTACT_CNT_ACCURATE |
> +			MT_QUIRK_STICKY_FINGERS |
> +			MT_QUIRK_WIN8_PTP_BUTTONS |
> +			MT_QUIRK_CONFIDENCE |
> +			MT_QUIRK_IGNORE_FEATURE_ID_MISMATCH,
> +		.export_all_inputs =3D true },

While reviewing these class quirk additions, I noticed a pre-existing issue
in the probe function where quirks are assigned:

drivers/hid/hid-multitouch.c:mt_probe() {
...
    if (hdev->quirks & (HID_QUIRK_X_INVERT | HID_QUIRK_Y_INVERT) &&
        !((hdev->quirks & HID_QUIRK_X_INVERT)
          && (hdev->quirks & HID_QUIRK_Y_INVERT)))
        td->mtclass.quirks =3D MT_QUIRK_ORIENTATION_INVERT;
...
}

[Severity: High]
This is a pre-existing issue, but does this assignment mistakenly overwrite
the entire td->mtclass.quirks bitmask instead of appending to it?

If a device is probed with HID_QUIRK_X_INVERT or HID_QUIRK_Y_INVERT (but not
both), it looks like the driver assigns td->mtclass.quirks directly rather
than using the bitwise OR operator (|=3D).

Could this cause the device to lose core functionality derived from its cla=
ss
quirks (like MT_QUIRK_CONFIDENCE or MT_QUIRK_ALWAYS_VALID)?

[ ... ]

I also noticed another pre-existing issue during device teardown:

drivers/hid/hid-multitouch.c:mt_remove() {
...
    timer_delete_sync(&td->release_timer);

    sysfs_remove_group(&hdev->dev.kobj, &mt_attribute_group);
    hid_hw_stop(hdev);
...
}

[Severity: Critical]
This isn't a bug introduced by this patch, but is there a race condition
here that could lead to a use-after-free?

Because hid_hw_stop(hdev) hasn't been called yet when timer_delete_sync()
is called, the hardware transport might still be processing events.

If a touch event is processed immediately after the timer is stopped,
couldn't mt_touch_report() re-arm the timer right before the devres-managed
td structure is freed?

--=20
Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260804202031.7573=
[email protected]?part=3D1