media: solo6x10: KASAN wild-memory-access in complete() on early IRQ

[Jaeyoung Chung]

Hi,

solo_pci_probe() in drivers/media/pci/solo6x10/solo6x10-core.c registers
the interrupt handler solo_isr() with devm_request_irq() before it
initializes each p2m_dev->completion with init_completion() in
solo_p2m_init(). If an interrupt arrives after devm_request_irq() and
before solo_p2m_init(), the handler calls complete() on an
uninitialized completion, causing a kernel panic.


The probe path, in solo_pci_probe():

    solo_dev = kzalloc_obj(*solo_dev);                /* completions zeroed */
    ...
    ret = devm_request_irq(&pdev->dev, pdev->irq, solo_isr, /* register handler */
                           IRQF_SHARED, SOLO6X10_NAME, solo_dev);
    ...
    ret = solo_p2m_init(solo_dev);                    /* init_completion() */

The interrupt handler path solo_isr() -> solo_p2m_error_isr() calls
complete() on the uninitialized completion:

    for (i = 0; i < SOLO_NR_P2M; i++) {
        ...
        complete(&p2m_dev->completion);
    }

If the device raises an interrupt before solo_p2m_init() 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 devm_request_irq() below solo_p2m_init(), so the
completions are valid before the handler can run.

Reported-by: Sangyun Kim <sangyun.kim@xxxxxxxxx>
Reported-by: Kyungwook Boo <bookyungwook@xxxxxxxxx>

Thanks,
Jaeyoung Chung