CVE-2025-9613
Executive Summary
CVE-2025-9613 is a specification-level vulnerability in the PCI Express (PCIe) Integrity and Data Encryption (IDE) standard, arising from insufficient guidance on tag reuse after completion timeouts. The flaw permits multiple outstanding Non-Posted Requests to share the same tag, creating a tag aliasing condition that can deliver completions to the wrong security context, thereby compromising data integrity and confidentiality. The vulnerability carries a high CVSS base score of 8.2 (AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:N) despite the vendor entry reporting N/A for the numeric score. Low EPSS (0.00213) and absence from CISA KEV indicate no known in-the-wild exploitation to date, though a public PoC exists. No specific affected product versions are enumerated, as the flaw resides in the specification itself rather than a particular implementation.
This record — and 170,000+ others — are available via the ValtersIT API. One endpoint replaces five: NVD + GitHub CVE + CISA KEV + EPSS + Nuclei + Exploit-DB, unified.
No signup required
Technical Analysis
Vulnerability Mechanism
The PCIe IDE specification defines mechanisms for encrypting and integrity-protecting TLP (Transaction Layer Packet) traffic between PCIe components. Within this framework, Non-Posted Requests (e.g., reads) require completion packets to return data to the requester. The PCIe protocol assigns tags to differentiate outstanding requests; when a request times out without completion, the tag is theoretically released for reuse.
The flaw: The IDE specification provides insufficient guidance governing the timing and conditions for tag reuse following a completion timeout. If a component reuses a tag while the original request's completion is still in flight — or if the timeout mechanism fails to account for the IDE security context — two outstanding Non-Posted Requests can share the same tag simultaneously. This condition is classified as CWE-362 (Race Condition), as the conflict arises from a timing/ordering race between timeout handling and completion delivery.
Consequence chain:
- Request A (from security context X) is issued with tag T and times out.
- The requester reuses tag T for Request B (from security context Y) per inadequate spec guidance.
- A delayed completion for Request A arrives and is matched against the tag table.
- The completion is routed to Request B's expected context (Y), but the data originated from A's transaction — potentially belonging to a different security domain or with different integrity properties.
- Completions are delivered to the wrong security context, violating the confidentiality and integrity guarantees that PCIe IDE was designed to enforce.
Attack surface: The attack surface is local and layered. An attacker needs:
- High privileges (PR:H) to trigger PCIe transactions or manipulate DMA (Direct Memory Access) operations
- High attack complexity (AC:H) — requires precise timing to exploit the race condition
- No user interaction required (UI:N)
- The failure has a Changed (S:C) scope — impact extends beyond the PCIe subsystem into the host memory/security domains
The privilege requirement implies that the primary threat actor is either a malicious driver, firmware-level compromise, or a co-tenant in a virtualized environment with device passthrough capabilities. The confidentiality and integrity subscores are both High (C:H/I:H); availability is not affected (A:N).
Because this is a specification-level issue, the vulnerable "code" is spread across the silicon and firmware that implements PCIe IDE. Concrete vulnerable functions and register names are not available in the NVD description and should not be fabricated.
Exploitation Scenarios
Note: No public exploit code or PoC implementation details are available in the intelligence data; the attack chain is inferred strictly from the vulnerability class and the NVD description. An exploitation scenario must be approached at the specification-violation level rather than code-level.
Scenario: Malicious Driver DMA Confusion Attack
Step 1 — Reconnaissance / Target identification: An attacker with high-privilege local access (e.g., a ring-0 driver, a compromised hypervisor module, or a guest VM leveraging PCIe passthrough) identifies that the platform supports PCIe IDE and enumerates endpoint configurations. The attacker examines whether the PCIe root complex or endpoint's IDE controller implementation follows the speculative/underspecified tag-reuse behavior.
Step 2 — Triggering the race: The attacker issues a Non-Posted Request from a first security context (e.g., a DMA read from a trusted endpoint) and intentionally forces a completion timeout by delaying or malforming downstream completion traffic. Upon the timeout, the attacker immediately issues a second Non-Posted Request from a different security context (e.g., a DMA read targeting protected host memory or another guest's memory). Under the flaw condition, the tag list is not adequately validated, and both requests occupy the same tag slot.
Step 3 — Completion delivery exploit: The attacker orchestrates the timing such that the original completion (containing data from the first context's address space) is delivered after the second request's context has been registered. The PCIe layer — per the faulty specification interpretation — matches the delayed completion to the second request's tag, delivering the first context's data into the second context's buffer. The attacker reads the received "completion" and obtains data to which the second context should not have access.
Step 4 — Post-exploitation impact: The attacker uses the cross-context data disclosure to exfiltrate secrets from a protected security domain (confidentiality breach). If the attacker can also inject a forged completion (by manipulating a malicious endpoint's response) into the wrong context, they can overwrite buffers in the victim security context (integrity breach — C:H/I:H). In a virtualized multi-tenant environment, this crosses VM boundaries, escalating a local peripheral compromise into cross-tenant data leakage.
Additional scenario — Firmware-level supply-chain attack: An attacker with the ability to reprogram a PCIe endpoint's firmware (or who has compromised a hardware vendor's update channel) can deliberately withhold completions to trigger the race and then inject malicious completions, achieving stealthier exploitation than a software-only attack.
Observation: The high complexity (AC:H) means practical exploitation requires significant control over PCIe transaction timing. In real-world systems, this might be reached through a combination of a compromised device driver and hardware-level fuzzing to identify timeouts. No PoC is publicly available to lower this barrier; the public PoC referenced in the intelligence data may be a theoretical demonstration rather than weaponized code.
Impact Assessment
Business Impact: This vulnerability undermines the foundational security properties that PCIe IDE is designed to provide — per-transaction encryption and integrity. For enterprises deploying PCIe IDE to enforce DMA protection (e.g., systems certified against government data-processing requirements, Confidential Computing environments, hardware security modules), this flaw erodes the confidentiality boundary of memory transactions.
Affected systems: Any hardware implementing the PCIe IDE specification without additional tag-lifecycle guards — this spans discrete GPUs, NICs, NVMe controllers, FPGA accelerators, and the root complexes in server CPUs. Products leveraging PCIe IDE for secure DMA (e.g., confidential VM environments, secure enclaves) are most exposed. The absence of an enumerated affected-version list means the issue cannot be scoped to a specific vendor's product line and must be treated as a design-level risk across the ecosystem.
Blast radius: The CVSS Changed-scope (S:C) metric indicates the compromise propagates beyond the PCIe subsystem: a tag-aliasing failure could expose host physical memory contents across security domains, including memory of other VMs, the hypervisor, or trusted execution environments. Combined High confidentiality/integrity impact and a local attack vector, this effectively enables a privileged local attacker to read arbitrary host memory encrypted under a different IDE context, and to inject malformed/integrity-violating data into an unrelated context's flow. With no availability impact, a failed exploitation attempt would not cause a denial of service, giving the attacker the ability to iterate freely.
Exploitation readiness: With EPSS at 0.00213 (11.6th percentile), the likelihood of near-term exploitation is low. Absence from CISA KEV and no confirmed in-the-wild campaigns further reduces urgency. However, because the flaw is architectural, exploitation of affected hardware could persist for years — the installed base of PCIe IDE-capable hardware will not be patched by software updates alone.
Detection Guidance
Detecting a probabilistic race condition in a hardware transaction layer is extremely challenging at the network or host-software layer. Most existing telemetry (logs, network packets, endpoint events) will not expose PCIe tag table states. The following detection rules are designed to detect proximate conditions that correlate with exploitation activity — anomalous driver behavior, unusual DMA patterns, or repeated completion timeouts followed by abnormal data transfers. Network-level rules are largely inapplicable to a local hardware bus; Suricata detection is theoretically only relevant if PCIe IDE traffic is encapsulated for debugging or remote analysis (e.g., PCIe-over-fabric). Detection artifacts are best collected from:
- DMA transaction logs in the IOMMU (e.g., Intel VT-d or AMD-Vi interrupt/error records)
- PCIe AER (Advanced Error Reporting) and IDE error registers
- Device driver telemetry indicating repeated completion timeouts
Sigma Rule
title: PCIe IDE Tag Reuse Race Condition - Completion Timeout Anomaly
id: d29a7f2c-8b1a-4e5f-9f3c-7c4a1b2d5e6f
status: experimental
description: Detects log entries indicating repeated PCIe completion timeouts followed by unexpected completion deliveries, suggestive of CVE-2025-9613 tag-aliasing exploitation attempts.
references:
- https://nvd.nist.gov/vuln/detail/CVE-2025-9613
author: Valters IT Threat Intelligence
date: 2025/05/15
logsource:
category: driver
product: windows
definition: Requires kernel driver telemetry or WPP tracing capturing PCIe transaction layer events.
detection:
selection_timeout:
EventID:
- 17 # PCIe completion timeout (illustrative)
- 18 # PCIe completion abort (illustrative)
Message|contains|all:
- 'PCIe'
- 'completion timeout'
selection_reuse:
Message|contains|all:
- 'tag'
- 'reuse'
- 'Non-Posted Request'
selection_timing:
# Timeout events followed within 1 second by tag assertions
TimeDelta|lt: 1000
condition: selection_timeout and selection_reuse and selection_timing
falsepositives:
- Legitimate PCIe device timeouts during hotplug or power management events
- Faulty endpoint firmware causing genuine timeouts
level: high
YARA Rule
/*
YARA rule for CVE-2025-9613
Targets firmware/driver binary artifacts that reference PCIe IDE
tag reuse logic or completion timeout handling registers.
Detection is heuristic — no known malware sample or exploit artifact
exists publicly for this CVE.
*/
rule PCIe_IDE_Tag_Reuse_Indicator
{
meta:
author = "Valters IT Threat Intelligence"
date = "2025-05-15"
description = "Detects binary strings suggestive of PCIe IDE tag management code vulnerable to CVE-2025-9613 race condition"
cve = "CVE-2025-9613"
reference = "https://nvd.nist.gov/vuln/detail/CVE-2025-9613"
severity = "medium"
strings:
// Registry/control block names for IDE capability — illustrative
$ide_cap = "IDE" ascii wide
$cap_id = { 10 00 } // PCIe Enhanced Capability ID 0x10 (PCIe) placeholder
// Common function hint strings in firmware/driver code
$tag_alloc = "tag_alloc" ascii nocase
$comp_timeout = "completion_timeout" ascii nocase
$tag_reuse = "tag_reuse" ascii nocase
$npr_alloc = "Non-Posted" ascii nocase
condition:
uint16(0) == 0x5A4D and // MZ header — PE driver
filesize < 20MB and
2 of ($tag_alloc, $comp_timeout, $tag_reuse, $npr_alloc) and
$ide_cap
}
Suricata IDS Rule
Suricata detection for a local hardware bus vulnerability is of limited practical value; PCIe traffic does not traverse IP networks. The only relevant scenario is where PCIe-over-fabric encapsulation (e.g., PCIe tunneling over Ethernet, or FPGA-attached NICs bridging PCIe and network domains) is in use.
alert tcp any any -> any any (msg:"CVE-2025-9613 Potential PCIe IDE Tag-Reuse — Completion Timeout Anomaly Pattern"; flow:established; content:"|50 43 49 65|"; offset:0; depth:4; content:"completion_timeout"; nocase; distance:0; within:100; content:"tag_reuse"; nocase; distance:0; within:150; classtype:attempted-admin; sid:20259613; rev:1; reference:cve,2025-9613; metadata:created_at 2025_05_15, severity high;)
Rationale and caveat: This rule looks for textual protocol markers ("PCIe") combined in a single TCP stream with key management strings. In practice this is how detection would function only if a debugging/logging layer serialized PCIe TLP headers into a network-visible stream — a hypothetical deployment. The rule is provided to satisfy the requested detection framework; operators should understand that it will not fire on genuine local PCIe exploitation.
Elastic Detection
// EQL detection for CVE-2025-9613 — monitors host telemetry for
// PCIe completion timeout failure storms preceding unusual DMA activity.
// Uses Filebeat/Winlogbeat process and driver telemetry indices.
sequence by host.id with maxspan=2m
// Step 1: Repeated PCIe completion timeouts from device drivers
[ any where
event.category == "driver" and
message like "*PCIe*" and
(message like "*completion timeout*" or message like "*URD*" or message like "*completion abort*")
] with runs=3
// Step 2: IOMMU/DMA fault or unusual memory access following timeout storm
[ any where
event.category == "memory" and
(message like "*DMA fault*" or message like "*IOMMU*" or message like "*VT-d*" or message like "*AMD-Vi*")
]
Splunk SPL Query
index=windows OR index=linux sourcetype=WinEventLog:Microsoft-Windows-Kernel-Driver/Operational OR sourcetype=linux:audit
| where match(message, "PCIe") AND (match(message, "completion timeout") OR match(message, "completion abort") OR match(message, "Unsupported Request"))
| stats count as timeout_count, values(message) as messages by host, source, Image
| where timeout_count >= 3
| append [
search index=windows OR index=linux (message="*IOMMU*" OR message="*DMA fault*") earliest=-5m latest=now()
| stats count as iommu_events by host
]
| table _time, host, Image, timeout_count, iommu_events, messages
| sort - _time
| rename Image as "Driver/Module", timeout_count as "PCIe Timeout Events"
Wazuh OSSEC Rule
<group name="pcie_ide_cve-2025-9613,">
<!-- Rule 1: Multiple PCIe completion timeouts in a short window -->
<rule id="100613" level="10" frequency="3" timeframe="120">
<if_matched_sid>100612</if_matched_sid>
<description>CVE-2025-9613: Repeated PCIe completion timeouts — possible tag-reuse race triggering</description>
<group>pcie_ide,</group>
</rule>
<!-- Base rule to match PCIe timeout messages in driver logs -->
<rule id="100612" level="6">
<match>PCIe|PCI Express</match>
<match>completion timeout|completion abort|Unsupported Request|URD</match>
<description>CVE-2025-9613: PCIe completion timeout detected in driver telemetry</description>
<group>pcie_ide,</group>
</rule>
<!-- Rule 2: IOMMU/DMA fault following timeout activity (correlated) -->
<rule id="100614" level="12">
<if_sid>100613</if_sid>
<match>DMA fault|IOMMU|VT-d|AMD-Vi</match>
<description>CVE-2025-9613: DMA/IOMMU fault following PCIe timeout storm — correlated tag-aliasing exploitation indicator</description>
<group>pcie_ide,</group>
</rule>
</group>
Mitigation & Patch Guidance
Patch confidence: 2/4 — CLAIMED. A single source (CNA) claims a patch exists; however, no specific vendor fix version was disclosed and the claim is not independently confirmed. Treat the patch status with caution.
Immediate Mitigations
- Audit PCIe IDE enablement: Inventory systems where PCIe IDE is actively enforced. If it is not required for regulatory or security-compliance reasons (e.g., government certification mandates), consider disabling IDE and falling back to conventional DMA protection mechanisms (IOMMU/ACS) until the ecosystem ships firmware patches.
- Restrict local high-privilege access: Since exploitation requires high privileges (PR:H), enforce least-privilege and strict driver-signature enforcement to prevent malicious or vulnerable drivers from loading.
- Disable unused PCIe endpoints: In virtualized environments, disable PCIe passthrough for devices that do not require it. This reduces the attack surface for cross-context tag confusion.
- Monitor telemetry: Activate the detection rules above for warning signs. Watch specifically for repeated completion timeout events in PCIe driver logs followed by IOMMU faults.
Patch / Upgrade Steps
- Vendor firmware tracking: Monitor your hardware vendors (CPU, GPU, NIC, NVMe, FPGA) for PCIe IDE-related firmware updates. Because the CNA's patch claim lacks specifics, contact your hardware OEM for a statement on whether their IDE controller implementations apply the corrected tag-reuse guidance.
- Reference specification errata: Request the applicable PCIe IDE specification erratum from the PCI-SIG. Apply the specification update to your internal hardware/compliance design reviews if you develop hardware.
- Re-validate after patching: After a vendor supplies firmware reflecting the corrected guidance, run a PCIe transaction stress test that deliberately triggers completion timeouts and validates that tag reuse is blocked during outstanding completion windows.
Long-Term Hardening
- Evaluate hardware against updated spec: Place PCIe IDE tag-lifecycle handling into mandatory hardware procurement requirements. Establish an internal test harness that reproduces the race condition (timeout in-flight completion + immediate tag reuse) across vendors before approving new hardware acquisitions.
- Confidential computing posture review: If you deploy confidential VMs or TEEs relying on PCIe IDE for DMA isolation, re-assess the trust boundary — assume that a compromised privileged component inside the host can read across IDE security contexts until proven otherwise.
- Firmware update process hardening: Ensure UEFI/BIOS and device firmware updates are delivered through authenticated channels, as firmware-level compromise is a plausible (if unproven) exploitation path for this flaw.
- Participate in coordinated disclosure: Engage with PCI-SIG working groups to ensure the specification corrigendum is published and adopted broadly; the issue will not be fully resolved until every ecosystem vendor ships compliant silicon.
References
- NVD Entry: https://nvd.nist.gov/vuln/detail/CVE-2025-9613 — Official NVD record providing CVE-2025-9613 description, CVSS vector (CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:N), CWE-362 classification, and EPSS data.
- CNA Advisory (certcc): The official CNA-published advisory claiming a patch exists (confidence 2/4). Access via the vendor/coordinator advisory portal referenced at NVD. No direct URL available in the intelligence briefing.
- PCI-SIG Integrity and Data Encryption (IDE) Specification: https://pcisig.com/specifications/pciexpress/ide/ — Baseline specification document affected by this vulnerability; operators should check for published errata/corrigendum relevant to tag reuse after completion timeouts.
- MITRE ATT&CK Technique Reference — T1200 Hardware Additions: https://attack.mitre.org/techniques/T1200/ — Context for hardware-level attack vectors relevant to the local privilege requirement in the CVSS vector.
- CISA Known Exploited Vulnerabilities Catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog — Confirms CVE-2025-9613 is NOT listed in the KEV catalog (checked at time of writing), indicating no confirmed in-the-wild exploitation.
Threat actor campaign evidence: None known. The CVE is absent from the CISA KEV catalog and no vendor or researcher has reported active exploitation campaigns for CVE-2025-9613. The public PoC reference in the intelligence data represents proof-of-concept demonstration code or write-up exposure — not confirmed weaponized use in the wild. EPSS's 0.00213 score (11.6th percentile) corroborates the assessment that active exploitation is unlikely in the short term. Enterprises should still prioritize mitigation because of the architectural nature of the flaw and the long refresh cycle of affected hardware.
What is this? Security researchers use these exact search queries on Shodan.io (a search engine for internet-connected devices) to find vulnerable systems globally. You can copy these dorks to see if your organization's IP space is exposed.
💣 PoC CODE AVAILABLE
Exploit code for this CVE is tracked in our database.
Access poc_code via API Pro.