CVE-2026-63798

What it actually does

This is a Linux kernel use-after-free condition in the imgpdc interrupt controller driver. During probe, the driver allocates generic interrupt chips and installs chained interrupt handlers, but during removal it fails to free the generic chips and clear the chained handlers. After the driver is removed, kernel suspend, resume, shutdown, or interrupt handling paths may still reference stale structures, causing access to freed memory. The most likely technical outcome is a kernel crash or panic; depending on memory reuse and platform specifics, broader kernel memory corruption may be possible, but no public exploit maturity is indicated.

Why it matters to the business

Systems using affected Linux kernels on hardware that includes the imgpdc interrupt controller may experience unexpected crashes, reboots, or failed suspend/resume/shutdown operations if the driver is removed or the affected interrupt paths are triggered after removal. This can cause service disruption, device instability, and operational downtime. The currently low EPSS score and absence from the Known Exploited Vulnerabilities catalog suggest low near-term internet-scale exploitation likelihood, but kernel crashes on embedded, appliance, or production Linux systems can still have meaningful availability impact.

How an attack unfolds

An attacker would generally need a way to influence the affected driver lifecycle or trigger relevant interrupt handling after the driver has been removed. In a plausible local attack scenario, the attacker gains sufficient privileges or access to unbind/remove the imgpdc driver, causing the driver cleanup path to run without freeing generic interrupt chip state or clearing chained handlers. The attacker then triggers a suspend, resume, shutdown, or relevant interrupt event. The kernel may follow stale global interrupt chip references or dangling chained handler pointers, dereferencing freed memory and causing a kernel crash. Practical exploitation is expected to be highly platform-dependent and primarily availability-focused unless additional primitives are present.

How to fix it

Upgrade to a Linux kernel build that includes the upstream fix for the imgpdc irqchip driver. The fix sets IRQ_DOMAIN_FLAG_DESTROY_GC so generic chips are destroyed during irq_domain_remove(), and explicitly clears chained handlers in pdc_intc_remove(). If vendor fixed package versions are not available, track your Linux distribution, appliance vendor, or board support package advisories for the backported patch. Where immediate patching is not possible, reduce exposure by preventing untrusted users from loading, unloading, or unbinding kernel drivers; disabling unnecessary debug or administrative interfaces that permit driver manipulation; restricting suspend/resume control paths; and applying normal kernel hardening and least-privilege controls.

How to confirm the fix worked

Confirm the running kernel or vendor kernel package contains the imgpdc irqchip cleanup fix. Source-based validation can check that the driver sets IRQ_DOMAIN_FLAG_DESTROY_GC on the IRQ domain and clears chained handlers with NULL during pdc_intc_remove(). Operational validation should include confirming the affected hardware/driver is present only where expected, verifying that unprivileged users cannot unbind or remove the driver, and testing suspend/resume/shutdown workflows on patched non-production systems without kernel warnings, crashes, or KASAN use-after-free reports.

Typical attack path

1. Identify a Linux system running an affected kernel on hardware using the imgpdc interrupt controller driver.
2. Obtain local privileges or another mechanism capable of removing, unbinding, or unloading the affected driver path.
3. Trigger driver removal so generic interrupt chips and chained handlers are left registered incorrectly.
4. Cause a suspend, resume, shutdown, or interrupt event that reaches the stale interrupt chip or handler state.
5. Induce a kernel use-after-free condition, commonly resulting in a crash, panic, reboot, or system instability.

How to detect it

Look for evidence of driver removal or unbinding followed by kernel faults, panic, watchdog resets, or KASAN reports. Useful log sources include kernel ring buffer output, system journal entries, kdump/vmcore analysis, serial console logs, appliance crash logs, and EDR telemetry that records privileged writes to sysfs driver bind/unbind interfaces. Focus on events involving the imgpdc or pdc_intc driver, interrupt controller cleanup, chained interrupt handlers, generic interrupt chip suspend/resume/shutdown callbacks, and crashes occurring immediately after suspend, resume, shutdown, or driver removal. Because no public exploitation is indicated, detection is primarily behavioral and crash-forensic rather than based on a stable attacker IOC.

• imgpdc
• irqchip/imgpdc
• pdc_intc_remove
• IRQ_DOMAIN_FLAG_DESTROY_GC
• irq_domain_remove
• irq_alloc_domain_generic_chips
• irq_set_chained_handler_and_data
• irq_gc_suspend
• irq_gc_resume
• irq_gc_shutdown
• BUG: KASAN: use-after-free
• Unable to handle kernel paging request
• Kernel panic - not syncing
• /sys/bus/platform/drivers/*/unbind
• /sys/bus/platform/drivers/*/bind

What your security team should do

• Inventory Linux systems, embedded devices, appliances, and board support packages that use kernels containing the imgpdc interrupt controller driver.
• Prioritize patching systems where the driver is present and where crashes would affect production availability or safety-critical operations.
• Monitor vendor kernel advisories for exact fixed package versions and deploy the patched kernel as soon as available.
• Restrict access to driver unbind, module loading/unloading, debugfs, sysfs administration, and power-management controls to trusted administrators only.
• Enable or review kernel crash collection, persistent journaling, kdump, and centralized logging for affected platforms.
• Hunt for kernel crashes or KASAN reports referencing imgpdc, pdc_intc_remove, generic interrupt chips, chained handlers, suspend, resume, or shutdown paths.
• Treat repeated unexplained crashes around driver removal or power-state transitions as potentially security-relevant until patched and investigated.