Re: [PATCH v2 3/4] Input: call handler->start() when uninhibiting device
From: sashiko-bot@kernel.org
Date: 2026-08-03 01:27:58
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 [off-list ref] 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.
quoted hunk ↗ jump to hunk
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/20260803005210.1251102-1-dmitry.torokhov@gmail.com?part=3