Linux Kernel Patch: MCHP EIC IRQ Mapping Fixed (CVE-2025-68766)

The Linux kernel received a focused upstream fix for CVE-2025-68766 that corrects an error-handling bug in the Microchip External Interrupt Controller (irqchip/mchp-eic) code: when irq_domain_translate_twocell could produce a hardware interrupt number (hwirq) equal to or greater than the controller's supported IRQ count (MCHP_EIC_NIRQ == 2), the code validated the value but failed to set a proper error return, allowing an out‑of‑bounds access to proceed; the accepted upstream change forces the function to return -EINVAL for that invalid mapping and thereby prevents the OOB access.

---

Background​

The Microchip External Interrupt Controller (MCHP EIC) driver implements irq domain translation helpers used by device-tree or firmware bindings to map system interrupt specifiers into hardware IRQ indices consumed by the controller. In the vulnerable code path, the domain allocation routine — the function named mchp_eic_domain_alloc in drivers/irqchip/irq-mchp-eic.c — relied on the helper irq_domain_translate_twocell to fill in an hwirq value. If the translation produced a value outside the controller’s supported range (specifically, greater than or equal to the compile-time constant MCHP_EIC_NIRQ which equals 2), the code attempted to detect this invalid condition but did not set the function’s error return appropriately. That omission let callers proceed under the assumption that translation succeeded, exposing an out‑of‑bounds read and potential system instability. This behavior is documented in the formal CVE entry and mirrored vulnerability databases. Why this matters: even small indexing mistakes in kernel IRQ domain code can produce out‑of‑bounds accesses that cause kernel oopses, panics, or other availability failures on affected platforms — especially in small SoC environments where the controller has a tiny supported range and device-tree wiring mistakes or malformed firmware data might supply an unexpected interrupt specifier.

---

What changed (the patch in plain terms)​

The upstream patch is intentionally minimal and defensive: the allocation routine now explicitly returns -EINVAL when the translated hwirq is outside the allowable range, rather than returning success or silently letting a downstream pointer/index use invalid values. That change converts a logic path that previously allowed an out‑of‑bounds access into a deterministic error return that callers can handle safely.
Key technical elements of the fix:

• Add an explicit check after irq_domain_translate_twocell to test if hwirq >= MCHP_EIC_NIRQ.
• When that invalid condition is true, set the function’s return value to -EINVAL and avoid any indexing into arrays or data structures with the bad index.
• No behavior change for valid inputs — the happy path remains unchanged, which reduces regression risk and eases backporting to stable kernel branches.

Upstream vulnerability databases and OSV record the same corrective action and provide references to the stable-tree commits where the change was applied.

---

Technical analysis: root cause and exploitability​

Root cause​

The bug is a classic incomplete error-handling defect: the translation helper can report an invalid hardware IRQ, and although the driver code detects the invalidity, it fails to propagate an appropriate error return to the caller. That mismatch leaves the caller to assume that translation succeeded and to use the out-of-range hwirq value, which in turn indexes or otherwise accesses memory outside the valid small table (the controller only supports two IRQ indices).
This is not a memory-corruption-style use‑after‑free or heap overflow; it is an out‑of‑bounds read resulting from an unchecked numeric value. The underlying cause is a failure to align control flow and error semantics: detection happened, but the error code path did not get activated.

Exploitability and attack surface​

• Attack vector: local. The condition requires malformed interrupt specifiers or faulty device-tree / firmware that causes irq_domain_translate_twocell to yield an invalid hwirq. In practice, that can happen during device probe, runtime binding, or when userland or firmware updates change device-tree nodes.
• Privileges required: low — an attacker with the ability to influence device-tree, supply malformed firmware data, or locally load device bindings could trigger the condition. On many standard desktop or server deployments the attack surface is trivial or absent (platforms rarely expose raw device-tree editing to unprivileged users), but embedded and development boards are more exposed.
• Impact class: availability-first. Public trackers classify the issue as an out‑of‑bounds read that can cause Denial of Service (kernel oops/panic), and there is no authoritative report of a remote code‑execution exploit built on this issue at disclosure. Treat remote RCE claims as speculative without a published proof-of-concept.

