Skip to main content

Linux Kernel CVE-2025-40026

HIGH
2025-10-28 416baaa9-dc9f-4396-8d5f-8c081fb06d67
High
Disputed · 7.9 Vendor: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
Share

Severity by source

Sources disagree (Low–High)
Vendor (416baaa9-dc9f-4396-8d5f-8c081fb06d67) PRIMARY
7.9 HIGH
AV:L/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:H
vuln.today AI
7.3 HIGH

Local KVM access is required (AV:L, PR:L); guest/VMM context crashing the host is a scope change (S:C); demonstrated impact is host WARN/instability (A:H) with negligible confidentiality (C:N).

3.1 AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:L/A:H
4.0 AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:H/SC:N/SI:N/SA:N
SUSE
3.6 LOW
AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:L
Red Hat
5.5 MEDIUM
qualitative

vuln.today treats the vendor’s rating as authoritative. A higher third-party CVSS (e.g. CISA-ADP) is shown for transparency but does not drive the headline severity.

CVSS VectorVendor: 416baaa9-dc9f-4396-8d5f-8c081fb06d67

Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Changed
Confidentiality
Low
Integrity
Low
Availability
High

Lifecycle Timeline

2
Analysis Generated
Jul 30, 2026 - 07:58 vuln.today
CVE Published
Oct 28, 2025 - 10:15 cve.org
HIGH 7.9

DescriptionCVE.org

In the Linux kernel, the following vulnerability has been resolved:

KVM: x86: Don't (re)check L1 intercepts when completing userspace I/O

When completing emulation of instruction that generated a userspace exit for I/O, don't recheck L1 intercepts as KVM has already finished that phase of instruction execution, i.e. has already committed to allowing L2 to perform I/O. If L1 (or host userspace) modifies the I/O permission bitmaps during the exit to userspace, KVM will treat the access as being intercepted despite already having emulated the I/O access.

Pivot on EMULTYPE_NO_DECODE to detect that KVM is completing emulation. Of the three users of EMULTYPE_NO_DECODE, only complete_emulated_io() (the intended "recipient") can reach the code in question. gp_interception()'s use is mutually exclusive with is_guest_mode(), and complete_emulated_insn_gp() unconditionally pairs EMULTYPE_NO_DECODE with EMULTYPE_SKIP.

The bad behavior was detected by a syzkaller program that toggles port I/O interception during the userspace I/O exit, ultimately resulting in a WARN on vcpu->arch.pio.count being non-zero due to KVM no completing emulation of the I/O instruction.

WARNING: CPU: 23 PID: 1083 at arch/x86/kvm/x86.c:8039 emulator_pio_in_out+0x154/0x170 [kvm] Modules linked in: kvm_intel kvm irqbypass CPU: 23 UID: 1000 PID: 1083 Comm: repro Not tainted 6.16.0-rc5-c1610d2d66b1-next-vm #74 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:emulator_pio_in_out+0x154/0x170 [kvm] PKRU: 55555554 Call Trace: <TASK> kvm_fast_pio+0xd6/0x1d0 [kvm] vmx_handle_exit+0x149/0x610 [kvm_intel] kvm_arch_vcpu_ioctl_run+0xda8/0x1ac0 [kvm] kvm_vcpu_ioctl+0x244/0x8c0 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0x5d/0xc60 entry_SYSCALL_64_after_hwframe+0x4b/0x53 </TASK>

AnalysisAI

Improper instruction emulation in the Linux kernel's KVM x86 subsystem allows a local user with access to KVM (typically /dev/kvm) to crash or destabilize the host hypervisor by racing port I/O interception changes against a userspace I/O exit. Because KVM re-checks L1 intercepts after it has already committed to emulating an L2 I/O access, a malicious or buggy VMM/guest can leave vcpu->arch.pio.count non-zero and trigger a kernel WARN in emulator_pio_in_out(); the flaw was discovered via a syzkaller reproducer. There is no public exploit identified at time of analysis and EPSS exploitation probability is low (0.25%).

Technical ContextAI

The affected component is KVM (Kernel-based Virtual Machine) x86 nested-virtualization emulation in arch/x86/kvm/x86.c. When a guest instruction performs port I/O that must be handled in userspace, KVM exits to the VMM and later resumes via complete_emulated_io() to finish the instruction. The bug is a re-validation ordering error: on completion KVM should NOT re-consult the L1 I/O permission bitmaps (intercepts) because the I/O phase is already committed, yet it did, so if L1 or host userspace toggles the I/O bitmap during the exit the access is wrongly treated as intercepted. The fix pivots on EMULTYPE_NO_DECODE to detect the completion path (only complete_emulated_io() reaches the problematic code; gp_interception() is mutually exclusive with is_guest_mode() and complete_emulated_insn_gp() pairs it with EMULTYPE_SKIP). No CWE was assigned, but the root cause is a state-management/race class defect (TOCTOU-style re-check on already-committed emulation state), not the 'Authentication Bypass' implied by the input tag.

Affected ProductsAI

The Linux kernel x86 KVM subsystem is affected; the syzkaller report reproduced on 6.16.0-rc5 (next tree). No NVD CPE strings were provided in the input, so exact affected version ranges cannot be enumerated precisely, but the nine git.kernel.org/stable commit references indicate the fix was backported across multiple stable branches. Systems running KVM with x86 (Intel VMX / kvm_intel or AMD) that expose /dev/kvm to non-root or semi-trusted users, and nested-virtualization hosts, are the relevant deployment surface. Authoritative fix commits: https://git.kernel.org/stable/c/3d3abf3f7e8b1abb082070a343de82d7efc80523 and the eight sibling stable backports listed in the references.

RemediationAI

Upstream fix available (multiple stable-tree commits); a specific tagged release version was not provided in the input, so upgrade to the stable kernel release that incorporates commit 3d3abf3f7e8b1abb082070a343de82d7efc80523 (or the matching backport for your series among the nine referenced commits at git.kernel.org/stable) via your distribution's kernel update once published. As a compensating control where patching is delayed, restrict access to /dev/kvm to trusted users/services only (e.g., tighten the kvm group membership and libvirt permissions) so untrusted local users cannot drive vcpu ioctls, and avoid exposing nested virtualization to untrusted guests; the trade-off is that legitimate unprivileged virtualization workloads (some container/VM tooling) will lose direct KVM access. Because the demonstrated impact is a kernel WARN rather than privilege escalation, panic_on_warn should NOT be enabled as a mitigation here, as that would convert the WARN into a host panic and amplify the DoS.

Vendor StatusVendor

SUSE

Severity: Low
Product Status
SUSE Liberty Linux 8 Fixed
SUSE Liberty Linux 9 Fixed
openSUSE Tumbleweed Fixed
SUSE Linux Enterprise Desktop 15 SP7 Affected
SUSE Linux Enterprise Desktop 15 SP7 Affected

Share

CVE-2025-40026 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy