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)