CVE-2026-89777

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

HIGH
8.8
CVSS Score
Published: September 16, 2026 at 08:48 AM UTC
Updated: October 19, 2026 at 09:18 AM UTC
1 product affected across 1 vendorLinux Kernel

Using Linux by Linux?

Get instant alerts when new vulnerabilities affect Linux - before attackers find them.

Real-time alertsTrack your software stackFree plan available
Severity
HIGH8.8
Exploit prediction
EPSS 0.2%

Description

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 same object: Oops: general protection fault, probably for non-canonical address 0x1f63e0e8000008: 0000 [#1] SMP KASAN NOPTI RIP: 0010:kfree (mm/slub.c:6711) Call Trace: vfio_config_free (drivers/vfio/pci/vfio_pci_config.c:1861) vfio_pci_core_disable (drivers/vfio/pci/vfio_pci_core.c:685) vfio_pci_core_close_device (drivers/vfio/pci/vfio_pci_core.c:777) vfio_df_close (drivers/vfio/vfio_main.c:602) vfio_device_fops_release (drivers/vfio/vfio_main.c:648) __fput (fs/file_table.c:512) __x64_sys_close (fs/open.c:1496) do_syscall_64 (arch/x86/entry/syscall_64.c:94) ... Kernel panic - not syncing: Fatal exception

Affected

Our own answer: ranges merged, affected separated from platform-only, with confidence and review flags.

30ea32ab1951c80c6113f300fce2c70cd12659e44.14.1554.19.854.204.4.2034.9.203ac370e3d1f3b01519d2705cd5815d1c9d0a8812bbe363e27ec3c3a99793da2be6c07eafb95709c6bdde3433de9a067a33d67d65b9093cad3e043e49ef1b10ba5739440ca51d66f0b2949cead88d2dd02
Vendor states this is fixed in 25cdd2a492d868cff1e519a60fe282909c52d385 (fixed)
Vendor states this is fixed in 533d0c5feef85ee6404b9f41d5564fac6971a008 (fixed)
Vendor states this is fixed in 812f1db7f0755a19ef16ecdc5cec51bcabc5eda5 (fixed)
Vendor states this is fixed in d665a1688af7f8fefd7c0eb04f2a37122ce007f4 (fixed)
Vendor states this is fixed in dc77acfeb979dded39b247b60fef0399536bfa77 (fixed)
Vendor states this is fixed in eb84cd81040e58dd05ac190f561f2115e3367249 (fixed)
Vendor states this is fixed in f0eea8f9013676b42289ec35941e848b8a543e19 (fixed)
Vendor states this is fixed in fda8fb7e8179561693a786a7af593f6b944a21c1 (fixed)
Affected range stops below 4.10, so it looks safe — our inference, not a vendor statement
Affected range stops below 4.15, so it looks safe — our inference, not a vendor statement
Vendor states this is fixed in 4.20 (unaffected)
Affected range stops below 4.5, so it looks safe — our inference, not a vendor statement
Vendor states this is fixed in 5.10.270 (unaffected)
Vendor states this is fixed in 5.15.221 (unaffected)
Vendor states this is fixed in 6.1.188 (unaffected)
Vendor states this is fixed in 6.12.110 (unaffected)
Vendor states this is fixed in 6.18.52 (unaffected)
Vendor states this is fixed in 6.6.157 (unaffected)
Vendor states this is fixed in 7.2.6 (unaffected)
Vendor states this is fixed in 7.3 (unaffected)
Vendor states this is fixed in 7.3-rc1 (unaffected)

Remediation

No guide yet

No remediation guidance has been written for this CVE yet, and no fixed version or vendor advisory is recorded against it.

CVSS

8.8HIGHLinux
Vector?

Quick Info

StatusRECEIVED

Get alerted

Stop reading CVE feeds looking for your own stack

Track the products you run and VulnTracker tells you when a new CVE affects them — with what is known about fixing it, and nothing about the rest.

Free plan, no card