ZDF
Sign inSign up

Vulnerabilities

Vulnerability · CVE-2026-89777

vfio/pci: clear vdev->msi_perm after freeing it on init failure

Published Sep 16, 2026 · catalog updated Oct 22, 2026 · vfio/pci: clear vdev->msi_perm after

Check if you run it

No confirmed exploitation is on record for CVE-2026-89777. EPSS is 0.16%. Act only if a listed version of vfio/pci: clear vdev->msi_perm after is installed.

Gaps on this record

  • The stored product name is a package slug. The name on this page is taken from the title (vfio/pci: clear vdev->msi_perm after).
  • No vendor fix or required action is stored. Compare the linked advisory before you change production.
Severity
High8.8
Known exploitation
Not in CISA/VulnCheck KEV
EPSS
0.16%
Remediation
Not established
Affected products
Linux Kernel

In the Linux kernel, the following vulnerability has been resolved: vfio/pci: clear vdev->msi_perm after freeing it on init failure vfio_msi_cap_len() lazily allocates the per-device MSI permission table: vdev->msi_perm = kmalloc_obj(struct perm_bits, GFP_KERNEL_ACCOUNT); if (!vdev->msi_perm) return -ENOMEM; ret = init_pci_cap_msi_perm(vdev->msi_perm, len, flags); if (ret) { kfree(vdev->msi_perm); return ret; /* vdev->msi_perm left dangling */ } When init_pci_cap_msi_perm() -> alloc_perm_bits() fails with -ENOMEM, the error path frees vdev->msi_perm but leaves the freed pointer stored in it. vdev->msi_perm is not re-zeroed later because struct vfio_pci_core_device is per-device and persists across open/close cycles, and the vfio_config_init() error path returns without calling vfio_config_free(). So the dangling pointer outlives the failed open. That leads to two use-after-frees on the same device: 1. Reuse. The next vfio_config_init() sees the stale pointer at "if (vdev->msi_perm) return len;" and reuses the freed object. MSI config accesses in vfio_pci_config_rw_single() then dereference and call the freed perm->readfn / perm->writefn function pointers. 2. Double free. A later vfio_config_free() runs free_perm_bits() and kfree() on the already-freed object. Fix it by NULLing vdev->msi_perm after the kfree(), matching the NULL-after-free discipline already used in free_perm_bits() and vfio_config_free(). BUG: KASAN: slab-use-after-free in vfio_pci_config_rw_single (drivers/vfio/pci/vfio_pci_config.c:1961) Read of size 8 at addr ffff88800fcc88d0 by task exploit/143 Call Trace: ... kasan_report (mm/kasan/report.c:595) vfio_pci_config_rw_single (drivers/vfio/pci/vfio_pci_config.c:1961) vfio_pci_config_rw (drivers/vfio/pci/vfio_pci_config.c:1986) vfio_pci_rw (drivers/vfio/pci/vfio_pci_core.c:1599) vfs_read (fs/read_write.c:572) __x64_sys_pread64 (fs/read_write.c:764) do_syscall_64 (arch/x86/entry/syscall_64.c:94) ... Followed on device close by a double free of the sam

Are you affected?

Enter the version you run. The result uses only the ranges stored on this record.

The check returns affected, not affected, or incomplete. It does not guess a version that is missing from the record.

  • Linux Kernel4.20.0 → 5.10.270; 5.11.0 → 5.15.221; 5.16.0 → 6.1.188

How to fix CVE-2026-89777

What to do

Three questions, each answered from this record only. Confirm the vendor advisory before you patch.

Should you patch?

No confirmed exploitation is on record for CVE-2026-89777. EPSS is 0.16%. Act only if a listed version of vfio/pci: clear vdev->msi_perm after is installed.

Which versions are affected?

Compare what you have installed with Kernel 4.20.0 → 5.10.270; 5.11.0 → 5.15.221; 5.16.0 → 6.1.188. Compare the installed version with the linked vendor advisory before you change production.

What should an analyst verify?

No weakness class is stored. EPSS 0.16%. There is no CISA KEV listing. No Exploit-DB or Metasploit reference is linked. Use the source links for the original advisory.

Code

The project this record applies to. Exploit listings stay in References.

Timeline

Detection, updates, and resolution for this record.

  1. Sep 16, 2026 · OpenSSF OSV / OSV Scanner

    Detected

    In the Linux kernel, the following vulnerability has been resolved: vfio/pci: clear vdev->msi_perm after freeing it on init failure vfio_msi_cap_len() lazily allocates the per-device MSI permission table: vdev->msi_perm = kmalloc_obj(struct perm_bits, GFP_KERNEL_ACCOUNT); if (!vdev->msi_perm) return -ENOMEM; ret = init_pci_cap_msi_perm(vdev->msi_perm, len, flags); if (ret) { kfree(vdev->msi_perm);

  2. Oct 22, 2026 · OpenSSF OSV / OSV Scanner

    Fix available

    Kernel fixed in 5.10.270; Kernel fixed in 5.15.221; Kernel fixed in 6.1.188; Kernel fixed in 6.6.157

  3. Oct 22, 2026 · OpenSSF OSV / OSV Scanner

    Fix available

    Kernel fixed in 5.10.270; 5.11.0

  4. Oct 22, 2026 · OpenSSF OSV / OSV Scanner

    Updated

    In the Linux kernel, the following vulnerability has been resolved: vfio/pci: clear vdev->msi_perm after freeing it on init failure vfio_msi_cap_len() lazily allocates the per-device MSI permission table: vdev->msi_perm = kmalloc_obj(struct perm_bits, GFP_KERNEL_ACCOUNT); if (!vdev->msi_perm) return -ENOMEM; ret = init_pci_cap_msi_perm(vdev->msi_perm, len, flags); if (ret) { kfree(vdev->msi_perm);

Sources

References

Freshness

Last verified in this catalog Oct 23, 2026. Significant claims (KEV, EPSS, CVSS, affected ranges) come from the source rows above — open the original publisher for the authoritative advisory.