Re: Xen Security Advisory 476 v1 (CVE-2025-58149) - Incorrect removal of permissions on PCI device unplug

["Teddy Astie" <teddy.astie@xxxxxxxxxx>]

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