Understanding CVE-2025-68259: Linux KVM SVM INT3 Re-injection Bug

A subtle but important Linux kernel vulnerability in the KVM SVM backend — tracked as CVE-2025-68259 — allows KVM to mis-handle software interrupt re-injection (INT3/INTO and select INTn) when the guest code stream has been modified between execution and KVM’s decode step, which can lead to erroneous instruction decoding, a wrong next RIP, and deterministic guest panics or host instability for AMD/SVM guests.

Background / Overview​

This issue arises from the interaction between KVM’s SVM (AMD) fastpaths and the way Linux performs atomic text patching (the “text poke” mechanism used for static branch enabling/disabling). When the kernel or another CPU temporarily replaces the first byte of an instruction with an INT3 (opcode 0xCC) to patch code concurrently, a vCPU may execute that INT3 while another CPU is in the middle of replacing the rest of the instruction bytes. If KVM decodes the instruction at the wrong time — and later attempts to retry the instruction instead of re-injecting the INT3/INTO exception — the decoded instruction stream can be inconsistent with the guest’s intended code, leading to an incorrect next RIP and a crash in the guest kernel. This behavior is summarized in multiple vulnerability trackers and the OSV entry for CVE-2025-68259. At a high level the bug is a correctness/race problem at the fastpath/emulator boundary: KVM’s handling of soft-interrupt re-injection (for INT3/INTO/INTn) must confirm that the instruction it decoded matches the instruction that actually executed on the vCPU. Failure to verify that can “clobber” guest state by using a wrong next RIP computed from a mismatched decoded instruction. Multiple independent trackers and mailing-list discussions describe the same model and root cause.

---

Technical anatomy​

How the race appears in practice​

• Linux performs text patching by: (1) writing an INT3 (0xCC) into the first byte of a target instruction, (2) writing new code bytes for the remainder of the instruction (or new instruction sequence) while leaving the first byte alone, and (3) finally replacing the INT3 with the final first byte of the new code. This ensures an executing CPU that hits the INT3 will trap and the kernel can handle the breakpoint and emulate or continue as appropriate.
• When a vCPU executes an INT3 (or INTO/select INTn) while the host KVM is decoding for the next RIP, there is a window where the code bytes visible to the vCPU and the bytes that KVM decodes may differ — for example, because a different vCPU or the host patched the memory between execution and decode.
• KVM historically sometimes retries the instruction (i.e., treat it as if the CPU should execute it again) rather than re-inject the soft-interrupt. If the decoded instruction doesn't match the executed instruction, that retry can advance RIP incorrectly or perform the wrong emulation path. The end result can be a guest kernel panic (commonly "Oops: int3") or corrupted guest control flow. This is the behavior fixed by the CVE. Multiple vulnerability databases and kernel patch notes describe this failure mode.

Why re-injection is the correct model​

The accepted engineering approach — implemented upstream in the KVM SVM code changes that map to this CVE — is to re-inject the original INTn exception when the CPU encountered an exception while vectoring INT3/INTO, rather than blindly retrying the instruction. Re-injection preserves the semantics of the guest’s breakpoint handling and prevents decoding-based RIP mismatch from corrupting guest execution. This approach was anticipated in earlier upstream patches and was the explicit justification for the subsequent fix series. The kernel mailing list and patchew archives document the rationale and the patch series history.

Where the failure manifests​

• Typical observable symptom: repeated "Oops: int3" panics in affected guests during workloads that heavily exercise static branch checks or text-patching code paths.
• Reproducible test case: researchers reproduced the bug quickly by running a guest that spins on a static branch while the host runs a small control program (for example, a drgn script) to repeatedly swap or modify the memory containing the guest’s relevant region (TSS or code pages). Several public writeups and the CVE description point to gist test-cases used in reproducibility experiments.

---

What the upstream patches changed​

Upstream KVM maintainers implemented a narrow, surgical change to ensure KVM:

• Verifies the vectoring/re-injection semantics for INT3/INTO and select INTn cases,
• Discards the exception and retries the instruction only if the code stream has not changed between execution and decode, and
• When the next-RIP information is not provided by the CPU (or the architecture semantics clear next_rip), forces controlled emulation paths that compute next RIP correctly and avoid unsafe fastpath assumptions.

The patch series (discussed on LKML and mirrored on patchew) adjusted the logic around svm_update_soft_interrupt_rip and __svm_skip_emulated_instruction to use emulation types that explicitly request skipping or re-injection behavior, and to ensure RIP is corrected using the appropriate NRIPS/next_rip semantics. These commit-level intentions are recorded in upstream patch messages and kernel mailing list discussion. A mirror of the SVM KVM source that contains the relevant code paths (for example arch/x86/kvm/svm/svm.c) shows the code comments and the control-flow changes that underpin the fix; independent mirrors and archives used for code search corroborate the implementation approach.

---

Affected systems and exploitability​

• Affected component: Linux kernel — KVM SVM (AMD virtualization) backend.
• Attack vector: local/guest — a tenant or user-space entity that can run code in a guest VM can trigger the condition. This is not remotely exploitable without the ability to execute arbitrary code inside a guest on a host that runs the vulnerable kernel.
• Impact class: Availability (denial-of-service) and guest integrity (incorrect RIP leads to panics). There is no public evidence that this vulnerability leads directly to cross-VM data exfiltration or host privilege escalation; the principal real-world effect is deterministic crashes and instability for guests and potentially the hypervisor host under some conditions. Several vulnerability trackers and advisory writeups categorize the risk accordingly.

Caveat: vendor- and distribution-level impact depends on which kernel tree and which stable backports a given vendor has shipped. Some trackers list kernel version ranges where the upstream fix had not yet been applied in particular stable branches; site operators must confirm package changelogs in their distribution security advisories. Distributors and cloud vendors often backport the upstream fix to their stable kernels; confirm the exact package name and version in vendor documentation before assuming a host is fixed.

---

Detection and indicators of compromise​

• Kernel logs containing “Oops: int3” in guest stack traces correlated with KVM/SVM frames often indicate this class of problem.
• Host logs that show KVM call traces involving instruction decode or emulation routines (x86_decode_insn, x86_emulate_instruction) together with __might_fault or __might_resched may indicate the fastpath/emulation inconsistency.
• Reproducible testing: running a test guest that exercises static branch patching while simultaneously altering the guest code (simulating a concurrent patch on another vCPU) can make the bug appear quickly; this is why researchers used short drgn scripts and simple guest code to reproduce the failure. Multiple trackers and the CVE description point to such test methodologies.

---

Mitigation and remediation​

Immediate practical steps for operators:

• Confirm whether your host kernel package includes the upstream fix or a vendor backport. Look for the CVE identifier in the package changelog or for the upstream commit IDs referenced by vendor advisories. Do not assume a kernel is fixed without explicit changelog/backport confirmation.
• If a fixed kernel is available from your distribution or cloud provider, schedule a maintenance window to apply the update and reboot the host. This is the definitive remediation.
• If you cannot update immediately:
• Reduce exposure by not running untrusted guests on vulnerable hosts.
• Consider migrating higher-risk tenants to patched hosts where possible.
• As a temporary and cautious mitigation, avoid kernel/CPU configurations that remove next-RIP support (for example, do not force nrips=false unless you understand the consequences) because many of the failure modes appear when the CPU does not supply a reliable next RIP — though changing such low-level flags is brittle and must be tested.
• Detection: monitor kernel logs on hypervisor hosts for KVM-related panic traces, repeated vCPU failures, and the specific "sleeping function called from invalid context" or "Oops: int3" signatures that have been associated with SVM fastpath/emulation mismatches.
• For cloud operators: coordinate with tenants and follow established live-migration/evacuation practices when patching hypervisors. Patch in staged waves with good telemetry (kernel logs, guest health checks) to catch regressions before broad rollout.

---

Vendor and distribution status (what to watch for)​

Upstream kernel developers applied the changes in the SVM code path and that patch has been propagated into stable branches and vendor backports in a typical kernel-stable workflow. However, the exact point at which a given distribution’s package contains the fix varies. Public trackers and distribution advisories are the authoritative sources for fixed package names and versions; operators should consult:

