CVE-2026-64500

What it actually does

This is a Linux kernel race condition in the LPC32xx ADC Industrial I/O driver. During device probe, the driver registers its interrupt handler before initializing the completion object used by that handler. If the ADC device raises an interrupt in that short window, the interrupt service routine calls complete() on an uninitialized completion structure, which can dereference invalid or NULL list pointers and trigger a kernel panic. The practical technical impact is denial of service of the affected system; there is no clear indication from the provided information that this enables privilege escalation or code execution.

Why it matters to the business

Affected systems can crash during device initialization or driver probing, causing service interruption, unexpected reboots, loss of availability, and potential operational disruption for embedded or appliance-like Linux systems using LPC32xx ADC hardware. The EPSS score is very low, it is not listed in CISA KEV, and no public exploit maturity is indicated, so broad internet-scale exploitation is unlikely; however, systems that rely on this hardware path should still prioritize patching because a kernel panic can directly affect uptime.

How an attack unfolds

An attacker would need a system running a vulnerable Linux kernel with the LPC32xx ADC driver present and the relevant device being probed. Exploitation depends on causing, inducing, or racing an ADC interrupt after devm_request_irq() registers lpc32xx_adc_isr() but before init_completion() initializes the completion object. If the interrupt lands in that window, the handler calls complete() on an uninitialized structure, causing invalid list handling in the kernel wake-up path and leading to a kernel crash. In realistic scenarios, this is most plausible through local hardware access, control of attached device behavior, malicious or faulty peripheral behavior, repeated driver bind/unbind or boot-time probing conditions, or accidental spurious IRQs rather than remote network exploitation.

How to fix it

Update to a Linux kernel build that includes the fix moving init_completion(&st->completion) before devm_request_irq() in drivers/iio/adc/lpc32xx_adc.c. Where vendor fixed versions are not available, obtain the corrected kernel from the relevant distribution, device vendor, BSP provider, or upstream stable branch once released. If immediate patching is not possible, reduce exposure by disabling or removing the LPC32xx ADC driver where it is not required, preventing the affected hardware from being probed, avoiding unnecessary driver bind/unbind operations, and limiting local or physical access to interfaces that could influence ADC interrupt behavior. For custom kernels, backport the source-level fix and rebuild, then redeploy the kernel and modules consistently.

How to confirm the fix worked

Confirm the running kernel or vendor package includes the source change that initializes st->completion before registering the IRQ handler in lpc32xx_adc_probe(). On source-based or custom builds, inspect drivers/iio/adc/lpc32xx_adc.c and verify init_completion(&st->completion) appears before devm_request_irq(... lpc32xx_adc_isr ...). Confirm whether the driver is enabled by checking the kernel configuration for the LPC32xx ADC driver, loaded modules, device tree/platform device configuration, and boot logs referencing lpc32xx ADC or IIO ADC registration. After patching, reboot into the fixed kernel and confirm the active kernel version matches the patched build. If feasible in a controlled test environment, perform repeated boot, probe, unbind, and rebind cycles and verify no kernel panic or KASAN report occurs around lpc32xx_adc_isr(), complete(), or swake_up_locked().

Typical attack path

1. Identify a Linux system using a vulnerable kernel with the LPC32xx ADC IIO driver enabled or loaded.
2. Ensure the LPC32xx ADC device is present or the driver probe path can be triggered, such as during boot, device registration, or driver rebind.
3. Cause or wait for an ADC interrupt to occur immediately after the IRQ handler is registered but before the completion object is initialized.
4. The interrupt handler invokes complete() on the uninitialized completion object.
5. The kernel dereferences invalid completion/list state and panics, resulting in denial of service.

How to detect it

Review kernel logs, persistent journal entries, serial console captures, crash dumps, pstore records, and kdump/vmcore artifacts for kernel panics or memory-access violations during boot or device probing. Focus on systems with LPC32xx ADC hardware or the lpc32xx_adc driver enabled. Relevant evidence includes stack traces mentioning lpc32xx_adc_isr(), complete(), swake_up_locked(), wait queues, completion handling, KASAN wild-memory-access, NULL pointer dereference, or crashes shortly after IRQ registration for the LPC32xx ADC device. Because this flaw causes a crash rather than a durable post-exploitation footprint, absence of logs after reboot does not prove absence of exploitation; ensure persistent kernel logging, pstore, netconsole, serial console, or crash dump capture is enabled on high-value embedded systems.

• lpc32xx_adc_isr
• lpc32xx_adc
• drivers/iio/adc/lpc32xx_adc.c
• KASAN: wild-memory-access
• BUG: KASAN
• Unable to handle kernel NULL pointer dereference
• kernel panic
• complete
• swake_up_locked
• list_empty
• devm_request_irq
• init_completion
• LPC32XXAD_NAME

What your security team should do

• Inventory Linux systems and embedded devices that use LPC32xx ADC hardware or include the LPC32xx ADC IIO driver.
• Prioritize patching for production embedded, appliance, industrial, or availability-sensitive systems where a kernel panic would cause operational impact.
• Upgrade to a vendor kernel containing the fix, or backport the upstream source change if maintaining a custom kernel or board support package.
• If the driver or hardware is not required, disable the LPC32xx ADC driver in the kernel configuration or prevent the device from being probed.
• Restrict local, physical, and peripheral-level access on affected systems because exploitation is most plausible through hardware interrupt control or local device manipulation.
• Monitor kernel logs for panics, KASAN reports, NULL pointer dereferences, and stack traces involving lpc32xx_adc_isr, complete, or swake_up_locked.
• Track vendor advisories for exact fixed package versions, since no product-specific fixed versions were provided in the input.