Re: [PATCH 10/11] HID: hid-tmff: use 'hid_device_id::driver_data_ptr'

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Potential NULL pointer dereference in `tmff_init()` when dynamically binding devices via sysfs `new_id`.
--

commit 773ba3555b1e1205e4c7dd4ff010a1b6be4f15fa
Author: Pawel Zalewski (The Capable Hub) <pzalewski@thegoodpenguin.co.uk>

HID: hid-tmff: use 'hid_device_id::driver_data_ptr'

This commit updates the Thrustmaster HID driver to use the driver_data_ptr
field in the hid_device_id structure. It removes unsigned long and void
pointer casts to improve readability.

> diff --git a/drivers/hid/hid-tmff.c b/drivers/hid/hid-tmff.c
> index 423f395d01ac5..0d7e73fba0fa3 100644
> --- a/drivers/hid/hid-tmff.c
> +++ b/drivers/hid/hid-tmff.c
[ ... ]
> @@ -226,7 +226,7 @@ static int tm_probe(struct hid_device *hdev, const struct hid_device_id *id)
>  		goto err;
>  	}
>  
> -	tmff_init(hdev, (void *)id->driver_data);
> +	tmff_init(hdev, id->driver_data_ptr);

If a new device ID is dynamically added to the HID driver via the sysfs
new_id interface without explicitly providing driver_data, does
id->driver_data_ptr default to NULL?

If id->driver_data_ptr is NULL, and the dynamically bound device contains
a THRUSTMASTER_USAGE_FF usage in its HID report descriptor, can this lead
to a NULL pointer dereference in tmff_init()?

Looking at tmff_init(), it appears to unconditionally dereference the
ff_bits pointer in this situation:

    for (i = 0; ff_bits[i] >= 0; i++)

Could this regression allow a standard administrative sysfs action to crash
the system? While the missing NULL check might predate these changes,
modifying the pointer extraction here seems like a good time to address it.

>  
>  	return 0;
>  err:

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260518-mod-devicetable-hid_device_id-v1-0-a08e3989c283@thegoodpenguin.co.uk?part=10