Skip to main content

VSA-2026-037: Unconditionally do TLB flushing ahead of page scrubbing (CVE-2026-79603 / XSA-511)

PublishedUpdatedSeverityCVSS 4.0Affected products
2026-09-082026-09-08⚪ N/ANot available yet- None
info

A vulnerability in the Xen hypervisor's page scrubbing path has been discovered. For Vates products, we are not affected, as only an untrusted x86 PV guest can leverage the vulnerability. For details on how we assign severity levels, see our Severity Levels Explained page.

Summary

x86 PV guests can free memory pages while still keeping a stale TLB entry pointing to them. A TLB flush is only issued by Xen (if needed) when the page is re-used. Since it's possible for the page to be scrubbed ahead of the TLB flush, there's a window where a PV guest can modify an already scrubbed page.

Deployments using xsm=silo scrub-domheap with the aim of not allowing the exchange of information amongst guests are not effective in the presence of PV guests.

Impact

No impact.

On XCP-ng 8.3, pure PV guests are not supported. The PV-in-PVH (PV-shim) mode runs as PVH from the hypervisor's standpoint and cannot exploit this issue.

Status

  • 2026-09-08: In Progress

Affected Versions

  • XCP-ng 8.3: Not affected.

Mitigation

There is no known mitigation.

Resolution

As of 2026-09-08, the xen-* packages for XCP-ng 8.3 do not include the fix for this issue; it will be added later to stay aligned with upstream.

Credits

This issue was discovered by Roger Pau Monné of AMD.

References