CVE-2026-89777: Linux Kernel VFIO Use-After-Free Vulnerability

CVE-2026-89777 Overview

CVE-2026-89777 is a use-after-free vulnerability in the Linux kernel's vfio/pci subsystem. The flaw resides in vfio_msi_cap_len(), which lazily allocates a per-device MSI permission table. When init_pci_cap_msi_perm() fails, the error path frees vdev->msi_perm but leaves the dangling pointer stored in the structure. Because struct vfio_pci_core_device persists across open and close cycles, subsequent operations reuse the freed object. Attackers with local access to a VFIO device node can trigger both a use-after-free read through freed function pointers and a double free on device close, leading to kernel memory corruption and potential privilege escalation.

Critical Impact
A local user with access to a VFIO PCI device can trigger kernel use-after-free and double-free conditions, resulting in kernel panic, information disclosure, or privilege escalation to root.

Affected Products

Linux kernel versions containing the vulnerable vfio_msi_cap_len() allocation logic in drivers/vfio/pci/vfio_pci_config.c
Distributions shipping the affected vfio-pci driver used for PCI device passthrough to virtual machines
Systems exposing VFIO device nodes to non-root users or guest VMs

Discovery Timeline

2026-09-16 - CVE-2026-89777 published to the National Vulnerability Database
2026-09-16 - Last updated in NVD database

Technical Details for CVE-2026-89777

Vulnerability Analysis

The vulnerability lies in the initialization path of the VFIO PCI Message Signaled Interrupt (MSI) capability handler. In vfio_msi_cap_len(), the kernel allocates vdev->msi_perm using kmalloc_obj() and then calls init_pci_cap_msi_perm() to populate the structure. When the nested alloc_perm_bits() call fails with -ENOMEM, the error path invokes kfree(vdev->msi_perm) but does not reset the pointer to NULL.

Because struct vfio_pci_core_device is per-device and persists across open and close cycles, the freed pointer outlives the failed open. The vfio_config_init() error path returns without calling vfio_config_free(), so the dangling reference remains attached to the device state.

Two distinct memory safety violations follow. First, a subsequent vfio_config_init() sees the stale pointer at the if (vdev->msi_perm) return len; check and reuses the freed object. MSI configuration accesses through vfio_pci_config_rw_single() then dereference and invoke the freed perm->readfn and perm->writefn function pointers. Second, a later vfio_config_free() runs free_perm_bits() and kfree() on the already-freed object, producing a double free.

Root Cause

The root cause is missing NULL assignment after kfree() in the error path. The fix aligns the code with the NULL-after-free discipline already used in free_perm_bits() and vfio_config_free() by setting vdev->msi_perm = NULL immediately after freeing. This vulnerability is categorized as Use After Free and Double Free, classes tracked as [CWE-416] and [CWE-415].

Attack Vector

Exploitation requires local access to a VFIO device file, typically /dev/vfio/*, which is commonly granted to virtualization users or guest VM processes performing PCI passthrough. The attacker induces an allocation failure in alloc_perm_bits() to leave the dangling pointer, then reopens the device to trigger reuse of the freed object. Controlled reads through pread64() on the device file invoke the freed function pointers reachable from vfio_pci_config_rw_single(). KASAN reports referenced in the advisory confirm the primitive: a slab use-after-free read followed by a general protection fault during kfree on close.

No verified public exploit is currently available. See the kernel commit d665a168 and related stable backports for authoritative technical details.

Detection Methods for CVE-2026-89777

Indicators of Compromise

KASAN reports of slab-use-after-free in vfio_pci_config_rw_single in kernel logs, matching the signature in the advisory
Kernel general protection faults originating in kfree with call traces through vfio_config_free and vfio_pci_core_disable
Unexpected Kernel panic - not syncing: Fatal exception events tied to vfio_pci close operations
Repeated failed open() or pread64() syscalls against /dev/vfio/* device nodes from non-virtualization workloads

Detection Strategies

Monitor kernel ring buffer output for KASAN and Oops events referencing vfio_pci_config_rw_single, vfio_config_free, or free_perm_bits
Audit process access to /dev/vfio/* and correlate with unprivileged user activity outside expected virtualization workflows
Deploy eBPF probes on vfio_msi_cap_len and vfio_config_init return paths to flag repeated -ENOMEM failures against the same device

Monitoring Recommendations

Forward dmesg and /var/log/kern.log to a centralized log platform and alert on VFIO-related fault signatures
Track container and VM host processes that hold open handles to VFIO nodes, and baseline expected callers
Alert on kernel panics and unexpected reboots on hypervisor hosts, which may indicate exploitation attempts against the double-free path

How to Mitigate CVE-2026-89777

Immediate Actions Required

Apply the upstream kernel patch or the stable backport shipped by your distribution as soon as it is available
Restrict access to /dev/vfio/* device nodes to trusted virtualization service accounts using group ownership and mode 0660
Audit which users and containers are members of the vfio or kvm groups and remove unnecessary membership
Disable VFIO PCI passthrough on hosts that do not require it by unloading vfio_pci and blacklisting the module

Patch Information

The fix NULLs vdev->msi_perm after the failing kfree() call, preventing reuse of the freed object and the subsequent double free. Patches are available in the following upstream commits: 25cdd2a, 533d0c5f, 812f1db7, d665a168, dc77acfe, eb84cd81, f0eea8f9, and fda8fb7e.

Workarounds

Remove vfio_pci from hosts that do not use PCI passthrough and blacklist the module in /etc/modprobe.d/
Tighten permissions on /dev/vfio/* and confirm only privileged virtualization daemons such as libvirtd can open device nodes
Enable kernel hardening options such as slab_nomerge and init_on_free=1 to reduce reliability of use-after-free exploitation
Isolate untrusted guests on hosts without VFIO passthrough until patches are deployed

bash

# Restrict VFIO access and disable module where not required
sudo chown root:vfio /dev/vfio/*
sudo chmod 0660 /dev/vfio/*

# Blacklist vfio-pci on hosts that do not use passthrough
echo 'blacklist vfio_pci' | sudo tee /etc/modprobe.d/blacklist-vfio.conf
sudo update-initramfs -u

# Add kernel hardening at boot via /etc/default/grub GRUB_CMDLINE_LINUX
# slab_nomerge init_on_free=1