A subtle ordering bug in the RISC‑V KVM teardown sequence has been assigned CVE‑2025‑23135 and patched upstream: during module removal the KVM cleanup path could call architecture‑specific cleanup routines in the wrong order, leaving per‑CPU IRQ state inconsistent and preventing the KVM module from being reinserted without a host reboot. The defect is not a memory‑corruption or data‑exfiltration primitive — it is an availability and correctness problem that can reliably break KVM module reattachment and, on affected hosts, produce kernel oopses during module removal. The vulnerability and the minimal upstream fix have been tracked across standard vulnerability databases and vendor advisories.
RISC‑V support in the Linux KVM hypervisor includes architecture‑specific initialisation and teardown code paths. In general, KVM must enable or disable platform features (interrupt controllers, AIA/AIA‑like acceleration, per‑CPU IRQs) at module load/unload time in a carefully ordered way so that resources are released cleanly and state left behind cannot break subsequent module inserts.
CVE‑2025‑23135 describes an ordering error in the teardown sequence: an architecture cleanup function (aia_exit) that should run after KVM‑level teardown was called before the KVM core’s kvm_exit. That inversion left per‑CPU interrupt state inconsistent — the kernel log example included the “percpu IRQ 31 still enabled on CPU0!” warning and a stack trace rooted in __free_percpu_irq — and ultimately prevented the KVM kernel module from being re‑inserted cleanly. Multiple vulnerability trackers and distribution advisories captured the bug description and demonstrated the symptomatic oops traces used to justify the fix.
Source: MSRC Security Update Guide - Microsoft Security Response Center
Background / Overview
RISC‑V support in the Linux KVM hypervisor includes architecture‑specific initialisation and teardown code paths. In general, KVM must enable or disable platform features (interrupt controllers, AIA/AIA‑like acceleration, per‑CPU IRQs) at module load/unload time in a carefully ordered way so that resources are released cleanly and state left behind cannot break subsequent module inserts.CVE‑2025‑23135 describes an ordering error in the teardown sequence: an architecture cleanup function (aia_exit) that should run after KVM‑level teardown was called before the KVM core’s kvm_exit. That inversion left per‑CPU interrupt state inconsistent — the kernel log example included the “percpu IRQ 31 still enabled on CPU0!” warning and a stack trace rooted in __free_percpu_irq — and ultimately prevented the KVM kernel module from being re‑inserted cleanly. Multiple vulnerability trackers and distribution advisories captured the bug description and demonstrated the symptomatic oops traces used to justify the fix.
What went wrong — a technical summary
The high‑level defect
At module removal, KVM runs a multi‑stage cleanup: the KVM core performs global teardown (kvm_exit), then architecture‑specific cleanup routines are expected to be executed to release per‑CPU resources and platform accelerators (for example AIA on some RISC‑V platforms). In the affected code path the architecture cleanup (aia_exit and other arch cleanup functions) was invoked before kvm_exit instead of after it, which allowed the following problematic sequence:- aia_exit attempted to free per‑CPU resources while KVM per‑CPU IRQs were still enabled or in flight;
- __free_percpu_irq observed the inconsistency and raised a kernel warning/panic trace such as “percpu IRQ 31 still enabled on CPU0!”;
- the kernel oops left the module in an inconsistent state and the KVM module could not be reinserted without corrective steps (reboot or further manual intervention).
The observable symptom and root call traces
Vendor advisories and selftest reproductions captured consistent traces showing __free_percpu_irq as the point where resource-state mismatch was detected, with kvm_riscv_aia_exit and cleanup_module present in the call stack. The specific error message and the presence of the per‑CPU IRQ warning are the most actionable telemetry for detection.Why ordering matters
Kernel module teardown is brittle: per‑CPU IRQs, device interrupts and other kernel subsystems have precise enable/disable and registration/unregistration contracts. Calling the wrong cleanup routine too early can leave hardware or kernel data structures in a state where later expected operations (like kvm_exit's arch disable) cannot run, or vice versa. The fix for this CVE is to restore the correct sequencing so the disable step executes before the final exit calls — ensuring that the platform-specific disablement (which quiesces interrupts) is visible to subsequent cleanup operations.Patch and vendor response
Multiple upstream stable commits addressed the problem by re‑ordering the teardown sequence: arch teardown helpers such as aia_exit and related routines are now invoked after kvm_exit and after any platform disable operations that ensure per‑CPU IRQs have been disabled. Vendor trackers and distribution advisories document the mapping from the upstream commits into stable backports; affected distributions (for example Ubuntu and Debian trackers) list CVE‑2025‑23135 and advise applying kernel packages that include the upstream fixes. Security advisories and incident trackers emphasize that the upstream fix is intentionally small and surgical — it corrects ordering rather than introducing a larger redesign — which reduces regression risk and makes backporting straightforward for stable kernel branches. Several curated vulnerability pages and CERT/CSIRT posts point to the upstream commit IDs used in stable trees; operators should confirm that their vendor package changelogs reference either CVE‑2025‑23135 or those commit identifiers before wide deployment. Caveat: some public sources list stable git references and vendor backports; in one authoritative reference list the upstream commit links are provided (these are the canonical patches shipped into stable trees), and operators should map those commit IDs to their distribution package versions for verification. If a vendor advisory or kernel changelog does not explicitly reference the CVE or the commit IDs, treat that package as unverified until you can confirm the backport.Impact and exploitability — what operators need to know
Primary impact class: Availability (host‑local)
This vulnerability is a correctness and cleanup ordering error: the immediate, reproducible impact is kernel instability during module removal leading to host‑level oopses and inability to reinsert the KVM module without a reboot. The threat model is local/host‑adjacent: an attacker or tenant who can run code on the machine (or control a guest VM that triggers the platform’s module unload path) could force the sequence that produces the oops and deny availability of KVM services. This makes multi‑tenant hypervisors and shared development hosts the most sensitive targets.Exploitability and required privileges
- Attack vector: Local or host‑adjacent (module unload requires root; however, guests exercising KVM’s hotplug/module behavior in some test setups could be a vector).
- Complexity: Low — the condition is deterministic once the sequence is reached; the bug surfaced under module removal flows and selftests that exercise teardown logic.
- Scope: The bug does not provide a straightforward path to code execution, information disclosure, or privilege escalation. Its primary effect is denial of service (kernel oops / module reinsert failure).
No public exploitation observed — but don’t be complacent
Public trackers and advisories do not report confirmed active exploitation campaigns tied to CVE‑2025‑23135. That absence is useful information but not proof of safety: availability bugs that reliably crash hypervisors are attractive targets for denial‑of‑service attacks in multi‑tenant clouds and on shared infrastructure. Treat the lack of reported exploits as a reason to patch proactively, not as an argument to deprioritise remediation.Detection, monitoring, and incident response
Indicators to hunt for
- Kernel log entries showing the per‑CPU IRQ warning text such as “percpu IRQ 31 still enabled on CPU0!” or similar IRQ‑related warnings during module removal attempts.
- OOPS traces with frames referencing __free_percpu_irq, free_percpu_irq and arch cleanup functions such as kvm_riscv_aia_exit in the same call stack.
- Repeated failures to rmmod/rmmod‑then‑insmod the KVM module without a host reboot.
- Selftest failures in RISC‑V kernel BPF or KVM selftests executed during CI that reproduce module unload sequences.
Short incident playbook
- If you observe the oops trace, isolate the host from production pools to prevent propagation of guest instability and to limit tenant impact.
- Capture and preserve kernel logs, dmesg output and, if necessary, a memory capture for forensic analysis. The oops traces tend to be deterministic and helpful for root‑cause verification.
- Avoid attempting repeated module removal/insert cycles on a live host; a full host reboot into a patched kernel is the most robust recovery.
- Identify which guest or local process triggered the unload sequence (correlate with kexec/kmod events and selftest runs) and quarantine any untrusted guests.
- Apply the vendor/distribution kernel update that contains the upstream fix and reboot. Confirm the rebooted host no longer reproduces the oops under the same test sequence.
Remediation and operational guidance (practical checklist)
- Inventory hosts: identify RISC‑V systems and any hypervisors that run KVM on RISC‑V or that boot RISC‑V kernels (use uname -r, check for kvm and kvm_riscv modules).
- Confirm vendor status: check your distribution’s security tracker (Ubuntu, Debian, vendor advisory) to find the package version that includes the upstream backport. Only treat a package as fixed if the changelog references CVE‑2025‑23135 or the upstream commit IDs.
- Stage updates: apply patched kernels in a pilot group; verify guest boot, live migration, snapshot and storage IO functions. Run the same module unload/load or selftests that previously triggered the oops in a controlled staging environment.
- Deploy in waves: roll the patched kernel to production hosts in phases with rollback windows and monitoring. Watch kernel logs for 7–14 days post‑patch for any regression signals.
- Short‑term mitigations if you cannot immediately patch: avoid running untrusted guests on vulnerable hosts; postpone VM migrations that would place untrusted workloads on RISC‑V hypervisors; and limit root access to hosts where module unloads might be triggered. These are operational mitigations only — they do not fix the underlying kernel bug.
Why the fix is conservative and appropriate
Upstream maintainers fixed CVE‑2025‑23135 with a minimal change to correct the teardown ordering rather than performing a broad redesign of the KVM teardown sequence. That narrow approach reduces regression risk and simplifies vendor backports into stable kernel trees. Distribution advisories and security trackers reflect that this corrective pattern is the accepted engineering solution for similar teardown correctness bugs in KVM — fix the order, ensure disable steps run before resource free operations, and verify per‑CPU/per‑device invariants.Risk assessment — strengths and residual concerns
- Strengths of the remediation: the patch is small, targeted and straightforward to backport; the failure mode is deterministic and produces clear kernel traces for detection; vendor advisories have broadly propagated fixes for affected kernel packages.
- Residual risks and caveats:
- Hardware and distribution variability means some vendor kernels may lag upstream or provide different backports; do not assume your platform is fixed until you verify patch presence in package changelogs.
- The bug is availability‑focused; while there is no public evidence that it leads to data leakage or code execution, kernel oopses are high‑value primitives for attackers with local access and may be combined with other vulnerabilities in complex exploit chains — treat that as a non‑zero risk.
- Verification note: certain authoritative upstream commit pages are referenced by vendor advisories and security trackers; operators should map those commit IDs to their vendor package versions for absolute verification. If a vendor does not publish the mapping, request the vendor’s attestation or test the patch in staging.
Quick reference: what to do now (concise action list)
- Immediately inventory any KVM hosts running RISC‑V kernels.
- If you run such hosts in multi‑tenant or cloud‑style deployments, prioritize patching them first.
- Apply vendor kernel updates that list CVE‑2025‑23135 or the upstream commit IDs; reboot hosts into the patched kernel.
- Monitor kernel logs for the IRQ/percpu oops signature and validate remediation in staging before full roll‑out.
Conclusion
CVE‑2025‑23135 is a classic kernel‑teardown ordering bug: small in scope but significant in operational impact. It does not present an immediate memory‑corruption or data‑exfiltration vector, but it produces reliable availability failures that can disrupt hypervisor hosts and multi‑tenant infrastructure. The upstream fix is minimal, has been incorporated into stable kernel trees and distribution advisories, and should be treated as a high‑priority patch for any environment that runs RISC‑V KVM hosts or otherwise depends on clean module teardown semantics. Verify vendor package changelogs for the CVE or the upstream commit IDs, stage the patches, and monitor hosts post‑deployment for related kernel oops traces. Acting promptly on correct, vendor‑mapped kernel updates will prevent this deterministic denial‑of‑service condition from impacting production virtualization platforms.Source: MSRC Security Update Guide - Microsoft Security Response Center
