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

[Kunihiko Hayashi]

Hi, Jaeyoung Masami-san

On 2026/06/10 22:57, Masami Hiramatsu wrote:
> On Wed, 10 Jun 2026 20:56:21 +0900
> Jaeyoung Chung <jjy600901@xxxxxxxxx> 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@xxxxxxxxx>
> > Reported-by: Kyungwook Boo <bookyungwook@xxxxxxxxx>

Thank you for your report.

Indeed, if an interrupt occurs before init_completion, an exception might
occur depending on the status.

And I also confirmed the detection of KASAN using pseudo interrupt call.

  BUG: KASAN: out-of-bounds in complete+0x74/0xf0
  Read of size 8 at addr fffffffffffffff8 by task swapper/0/1
  Pointer tag: [ff], memory tag: [fe]
  ...
  Memory state around the buggy address:
   fffffffffffffd00: fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe
   fffffffffffffe00: fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe
  >ffffffffffffff00: fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe
  Unable to handle kernel paging request at virtual address efff800000000000
  KASAN: null-ptr-deref in range [0x0000000000000000-0x000000000000000f]

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

Yes, I'll prepare to fix it according to the report.

Thank you,

> Thank you,
>
> > Thanks,
> > Jaeyoung Chung

--
---
Best Regards
Kunihiko Hayashi