Le 24/10/2025 à 14:14, Xen.org security team a écrit : > Xen Security Advisory CVE-2025-58149 / XSA-476 > > Incorrect removal of permissions on PCI device unplug > > ISSUE DESCRIPTION > ================= > > When passing through PCI devices, the detach logic in libxl won't remove > access permissions to any 64bit memory BARs the device might have. As a > result a domain can still have access any 64bit memory BAR when such > device is no longer assigned to the domain. >
It it exclusive to devices where bar is above 32-bits (which requires things like Above 4G Decoding / Resizable BAR) or all devices are affected ? > For PV domains the permission leak allows the domain itself to map the memory > in the page-tables. For HVM it would require a compromised device model or > stubdomain to map the leaked memory into the HVM domain p2m. > Do HVM guests actually needs the device model to perform this ? > IMPACT > ====== > > A buggy or malicious PV guest can access memory of PCI devices no longer > assigned to it. > > VULNERABLE SYSTEMS > ================== > > Xen versions 4.0 and newer are vulnerable. > > Only PV guests with PCI passthrough devices can leverage the vulnerability. > > Only domains whose PCI devices are managed by the libxl library are affected. > This includes the xl toolstack and xapi, which uses the xl toolstack when > dealing with PCI devices. > XAPI doesn't appears to have PCI hotplug facilities, so shouldn't be able to trigger this vulnerability. Unless I missed something. > HVM guests are also affected, but accessing the leaked memory requires an > additional compromised component on the system. > > MITIGATION > ========== > > Not doing hot unplug of PCI devices will avoid the vulnerability. > > Passing through PCI devices to HVM domains only will also limit the impact, as > an attacker would require another compromised component to exploit it. > > CREDITS > ======= > > This issue was discovered by Jiqian Chen of AMD and diagnosed as a > security issue by Roger Pau Monné of XenServer. > > RESOLUTION > ========== > > Applying the attached patch resolves this issue. > > Note that patches for released versions are generally prepared to > apply to the stable branches, and may not apply cleanly to the most > recent release tarball. Downstreams are encouraged to update to the > tip of the stable branch before applying these patches. > > xsa476.patch xen-unstable > xsa476-4.20.patch Xen 4.20.x - Xen 4.18.x > xsa476-4.17.patch Xen 4.17.x > > $ sha256sum xsa476* > ee4c2fa73d38c5c699006b6317ba53f20343af0593ff9a8c38e7e59b69a0beca xsa476.patch > 3b921545f023dc7d9d943d0d661e677711458a917630de14f0871b03db0f2148 > xsa476-4.17.patch > 5babfaa3680de9950d3391a78e4956b5c18d54eaac9938c6cde2433a2ad3f27d > xsa476-4.20.patch > $ > > NOTE REGARDING LACK OF EMBARGO > ============================== > > This issue was discussed in public already. -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech
