CVE-2026-72284 in Linux
Summary
by MITRE • 08/15/2026
In the Linux kernel, the following vulnerability has been resolved:
KVM: x86: Ignore pending PV EOI if the vCPU has since disabled PV EOIs
Ignore KVM's internal "service pending PV EOI" request if the vCPU has disabled PV EOIs since the request was made. Asserting that PV EOIs are enabled can fail if reading guest memory in pv_eoi_get_user() fails, i.e. if pv_eoi_test_and_clr_pending() bails early, *and* the vCPU also disables PV EOIs.
kernel BUG at arch/x86/kvm/lapic.c:3338! Oops: invalid opcode: 0000 [#1] SMP
CPU: 4 UID: 1000 PID: 890 Comm: pv_eoi_test Not tainted 7.0.0-d585aa5894d8-vm #337 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:kvm_lapic_sync_from_vapic+0x12b/0x140 [kvm]
Call Trace: <TASK> kvm_arch_vcpu_ioctl_run+0x1075/0x1c30 [kvm]
kvm_vcpu_ioctl+0x2d5/0x980 [kvm]
__x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0xb5/0xb40 entry_SYSCALL_64_after_hwframe+0x4b/0x53 </TASK> Modules linked in: kvm_intel kvm irqbypass ---[ end trace 0000000000000000 ]---
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/15/2026
This vulnerability exists within the Linux kernel's KVM hypervisor implementation on x86 architectures, specifically affecting the Local APIC (Advanced Programmable Interrupt Controller) handling during virtual machine operations. The issue stems from a race condition or improper state management between the hypervisor's internal PV EOI (Posted Interrupts End of Interrupt) mechanisms and guest virtual CPU state transitions. When a vCPU disables PV EOIs while a pending service request is still in progress, the kernel fails to properly handle this inconsistency, leading to a critical system crash.
The technical flaw manifests in the lapic.c file at line 3338 where a kernel BUG occurs due to an invalid opcode exception. This happens when the kvm_lapic_sync_from_vapic function attempts to process a pending PV EOI request without first verifying that PV EOIs remain enabled for the vCPU. The vulnerability is particularly triggered during memory access operations in pv_eoi_get_user() where guest memory reading fails, combined with the vCPU simultaneously disabling PV EOIs through pv_eoi_test_and_clr_pending(). This dual condition creates an inconsistent state where the kernel assumes PV EOIs are still active while they have been disabled, resulting in invalid instruction execution.
The operational impact of this vulnerability is severe as it can cause complete system crashes or kernel panics in virtualized environments. When triggered, the system displays a kernel oops message with the invalid opcode error and dumps the call trace showing the execution path through KVM's architecture functions. The crash occurs during vcpu ioctl operations when processing guest requests, specifically in the kvm_arch_vcpu_ioctl_run function, making it particularly dangerous for production virtualization environments where stability is critical.
This vulnerability aligns with CWE-691 - Insufficient Control Flow Management and relates to ATT&CK technique T1484.001 - Valid Accounts - Privilege Escalation through hypervisor compromise. The issue represents a control flow management failure where the kernel does not properly validate state transitions before executing operations that depend on specific conditions being met. Mitigation strategies should include ensuring proper synchronization between PV EOI state changes and pending service requests, implementing defensive programming patterns to check preconditions before execution, and potentially adding additional validation layers in the KVM subsystem to prevent invalid opcode execution when PV EOI states are inconsistent.
The root cause demonstrates a failure in the kernel's internal consistency checking mechanisms, where the hypervisor assumes that once a service request is initiated, the underlying conditions remain stable throughout processing. This pattern of assuming state consistency without proper validation creates an attack surface where malicious or faulty guest operations can trigger kernel-level crashes. The vulnerability highlights the importance of defensive programming in kernel space where all assumptions about system state must be validated before execution, particularly in complex virtualization environments where multiple components interact through shared memory and interrupt handling mechanisms.