Severity scoring varies by vendor databases (some mark it moderate or low depending on the exact CVSS formula), but the consensus view is that the flaw is locally exploitable and primarily availability-impacting rather than immediately enabling privilege escalation. SUSE rates the issue as moderate and provides CVSS breakdowns that emphasize Local attack vector and a relatively high availability impact.

---

Affected components and practical exposure​

• Affected component: Linux kernel irqchip driver for Microchip EIC — source file drivers/irqchip/irq-mchp-eic.c and the function mchp_eic_domain_alloc.
• Practical exposure: devices and kernels that build and load the MCHP EIC driver. That typically includes small SoC platforms, vendor BSP kernels, and embedded boards using Microchip SoCs or EIC hardware that expose the EIC via device-tree bindings.
• Distribution impact: Because this is an in-tree kernel bug fixed upstream, distributions and vendors will need to map the upstream commit to their kernel package versions and release updates; embedded/OEM kernels and vendor BSPs are the most likely to lag upstream and therefore remain vulnerable longer. OSV and distribution trackers list Debian and other packaging trackers for mapping.

Note: generic cloud images and mainstream server hardware are less likely to include the Microchip EIC driver or to have the driver probed in typical cloud configurations — inventorying your deployed kernel configuration is the first step to determine if you need the patch.

---

Proof, patch availability and distribution status​

Upstream kernel maintainers committed a small change to the stable kernel trees to return -EINVAL on invalid hwirq values in mchp_eic_domain_alloc, and vulnerability aggregators (NVD, OSV) ingest that change into public advisories. Public vulnerability pages list stable tree commits as references; some distribution trackers have already ingested the CVE metadata for packaging work. Caveat about direct commit inspection: canonical upstream commit diffs are referenced by many trackers, but some web mirrors or fetch endpoints block automated tools — where a direct git.kernel.org diff fetch fails, rely on OSV/NVD references and your vendor’s package changelog to validate the presence of the upstream patch in your kernel. Where available, the stable-tree commit id in the kernel repository authoritatively shows the change; operators should map commits to their distribution package versions for proof of remediation.

---

Detection and triage guidance​

A practical triage checklist for system administrators and integrators:

• Inventory: run uname -r and inspect the kernel configuration to determine whether the MCHP EIC driver is compiled in or present as a module. Search for drivers/irqchip/irq-mchp-eic.c in your kernel sources or modules tree.
• Probe logs: examine dmesg or journalctl for EIC probe or irq-domain translation messages. Look for device-tree translation warnings, unexpected IRQ index values, or oops traces mentioning irqchip/irq-mchp-eic or the EIC driver.
• Test cases: on test hardware, exercise device probe/unbind cycles and validate that invalid device-tree interrupt specifiers are rejected safely without kernel oops.
• Verify patch: check your kernel package changelog or vendor advisory for the upstream stable commit id or an explicit mention of CVE-2025-68766. If the vendor does not provide a clear mapping, inspect the kernel source tree in your build to confirm the function returns -EINVAL in the out‑of‑range case.
• Short-term mitigation: if the driver is not required on the host, consider blacklisting the module until a patched kernel package is available; for embedded devices where kernel rebuild is the only path, plan a BSP backport of the minimal fix.

Because the fault is an index/guarding issue, good detection telemetry often looks like a kernel oops stack that indicates a small-bounded indexing operation or an IRQ domain translation path — gather crash logs and stack traces and preserve them for vendor triage.

---

Remediation options and recommended steps​

• Apply vendor or distribution kernel updates that include the upstream fix. This is the recommended and simplest remediation path for most operators.
• If you manage your own kernel builds (OEM, BSP, embedded), cherry-pick the small upstream patch into your stable branch and rebuild. The patch is intentionally minimal and backport-friendly: it only changes the error-return path, leaving normal behaviour intact.
• If no immediate kernel update is possible:
• Blacklist the irq-mchp-eic module if the hardware is not present or the driver is unnecessary.
• Harden device-tree provisioning processes to validate interrupt specifiers before runtime deployment.
• Restrict local access to device-configuration tooling that could introduce malformed bindings.
• Post-patch validation: after rebuilding or installing a patched kernel, run probe/unbind regression tests and check logs for absence of the previous oops patterns. Validate that device-tree translation failures now return error codes rather than causing crashes.

Upstream maintainers intentionally prefer small, surgical patches for this class of bug to reduce regression risk and make backporting straightforward — a pattern seen repeatedly in kernel maintenance practice.

---

Why the fix is the right engineering choice — and its limitations​

Strengths of the upstream approach:

• Minimal and deterministic: returning -EINVAL for invalid interrupt indices eliminates the ambiguous state that led to the OOB access without rearchitecting the domain translation subsystem.
• Low regression risk: the happy-path is unchanged; tests and backports are simpler.
• Backport‑friendly: small changes are easy to cherry-pick into multiple stable branches used by distributors and OEMs, speeding remediation across diverse kernels.

Risks and limitations:

• The fix addresses the immediate symptom (incorrect return value) but does not change how or why invalid specifiers are presented to the driver. Systems that produce malformed device-tree data or poorly validated firmware may continue to surface errors; the driver is now safe, but the underlying data-quality problem may remain.
• Vendor kernel forks and embedded BSPs often have long patch tails. Even though the patch is small, operators must verify that vendor builds contain the change; patch absence in vendor kernels is the most likely reason devices remain vulnerable after the upstream fix. This operational lag is a recurring theme in kernel maintenance and remains a practical remediation challenge.

---

Risk prioritization: who should care now​

• High priority: embedded system maintainers, BSP integrators, and device vendors that ship Microchip EIC hardware or vendor kernels that include the irq-mchp-eic driver. These environments are most likely to exercise the affected code and to encounter device-tree or firmware irregularities.
• Medium priority: developers and testers working on SoC platforms that may probe the EIC as part of bring-up. Test harnesses that exercise device-tree parsing should include the fix to avoid flaky test failures.
• Low priority: mainstream cloud/server infrastructure where the Microchip EIC is neither present nor probed in typical deployments.

Overall, treat this CVE as an availability and robustness issue: it should be fixed in any kernel build that includes the EIC driver, but it does not demand the same urgency as a verified remote code execution flaw unless you operate affected hardware or your threat model includes local, untrusted configuration channels.

---

Detection signatures and monitoring hints​

• Kernel oops traces that mention irq-mchp-eic or EIC probe routines.
• Device-tree translation errors during boot or probe that indicate the interrupt specifier produced an index >= 2.
• Regression test failures in device bring-up that previously produced transient crashes on probe/unbind.

Ensure crash collectors and log aggregation capture kernel oops output (dmesg, journalctl -k, or persistent kdump) and that logs are retained for vendor support if you need to escalate.

---

Recommendations (concise action list)​

• Inventory: confirm whether your kernels compile or load irq-mchp-eic.
• Patch: apply vendor/distribution kernels that reference the upstream fix or include CVE-2025-68766 in their changelog.
• Backport: for embedded/BSP kernels, cherry-pick the upstream patch into your maintenance branch and rebuild.
• Test: validate no probe-time oopses and confirm translated interrupt outputs are rejected safely.
• Mitigate: blacklist the module where the hardware is unused; harden device-tree provisioning to prevent malformed specifiers.

This sequence balances operational safety with practical engineering constraints: small upstream fixes of the type applied here are specifically chosen to minimize the chance of regressions while restoring correct behavior in drivers that interact with firmware and device-tree.

---

Closing analysis​

CVE-2025-68766 is a focused, in-tree Linux kernel fix that eliminates an out‑of‑bounds read by making mchp_eic_domain_alloc reliably return an error when irq_domain_translate_twocell yields an out‑of‑range hardware IRQ value. The fix is small, low-risk, and backportable — precisely the pattern kernel maintainers favor for correctness bugs in hardware glue code. Public vulnerability databases (NVD, OSV) and vendor advisories record the fix and ingest the CVE metadata; distributions and vendors should map the upstream commit to their packaged kernels and roll updates to affected devices as appropriate. Two practical cautions for operators: first, verify the actual presence of the fix in vendor kernels rather than assuming immediate protection; second, treat lingering device-tree or firmware errors as a separate reliability problem — the patch prevents OOB access, but upstream data quality issues should be corrected at source where possible. The broader lesson remains unchanged: defensive error handling at API boundaries — especially for tiny, bounded hardware indices — is essential to preventing reliability defects that can manifest as local denial of service in deployed systems.
Conclusion: apply the patch where applicable, verify vendor backports, and treat this CVE as a robust reminder that index validation and correct error propagation are a low-cost, high-value form of defensive kernel engineering.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center