Re: iio: adc: KASAN wild-memory-access in complete() on early IRQ

[Vladimir Zapolskiy]

On 6/11/26 19:07, Maxwell Doose wrote:
> On Wed, Jun 10, 2026 at 7:04 AM Jaeyoung Chung <jjy600901@xxxxxxxxx> wrote:
> > Hi,
> >
> > lpc32xx_adc_probe() in drivers/iio/adc/lpc32xx_adc.c and
> > spear_adc_probe() in drivers/iio/adc/spear_adc.c register their
> > interrupt handler with devm_request_irq() before they initialize
> > st->completion 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 lpc32xx_adc_probe():
> >
> >      iodev = devm_iio_device_alloc(&pdev->dev, sizeof(*st)); /* st kzalloc-zeroed */
> >      ...
> >      retval = devm_request_irq(&pdev->dev, irq, lpc32xx_adc_isr, 0,
> >                                LPC32XXAD_NAME, st);           /* register handler */
> >      ...
> >      init_completion(&st->completion);                       /* initialize completion */
> >
> > spear_adc_probe() has the same ordering: devm_request_irq() for
> > spear_adc_isr() before init_completion(&st->completion).
> >
> > Both interrupt handlers, lpc32xx_adc_isr() and spear_adc_isr(), call
> > complete():
> >
> >      complete(&st->completion);
> >
> > 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(&st->completion) 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>
>
> Thanks for reporting this; I can start working on a fix shortly
> (assuming nobody else is already working on it).

The analysis and the proposed fix are correct, please go ahead, thank you
in advance.

--
Best wishes,
Vladimir