CVE-2026-64476

What it actually does

This Linux kernel VFIO PCI flaw can cause inconsistent runtime power-management state for devices bound to vfio-pci or vfio-pci variant drivers. The vulnerable behavior occurs because the disable_idle_d3 setting was treated as a mutable global value while already-bound devices could continue operating under assumptions made at initialization time. If the vfio-pci module is loaded, unloaded, reloaded, or its module parameter is changed through sysfs with different values, runtime PM get/put operations can become unbalanced. The practical technical result is denial of service against affected PCI passthrough devices or the host’s device-management path, such as devices being left in the wrong power state, reset failures, device availability loss, or instability in workloads using VFIO passthrough.

Why it matters to the business

Organizations using Linux systems with VFIO PCI passthrough, such as virtualization hosts, GPU passthrough systems, accelerator platforms, or environments assigning physical PCI devices to virtual machines, may experience service disruption if affected devices become unusable or unstable. This could interrupt virtual machines, workloads relying on assigned GPUs/NICs/storage controllers, or maintenance operations involving driver rebinding and module reloads. The issue is not currently listed in CISA KEV, has very low EPSS, and has no reported exploit maturity in the provided data, so broad internet-scale exploitation is unlikely; however, systems that expose administrative module or sysfs control to local users, automation, or management tooling should treat it as an operational reliability risk.

How an attack unfolds

An attacker would typically need local privileges or an execution context capable of manipulating kernel modules, VFIO driver bindings, or writable sysfs module parameters. The attacker first identifies a Linux host using vfio-pci or vfio-pci variant drivers for PCI passthrough. They then arrange for one or more PCI devices to remain bound to VFIO while changing the vfio-pci disable_idle_d3 behavior, commonly by writing to the module parameter through sysfs or by unloading and reloading vfio-pci with different parameter values. Because vulnerable kernels can apply the changed global setting inconsistently relative to already-initialized devices, later runtime PM or reset operations may perform unbalanced power-management references. The attacker then triggers device activity, idle transitions, resets, VM start/stop operations, or driver rebinding to cause the device to enter an inconsistent power-management state, resulting in denial of service for the assigned device or dependent workload.

How to fix it

Apply a Linux kernel update that includes the vfio/pci fix that latches disable_idle_d3 per vfio_pci_core_device at device initialization. Use vendor-supported kernel packages for the affected distribution or appliance, since fixed versions were not provided in the input. If immediate patching is not possible, reduce exposure by preventing untrusted users and automation from changing vfio-pci module parameters, loading or unloading vfio-pci modules, rebinding PCI devices, or managing VFIO passthrough devices. Avoid changing /sys/module/vfio_pci/parameters/disable_idle_d3 on running systems with devices already bound to VFIO. Schedule maintenance windows for module reloads, driver rebinding, and PCI passthrough changes, and reboot after mitigation if device power-management state is suspected to be inconsistent.

How to confirm the fix worked

Confirm that the running kernel package includes the upstream stable or distribution backport for the vfio/pci change that stores disable_idle_d3 as a per-device value rather than relying on a mutable global. Validate with the OS vendor advisory, kernel changelog, or package metadata. On representative VFIO hosts, verify that PCI passthrough devices can be assigned, idled, reset, detached, and reattached without runtime PM imbalance symptoms, reset failures, or unexpected D3hot/D0 state issues. Check that access controls prevent non-administrative users from writing vfio-pci module parameters or performing module load/unload operations. Review boot-time and runtime configuration to ensure disable_idle_d3 is set consistently and not changed dynamically on vulnerable kernels.

Typical attack path

1. Gain local administrative capability or equivalent control over kernel module loading, sysfs module parameters, VFIO device binding, or host management automation.
2. Identify systems using vfio-pci or vfio-pci variant drivers for PCI passthrough devices.
3. Ensure one or more PCI devices are already bound to VFIO while the vfio-pci disable_idle_d3 behavior can be changed.
4. Change the disable_idle_d3 module parameter through sysfs or reload vfio-pci with a different parameter value.
5. Trigger runtime power-management transitions, device reset, VM start/stop, passthrough attach/detach, or driver rebinding operations.
6. Cause unbalanced runtime PM handling, leading to device reset failure, incorrect power state, or loss of availability for the PCI device or dependent workload.

How to detect it

To assess whether this was already triggered, review host-level logs and audit data for changes to vfio-pci configuration followed by PCI passthrough failures. Useful sources include auditd logs, Linux journal, dmesg, shell history for privileged users, sudo logs, configuration-management logs, hypervisor or VM lifecycle logs, and EDR telemetry for module-management commands. Look specifically for writes to /sys/module/vfio_pci/parameters/disable_idle_d3, modprobe/rmmod activity involving vfio_pci or vfio-pci variant drivers, PCI driver unbind/bind operations, and subsequent kernel messages involving vfio-pci, runtime PM, D3hot/D0 transitions, or reset failures. Correlate these events with VM failures, device assignment errors, passthrough device disappearance, or workloads failing after device idle, reset, detach, or reattach events. There are no known threat actors or KEV exploitation signals in the provided data, so detection should focus on local administrative misuse, accidental automation changes, and operational evidence of device-level denial of service rather than remote exploit traffic.

• /sys/module/vfio_pci/parameters/disable_idle_d3
• disable_idle_d3
• vfio_pci
• vfio-pci
• vfio_pci_core
• modprobe vfio_pci
• modprobe vfio-pci
• rmmod vfio_pci
• rmmod vfio-pci
• /sys/bus/pci/drivers/vfio-pci/bind
• /sys/bus/pci/drivers/vfio-pci/unbind
• /sys/bus/pci/devices/
• runtime PM
• D3hot
• pci_set_power_state
• vfio_pci_dev_set_pm_runtime_get
• vfio_pci_dev_set_try_reset

What your security team should do

• Prioritize patching Linux virtualization or accelerator hosts that use vfio-pci passthrough, especially where device reset, runtime PM, or VM lifecycle operations are frequent.
• Inventory systems with vfio-pci, vfio_pci_core, or vfio-pci variant drivers loaded and identify devices currently bound to VFIO.
• Restrict write access to vfio-pci sysfs parameters and restrict module load/unload capability to trusted administrators only.
• Avoid changing disable_idle_d3 dynamically on vulnerable kernels; use a consistent boot-time configuration until patched.
• Monitor for unexpected writes to /sys/module/vfio_pci/parameters/disable_idle_d3 and for vfio-pci module unload/reload activity outside approved maintenance windows.
• Review dmesg, kernel journal, and virtualization management logs for PCI passthrough reset failures, runtime PM warnings, or devices stuck in low-power states.
• If symptoms are observed, migrate or stop dependent workloads safely, reboot the host if needed to restore device state, and apply the fixed kernel before returning the host to production use.