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

[Dmitry Torokhov <dmitry.torokhov@gmail.com>]

Hi Shih-Yuan,

On Sat, Jul 11, 2026 at 09:11:38PM +0800, Shih-Yuan Lee wrote:
> 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 <fourdollars@debian.org>
> ---
>  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/