• Their Linux distribution’s security tracker (Debian, Ubuntu, Red Hat, SUSE, etc. for the fixed kernel package and CVE mapping.
• Cloud provider advisories (public cloud vendors publish kernel and image advisories) for guidance on whether hosted images and managed kernels in their environment contain the backport.

Some vendors produce machine-readable VEX/CSAF attestation that maps CVEs to specific product artifacts (for example, certain cloud-supplied Linux images); these attestations can confirm whether a particular vendor image is considered “potentially affected” or fixed. Operators should treat vendor advisories and changelogs as the canonical proof of fix status in any given environment.

---

Risk assessment and operational trade-offs​

Strengths of the fix​

• The upstream patch is intentionally small and narrowly scoped: it restores correct re-injection semantics and avoids broader redesign. That reduces regression risk and simplifies backporting into stable kernels.
• By drawing a clear boundary between safe emulation contexts and fastpath contexts that cannot sleep, the fix addresses both correctness and context-safety (preventing sleeping-from-fastpath faults). This pattern is tested and repeated across similar KVM fixes and is a robust design approach.

Residual risks and caveats​

• Performance trade-off: in some specific CPU/configurations where the CPU does not supply next-RIP, KVM may be forced to take the slower emulation path more frequently (to safely compute next RIP and avoid unsafe fastpath assumptions). That can have a measurable performance impact on workloads that previously benefitted from fastpaths. Operators should test critical workloads and measure impact during staged rollouts.
• Backport correctness: distributions may backport the upstream change differently; operators should validate vendor package changelogs against the upstream commit descriptions. If a distribution’s fix is incomplete or not applied, the host remains vulnerable.
• Detection difficulty: because the attack vector is guest-local and the observable outcome is availability loss, exploitation is noisy (panics, oops), but that also means an attacker with guest access can trivially demonstrate the issue — making the bug attractive for denial-of-service on multi-tenant hypervisors. Prioritize patching in public cloud and shared environments.

---

Forensics and responsible disclosure notes​

• There are no widely published weaponized exploits for this CVE; however the bug’s deterministic reproduction and the fact it can be triggered from a guest VM make it an obvious denial-of-service primitive for untrusted tenants.
• If you observe relevant kernel traces in production, collect kernel logs and preserved memory images as appropriate for post-incident analysis; the call traces are usually deterministic and useful for confirming root cause.

---

Practical checklist for sysadmins and security teams​

• Inventory: list all hosts running KVM and identify which ones use AMD/SVM virtualization. Check kernel package versions and vendor advisories for CVE-2025-68259 mappings.
• Prioritize: give highest priority to cloud hypervisors, multi-tenant hosts, and development/build clusters that accept untrusted guests. Single-tenant or isolated desktop hosts are lower priority but should still be patched.
• Patch: obtain vendor-supplied kernel packages that reference this CVE or the upstream commit and schedule reboots. Validate the fix in a test/staging environment before broad rollout.
• Monitor: set up log alerts for KVM/SVM oops signatures and track kernel logs for evidence of attempted exploitation or instability.
• Temporary mitigations: avoid running untrusted guests on vulnerable hosts, and if possible migrate those guests to patched infrastructure. Avoid ad-hoc changes to CPU/KVM flags unless validated.

---

Critical analysis​

This CVE is another reminder that virtualization code must be extremely conservative when it comes to assumptions about CPU-provided state and the guest code stream. Performance-oriented fastpaths (the small, specialized handlers used in KVM for common VM-exits) are valuable, but they create brittle boundaries: if a fastpath assumes it will never need to perform a sleepable operation (like fetching guest memory that might fault), a subtle configuration or timing difference can turn that optimization into a correctness hazard.
The upstream fix takes the correct conservative stance: preserve correct semantics by re-injecting exceptions when appropriate and force the slow/emulation path whenever the CPU’s metadata doesn’t give KVM the deterministic, safe answer it needs. This is a risk-averse, maintainable approach that favors correctness and host stability over micro-optimizations that cannot be proven safe under all configurations.
Operationally, the trade-offs are manageable: the patch is small and backportable, and distributions can deliver fixes with typical kernel-stable workflows. The larger operational burden falls on site operators to promptly apply vendor kernels and to add guardrails against running untrusted guests on unpatched hosts. Cloud tenants and multi-tenant providers should treat this as high-priority for remediation. Multiple independent trackers and upstream mailing-list archives confirm the diagnosis and the mitigation strategy; cross-referencing vendor advisories is required to determine whether a specific host is fixed.

---

Conclusion​

CVE-2025-68259 is a correctness/race vulnerability in the Linux KVM SVM backend that can cause guest panics and host instability when KVM re-injects soft-interrupts without verifying that the instruction decoded matches the instruction actually executed by the vCPU. The vulnerability is not remotely exploitable without guest access, but it is a practical denial-of-service vector in multi-tenant virtualization environments.
Remediation is straightforward in principle: apply upstream or vendor-provided kernels that contain the SVM re-injection fixes and monitor hypervisor logs for related kernel oops signatures. Operators should prioritize hypervisors that host untrusted workloads and validate vendor package changelogs or attestations before assuming a fix is present. The upstream patch is narrow and corrects the semantic root cause, but operators must balance the possible local performance impacts where slowpath decoding replaces a previously used fastpath. Cross-check vendor advisories and apply backports as soon as they are available to remove the availability risk.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center