KVM
Monthly
Privileged users inside a QEMU guest running on the Q35 machine type with the KVM accelerator can abuse the VAPIC setup hypercall (hw/i386/vapic.c) to break SMM isolation, because the code fails to verify that a writable RAM alias stays inside the option ROM window. By repositioning that alias over chipset-locked SMRAM, an attacker with root-equivalent guest access defeats D_LCK protection and injects code into System Management Mode memory, which QEMU scores as a scope-changing, total-impact compromise (CVSS 8.2). Exploitation is local to the guest with high privileges required (AV:L, PR:H, S:C), publicly available exploit code exists according to the CISA SSVC assessment, but there is no confirmed active exploitation and EPSS is low at 0.20% (10th percentile).
A use-after-free (CWE-416) in the Linux kernel's s390/vfio-ap AP crypto passthrough driver allows a local attacker with host-side privilege to corrupt kernel state by attaching a second vfio-ap mediated device to a KVM instance that already owns one. On the resulting -EPERM error path, vfio_ap_mdev_set_kvm() fails to restore kvm->arch.crypto.pqap_hook, leaving it pointing at an mdev that is never tracked by matrix_mdev->kvm; when that mdev is later freed, a guest-executed PQAP instruction dereferences the stale hook through pqap_hook_rwsem and triggers the use-after-free. Exploitation requires an IBM Z/s390 host running KVM with vfio-ap enabled but is not remotely reachable, needs authenticated local privilege to configure mediated devices, and depends on error-path plus free-then-execute sequencing; no public exploit code or confirmed active exploitation was identified at time of analysis, and vendor patches are available in the stable trees.
The s390 vfio-ap mediated device (mdev) driver in the Linux kernel fails to actually revoke crypto control-domain access when a privileged host administrator unplugs a control domain from a matrix mdev: vfio_ap_mdev_cfg_remove clears the wrong bit set with bitmap_andnot instead of intersecting with bitmap_and on the mdev's adm bitmap. The practical result is that a KVM guest on IBM Z hardware configured for AP (Adjunct Processor) passthrough retains access to control domains the host intended to remove, a residual-access/state-desynchronization condition rather than remote code execution, reached only when a host admin performs an explicit control-domain removal (CVSS 3.1 AV:L/AC:L/PR:H/UI:N/S:C/C:L/I:L/A:N). No public exploit code has been identified at time of analysis and the issue is not listed in CISA KEV; the vendor-supplied 8.8 score (AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H) materially overstates real-world risk given that exploitation is confined to the rare s390 crypto-passthrough deployment mode and requires a trusted privileged reconfiguration action.
Stale hardware access to unplugged crypto resources in Linux KVM guests on IBM Z (s390) stems from a logic error in the vfio-ap mediated-device driver: when the last AP adapter, domain, or control domain is removed from the host's AP configuration, the shadow APCB is cleared but the bitmap_andnot() return value is false for an empty result, so the do_hotplug flag never gets set and the guest's APCB is never refreshed. Only s390 hosts with CEX crypto adapters configured for guest passthrough are affected, exploitation is local and requires privileged host management access to modify the AP configuration, and no public exploit code has been identified at time of analysis. The practical consequence is a crypto-resource isolation failure in which the guest passively retains access to AP devices the administrator believes were unplugged, not memory corruption or code execution.
Stale TLB entries can be reused by an L2 guest in the Linux kernel's KVM nested virtualization (nVMX) implementation on x86 Intel VMX hosts, because vpid02 is not flushed on its first use after a VPID is recycled following an L1 guest's VMXOFF/VMXON cycle. Exploitation requires an attacker who already controls an L1 guest on a host running KVM with nested virtualization enabled (kvm_intel nested=1) where L1 uses VPID for its L2 guests, and success depends on KVM reusing a vpid02 value that still has TLB entries resident on the physical CPU, making the outcome timing- and reuse-dependent rather than deterministic. No public exploit has been identified at time of analysis, and our independent assessment rates the realistic impact well below the vendor's CVSS 8.8 - limited confidentiality and integrity loss with high availability impact under local, high-complexity preconditions (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:L/I:L/A:H).
Incorrect handling of queued local TLB flushes in the Linux kernel's KVM nested-VMX (nVMX) implementation can leave stale guest translations active after a failed nested VM-Enter, causing KVM to miss a required TLB flush when L1 changes L2's VPID. Only hosts running Intel VMX with KVM nested virtualization explicitly enabled (nested=1) are affected; an attacker who already controls an L1 hypervisor guest vCPU with the ability to manipulate nested VMCS state could reassign L2's VPID, force a nested VM-Enter to fail, and then perform a successful VM-Enter so the missed flush leaves stale address translations in place. The independent assessment rates this CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:N/I:L/A:H - local hypervisor context, non-default configuration, no confidentiality impact, limited integrity and availability impact - and notes it is not exploitable against default (non-nested) KVM deployments; no public exploit code or confirmed active exploitation has been identified at time of analysis.
Linux kernel's KVM nested-VMX (nVMX) emulation can leave stale L2 guest TLB entries on a physical CPU, because KVM executes the L1 guest's INVVPID on whichever pCPU is currently active rather than on the pCPU where L2 last ran. When L1 migrates to another CPU, issues INVVPID, and then migrates back to the original CPU to resume L2, the stale VPID mappings on that original pCPU are never invalidated and vmx_vcpu_load_vmcs() does not request a KVM_REQ_TLB_FLUSH because vmcs02 never ran on a different pCPU. Affected are x86 hosts with non-default nested virtualization enabled and a malicious or buggy L1 guest controlling an L2 guest; exploitation requires local access to an L1 vCPU (PR:L) and a narrow cross-CPU scheduling/migration race, no public exploit code has been identified at time of analysis, and CISA KEV does not list this issue. The judged impact is primarily TLB corruption and nested-guest instability rather than a reliable code-execution or data-exfiltration primitive, consistent with an assessed vector of AV:L/AC:H/PR:L/S:C/C:L/I:L/A:H.
Slab use-after-free in the Linux kernel's KVM x86 MMU lockless rmap aging path affects hosts running Linux 6.15 through 6.18.50 and 7.x before 7.2.5 that are built with CONFIG_KVM_MMU_LOCKLESS_AGING=y. A local user able to run or drive a KVM guest (PR:L, no user interaction) can race the lock-elision window so that a writer populates a KVM_RMAP_MANY rmap and later frees its pte_list_desc chain while the lockless aging walk is still traversing it, yielding memory corruption of kernel slab memory; the race is timing-dependent (AC:H) and is driven by host memory reclaim rather than attacker-controlled scheduling, so exploitation is opportunistic rather than deterministic. No proof-of-concept or public exploit code has been identified at time of analysis and there is no evidence of active exploitation. Vendor scoring is 8.8 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H), while independent assessment rates it 6.3 with AC:H and no confidentiality impact, reflecting the narrow, reclaim-triggered race window; it is a local privilege/DoS-class memory-safety bug, not a remote code execution issue despite the 'RCE' tag on the record.
An integer overflow in KVM's x86 Hyper-V synthetic timer emulation (stimer_start(), which computes a 100ns-tick deadline using ktime_add_ns(ktime_now, 100 * (stimer->exp_time - time_now))) allows a guest or userspace VMM to program a STIMERi deadline that wraps into the past, causing the vCPU to spin through an immediate hrtimer re-arm / KVM_REQ_HV_STIMER request cycle without ever disabling the timer. The result is a host CPU livelock that starves RCU grace-period kthreads and produces the RCU stall and eventual OOM condition reported by syzkaller. Exploitation requires a KVM x86 host running a guest with Hyper-V enlightenments and SynIC synthetic timers exposed, and control over the guest's WRMSR (HV_X64_MSR_STIMERi_CONFIG/COUNT) or KVM_SET_MSRS writes; the assessed vector is local, PR:L, availability-only (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H, 7.1), with no public exploit identified at time of analysis and no CISA KEV listing.
A use-after-free race condition in the Linux kernel's s390 KVM guest-debug watchpoint code lets a local user who can control an IBM Z guest VM read or corrupt freed kernel memory. When a hardware watchpoint is imported via the KVM_SET_GUEST_DEBUG path, __import_wp_info() backs up guest memory with read_guest_abs() without holding kvm->srcu, so a concurrent memslot update can free the memslots array mid-read. Exploitation is s390-specific, requires local privileges over the VM/VMM (authenticated, PR:L per the assessed vector) and a narrow timing window, so reliability is limited; no public exploit code and no confirmed active exploitation were identified at time of analysis, and patch data indicates the vendor has released fixes.
Address-rollover bug in the Linux kernel's KVM/arm64 TLB-by-VA invalidation path causes the hypervisor to silently skip an invalidation when the range ends at the last page or block of the TTBR1 VA space, because the exclusive end computation (base + size) wraps to zero. The faulty logic was introduced in Linux 6.16 and is fixed in 6.18.51, 7.2.5 and 7.3-rc1; hosts running unpatched kernels are exposed where a guest vCPU can drive trapped TLB-by-VA invalidations, while the IPA-invalidation path never suffered the rollover. The assessed vector is local (AV:L) with low privileges (PR:L) and high attack complexity (AC:H) because of the narrow address-layout precondition, with scope change and high availability impact; no public exploit code and no confirmed active exploitation (no CISA KEV entry) have been identified, and the provided reference CVSS of 9.3 overstates the practical risk relative to that assessment.
Race conditions in the arm64 KVM path that invalidates VNCR translations can leave a stale stage-1 TLB entry installed for a page-table mapping that another vCPU has just invalidated, so a guest can keep using a translation the host believes is gone, corrupting host state and potentially crashing the host. The flaw only affects arm64 hosts running KVM with nested virtualization (FEAT_NV2 / VNCR fixmap) enabled where an attacker already controls a guest with at least two concurrently executing vCPUs, and exploitation hinges on winning a narrow race window between invalidate_vncr_va() on one vCPU and a VNCR translation fault-in on another (one vCPU rewriting S1 page tables and issuing TLBI S1E2 while the other is mid-walk). Because the path is local-only and nested virtualization on arm64 is rarely deployed, the independent assessment rates the issue well below the vendor's CVSS 9.3 (assessed AV:L/AC:H/PR:L/UI:N/S:C/C:N/I:L/A:H - high availability impact, low integrity impact, no confidentiality impact); no public exploit identified at time of analysis, and vendor patches are available in Linux 7.2.5, 6.18.51 and 7.3-rc1.
Missed TLB invalidations in the arm64 KVM nested-virtualization path of the Linux kernel can leave stale translations for an L1-supplied VNCR page in L0, allowing a guest with control of an L1 vCPU on an arm64 host to cross the guest-to-host boundary in a timing-sensitive way. Affected systems are those running kernel 6.16 or later with arm64 nested virtualization (FEAT_NV2 / VNCR page support) enabled and exposed to a guest; the flaw is a guest-to-host (L1-to-L0) issue, so exploitation requires guest-vCPU privileges and is local to the host, which contradicts the vendor's PR:N vector. Vendor-released patches exist in Linux 6.18.52, 7.2.5, and 7.3-rc1, and no public exploit code has been identified at time of analysis; the vendor's CVSS of 9.3 substantially overstates real-world risk given that nested virtualization is off by default and deployed on only a small subset of arm64 KVM hosts, and the missed-invalidation window is opportunistic and mapping-state dependent rather than deterministic.
Range-based TLB invalidation in the arm64 KVM hypervisor of the Linux kernel is computed against the wrong address range because the decode_range_tlbi() helper omitted the required virtual-address sign-extension when it was reused for stage-1 TLBI handling, and the same helper can overflow physical-address bits when invoked for stage-2 invalidation. Only arm64 hosts running KVM are affected, and the attacker must already control a guest VM/vCPU able to issue range-based TLBI operations (low-privilege guest context, no user interaction, no network reachability); kernels from the 6.16 introduction through the fixes in 6.18.51, 7.2.5 and 7.3-rc1 are in scope. Exploitation results in stale or incorrectly scoped TLB entries on the host, with the assessed impact being availability loss (A:H) plus limited integrity impact (I:L) and no confidentiality impact; no public exploit identified at time of analysis.
A use-after-free race in the arm64 KVM vGICv3 code path of the Linux kernel (vgic_v3_save_pending_tables) allows a locally authenticated guest with vCPU-level access to trigger a dangling-pointer dereference against host kernel memory. The flaw requires an arm64 KVM host configured with GICv3 LPI/ITS support, where a concurrent irqfd cached-injection plus a guest ITS DISCARD can free an LPI that the pending-table save loop still holds via a stale xarray iterator pointer; the practical outcome is a host-side crash/denial of service with limited integrity impact rather than a clean, reliable privilege escalation, and exploitation depends on a tight timing window (assessed AV:L/AC:H/PR:L, S:C, C:N/I:L/A:H). Vendor patches are available in Linux 6.18.51, 7.2.5, and 7.3-rc1; no public exploit code and no confirmed active exploitation have been identified at time of analysis.
Linux kernel KVM/arm64 hosts that emulate a vGIC ITS can be crashed with a host kernel NULL-pointer dereference when a guest issues the crafted ITS command sequence MAPD, MAPTI, then MAPC with V=0 and the VMM subsequently performs an ITS table save (KVM_DEV_ARM_ITS_SAVE_TABLES, as used for live migration or snapshotting). Exploitation requires arm64 KVM virtualization with the in-kernel GICv3 ITS, an attacker able to run a guest at guest/tenant privilege (authenticated, PR:L in the assessed vector), and - critically - a host-initiated migration or save operation, since the fault is latent in guest state until the VMM touches the tables. The result is a host-wide denial of service affecting all guests on the machine; no public exploit code has been identified at time of analysis, and the review confirms this is a bounded availability issue rather than a broadly exploitable priority bug.
Host denial of service (with potential low integrity impact) in the Linux kernel's KVM/arm64 hypervisor allows a local attacker with guest execution privileges to trigger a TLB invalidation range overflow, corrupting hypervisor state. The flaw affects kernels approximately from 6.16 until the fixes in 6.18.51, 7.2.5, and 7.3-rc1, and requires the guest to issue TLB Invalidation by Range operations with an attacker-chosen virtual address. No public exploit code is identified at time of analysis.
Uninitialized stack memory in the Linux kernel's LoongArch KVM DMSINTC interrupt-injection path can let a local user who is able to create or control a KVM virtual machine - or code running inside a guest - have non-deterministic stack contents consumed while injecting a dynamic message-signaled interrupt. The vendor rates this 7.3 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N), while our independent assessment keeps the local, low-privilege, scope-changing profile but lowers the impact components to C:L/I:L/A:L because the leaked data is not reliably attacker-controlled; the affected surface is limited to LoongArch hosts with KVM enabled and DMSINTC in use. Vendor fixes are available as upstream stable commits, and no public exploit code or confirmed active exploitation has been identified at time of analysis.
On LoongArch hosts running KVM, a memory-slot update that changes only flags (KVM_MR_FLAGS_ONLY, most notably toggling KVM_MEM_LOG_DIRTY_PAGES for live migration) zeroes the slot's architecture-specific flags, so a slot previously marked KVM_MEM_HUGEPAGE_INCAPABLE because of a GPA/HVA offset mismatch can subsequently be mapped with PMD-sized entries; because the mapping path aligns the guest frame number and host page frame number independently, the guest can read or write the wrong host pages, giving a local attacker with access to the KVM VM file descriptor both confidentiality and integrity impact on the host (CVSS 8.8 vendor score, AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H). The independent assessment rates the attack complexity higher (AC:H) because exploitation requires a misaligned memslot plus a flags-only update, typically during live migration, and does not manifest for a static guest with aligned memslots; only the LoongArch architecture is affected. No public exploit code was identified at time of analysis and the issue is not listed in CISA KEV, though the tags classify the outcome as information disclosure and the successful corruption path is a memory-safety violation with high integrity impact.
Out-of-bounds kernel memory corruption in the Linux kernel's LoongArch KVM EIOINTC interrupt-routing code allows a local attacker who holds a VM file descriptor to read and write memory beyond the loongarch_eiointc allocation. The MSI data field supplied by userspace through KVM_SET_GSI_ROUTING (irqfd/KVM_IRQ_LINE) or KVM_SIGNAL_MSI is passed unchecked into eiointc_set_irq() and used as an IRQ index against 256-bit bitmaps and the sw_coremap[]/coreisr/sw_coreisr arrays, so any value of 256 or greater triggers deterministic, fully attacker-controlled out-of-bounds accesses with scope change from the guest process into kernel memory (CVSS 3.1 8.8, AV:L/PR:L/S:C). Exploitation is confined to LoongArch hosts running KVM and requires local access to the KVM interfaces; the DMSINTC path is unaffected because it decodes and masks the vector from the address. No public exploit code has been identified and the flaw is not confirmed actively exploited (not in CISA KEV), and vendor patches are available in the stable kernel commits referenced by the advisory.
Arbitrary host file exfiltration from Cloud Hypervisor VMM versions 34.0-50.0. CVSS 10.0. Patch available.
Privileged users inside a QEMU guest running on the Q35 machine type with the KVM accelerator can abuse the VAPIC setup hypercall (hw/i386/vapic.c) to break SMM isolation, because the code fails to verify that a writable RAM alias stays inside the option ROM window. By repositioning that alias over chipset-locked SMRAM, an attacker with root-equivalent guest access defeats D_LCK protection and injects code into System Management Mode memory, which QEMU scores as a scope-changing, total-impact compromise (CVSS 8.2). Exploitation is local to the guest with high privileges required (AV:L, PR:H, S:C), publicly available exploit code exists according to the CISA SSVC assessment, but there is no confirmed active exploitation and EPSS is low at 0.20% (10th percentile).
A use-after-free (CWE-416) in the Linux kernel's s390/vfio-ap AP crypto passthrough driver allows a local attacker with host-side privilege to corrupt kernel state by attaching a second vfio-ap mediated device to a KVM instance that already owns one. On the resulting -EPERM error path, vfio_ap_mdev_set_kvm() fails to restore kvm->arch.crypto.pqap_hook, leaving it pointing at an mdev that is never tracked by matrix_mdev->kvm; when that mdev is later freed, a guest-executed PQAP instruction dereferences the stale hook through pqap_hook_rwsem and triggers the use-after-free. Exploitation requires an IBM Z/s390 host running KVM with vfio-ap enabled but is not remotely reachable, needs authenticated local privilege to configure mediated devices, and depends on error-path plus free-then-execute sequencing; no public exploit code or confirmed active exploitation was identified at time of analysis, and vendor patches are available in the stable trees.
The s390 vfio-ap mediated device (mdev) driver in the Linux kernel fails to actually revoke crypto control-domain access when a privileged host administrator unplugs a control domain from a matrix mdev: vfio_ap_mdev_cfg_remove clears the wrong bit set with bitmap_andnot instead of intersecting with bitmap_and on the mdev's adm bitmap. The practical result is that a KVM guest on IBM Z hardware configured for AP (Adjunct Processor) passthrough retains access to control domains the host intended to remove, a residual-access/state-desynchronization condition rather than remote code execution, reached only when a host admin performs an explicit control-domain removal (CVSS 3.1 AV:L/AC:L/PR:H/UI:N/S:C/C:L/I:L/A:N). No public exploit code has been identified at time of analysis and the issue is not listed in CISA KEV; the vendor-supplied 8.8 score (AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H) materially overstates real-world risk given that exploitation is confined to the rare s390 crypto-passthrough deployment mode and requires a trusted privileged reconfiguration action.
Stale hardware access to unplugged crypto resources in Linux KVM guests on IBM Z (s390) stems from a logic error in the vfio-ap mediated-device driver: when the last AP adapter, domain, or control domain is removed from the host's AP configuration, the shadow APCB is cleared but the bitmap_andnot() return value is false for an empty result, so the do_hotplug flag never gets set and the guest's APCB is never refreshed. Only s390 hosts with CEX crypto adapters configured for guest passthrough are affected, exploitation is local and requires privileged host management access to modify the AP configuration, and no public exploit code has been identified at time of analysis. The practical consequence is a crypto-resource isolation failure in which the guest passively retains access to AP devices the administrator believes were unplugged, not memory corruption or code execution.
Stale TLB entries can be reused by an L2 guest in the Linux kernel's KVM nested virtualization (nVMX) implementation on x86 Intel VMX hosts, because vpid02 is not flushed on its first use after a VPID is recycled following an L1 guest's VMXOFF/VMXON cycle. Exploitation requires an attacker who already controls an L1 guest on a host running KVM with nested virtualization enabled (kvm_intel nested=1) where L1 uses VPID for its L2 guests, and success depends on KVM reusing a vpid02 value that still has TLB entries resident on the physical CPU, making the outcome timing- and reuse-dependent rather than deterministic. No public exploit has been identified at time of analysis, and our independent assessment rates the realistic impact well below the vendor's CVSS 8.8 - limited confidentiality and integrity loss with high availability impact under local, high-complexity preconditions (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:L/I:L/A:H).
Incorrect handling of queued local TLB flushes in the Linux kernel's KVM nested-VMX (nVMX) implementation can leave stale guest translations active after a failed nested VM-Enter, causing KVM to miss a required TLB flush when L1 changes L2's VPID. Only hosts running Intel VMX with KVM nested virtualization explicitly enabled (nested=1) are affected; an attacker who already controls an L1 hypervisor guest vCPU with the ability to manipulate nested VMCS state could reassign L2's VPID, force a nested VM-Enter to fail, and then perform a successful VM-Enter so the missed flush leaves stale address translations in place. The independent assessment rates this CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:N/I:L/A:H - local hypervisor context, non-default configuration, no confidentiality impact, limited integrity and availability impact - and notes it is not exploitable against default (non-nested) KVM deployments; no public exploit code or confirmed active exploitation has been identified at time of analysis.
Linux kernel's KVM nested-VMX (nVMX) emulation can leave stale L2 guest TLB entries on a physical CPU, because KVM executes the L1 guest's INVVPID on whichever pCPU is currently active rather than on the pCPU where L2 last ran. When L1 migrates to another CPU, issues INVVPID, and then migrates back to the original CPU to resume L2, the stale VPID mappings on that original pCPU are never invalidated and vmx_vcpu_load_vmcs() does not request a KVM_REQ_TLB_FLUSH because vmcs02 never ran on a different pCPU. Affected are x86 hosts with non-default nested virtualization enabled and a malicious or buggy L1 guest controlling an L2 guest; exploitation requires local access to an L1 vCPU (PR:L) and a narrow cross-CPU scheduling/migration race, no public exploit code has been identified at time of analysis, and CISA KEV does not list this issue. The judged impact is primarily TLB corruption and nested-guest instability rather than a reliable code-execution or data-exfiltration primitive, consistent with an assessed vector of AV:L/AC:H/PR:L/S:C/C:L/I:L/A:H.
Slab use-after-free in the Linux kernel's KVM x86 MMU lockless rmap aging path affects hosts running Linux 6.15 through 6.18.50 and 7.x before 7.2.5 that are built with CONFIG_KVM_MMU_LOCKLESS_AGING=y. A local user able to run or drive a KVM guest (PR:L, no user interaction) can race the lock-elision window so that a writer populates a KVM_RMAP_MANY rmap and later frees its pte_list_desc chain while the lockless aging walk is still traversing it, yielding memory corruption of kernel slab memory; the race is timing-dependent (AC:H) and is driven by host memory reclaim rather than attacker-controlled scheduling, so exploitation is opportunistic rather than deterministic. No proof-of-concept or public exploit code has been identified at time of analysis and there is no evidence of active exploitation. Vendor scoring is 8.8 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H), while independent assessment rates it 6.3 with AC:H and no confidentiality impact, reflecting the narrow, reclaim-triggered race window; it is a local privilege/DoS-class memory-safety bug, not a remote code execution issue despite the 'RCE' tag on the record.
An integer overflow in KVM's x86 Hyper-V synthetic timer emulation (stimer_start(), which computes a 100ns-tick deadline using ktime_add_ns(ktime_now, 100 * (stimer->exp_time - time_now))) allows a guest or userspace VMM to program a STIMERi deadline that wraps into the past, causing the vCPU to spin through an immediate hrtimer re-arm / KVM_REQ_HV_STIMER request cycle without ever disabling the timer. The result is a host CPU livelock that starves RCU grace-period kthreads and produces the RCU stall and eventual OOM condition reported by syzkaller. Exploitation requires a KVM x86 host running a guest with Hyper-V enlightenments and SynIC synthetic timers exposed, and control over the guest's WRMSR (HV_X64_MSR_STIMERi_CONFIG/COUNT) or KVM_SET_MSRS writes; the assessed vector is local, PR:L, availability-only (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H, 7.1), with no public exploit identified at time of analysis and no CISA KEV listing.
A use-after-free race condition in the Linux kernel's s390 KVM guest-debug watchpoint code lets a local user who can control an IBM Z guest VM read or corrupt freed kernel memory. When a hardware watchpoint is imported via the KVM_SET_GUEST_DEBUG path, __import_wp_info() backs up guest memory with read_guest_abs() without holding kvm->srcu, so a concurrent memslot update can free the memslots array mid-read. Exploitation is s390-specific, requires local privileges over the VM/VMM (authenticated, PR:L per the assessed vector) and a narrow timing window, so reliability is limited; no public exploit code and no confirmed active exploitation were identified at time of analysis, and patch data indicates the vendor has released fixes.
Address-rollover bug in the Linux kernel's KVM/arm64 TLB-by-VA invalidation path causes the hypervisor to silently skip an invalidation when the range ends at the last page or block of the TTBR1 VA space, because the exclusive end computation (base + size) wraps to zero. The faulty logic was introduced in Linux 6.16 and is fixed in 6.18.51, 7.2.5 and 7.3-rc1; hosts running unpatched kernels are exposed where a guest vCPU can drive trapped TLB-by-VA invalidations, while the IPA-invalidation path never suffered the rollover. The assessed vector is local (AV:L) with low privileges (PR:L) and high attack complexity (AC:H) because of the narrow address-layout precondition, with scope change and high availability impact; no public exploit code and no confirmed active exploitation (no CISA KEV entry) have been identified, and the provided reference CVSS of 9.3 overstates the practical risk relative to that assessment.
Race conditions in the arm64 KVM path that invalidates VNCR translations can leave a stale stage-1 TLB entry installed for a page-table mapping that another vCPU has just invalidated, so a guest can keep using a translation the host believes is gone, corrupting host state and potentially crashing the host. The flaw only affects arm64 hosts running KVM with nested virtualization (FEAT_NV2 / VNCR fixmap) enabled where an attacker already controls a guest with at least two concurrently executing vCPUs, and exploitation hinges on winning a narrow race window between invalidate_vncr_va() on one vCPU and a VNCR translation fault-in on another (one vCPU rewriting S1 page tables and issuing TLBI S1E2 while the other is mid-walk). Because the path is local-only and nested virtualization on arm64 is rarely deployed, the independent assessment rates the issue well below the vendor's CVSS 9.3 (assessed AV:L/AC:H/PR:L/UI:N/S:C/C:N/I:L/A:H - high availability impact, low integrity impact, no confidentiality impact); no public exploit identified at time of analysis, and vendor patches are available in Linux 7.2.5, 6.18.51 and 7.3-rc1.
Missed TLB invalidations in the arm64 KVM nested-virtualization path of the Linux kernel can leave stale translations for an L1-supplied VNCR page in L0, allowing a guest with control of an L1 vCPU on an arm64 host to cross the guest-to-host boundary in a timing-sensitive way. Affected systems are those running kernel 6.16 or later with arm64 nested virtualization (FEAT_NV2 / VNCR page support) enabled and exposed to a guest; the flaw is a guest-to-host (L1-to-L0) issue, so exploitation requires guest-vCPU privileges and is local to the host, which contradicts the vendor's PR:N vector. Vendor-released patches exist in Linux 6.18.52, 7.2.5, and 7.3-rc1, and no public exploit code has been identified at time of analysis; the vendor's CVSS of 9.3 substantially overstates real-world risk given that nested virtualization is off by default and deployed on only a small subset of arm64 KVM hosts, and the missed-invalidation window is opportunistic and mapping-state dependent rather than deterministic.
Range-based TLB invalidation in the arm64 KVM hypervisor of the Linux kernel is computed against the wrong address range because the decode_range_tlbi() helper omitted the required virtual-address sign-extension when it was reused for stage-1 TLBI handling, and the same helper can overflow physical-address bits when invoked for stage-2 invalidation. Only arm64 hosts running KVM are affected, and the attacker must already control a guest VM/vCPU able to issue range-based TLBI operations (low-privilege guest context, no user interaction, no network reachability); kernels from the 6.16 introduction through the fixes in 6.18.51, 7.2.5 and 7.3-rc1 are in scope. Exploitation results in stale or incorrectly scoped TLB entries on the host, with the assessed impact being availability loss (A:H) plus limited integrity impact (I:L) and no confidentiality impact; no public exploit identified at time of analysis.
A use-after-free race in the arm64 KVM vGICv3 code path of the Linux kernel (vgic_v3_save_pending_tables) allows a locally authenticated guest with vCPU-level access to trigger a dangling-pointer dereference against host kernel memory. The flaw requires an arm64 KVM host configured with GICv3 LPI/ITS support, where a concurrent irqfd cached-injection plus a guest ITS DISCARD can free an LPI that the pending-table save loop still holds via a stale xarray iterator pointer; the practical outcome is a host-side crash/denial of service with limited integrity impact rather than a clean, reliable privilege escalation, and exploitation depends on a tight timing window (assessed AV:L/AC:H/PR:L, S:C, C:N/I:L/A:H). Vendor patches are available in Linux 6.18.51, 7.2.5, and 7.3-rc1; no public exploit code and no confirmed active exploitation have been identified at time of analysis.
Linux kernel KVM/arm64 hosts that emulate a vGIC ITS can be crashed with a host kernel NULL-pointer dereference when a guest issues the crafted ITS command sequence MAPD, MAPTI, then MAPC with V=0 and the VMM subsequently performs an ITS table save (KVM_DEV_ARM_ITS_SAVE_TABLES, as used for live migration or snapshotting). Exploitation requires arm64 KVM virtualization with the in-kernel GICv3 ITS, an attacker able to run a guest at guest/tenant privilege (authenticated, PR:L in the assessed vector), and - critically - a host-initiated migration or save operation, since the fault is latent in guest state until the VMM touches the tables. The result is a host-wide denial of service affecting all guests on the machine; no public exploit code has been identified at time of analysis, and the review confirms this is a bounded availability issue rather than a broadly exploitable priority bug.
Host denial of service (with potential low integrity impact) in the Linux kernel's KVM/arm64 hypervisor allows a local attacker with guest execution privileges to trigger a TLB invalidation range overflow, corrupting hypervisor state. The flaw affects kernels approximately from 6.16 until the fixes in 6.18.51, 7.2.5, and 7.3-rc1, and requires the guest to issue TLB Invalidation by Range operations with an attacker-chosen virtual address. No public exploit code is identified at time of analysis.
Uninitialized stack memory in the Linux kernel's LoongArch KVM DMSINTC interrupt-injection path can let a local user who is able to create or control a KVM virtual machine - or code running inside a guest - have non-deterministic stack contents consumed while injecting a dynamic message-signaled interrupt. The vendor rates this 7.3 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N), while our independent assessment keeps the local, low-privilege, scope-changing profile but lowers the impact components to C:L/I:L/A:L because the leaked data is not reliably attacker-controlled; the affected surface is limited to LoongArch hosts with KVM enabled and DMSINTC in use. Vendor fixes are available as upstream stable commits, and no public exploit code or confirmed active exploitation has been identified at time of analysis.
On LoongArch hosts running KVM, a memory-slot update that changes only flags (KVM_MR_FLAGS_ONLY, most notably toggling KVM_MEM_LOG_DIRTY_PAGES for live migration) zeroes the slot's architecture-specific flags, so a slot previously marked KVM_MEM_HUGEPAGE_INCAPABLE because of a GPA/HVA offset mismatch can subsequently be mapped with PMD-sized entries; because the mapping path aligns the guest frame number and host page frame number independently, the guest can read or write the wrong host pages, giving a local attacker with access to the KVM VM file descriptor both confidentiality and integrity impact on the host (CVSS 8.8 vendor score, AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H). The independent assessment rates the attack complexity higher (AC:H) because exploitation requires a misaligned memslot plus a flags-only update, typically during live migration, and does not manifest for a static guest with aligned memslots; only the LoongArch architecture is affected. No public exploit code was identified at time of analysis and the issue is not listed in CISA KEV, though the tags classify the outcome as information disclosure and the successful corruption path is a memory-safety violation with high integrity impact.
Out-of-bounds kernel memory corruption in the Linux kernel's LoongArch KVM EIOINTC interrupt-routing code allows a local attacker who holds a VM file descriptor to read and write memory beyond the loongarch_eiointc allocation. The MSI data field supplied by userspace through KVM_SET_GSI_ROUTING (irqfd/KVM_IRQ_LINE) or KVM_SIGNAL_MSI is passed unchecked into eiointc_set_irq() and used as an IRQ index against 256-bit bitmaps and the sw_coremap[]/coreisr/sw_coreisr arrays, so any value of 256 or greater triggers deterministic, fully attacker-controlled out-of-bounds accesses with scope change from the guest process into kernel memory (CVSS 3.1 8.8, AV:L/PR:L/S:C). Exploitation is confined to LoongArch hosts running KVM and requires local access to the KVM interfaces; the DMSINTC path is unaffected because it decodes and masks the vector from the address. No public exploit code has been identified and the flaw is not confirmed actively exploited (not in CISA KEV), and vendor patches are available in the stable kernel commits referenced by the advisory.
Arbitrary host file exfiltration from Cloud Hypervisor VMM versions 34.0-50.0. CVSS 10.0. Patch available.