CVE-2026-64500

iio: adc: lpc32xx: Initialize completion before requesting IRQ

N/A
Published: July 25, 2026 at 08:51 AM UTC
Updated: August 17, 2026 at 05:17 AM UTC
1 product affected across 1 vendorLinux Kernel

Using Linux by Linux?

Get instant alerts when new vulnerabilities affect Linux - before attackers find them.

Real-time alertsTrack your software stackFree plan available
Severity
N/A
Exploit prediction
EPSS 0.2%

Description

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().

Affected

Our own answer: ranges merged, affected separated from platform-only, with confidence and review flags.

4.12 ≤ v < 5.10.2614.12 ≤ v < 5.15.2124.12 ≤ v < 6.1.1784.12 ≤ v < 6.12.964.12 ≤ v < 6.18.394.12 ≤ v < 6.6.1454.12 ≤ v < 7.1.44.12 ≤ v < 7.24.127901b2a1453e48c9defff2c97c67d3089bf4df7a
Vendor states this is fixed in 0e33587967b356519aa6f220b5b43c6976320397 (fixed)
Vendor states this is fixed in 1ddf7b6ffb8ebb22b92a184a9eaa76277ef0c7cd (fixed)
Vendor states this is fixed in 2f18c5551aa97ca7f39dbb151c67c9053ccadc17 (fixed)
Vendor states this is fixed in 48eccc6caed4e62c0f199ab3a3772fa969cd3b2d (fixed)
Vendor states this is fixed in 7090c0d29708ee305022d0ea7b37612b33242fa2 (fixed)
Vendor states this is fixed in 820c4f15353efe9a9429ae86ccceeaf4e0e4e585 (fixed)
Vendor states this is fixed in 9e2e8b8cdfd37ae7c7a8a5c96c59e98a768731c4 (fixed)
Vendor states this is fixed in e561b35633f450ee607e87a6401d97f156a0cd54 (fixed)
Vendor states this is fixed in 4.12 (unaffected)
Vendor states this is fixed in 5.10.261 (unaffected)
Vendor states this is fixed in 5.15.212 (unaffected)
Vendor states this is fixed in 6.1.178 (unaffected)
Vendor states this is fixed in 6.12.96 (unaffected)
Vendor states this is fixed in 6.18.39 (unaffected)
Vendor states this is fixed in 6.6.145 (unaffected)
Vendor states this is fixed in 7.1.4 (unaffected)
Vendor states this is fixed in 7.2 (unaffected)

Remediation

No guide yet

No remediation guidance has been written for this CVE yet, and no fixed version or vendor advisory is recorded against it.

Quick Info

StatusRECEIVED

Get alerted

Stop reading CVE feeds looking for your own stack

Track the products you run and VulnTracker tells you when a new CVE affects them — with what is known about fixing it, and nothing about the rest.

Free plan, no card