CVE-2026-63862

What it actually does

This flaw is a resource-leak denial-of-service issue in the Linux kernel MediaTek Gen3 PCIe controller driver. During PCIe IRQ setup, the driver allocated IRQ domains before confirming that the controller IRQ was available; if IRQ lookup failed, the function returned without freeing the allocated IRQ domain objects. On affected systems, repeated probe failures or device reinitialization paths could consume kernel resources over time, potentially degrading PCIe functionality or system stability. The issue is limited to systems using the affected MediaTek Gen3 PCIe driver path and is not a general remote code execution or privilege-escalation vulnerability.

Why it matters to the business

The main operational risk is instability or loss of PCIe functionality on affected Linux-based systems, especially embedded, appliance, networking, or IoT platforms using MediaTek PCIe hardware. Exploitation likelihood appears low based on the very low EPSS score, no known public exploit maturity, and no CISA KEV listing, but organizations that ship or operate Linux images on affected hardware should still remediate through normal kernel maintenance because kernel resource leaks can cause difficult-to-diagnose reliability incidents.

How an attack unfolds

An attacker would need a way to cause the MediaTek Gen3 PCIe controller driver to enter the error path where the controller IRQ cannot be found after IRQ domains have already been allocated. In realistic scenarios this is most likely triggered by malformed or inconsistent platform firmware/device-tree configuration, repeated driver probe failures, repeated bind/unbind operations, or other local administrative actions that force the PCIe controller initialization path to run and fail. Each failed initialization can leave IRQ domain resources allocated. Over time, repeated triggering may exhaust relevant kernel resources or destabilize PCIe initialization, resulting in denial of service. There is no indication from the provided data that this is remotely exploitable, used by known threat actors, or used in ransomware campaigns.

How to fix it

Update to a Linux kernel version or vendor kernel package that includes the fix for the MediaTek Gen3 PCIe driver, specifically the change that fetches the controller IRQ before allocating IRQ domains in mtk_pcie_setup_irq(). Because no exact affected product list or fixed package versions were provided, use the kernel or device vendor’s advisory and changelog to identify the corrected build for each supported platform. If immediate patching is not possible, reduce exposure by avoiding repeated driver reprobe/bind/unbind operations, preventing untrusted users from gaining administrative access to kernel module or device-management interfaces, and validating platform firmware/device-tree configuration so the PCIe controller IRQ is correctly defined.

How to confirm the fix worked

Confirm remediation by verifying the running kernel or vendor firmware image contains the patched MediaTek Gen3 PCIe driver logic. Review vendor release notes, kernel changelogs, or source code to ensure mtk_pcie_setup_irq() obtains the controller IRQ before allocating IRQ domains. On test hardware, boot with the corrected image and confirm that the MediaTek PCIe controller initializes without repeated IRQ lookup failures or accumulating kernel warnings. Where source validation is possible, compare the driver under drivers/pci/controller/pcie-mediatek-gen3.c against the upstream fix. Operationally, monitor dmesg or journal logs for recurring MediaTek PCIe probe failures before and after patching.

Typical attack path

1. Identify a Linux system using the MediaTek Gen3 PCIe controller driver.
2. Obtain sufficient local, physical, firmware, or administrative control to influence PCIe controller initialization or driver probing.
3. Cause the PCIe controller IRQ lookup to fail during driver setup, such as through invalid platform configuration or repeated failed probe paths.
4. Repeat the failure condition so leaked IRQ domain allocations accumulate.
5. Trigger degraded PCIe behavior, failed device initialization, resource exhaustion, or broader system instability.

How to detect it

Look for evidence of repeated MediaTek Gen3 PCIe controller initialization failures rather than classic intrusion artifacts. Useful sources include kernel ring buffer output, systemd journal kernel logs, serial console logs, embedded device boot logs, crash dumps, and hardware watchdog reset records. Search for recurring PCIe probe failures, missing IRQ messages, IRQ-domain allocation issues, driver bind/unbind activity, and repeated reboots or watchdog resets after PCIe initialization errors. If local misuse is a concern, review audit logs and shell history for privileged writes to sysfs driver bind/unbind paths, kernel module management commands, firmware updates, or device-tree overlay changes. No public threat-actor or ransomware exploitation is indicated in the provided intelligence.

• drivers/pci/controller/pcie-mediatek-gen3.c
• mtk_pcie_setup_irq
• mediatek-gen3
• pcie-mediatek-gen3
• mtk-pcie
• IRQ not found
• irq not found
• failed to get IRQ
• failed to get irq
• of_irq_get
• irq_domain
• /sys/bus/platform/drivers/*/bind
• /sys/bus/platform/drivers/*/unbind
• /sys/bus/pci/drivers/*/bind
• /sys/bus/pci/drivers/*/unbind
• modprobe pcie-mediatek-gen3
• rmmod pcie-mediatek-gen3

What your security team should do

• Prioritize remediation for Linux-based appliances, embedded systems, routers, gateways, or custom platforms that use MediaTek Gen3 PCIe hardware.
• Track kernel and device-vendor advisories for the first fixed kernel/package version applicable to each affected platform.
• Include this fix in the next normal kernel maintenance cycle unless affected systems are safety-critical or showing PCIe instability, in which case accelerate patching.
• Restrict administrative access that can trigger driver bind/unbind, kernel module operations, firmware changes, or device-tree changes.
• Review boot and kernel logs on affected hardware for repeated MediaTek PCIe IRQ/probe failures that may indicate exposure to the vulnerable error path.
• Add regression tests for PCIe controller probe-failure cleanup in hardware validation or CI pipelines for affected Linux images.