Описание
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:
- 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.
- 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
A flaw was found in the Linux kernel's vfio/pci component. During device initialization, a memory pointer is not properly cleared after being freed, leading to a use-after-free and double-free vulnerability. A local attacker could exploit this flaw to cause a system crash, resulting in a denial of service, or potentially execute arbitrary code with elevated privileges.
Отчет
A use-after-free and double-free flaw in the Linux kernel's vfio/pci subsystem has been rated Important by Red Hat. When initialization of the per-device MSI permission table fails (for example, when an underlying allocation fails with -ENOMEM), the error path in vfio_msi_cap_len() frees vdev->msi_perm but leaves the dangling pointer stored in the per-device vfio_pci_core_device structure, which persists across open/close cycles. A local attacker with access to a VFIO PCI device could trigger this failed initialization path and then, on a subsequent open or close of the device, cause the freed object to be reused for MSI config-space accesses (dereferencing and calling the freed perm->readfn/perm->writefn function pointers) or to be freed a second time in vfio_config_free(). This can lead to a kernel panic and system crash (denial of service) or potentially to execution of arbitrary code with elevated privileges. Red Hat rates this flaw as Important with a CVSS 3.1 score of 7.0 (AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H); the higher CVE.org score of 8.8 reflects a lower attack-complexity assessment, whereas Red Hat considers exploitation to depend on reliably steering a memory-allocation failure during device initialization. Within Red Hat's affected product scope, Red Hat Enterprise Linux 6 and 7 (kernel and kernel-rt ELS streams) are not affected because the vulnerable code is not present, while the vulnerable code is present in Red Hat Enterprise Linux 8, 9, and 10 (kernel and kernel-rt), Red Hat In-Vehicle OS, and Red Hat OpenShift versions that ship an affected kernel, and fixes are being pursued through the responsible engineering teams.
Меры по смягчению последствий
Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base, or stability.
Затронутые пакеты
| Платформа | Пакет | Состояние | Рекомендация | Релиз |
|---|---|---|---|---|
| Red Hat Enterprise Linux 6 | kernel | Not affected | ||
| Red Hat Enterprise Linux 7 | kernel | Not affected | ||
| Red Hat Enterprise Linux 7 | kernel-rt | Not affected | ||
| Red Hat Enterprise Linux 9 | kernel-rt | Affected | ||
| Red Hat OpenShift Container Platform 4 | openshift/ose-rhel-coreos-8 | Affected | ||
| Red Hat OpenShift Container Platform 4 | openshift/ose-rhel-coreos-9 | Affected | ||
| Red Hat OpenShift Container Platform 5 | openshift/ose-rhel-coreos-9 | Affected | ||
| Red Hat Enterprise Linux 10 | kernel | Fixed | RHSA-2026:91565 | 28.10.2026 |
| Red Hat Enterprise Linux 8 | kernel-rt | Fixed | RHSA-2026:87374 | 21.10.2026 |
| Red Hat Enterprise Linux 8 | kernel | Fixed | RHSA-2026:87375 | 21.10.2026 |
Показывать по
Дополнительная информация
Статус:
EPSS
7.8 High
CVSS3
Связанные уязвимости
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)...
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 "i
vfio/pci: clear vdev->msi_perm after freeing it on init failure
In the Linux kernel, the following vulnerability has been resolved: v ...
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 ...
EPSS
7.8 High
CVSS3