Re: [PATCH v2 3/4] Input: call handler->start() when uninhibiting device

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

Pre-existing issues:
- [High] Sysfs uninhibiting a device can race with device unregistration, causing `dev->open()` to be called on a hardware device that is being destroyed.
--

--- Patch [3]: [PATCH v2 3/4] Input: call handler->start() when uninhibiting device ---
commit 7812e6dd22b71b48fc822b6545778a4eb30f8e35
Author: Dmitry Torokhov <[email protected]>

Input: call handler->start() when uninhibiting device

When an input device is uninhibited, the driver is re-opened. This patch
ensures that complex handlers are also notified to re-synchronize their
state by calling handler->start() for each open handle.

> diff --git a/drivers/input/input.c b/drivers/input/input.c
> index e4f8c2067b84d..47886a394c6b8 100644
> --- a/drivers/input/input.c
> +++ b/drivers/input/input.c
> @@ -1806,6 +1806,7 @@ static int input_inhibit_device(struct input_dev *dev)
>  
>  static int input_uninhibit_device(struct input_dev *dev)
>  {
> +	struct input_handle *handle;
>  	int error;
>  
>  	guard(mutex)(&dev->mutex);

[Severity: High]
This is a pre-existing issue, but does this function open a race condition
with input_unregister_device() by missing a check for dev->going_away?

When a driver calls input_unregister_device(), the core sets
dev->going_away = true in input_disconnect_device() and releases
dev->mutex.

If a concurrent sysfs write to the inhibited attribute executes
input_uninhibit_device(), it acquires dev->mutex here.

Because it lacks a dev->going_away check (unlike input_open_device()), it
proceeds to set dev->inhibited = false and calls dev->open() on a dying
device.

Can this lead to a use-after-free or hardware state corruption if the
driver has already freed its IO mappings or IRQs during unregistration?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=3