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 at 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 at snu.ac.kr>
>> Reported-by: Kyungwook Boo <bookyungwook at gmail.com>

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