CVE-2026-64474

What it actually does

This Linux kernel flaw affects VFIO device migration state handling. When a VFIO device is in a migration state where a transition is blocked, the kernel may encode the next state as an ERROR sentinel. The vulnerable logic continues trying to skip unsupported optional states without stopping on that ERROR value, causing an infinite loop in vfio_mig_get_next_state() while holding a driver state mutex. The result is CPU soft lockup, stalled VFIO migration/control paths, and, on systems configured with softlockup_panic, a kernel panic and full host crash. Exploitation requires the ability to interact with an affected VFIO device and request the relevant migration state transition; this is not a typical unauthenticated network attack.

Why it matters to the business

The primary business risk is denial of service on Linux virtualization or passthrough hosts using VFIO, especially environments that rely on device assignment or live migration of VFIO-backed devices. A successful trigger can hang kernel execution paths and may crash the host, disrupting workloads, virtual machines, and maintenance operations. The issue is not currently listed in CISA KEV, has no known mature public exploitation, and has a low EPSS score, so urgency is highest for systems exposing VFIO device control to tenants, untrusted local users, or automation that performs device migration.

How an attack unfolds

An attacker first needs local or delegated access to a VFIO device or to a management path capable of driving VFIO migration state changes. They identify a device that supports pre-copy migration behavior and move or cause the device to be in a STOP_COPY migration state. They then request a blocked transition from STOP_COPY to PRE_COPY or PRE_COPY_P2P. In the vulnerable kernel, that transition resolves to the ERROR sentinel, but the skip loop does not terminate. The kernel repeatedly evaluates the same ERROR state, spinning indefinitely while holding the VFIO driver state mutex. This can produce a soft lockup, block related VFIO operations, and, depending on kernel watchdog settings, panic the host.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fix for the VFIO migration state-machine handling. The fix changes the skip loop so it stops when the ERROR sentinel is reached and returns the existing -EINVAL error instead of spinning indefinitely. If vendor fixed package versions are not yet available, track the relevant distribution kernel advisory and deploy the first patched kernel for the affected release stream. As interim mitigations, restrict VFIO device access to trusted users and management services, avoid exposing VFIO migration controls to untrusted tenants, disable or limit VFIO live migration workflows where feasible, and monitor systems using VFIO for soft lockup symptoms. Reboot into the patched kernel after installation; installing a kernel package alone is not sufficient until the running kernel is replaced.

How to confirm the fix worked

Confirm the running kernel includes the VFIO fix, not just that a patched package is installed. Validate with distribution tooling such as uname -r, package manager advisory status, and vendor security scanner output. On systems that build custom kernels, verify the source contains the change that terminates vfio_mig_get_next_state() skip processing when the next state is VFIO_DEVICE_STATE_ERROR. Confirm VFIO workloads continue to function and that invalid or blocked migration transitions return an error rather than causing CPU spin or soft lockup. Review kernel logs after testing for absence of soft lockup, watchdog, hung task, or vfio_mig_get_next_state-related messages.

Typical attack path

1. Gain local access, tenant-level control, or management-plane access that permits interaction with a VFIO device or VFIO migration state controls.
2. Select a VFIO device that supports pre-copy migration states.
3. Drive the device migration state machine into STOP_COPY.
4. Request a blocked transition such as STOP_COPY to PRE_COPY or STOP_COPY to PRE_COPY_P2P.
5. Trigger the vulnerable loop in vfio_mig_get_next_state(), causing the kernel to spin while holding the driver state mutex.
6. Induce a soft lockup, VFIO management disruption, and potentially a kernel panic if softlockup_panic is enabled.

How to detect it

Look for evidence of local denial-of-service attempts or unexplained VFIO-related host instability. Useful sources include kernel ring buffer output, systemd journal logs, /var/log/kern.log, /var/log/messages, hypervisor or virtualization management logs, audit logs for access to /dev/vfio devices, and crash dump records such as kdump/vmcore metadata. Search for soft lockup, watchdog, hung task, kernel panic, or call traces involving vfio_mig_get_next_state, VFIO migration state changes, or VFIO device file activity shortly before a crash. Correlate suspicious /dev/vfio/* access by non-administrative users or tenant-facing processes with host lockups or panics. Because this vulnerability causes availability failure rather than code execution, durable file-based IOCs are unlikely; detection relies mainly on kernel logs, crash traces, and access telemetry.

• vfio_mig_get_next_state
• BUG: soft lockup
• soft lockup - CPU
• watchdog: BUG: soft lockup
• Kernel panic - not syncing: softlockup
• INFO: task blocked for more than
• hung_task_timeout_secs
• VFIO_DEVICE_STATE_ERROR
• /dev/vfio/
• vfio
• vfio-pci
• softlockup_panic

What your security team should do

• Inventory Linux hosts using VFIO, PCI passthrough, mediated devices, or VFIO-backed live migration and prioritize those for kernel patching.
• Prioritize multi-tenant virtualization hosts, systems where untrusted users can access VFIO device files, and hosts with softlockup_panic enabled.
• Apply the vendor-patched kernel as soon as available and reboot into it.
• Restrict access to /dev/vfio/* and related management APIs to trusted administrators and services only.
• Temporarily disable or tightly control VFIO device migration workflows if patching is delayed.
• Monitor kernel logs and host availability telemetry for soft lockup, watchdog, hung task, and VFIO migration errors.
• If suspicious crashes or lockups occurred, preserve kernel logs, journal entries, crash dumps, and hypervisor management logs before rebooting or rebuilding the host.