In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
vfio\/pci: clear vdev->msi_perm after freeing it on init failure<\/p>\n
vfio_msi_cap_len() lazily allocates the per-device MSI permission table:<\/p>\n
\tvdev->msi_perm = kmalloc_obj(struct perm_bits, GFP_KERNEL_ACCOUNT);
\n\tif (!vdev->msi_perm)
\n\t\treturn -ENOMEM;<\/p>\n
\tret = init_pci_cap_msi_perm(vdev->msi_perm, len, flags);
\n\tif (ret) {
\n\t\tkfree(vdev->msi_perm);
\n\t\treturn ret;\t\t\/* vdev->msi_perm left dangling *\/
\n\t}<\/p>\n
When init_pci_cap_msi_perm() -> alloc_perm_bits() fails with -ENOMEM, the
\nerror path frees vdev->msi_perm but leaves the freed pointer stored in
\nit. vdev->msi_perm is not re-zeroed later because struct
\nvfio_pci_core_device is per-device and persists across open\/close cycles,
\nand the vfio_config_init() error path returns without calling
\nvfio_config_free(). So the dangling pointer outlives the failed open.<\/p>\n
That leads to two use-after-frees on the same device:<\/p>\n
1. Reuse. The next vfio_config_init() sees the stale pointer at
\n “if (vdev->msi_perm) return len;” and reuses the freed object. MSI
\n config accesses in vfio_pci_config_rw_single() then dereference and
\n call the freed perm->readfn \/ perm->writefn function pointers.<\/p>\n
2. Double free. A later vfio_config_free() runs free_perm_bits() and
\n kfree() on the already-freed object.<\/p>\n
Fix it by NULLing vdev->msi_perm after the kfree(), matching the
\nNULL-after-free discipline already used in free_perm_bits() and
\nvfio_config_free().<\/p>\n
BUG: KASAN: slab-use-after-free in vfio_pci_config_rw_single (drivers\/vfio\/pci\/vfio_pci_config.c:1961)
\n Read of size 8 at addr ffff88800fcc88d0 by task exploit\/143
\n Call Trace:
\n …
\n kasan_report (mm\/kasan\/report.c:595)
\n vfio_pci_config_rw_single (drivers\/vfio\/pci\/vfio_pci_config.c:1961)
\n vfio_pci_config_rw (drivers\/vfio\/pci\/vfio_pci_config.c:1986)
\n vfio_pci_rw (drivers\/vfio\/pci\/vfio_pci_core.c:1599)
\n vfs_read (fs\/read_write.c:572)
\n __x64_sys_pread64 (fs\/read_write.c:764)
\n do_syscall_64 (arch\/x86\/entry\/syscall_64.c:94)
\n …<\/p>\n
Followed on device close by a double free of the same object:<\/p>\n
Oops: general protection fault, probably for non-canonical address
\n 0x1f63e0e8000008: 0000 [#1] SMP KASAN NOPTI
\n RIP: 0010:kfree (mm\/slub.c:6711)
\n Call Trace:
\n vfio_config_free (drivers\/vfio\/pci\/vfio_pci_config.c:1861)
\n vfio_pci_core_disable (drivers\/vfio\/pci\/vfio_pci_core.c:685)
\n vfio_pci_core_close_device (drivers\/vfio\/pci\/vfio_pci_core.c:777)
\n vfio_df_close (drivers\/vfio\/vfio_main.c:602)
\n vfio_device_fops_release (drivers\/vfio\/vfio_main.c:648)
\n __fput (fs\/file_table.c:512)
\n __x64_sys_close (fs\/open.c:1496)
\n do_syscall_64 (arch\/x86\/entry\/syscall_64.c:94)
\n …
\n Kernel panic – not syncing: Fatal exception<\/p>\n","protected":false},"excerpt":{"rendered":"
In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
vfio\/pci: clear vdev->msi_perm after freeing it on init failure<\/p>\n
vfio_msi_cap_len() lazily allocates the per-device MSI permission <\/p>\n","protected":false},"template":"","meta":[],"categories":[],"tags":[],"class_list":["post-24434","vuln","type-vuln","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln\/24434","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln"}],"about":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/types\/vuln"}],"wp:attachment":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=24434"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=24434"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=24434"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}