CVE-2021-28703

7.0 HIGH

📋 TL;DR

This Xen hypervisor vulnerability allows guest virtual machines to retain access to memory pages after they've been deallocated and potentially reused. When a guest switches from grant table v2 to v1, racing mapping requests can cause status pages to remain mapped in multiple locations, leading to use-after-free conditions. This affects Xen-based virtualization environments where guests can switch between grant table versions.

💻 Affected Systems

Products:
  • Xen Hypervisor
Versions: Versions before Xen 4.14 and security branches before the backport of XSA-378 fix
Operating Systems: Linux distributions running Xen (Gentoo, others)
Default Config Vulnerable: ⚠️ Yes
Notes: Only affects systems using Xen grant tables with v2 functionality. Requires guest VM to switch between grant table v2 and v1.

📦 What is this software?

⚠️ Risk & Real-World Impact

🔴

Worst Case

Guest VM could read sensitive data from reallocated memory pages, potentially accessing hypervisor memory, other VM data, or cryptographic keys, leading to complete guest escape and host compromise.

🟠

Likely Case

Guest VM gains unauthorized read access to memory that may contain sensitive information from other VMs or the hypervisor, potentially enabling information disclosure attacks.

🟢

If Mitigated

With proper network segmentation and minimal guest privileges, impact is limited to the affected guest VM with reduced risk of lateral movement.

🌐 Internet-Facing: MEDIUM - While the vulnerability requires guest VM access, internet-facing VMs could be compromised and used as a foothold to exploit this vulnerability.
🏢 Internal Only: HIGH - Internal virtualization environments with multiple VMs are at significant risk as compromised guests could exploit this to access other VMs or the hypervisor.

🎯 Exploit Status

Public PoC: ✅ No
Weaponized: UNKNOWN
Unauthenticated Exploit: ✅ No
Complexity: HIGH - Requires guest VM access and specific conditions with grant table switching

Exploitation requires race conditions during grant table version switching, making reliable exploitation challenging but possible for determined attackers.

🛠️ Fix & Mitigation

✅ Official Fix

Patch Version: Xen 4.14 and later, or security branches with XSA-378 backport

Vendor Advisory: https://xenbits.xenproject.org/xsa/advisory-387.txt

Restart Required: Yes

Instructions:

1. Update Xen hypervisor to version 4.14 or later. 2. For older branches, apply the security patch for XSA-378. 3. Reboot the hypervisor host. 4. Verify all guest VMs are using patched hypervisor.

🔧 Temporary Workarounds

Disable grant table v2

linux

Prevent guests from using grant table v2 to avoid the switching condition

xl set-parameters <domain-id> grant-table-version=1

Isolate vulnerable VMs

all

Network segment VMs that require grant table v2 functionality

🧯 If You Can't Patch

  • Isolate affected Xen hosts from critical networks and other virtualization infrastructure
  • Implement strict monitoring for unusual memory access patterns or guest VM behavior

🔍 How to Verify

Check if Vulnerable:

Check Xen version with 'xl info' or 'xm info' and verify if below 4.14 without XSA-378 patches

Check Version:

xl info | grep xen_version || xm info | grep xen_version

Verify Fix Applied:

Confirm Xen version is 4.14+ or check for XSA-378 patch in changelog: 'xen-changelog | grep XSA-378'

📡 Detection & Monitoring

Log Indicators:

  • Xen hypervisor logs showing grant table version switching
  • Unexpected memory access patterns in hypervisor monitoring

Network Indicators:

  • Unusual inter-VM communication patterns
  • Guest VMs accessing unexpected memory regions

SIEM Query:

source="xen.log" AND ("grant table" OR "v2" OR "XSA-387")

🔗 References

📤 Share & Export