CVE-2024-26691

What it actually does

The flaw violates the established locking rule in KVM by acquiring kvm->lock while already holding vcpu->mutex in pkvm_create_hyp_vm(), creating a circular dependency that can result in deadlock during arm64 VM creation via kvm_vcpu_ioctl().

Why it matters to the business

Virtualized workloads on affected Linux kernels may experience hangs or crashes, disrupting availability of services relying on KVM for isolation; urgency remains low given absence from known exploitation lists and stable EPSS.

How an attack unfolds

An attacker with local access to a guest or host process invokes kvm_vcpu_ioctl() to trigger pkvm_create_hyp_vm(), which takes locks out of the required order; no named threat actors have been observed chaining this into remote code execution or ransomware.

How to fix it

Upgrade the Linux kernel to the commit 3d16cebf01127f459dcfeb79ed77bd68b124c228 or later stable releases that protect the hyp VM handle with config_lock instead.

How to confirm the fix worked

Confirm kernel source contains the referenced commit or verify that kvm_vcpu_ioctl() and pkvm_create_hyp_vm() no longer acquire locks in the deprecated order; recompile and boot test VMs to ensure no deadlock under load.

Typical attack path

1. Obtain local execution context on an arm64 system using KVM
2. Call kvm_vcpu_ioctl() to reach pkvm_create_hyp_vm() while vcpu->mutex is held
3. Trigger acquisition of kvm->lock to create circular dependency
4. Cause deadlock or system instability affecting VM operations

How to detect it

Search kernel logs and audit trails for repeated KVM lock acquisition warnings or hung task reports during VM creation; no widespread exploitation indicators have been published.

What your security team should do

• Prioritize kernel updates on arm64 hosts running KVM within the next maintenance window
• Monitor upstream stable branches for backports of the locking fix
• Review any downstream distributions for equivalent patches before the 90-day mark