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

[Jaeyoung Chung]

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>

Thanks,
Jaeyoung Chung