CVE-2026-64461

What it actually does

This is a Linux kernel resource-leak flaw in the MediaTek PCIe host controller driver. When a PCIe port fails to enable during probe/setup, the driver frees the port structure but fails to tear down IRQ domains that were initialized earlier. The result is a leaked kernel IRQ-domain resource on the probe error path. The most realistic technical consequence is kernel resource exhaustion or PCIe initialization instability on affected MediaTek SoC-based systems, rather than code execution or data disclosure.

Why it matters to the business

Systems using affected Linux kernels on MediaTek-based hardware may experience degraded reliability, failed PCIe device initialization, or instability after repeated PCIe probe failures. The currently reported exploitation likelihood is low, with no CISA KEV listing, no ransomware association, and no public exploit maturity reported, but embedded, networking, IoT, or appliance platforms using MediaTek SoCs should still take the fix through normal kernel maintenance cycles.

How an attack unfolds

An attacker would need a way to repeatedly trigger the MediaTek PCIe driver’s port-enable failure path. In practical terms, that usually requires local administrative control, control over kernel/module loading, manipulation of PCIe hardware state, malformed platform configuration, or physical/device-level influence over PCIe initialization. When the PCIe port enable operation fails, the vulnerable driver removes and frees the port object but leaves the IRQ domain allocated. Repeating this condition can accumulate leaked kernel resources and may eventually contribute to denial of service, driver initialization failures, or system instability. There is no indication from the provided data that this is remotely exploitable, weaponized, or used by named threat actors.

How to fix it

Apply a Linux kernel update that includes the upstream fix for the MediaTek PCIe IRQ-domain teardown path. If using a vendor kernel, install the vendor-provided kernel or firmware/platform update that backports the fix. No exact fixed package versions were provided in the input, so validate remediation through vendor advisories, distribution changelogs, or kernel source history for the MediaTek PCIe driver change that adds per-port IRQ teardown on the port-enable failure path. Where immediate patching is not possible, reduce exposure by disabling unused PCIe ports, avoiding repeated driver reload/probe cycles, preventing untrusted users from loading kernel modules or changing device-tree/platform configuration, and limiting physical access to affected embedded platforms.

How to confirm the fix worked

Confirm the running kernel includes the fix by checking distribution or vendor changelogs for the MediaTek PCIe IRQ-domain leak correction, or by reviewing the kernel source for a per-port IRQ teardown helper invoked when MediaTek PCIe port enable fails during setup. After updating, reboot into the fixed kernel and verify the active kernel version with standard OS tooling. On affected hardware, test PCIe initialization failure and recovery paths where feasible and confirm that repeated failures do not produce increasing kernel resource use or persistent IRQ-domain leakage symptoms. Review kernel logs for MediaTek PCIe probe failures before and after patching to ensure the driver behaves cleanly on error paths.

Typical attack path

1. Identify a Linux system running an affected kernel with the MediaTek PCIe host controller driver in use.
2. Obtain local privileged access, device-management control, or physical/platform-level ability to influence PCIe initialization.
3. Trigger PCIe port enable failures during driver probe or setup, such as by causing hardware, reset, clock, power, or configuration problems.
4. Repeat the failure condition so IRQ domains are allocated but not released.
5. Cause gradual kernel resource leakage that may lead to PCIe malfunction, service disruption, or system instability.

How to detect it

There are no known compromise-specific indicators, no reported public exploit, and no KEV listing for this issue. To assess whether the vulnerable path may have been exercised, review kernel logs from dmesg, journald, /var/log/kern.log, and /var/log/messages for repeated MediaTek PCIe probe failures, PCIe port enable failures, IRQ allocation/domain errors, or unexplained PCIe device initialization problems. Look for correlations between these messages and reboots, watchdog resets, kernel warnings, driver reloads, or degraded PCIe device availability. Because this flaw is a kernel resource leak, forensic evidence is more likely to appear as repeated driver initialization errors and system instability than as files, processes, network traffic, or registry-style artifacts.

What your security team should do

• Prioritize patching affected MediaTek SoC-based systems, especially embedded, network, industrial, or appliance devices where PCIe reliability is operationally important.
• Inventory Linux kernels and vendor firmware images that include the MediaTek PCIe host controller driver.
• Track vendor kernel advisories and ensure the upstream fix is backported into all maintained device images.
• Restrict local administrative access, kernel module loading, debug interfaces, and physical access to devices until patched.
• Monitor kernel logs for repeated MediaTek PCIe probe or port-enable failures, which may indicate exposure to the vulnerable error path.
• Treat this as a reliability and denial-of-service risk rather than an immediate remote compromise risk unless new exploit information emerges.