CVE-2026-64500

In the Linux kernel, the following vulnerability has been resolved:

iio: adc: lpc32xx: Initialize completion before requesting IRQ

In the report from Jaeyoung Chung:

"lpc32xxadcprobe() in drivers/iio/adc/lpc32xxadc.c registers its interrupt handler with devmrequestirq() before it initializes st->completion with initcompletion(). If an interrupt arrives after devmrequestirq() and before init_completion(), the handler calls complete() on an uninitialized completion, causing a kernel panic.

The probe path, in lpc32xxadcprobe():

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 */

lpc32xxadcisr() calls complete():

complete(&st->completion);

If the device raises an interrupt before initcompletion() runs, complete() acquires the uninitialized wait.lock and walks the zeroed tasklist in swakeuplocked(). The zeroed tasklist makes listempty() return false, so swakeuplocked() dereferences a NULL list entry, triggering a KASAN wild-memory-access."

Fix the chance of a spurious IRQ causing an uninitialized pointer dereference by moving initcompletion() above devmrequest_irq().