CVE-2025-58149 Overview
CVE-2025-58149 is a high-severity vulnerability in the Xen hypervisor affecting PCI device passthrough functionality. When passing through PCI devices, the detach logic in libxl fails to remove access permissions to any 64-bit memory Base Address Registers (BARs) the device might have. As a result, a domain can retain access to any 64-bit memory BAR even when such a device is no longer assigned to the domain.
This vulnerability represents an "Operation on a Resource after Expiration or Release" flaw (CWE-672), where the improper cleanup of device permissions creates a window for unauthorized memory access. For PV (paravirtualized) domains, the permission leak allows the domain itself to map the memory in the page-tables. For HVM (hardware virtual machine) domains, exploitation would require a compromised device model or stubdomain to map the leaked memory into the HVM domain's p2m (physical-to-machine) mapping.
Critical Impact
A malicious or compromised guest domain can potentially read sensitive memory regions belonging to other domains or the hypervisor itself after PCI device detachment, leading to information disclosure across virtualization boundaries.
Affected Products
- Xen Hypervisor (all versions with PCI passthrough support)
- Systems using libxl for domain management
- Environments with 64-bit PCI devices utilizing memory BARs
Discovery Timeline
- 2025-10-24 - Security advisory disclosed via Openwall OSS-Security Mailing List
- 2025-10-31 - CVE-2025-58149 published to NVD
- 2026-01-14 - Last updated in NVD database
Technical Details for CVE-2025-58149
Vulnerability Analysis
The vulnerability exists in the libxl library's PCI device detachment logic. When a PCI device is passed through to a guest domain and subsequently detached, the cleanup routine fails to properly revoke access permissions for 64-bit memory BARs associated with the device.
PCI devices can have multiple Base Address Registers that define memory-mapped I/O regions. For 64-bit memory BARs, the address spans two consecutive 32-bit BAR registers. The detach logic in libxl appears to correctly handle 32-bit BARs but overlooks the extended address space used by 64-bit BARs, leaving residual permissions in place after device detachment.
The impact differs based on the domain type:
- PV Domains: The leaked permissions allow the guest domain to directly map the memory regions into its own page tables, enabling direct access to potentially sensitive memory.
- HVM Domains: Exploitation requires an additional attack vector—a compromised device model (QEMU) or stubdomain that can leverage the leaked permissions to map memory into the HVM domain's p2m mappings.
Root Cause
The root cause is an incomplete permission revocation in the libxl PCI device detachment code path. When iterating through device BARs during cleanup, the code fails to account for 64-bit memory BARs that span two consecutive BAR registers. This results in the access control entries for these memory regions not being removed from the domain's I/O Memory Management Unit (IOMMU) mappings.
Attack Vector
An attacker with control over a guest domain could exploit this vulnerability through the following sequence:
- Request a PCI device with 64-bit memory BARs to be passed through to their domain
- Note the memory addresses of the 64-bit BARs
- Trigger or wait for the device to be detached from the domain
- Attempt to map the previously accessible 64-bit BAR memory regions
- Read data from these memory regions that may now be assigned to other domains or contain sensitive hypervisor data
For PV domains, steps 4-5 can be performed directly. For HVM domains, the attacker would need to first compromise the device model or stubdomain to perform the memory mapping.
The attack is network-accessible as the vulnerability can be exploited remotely if the attacker has the ability to control a guest domain, which is common in cloud and multi-tenant virtualization environments.
Detection Methods for CVE-2025-58149
Indicators of Compromise
- Unexpected memory access patterns from guest domains after PCI device detachment
- Guest domains accessing memory regions outside their assigned physical address ranges
- IOMMU violations or faults that indicate out-of-bounds memory access attempts
- Anomalous device model (QEMU) behavior in HVM environments
Detection Strategies
- Monitor Xen hypervisor logs for IOMMU-related errors or permission violations
- Implement memory access auditing at the hypervisor level for PCI passthrough scenarios
- Track PCI device attachment/detachment events and correlate with subsequent memory access patterns
- Deploy integrity monitoring on device models and stubdomains
Monitoring Recommendations
- Enable verbose logging for libxl PCI operations to track device attachment and detachment events
- Configure IOMMU to log all access violations rather than silently blocking
- Implement alerting on unusual guest domain memory access patterns post-device detachment
- Review Xen security advisories regularly for updated patches and mitigations
How to Mitigate CVE-2025-58149
Immediate Actions Required
- Review the Xen Project Security Advisory 476 for specific patch information
- Identify all systems using Xen with PCI passthrough functionality
- Prioritize patching systems in multi-tenant or cloud environments where domain isolation is critical
- Temporarily disable PCI passthrough for untrusted domains until patches are applied
Patch Information
The Xen Project has released patches addressing this vulnerability as documented in XSA-476. Administrators should consult the Xen Project Security Advisory 476 for the specific patches applicable to their Xen version. The patches correct the libxl detach logic to properly enumerate and revoke permissions for 64-bit memory BARs during PCI device detachment.
Apply the official patches from the Xen Project by following these steps:
- Download the appropriate patch for your Xen version from the advisory
- Apply the patch to your Xen source tree
- Rebuild and reinstall the Xen toolstack (libxl)
- Restart the Xen daemon to load the updated library
Workarounds
- Avoid using PCI passthrough with devices that have 64-bit memory BARs until patches are applied
- Restrict PCI device assignment to trusted domains only
- Implement additional monitoring for memory access patterns in environments where patching is delayed
- Consider using SR-IOV virtual functions instead of full PCI passthrough where possible, as they may have different memory mapping characteristics
# Check for PCI devices with 64-bit BARs before passthrough
lspci -vv | grep -A 20 "Memory at" | grep "64-bit"
# Monitor Xen domain memory mappings
xl debug-keys i
# Check /var/log/xen/xen-hotplug.log for device events
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.


