Thread (26 messages) 26 messages, 4 authors, 8d ago

Re: [PATCH v5 1/3] Input: applespi - cancel pending work on driver remove

From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Date: 2026-07-11 21:55:18
Also in: linux-spi, lkml

Hi Shih-Yuan,

On Sat, Jul 11, 2026 at 09:11:38PM +0800, Shih-Yuan Lee wrote:
quoted hunk ↗ jump to hunk
During driver removal in applespi_remove(), the managed private data
structure is freed by devres. However, the driver does not cancel the
asynchronous work applespi->work, which registers the touchpad input
device.

This creates a use-after-free (UAF) vulnerability if a pending or
running worker thread attempts to access the private data after the
remove function returns.

Fix this by explicitly calling cancel_work_sync(&applespi->work) in
applespi_remove() before cleanups.

Signed-off-by: Shih-Yuan Lee <redacted>
---
 drivers/input/keyboard/applespi.c | 2 ++
 1 file changed, 2 insertions(+)
diff --git a/drivers/input/keyboard/applespi.c b/drivers/input/keyboard/applespi.c
index b5ff71cd5a70..3bdb9e7cfb8b 100644
--- a/drivers/input/keyboard/applespi.c
+++ b/drivers/input/keyboard/applespi.c
@@ -1822,6 +1822,8 @@ static void applespi_remove(struct spi_device *spi)
 
 	applespi_drain_reads(applespi);
 
+	cancel_work_sync(&applespi->work);
+
 	debugfs_remove_recursive(applespi->debugfs_root);
 }
For this, and the next one, the issue is that the touchpad discovery is
asynchronous. I wonder if making touchpad detection synchronous and
making the entire driver as PROBE_PREFER_ASYNCHRONOUS would not make it
simpler and more robust.

It looks like Ronald tried to do that in [1] but unfortunately it was
dropped on the floor (my fault :( ). Maybe you can try it out and
freshen it?

Thanks.

-- 
Dmitry

[1] https://lore.kernel.org/all/20190721070523.24695-1-ronald@innovation.ch/ (local)
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help