CVE-2026-64473

What it actually does

This is a Linux kernel use-after-free in VFIO device teardown. VFIO per-device debugfs files created with devres-backed state can remain visible after device_del() releases that backing memory, leaving debugfs inode private data pointing to freed memory while userspace references are still draining. A local actor able to interact with VFIO debugfs entries and trigger VFIO device unregister paths may be able to cause kernel memory corruption, most realistically a denial of service through a kernel crash, with potential privilege-escalation risk depending on allocator behavior, kernel hardening, and exploitability of the stale pointer.

Why it matters to the business

Systems using VFIO for virtualization, device passthrough, accelerators, or other hardware assignment can be exposed to local kernel instability during device removal or reconfiguration. The most likely operational impact is host crashes or service disruption affecting virtual machines or workloads that depend on VFIO-backed devices. The vulnerability is not in CISA KEV, has no reported exploit maturity, and has a low EPSS score, so broad opportunistic exploitation is not currently indicated; however, kernel flaws in virtualization hosts can still carry high impact where untrusted local users or tenants can influence VFIO device lifecycle operations.

How an attack unfolds

An attacker would need local access to a system where VFIO and debugfs are available. They would first identify VFIO per-device debugfs entries and open or repeatedly read them to keep references active. In parallel, they would trigger or race a VFIO device unregister event, such as device removal, driver unbind, VM/device teardown, or another administrative workflow that causes vfio_unregister_group_dev() to run. In the vulnerable sequence, device_del() releases devres allocations before VFIO removes the associated debugfs tree, so the still-visible debugfs inode can reference freed memory. Subsequent reads or operations on that debugfs file may dereference stale private data, leading to use-after-free behavior in kernel context. A successful attack is most likely to crash the kernel; more advanced exploitation would require shaping freed kernel memory and bypassing kernel hardening to turn the stale pointer into controlled execution or privilege escalation. No public exploitation or named threat actor activity is indicated by the provided data.

How to fix it

Upgrade to a Linux kernel or vendor kernel package that includes the VFIO fix changing teardown order so the per-device debugfs tree is removed before device_del() releases devres-backed storage, and clearing the per-device debugfs root after removal. Because fixed versions were not provided, use the relevant distribution, appliance, hypervisor, or kernel vendor advisory to identify the exact patched kernel build. As mitigations until patching is complete, restrict debugfs access to trusted administrators, avoid mounting debugfs on production systems unless required, limit local shell access on VFIO-capable hosts, restrict device hot-unplug/unbind operations to trusted automation, and reduce exposure of VFIO device management interfaces to untrusted users or workloads.

How to confirm the fix worked

Confirm that the running kernel package includes the upstream VFIO teardown-order fix for this issue, not merely that a package has been installed. Validate with the distribution security advisory, kernel changelog, or source patch presence for the change that removes VFIO device debugfs before device_del() and clears the per-device debugfs root after removal. On test systems, verify that repeated reads of VFIO debugfs entries during VFIO device unbind, hot-unplug, or VM/device teardown do not produce KASAN reports, kernel oopses, stale debugfs dentries, or crashes. Also verify whether debugfs is mounted and whether access permissions are restricted to trusted administrative users.

Typical attack path

1. Obtain local access to a Linux system with VFIO enabled and debugfs mounted or otherwise accessible.
2. Locate VFIO per-device diagnostic files under the kernel debugfs hierarchy.
3. Open, read, or hold references to the VFIO debugfs files associated with a target device.
4. Trigger VFIO device unregister through hot-unplug, driver unbind, device reassignment, VM teardown, or another path that removes the VFIO device.
5. Race continued debugfs access against VFIO teardown so the debugfs inode private data points to memory already released by devres cleanup.
6. Cause a kernel use-after-free condition, typically resulting in a kernel oops, panic, or host denial of service; in a more advanced scenario, attempt memory manipulation for privilege escalation.

How to detect it

To determine whether this was already exploited, review kernel logs, persistent journals, crash dumps, and hypervisor or orchestration logs for crashes or oopses occurring during VFIO device unregister, hot-unplug, driver unbind, VM teardown, or device passthrough changes. Focus on evidence of use-after-free, invalid pointer dereference, general protection faults, kernel panics, or KASAN reports involving VFIO, debugfs, seq_file, or devres cleanup paths. Useful sources include dmesg output, /var/log/kern.log, /var/log/messages, journalctl -k, kdump/vmcore data, hypervisor management logs, auditd records for access to /sys/kernel/debug, and shell or automation logs showing device unbind or VFIO management actions. Look for suspicious repeated reads of VFIO debugfs entries immediately before device removal or host crashes. There are no known public threat actors, ransomware campaigns, or stable network indicators associated with this issue from the provided data, so detection should be behavior- and artifact-based rather than IOC-only.

What your security team should do

• Prioritize patching VFIO-enabled virtualization, passthrough, accelerator, and bare-metal compute hosts where local users or tenants may influence device lifecycle operations.
• Identify systems with VFIO modules enabled and debugfs mounted, then assess whether debugfs is required in production.
• Apply vendor kernel updates that contain the VFIO debugfs teardown fix; reboot into the patched kernel where required.
• Until patched, restrict debugfs access, disable unnecessary debugfs mounts, and limit VFIO device unbind, hot-plug, and reassignment operations to trusted administrators or automation.
• Enable or review kernel crash collection, KASAN testing in non-production, and centralized kernel log forwarding for VFIO/debugfs-related oops or use-after-free evidence.
• Monitor vendor advisories for exact fixed package versions and backports, since Linux distributions often fix kernel CVEs through backported patches without changing to an upstream version number.
• Treat unexplained crashes on VFIO hosts during device removal, passthrough changes, or VM teardown as potentially security-relevant and preserve crash dumps for analysis.