Re: spi: uniphier: KASAN wild-memory-access in complete() on early IRQ

[Masami Hiramatsu (Google) <mhiramat@kernel.org>]

On Wed, 10 Jun 2026 20:56:21 +0900
Jaeyoung Chung <jjy600901@snu.ac.kr> wrote:

> Hi,
> 
> uniphier_spi_probe() in drivers/spi/spi-uniphier.c registers the
> interrupt handler uniphier_spi_handler() with devm_request_irq() before
> it initializes priv->xfer_done with init_completion(). If an interrupt
> arrives after devm_request_irq() and before init_completion(), the
> handler calls complete() on an uninitialized completion, causing a
> kernel panic.
> 
> The probe path, in uniphier_spi_probe():
> 
>     host = spi_alloc_host(&pdev->dev, sizeof(*priv)); /* priv kzalloc-zeroed */
>     ...
>     ret = devm_request_irq(&pdev->dev, irq, uniphier_spi_handler,
>                            0, "uniphier-spi", priv);  /* register handler */
>     ...
>     init_completion(&priv->xfer_done);                /* initialize completion */
> 
> The interrupt handler uniphier_spi_handler() calls complete() on its
> done path:
> 
>     done:
>         complete(&priv->xfer_done);
> 
> If the device raises an interrupt before init_completion() runs,
> complete() acquires the uninitialized wait.lock and walks the zeroed
> task_list in swake_up_locked(). The zeroed task_list makes list_empty()
> return false, so swake_up_locked() dereferences a NULL list entry,
> triggering a KASAN wild-memory-access.
> 
> Suggested fix: move init_completion(&priv->xfer_done) above
> devm_request_irq(), so the completion is valid before the handler can run.
> 
> Reported-by: Sangyun Kim <sangyun.kim@snu.ac.kr>
> Reported-by: Kyungwook Boo <bookyungwook@gmail.com>
> 

Good catch! All resources used by a callback, should be initialized before
registering it.
Kinihiko, can you fix it by reordering the initialization?

Thank you, 

> Thanks,
> Jaeyoung Chung


-- 
Masami Hiramatsu (Google) <mhiramat@kernel.org>