Executive Summary



This vulnerability is currently undergoing analysis and not all information is available. Please check back soon to view the completed vulnerability summary
Informations
Name CVE-2024-53214 First vendor Publication 2024-12-27
Vendor Cve Last vendor Modification 2024-12-27

Security-Database Scoring CVSS v3

Cvss vector : N/A
Overall CVSS Score NA
Base Score NA Environmental Score NA
impact SubScore NA Temporal Score NA
Exploitabality Sub Score NA
 
Calculate full CVSS 3.0 Vectors scores

Security-Database Scoring CVSS v2

Cvss vector :
Cvss Base Score N/A Attack Range N/A
Cvss Impact Score N/A Attack Complexity N/A
Cvss Expoit Score N/A Authentication N/A
Calculate full CVSS 2.0 Vectors scores

Detail

In the Linux kernel, the following vulnerability has been resolved:

vfio/pci: Properly hide first-in-list PCIe extended capability

There are cases where a PCIe extended capability should be hidden from the user. For example, an unknown capability (i.e., capability with ID greater than PCI_EXT_CAP_ID_MAX) or a capability that is intentionally chosen to be hidden from the user.

Hiding a capability is done by virtualizing and modifying the 'Next Capability Offset' field of the previous capability so it points to the capability after the one that should be hidden.

The special case where the first capability in the list should be hidden is handled differently because there is no previous capability that can be modified. In this case, the capability ID and version are zeroed while leaving the next pointer intact. This hides the capability and leaves an anchor for the rest of the capability list.

However, today, hiding the first capability in the list is not done properly if the capability is unknown, as struct vfio_pci_core_device->pci_config_map is set to the capability ID during initialization but the capability ID is not properly checked later when used in vfio_config_do_rw(). This leads to the following warning [1] and to an out-of-bounds access to ecap_perms array.

Fix it by checking cap_id in vfio_config_do_rw(), and if it is greater than PCI_EXT_CAP_ID_MAX, use an alternative struct perm_bits for direct read only access instead of the ecap_perms array.

Note that this is safe since the above is the only case where cap_id can exceed PCI_EXT_CAP_ID_MAX (except for the special capabilities, which are already checked before).

[1]

WARNING: CPU: 118 PID: 5329 at drivers/vfio/pci/vfio_pci_config.c:1900 vfio_pci_config_rw+0x395/0x430 [vfio_pci_core] CPU: 118 UID: 0 PID: 5329 Comm: simx-qemu-syste Not tainted 6.12.0+ #1 (snip) Call Trace:

? show_regs+0x69/0x80
? __warn+0x8d/0x140
? vfio_pci_config_rw+0x395/0x430 [vfio_pci_core]
? report_bug+0x18f/0x1a0
? handle_bug+0x63/0xa0
? exc_invalid_op+0x19/0x70
? asm_exc_invalid_op+0x1b/0x20
? vfio_pci_config_rw+0x395/0x430 [vfio_pci_core]
? vfio_pci_config_rw+0x244/0x430 [vfio_pci_core]
vfio_pci_rw+0x101/0x1b0 [vfio_pci_core]
vfio_pci_core_read+0x1d/0x30 [vfio_pci_core]
vfio_device_fops_read+0x27/0x40 [vfio]
vfs_read+0xbd/0x340
? vfio_device_fops_unl_ioctl+0xbb/0x740 [vfio]
? __rseq_handle_notify_resume+0xa4/0x4b0
__x64_sys_pread64+0x96/0xc0
x64_sys_call+0x1c3d/0x20d0
do_syscall_64+0x4d/0x120
entry_SYSCALL_64_after_hwframe+0x76/0x7e

Original Source

Url : http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-53214

Sources (Detail)

https://git.kernel.org/stable/c/06f2fcf49854ad05a09d09e0dbee6544fff04695
https://git.kernel.org/stable/c/0918f5643fc6c3f7801f4a22397d2cc09ba99207
https://git.kernel.org/stable/c/1ef195178fb552478eb2587df4ad3be14ef76507
https://git.kernel.org/stable/c/4464e5aa3aa4574063640f1082f7d7e323af8eb4
https://git.kernel.org/stable/c/6c6502d944168cbd7e03a4a08ad6488f78d73485
https://git.kernel.org/stable/c/7d121f66b67921fb3b95e0ea9856bfba53733e91
https://git.kernel.org/stable/c/949bee8065a85a5c6607c624dc05b5bc17119699
https://git.kernel.org/stable/c/9567bd34aa3b986736c290c5bcba47e0182ac47a
https://git.kernel.org/stable/c/fe4bf8d0b6716a423b16495d55b35d3fe515905d
Source Url

Alert History

If you want to see full details history, please login or register.
0
Date Informations
2024-12-27 17:20:28
  • First insertion