CVE-2026-64462

What it actually does

This vulnerability is a Linux kernel use-after-free condition in the Altera PCIe host controller driver probe-failure path. During device initialization, the driver installs a chained interrupt handler and enables controller interrupts before pci_host_probe() completes. If probing fails, devm-managed host bridge memory containing the driver state can be released while the interrupt handler and INTx IRQ domain remain registered. A later interrupt can then invoke the handler with a stale data pointer, potentially causing kernel memory corruption, a kernel panic, or other undefined kernel behavior. Practical exposure is limited to systems using the affected Altera PCIe host controller driver and capable of reaching the faulty probe/error path.

Why it matters to the business

The most likely business impact is system instability or denial of service on affected Linux systems, especially embedded, FPGA, industrial, telecom, or appliance platforms using Altera PCIe host controller hardware. Successful exploitation could crash a device, interrupt workloads, or require manual recovery. There is currently no indication that this issue is being exploited in the wild, it is not listed in CISA KEV, and the EPSS score is low, so urgency should be driven primarily by asset criticality and whether affected hardware and driver code are present.

How an attack unfolds

An attacker would need a way to influence or trigger the affected PCIe host controller initialization failure path and then cause an interrupt to be delivered after the driver state has been freed but before the stale interrupt handler and IRQ domain are fully removed. In a realistic scenario, this is more likely to be reachable by a local privileged actor, a malicious or malfunctioning PCIe device, or a fault-injection condition during platform bring-up rather than by a remote network attacker. Once the stale interrupt fires, the kernel may dereference freed memory through the chained IRQ handler, causing a crash or potentially creating a kernel memory corruption primitive depending on timing, memory reuse, and platform behavior.

How to fix it

Apply a Linux kernel update that includes the fix for the Altera PCIe host controller probe-failure cleanup logic. The corrected code delays chained handler setup until after INTx domain creation, disables controller interrupts during IRQ teardown, and removes IRQ setup if pci_host_probe() fails. If vendor fixed versions are not listed for a distribution or appliance, track the relevant kernel package advisory from the OS, BSP, embedded Linux, or device vendor and update to the first release containing the upstream fix. Where immediate patching is not possible, reduce exposure by disabling unused Altera PCIe host controller functionality, preventing untrusted PCIe devices from being attached, restricting local administrative access, and prioritizing high-availability or safety-critical systems for maintenance windows.

How to confirm the fix worked

Confirm that affected systems are running a kernel build that includes the upstream fix or an equivalent vendor backport. Validate whether the Altera PCIe host controller driver is built, loaded, or present in the platform device tree. Check kernel package changelogs, vendor advisories, or source commits for the PCI Altera probe-failure cleanup fix. After patching, reboot into the fixed kernel and verify the running kernel version with uname -a and package manager metadata. For source-based kernels, inspect the driver implementation to confirm that IRQ teardown disables controller interrupts and that the chained handler is not left registered on pci_host_probe() failure.

Typical attack path

1. Identify a Linux system using the Altera PCIe host controller driver.
2. Trigger or wait for a driver probe failure after interrupts have been enabled and IRQ handling has been partially initialized.
3. Cause or rely on a controller interrupt after the probe failure cleanup path has released driver state.
4. The stale chained IRQ handler is invoked with a freed driver data pointer.
5. The kernel experiences memory corruption, a panic, or other instability, resulting in denial of service or potentially further exploitation under favorable conditions.

How to detect it

Review kernel and system logs for evidence of failed PCIe host controller probing followed by interrupt-related faults, kernel oops, panics, or crashes. Useful log sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, crash dumps, kdump/vmcore analysis, and appliance-specific system event logs. Look for messages involving the Altera PCIe host driver, pci_host_probe() failures, IRQ domain setup or teardown errors, unexpected chained interrupt activity, NULL pointer dereferences, use-after-free symptoms, general protection faults, or panics shortly after PCIe initialization. Because no public exploitation is currently known and no reliable exploit-specific artifacts are derivable from the advisory, detection should focus on anomalous kernel crash patterns and PCIe initialization failures on systems with affected hardware.

• altera-pcie
• Altera PCIe
• pci_host_probe
• IRQ domain
• INTx
• chained IRQ handler
• kernel BUG
• Oops:
• general protection fault
• Unable to handle kernel NULL pointer dereference
• use-after-free
• Kernel panic
• Call Trace:
• pcie-altera

What your security team should do

• Inventory Linux systems, embedded devices, appliances, and FPGA-based platforms that include or load the Altera PCIe host controller driver.
• Prioritize patching for systems where PCIe devices are physically accessible, hot-pluggable, managed by less-trusted operators, or used in critical operational environments.
• Apply vendor kernel updates or BSP updates containing the fix; if no vendor package is available, request a backport from the platform supplier.
• Restrict physical and administrative access to affected systems until patched, especially where untrusted PCIe hardware could be introduced.
• Monitor kernel logs for PCIe probe failures, interrupt storms, kernel oops messages, or panics associated with the Altera PCIe driver.
• Include this issue in embedded Linux and appliance vulnerability management workflows even if standard server scanners do not detect the hardware-specific driver exposure.