PT-2026-64721 · Linux · Linux
CVE-2026-64500
·
Published
2026-07-25
·
Updated
2026-07-25
None
No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
In the Linux kernel, the following vulnerability has been resolved:
iio: adc: lpc32xx: Initialize completion before requesting IRQ
In the report from Jaeyoung Chung:
"lpc32xx adc probe() in drivers/iio/adc/lpc32xx adc.c registers its
interrupt handler with devm request irq() before it initializes
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 */
lpc32xx adc isr() calls 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."
Fix the chance of a spurious IRQ causing an uninitialized pointer
dereference by moving init completion() above devm request irq().
Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Linux