Re: [PATCH 1/1] HID: wacom: Fix multiple Use-After-Free issues in shared state

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] The patch fails to fully resolve the Use-After-Free vulnerability for `touch_input` because interrupt handlers access it locklessly, leading to a Time-of-Check to Time-of-Use (TOCTOU) race condition.
- [High] A race condition exists between `kref_put()` and concurrent `kref_get()` due to missing list-level locking during object removal.
- [High] Unprotected and temporally separated assignments of `shared->touch` and `shared->touch_input` during probe allow concurrent `uhid` devices to desynchronize the shared state.
--

commit 007cb667e9154320e49d7d42911e8193520da3fe
Author: Lee Jones <lee@kernel.org>

HID: wacom: Fix multiple Use-After-Free issues in shared state

This commit redesigns the wacom_hdev_data structure to store stable static
copies of required attributes instead of a fragile representative pointer.
It explicitly clears the touch_input pointer in wacom_remove_shared_data()
under the wacom_udev_list_lock to address use-after-free vulnerabilities.

> diff --git a/drivers/hid/wacom_sys.c b/drivers/hid/wacom_sys.c
> index a32320b351e3e..9e4819c197c1b 100644
> --- a/drivers/hid/wacom_sys.c
> +++ b/drivers/hid/wacom_sys.c

[ ... ]

> @@ -871,10 +884,14 @@ static void wacom_remove_shared_data(void *res)
>  		data = container_of(wacom_wac->shared, struct wacom_hdev_data,
>  				    shared);
>  
> -		if (wacom_wac->shared->touch == wacom->hdev)
> +		mutex_lock(&wacom_udev_list_lock);
> +		if (wacom_wac->shared->touch == wacom->hdev) {
>  			wacom_wac->shared->touch = NULL;
> -		else if (wacom_wac->shared->pen == wacom->hdev)
> +			wacom_wac->shared->touch_input = NULL;

[Severity: High]
This isn't a bug introduced by this patch, but does clearing this pointer under
the lock fully prevent use-after-free conditions?

Interrupt handlers read shared->touch_input locklessly (for example, in
wacom_wireless_irq()). An interrupt handler could check that
shared->touch_input is valid, but then get preempted.

Concurrently, wacom_remove_shared_data() clears the pointer here, and the
input device is subsequently unregistered and freed by devres.

When the interrupt handler resumes, could it pass the freed pointer to
input_report_switch(), causing a use-after-free? The lock protects writers,
but it appears readers remain vulnerable to this time-of-check to
time-of-use race.

> +		} else if (wacom_wac->shared->pen == wacom->hdev) {
>  			wacom_wac->shared->pen = NULL;
> +		}
> +		mutex_unlock(&wacom_udev_list_lock);
>  
>  		kref_put(&data->kref, wacom_release_shared_data);

[Severity: High]
This is a pre-existing issue, but can this kref_put() race with concurrent
list traversal?

It is called outside of wacom_udev_list_lock. If the reference count drops to 0,
another thread probing a sibling device could simultaneously acquire the list
lock in wacom_add_shared_data(), find the logically dead object before it is
removed from the list, and call kref_get().

This would attempt to increment a 0 refcount, returning a pointer to an object
that will unconditionally be freed as soon as the first thread acquires the
lock in wacom_release_shared_data(), leading to a use-after-free.

>  		wacom_wac->shared = NULL;

[ ... ]

> @@ -899,8 +916,13 @@ static int wacom_add_shared_data(struct hid_device *hdev)
>  		}
>  
>  		kref_init(&data->kref);
> -		data->dev = hdev;
> +		strscpy(data->phys, hdev->phys, sizeof(data->phys));
> +		data->vendor = hdev->vendor;
> +		data->product = hdev->product;
> +		data->device_type = wacom_wac->features.device_type;
>  		list_add_tail(&data->list, &wacom_udev_list);
> +	} else {
> +		data->device_type |= wacom_wac->features.device_type;
>  	}
>  
>  	mutex_unlock(&wacom_udev_list_lock);

[Severity: High]
This is a pre-existing issue, but do the assignments to shared->touch and
shared->touch_input that follow this unlock need protection?

They are performed sequentially outside of any lock during device probe:

	if (wacom_wac->features.device_type & WACOM_DEVICETYPE_TOUCH)
		wacom_wac->shared->touch = hdev;

If two virtual devices with the same physical path are created concurrently
(for example, via uhid), they will share the same wacom_hdev_data structure.

Could a race in the probe sequence result in shared->touch pointing to
device B, while shared->touch_input points to device A?

If device A is then disconnected, wacom_remove_shared_data() would see
shared->touch == wacom->hdev as false and skip clearing shared->touch_input.
Device A's input device would be freed, leaving a dangling pointer that could
be dereferenced by sibling devices.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260527140731.642783-1-lee@kernel.org?part=1