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:
<TASK>
? 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
Security readout for executives and security teams
Plain-English summary
A Linux VFIO/PCI flaw can mishandle an unknown PCI Express capability when it appears first in a device’s capability list. Accessing that configuration through VFIO may trigger an out-of-bounds kernel memory access. Systems using PCI device passthrough for virtual machines are the clearest concern; ordinary Linux systems without VFIO/PCI use are less likely to encounter the vulnerable path.
Executive priority
Treat this as a high-priority infrastructure patch for virtualization hosts using PCI passthrough, especially where workloads are less trusted. Patch through normal emergency kernel maintenance after compatibility testing. Hosts without VFIO/PCI exposure can follow standard risk-based patching once configuration is verified.
Technical view
vfio_config_do_rw() used an insufficiently validated PCIe extended-capability ID to index the ecap_perms array. An ID above PCI_EXT_CAP_ID_MAX could therefore cause an out-of-bounds access when the first capability should be hidden. The upstream fix validates cap_id and uses alternative permission bits providing direct read-only access for this special case.
Likely exposure
Exposure is concentrated on Linux hosts using VFIO/PCI, commonly for direct PCI device assignment to virtual machines. The source lists numerous affected kernel versions, but does not provide sufficiently clear distribution-package boundaries. Confirm exposure using each Linux vendor’s advisory and backport status rather than relying only on upstream version numbers.
Exploitation context
The supplied CVSS 3.1 assessment is 7.8 and describes a local, low-privilege path with potential confidentiality, integrity, and availability impact. The bundle does not identify public exploitation, and the CVE is not listed as KEV. A kernel warning and out-of-bounds access are documented, but reliable security impact beyond that is not demonstrated here.
Researcher notes
CWE-129 fits the unchecked capability ID used as an array index. The trigger requires an unknown first-in-list PCIe extended capability exposed through the VFIO configuration-access path. The fix substitutes read-only permission metadata when cap_id exceeds PCI_EXT_CAP_ID_MAX. The provided evidence does not establish exploit reliability, affected hardware prevalence, or exact downstream package ranges.
Mitigation direction
Install a vendor-supported kernel containing the referenced VFIO/PCI fix or confirmed backport.
Check distribution security advisories for package-specific fixed versions and reboot requirements.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cwe · low confidence lookup
CWE-129: Exact CWE lookup
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
2CVSS vectors
3Timeline events
2ADP providers
12Source links
SSVC decision data
CISA-ADPCISA Coordinator
Timestamp
Version
2.0.3
Exploitation: noneAutomatable: noTechnical Impact: total
CVSS vector scores
2 official scores
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.
CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.
CWE-129 · source CWE mapping
Improper Validation of Array Index
Improper Validation of Array Index represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.