CVE-2025-21779 in Linux
Summary
by MITRE • 02/27/2025
In the Linux kernel, the following vulnerability has been resolved:
KVM: x86: Reject Hyper-V's SEND_IPI hypercalls if local APIC isn't in-kernel
Advertise support for Hyper-V's SEND_IPI and SEND_IPI_EX hypercalls if and only if the local API is emulated/virtualized by KVM, and explicitly reject said hypercalls if the local APIC is emulated in userspace, i.e. don't rely on userspace to opt-in to KVM_CAP_HYPERV_ENFORCE_CPUID.
Rejecting SEND_IPI and SEND_IPI_EX fixes a NULL-pointer dereference if Hyper-V enlightenments are exposed to the guest without an in-kernel local APIC:
dump_stack+0xbe/0xfd __kasan_report.cold+0x34/0x84 kasan_report+0x3a/0x50 __apic_accept_irq+0x3a/0x5c0 kvm_hv_send_ipi.isra.0+0x34e/0x820 kvm_hv_hypercall+0x8d9/0x9d0 kvm_emulate_hypercall+0x506/0x7e0 __vmx_handle_exit+0x283/0xb60 vmx_handle_exit+0x1d/0xd0 vcpu_enter_guest+0x16b0/0x24c0 vcpu_run+0xc0/0x550 kvm_arch_vcpu_ioctl_run+0x170/0x6d0 kvm_vcpu_ioctl+0x413/0xb20 __se_sys_ioctl+0x111/0x160 do_syscal1_64+0x30/0x40 entry_SYSCALL_64_after_hwframe+0x67/0xd1
Note, checking the sending vCPU is sufficient, as the per-VM irqchip_mode can't be modified after vCPUs are created, i.e. if one vCPU has an in-kernel local APIC, then all vCPUs have an in-kernel local APIC.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 05/25/2026
The vulnerability described in CVE-2025-21779 represents a critical security flaw within the Linux kernel's KVM hypervisor implementation, specifically affecting the x86 architecture virtualization components. This issue stems from improper handling of Hyper-V enlightenments when the local APIC is not emulated within the kernel itself. The vulnerability manifests as a NULL-pointer dereference that occurs when Hyper-V's SEND_IPI and SEND_IPI_EX hypercalls are processed without proper kernel-level local APIC virtualization, creating a potential attack vector for privilege escalation and system instability.
The technical root cause of this vulnerability lies in the KVM hypervisor's failure to properly validate the virtualization environment before accepting Hyper-V-specific hypercalls. When the local APIC is emulated in userspace rather than being handled within the kernel, the system should explicitly reject these hypercalls to prevent dangerous operations. However, the previous implementation relied on userspace to opt-in to KVM_CAP_HYPERV_ENFORCE_CPUID, which created a gap in validation. The vulnerability occurs because the kernel does not properly check whether the local APIC is in-kernel before processing the SEND_IPI hypercalls, leading to a NULL-pointer dereference in the __apic_accept_irq function. This failure results in a kernel oops and potential system crash, as evidenced by the stack trace showing execution path through kvm_hv_send_ipi, kvm_hv_hypercall, and ultimately to the kernel's virtualization handling mechanisms.
This vulnerability directly impacts the security and stability of virtualized environments running Linux KVM hypervisors, particularly those that utilize Hyper-V enlightenments for performance optimization. The operational impact extends beyond simple system crashes to potential privilege escalation opportunities, as attackers could exploit this NULL-pointer dereference to gain elevated privileges within the virtual machine environment. The flaw is particularly concerning in cloud computing and containerized environments where KVM is extensively used, as it could allow malicious guests to compromise the host system or other virtual machines sharing the same physical hardware. According to CWE classification, this represents a CWE-476: NULL Pointer Dereference, while the ATT&CK framework would categorize this under T1059.001: Command and Scripting Interpreter - PowerShell and potentially T1068: Exploitation for Privilege Escalation, as it enables unauthorized access to privileged system resources.
The mitigation strategy involves implementing strict validation checks within the KVM hypervisor to ensure that Hyper-V SEND_IPI and SEND_IPI_EX hypercalls are only accepted when the local APIC is properly emulated within the kernel. This requires modifying the hypercall processing logic to verify the virtualization state before accepting these operations, explicitly rejecting requests when userspace-based APIC emulation is detected. The fix also involves ensuring that the per-VM irqchip_mode cannot be modified after vCPU creation, as this would create inconsistencies in the virtualization environment. System administrators should update their Linux kernel versions to include this patch and verify that their virtualization environments properly configure APIC emulation settings to prevent exploitation of this vulnerability. Additionally, monitoring systems should be implemented to detect unusual hypercall patterns that might indicate attempted exploitation of this vulnerability, particularly in environments where Hyper-V enlightenments are enabled without proper kernel-level APIC virtualization.