HIGH
vfio/pci MsiPerm UAF
CVE-2026-89777
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
KernelScan AI7.4HIGH
01Description
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
02KernelScan AI Analysis
Risk summary
A local attacker with access to a VFIO PCI device can trigger a use-after-free by forcing an allocation failure during MSI capability initialization, then reopening the device to reuse the freed permission object. This can lead to arbitrary code execution in the kernel or a denial-of-service via kernel panic.
Vulnerability analysis
When the VFIO PCI subsystem initializes MSI capability permissions for a device, an allocation failure on the error path frees the permission object but leaves a dangling pointer stored in the per-device structure. Because the device structure persists across open/close cycles, a subsequent open reuses the stale pointer, causing use-after-free when MSI config space is read or written, and a double-free when the device is later released. The fix sets the pointer to NULL immediately after freeing it, so the next initialization allocates a fresh object instead of reusing freed memory. The vulnerable path is reachable from a local process that has access to a VFIO PCI device file descriptor, which typically requires the user to be granted access to the device (e.g., via a VFIO group/container) but does not require root privileges once access is granted.
Lifecycle
03Fix Versions
| Branch | Introduced | Fixed in | Patch commit |
|---|---|---|---|
| 4.14 | 4.14.155 | 4.15 | d665a1688af7 |
| 4.19 | 4.19.85 | 4.20 | 25cdd2a492d8 |
| 4.4 | 4.4.203 | 4.5 | eb84cd81040e |
| 4.9 | 4.9.203 | 4.10 | f0eea8f90136 |
| 5.10 | — | 5.10.270 | 812f1db7f075 |
| 5.15 | — | 5.15.221 | 533d0c5feef8 |
| 6.1 | — | 6.1.188 | fda8fb7e8179 |
| 6.12 | — | 6.12.110 | — |
| 6.18 | — | 6.18.52 | — |
| 6.6 | — | 6.6.157 | dc77acfeb979 |
| 7.2 | — | 7.2.6 | — |
| mainline | — | 7.3 | — |
| cip/5.10 | — | 5.10.271-cip78 | eb84cd81040e |
| cip/6.1 | — | 6.1.189-cip61 | d665a1688af7 |
| cip/6.1-rt | — | 6.1.189-cip61-rt32 | d665a1688af7 |
| cip/6.12 | — | 6.12.111-cip32 | 812f1db7f075 |
04CIP Kernels
State of the newest release of each Civil Infrastructure Platform SLTS tree, from CIP's own fix records.
| CIP tree | State |
|---|---|
| cip/6.12 | Fixed in 6.12.111-cip32 |
| cip/6.1 | Fixed in 6.1.189-cip61 |
| cip/6.1-rt | Fixed in 6.1.189-cip61-rt32 |
| cip/5.10 | Fixed in 5.10.271-cip78 |
| cip/5.10-rt | Affected — no CIP fix yet (latest 5.10.268-cip77-rt34) |
| cip/4.19 | Affected — no CIP fix yet (latest 4.19.325-cip136) |
| cip/4.19-rt | Affected — no CIP fix yet (latest 4.19.325-cip136-rt50) |
| cip/4.4 | Affected — no CIP fix yet (latest 4.4.302-cip115) |
| cip/4.4-rt | Affected — no CIP fix yet (latest 4.4.302-cip115-rt63) |