CVE-2026-62435
MediumCVSS 6.5Summary
When switching from Grant Table v1 to v2 in Xen, code holding the grant table lock but temporarily dropping and re-acquiring it wrongly assumes that table properties won't change during the window without the lock. This leads to a reduction in the number of valid grant references.
Risk Assessment
This could lead to incorrect management of grant references, potentially enabling privilege escalation or domain isolation breaches.
Recommendation
Apply the appropriate patch from the Xen vendor that addresses the grant table version switching issue.
Other vulnerabilities in Xen
See all- CVE-2026-62436Medium
When switching from Grant Table v2 to v1 in Xen, code holding the grant table lock but temporarily dropping and re-acquiring it wrongly assumes that table properties won't change during the window without the lock. This leads to issues with status frames that disappear when switching from v2 to v1.
- CVE-2026-62434Medium
A guest with Populated on Demand (PoD) enabled may attempt to reclaim pages that are not regular guest RAM. This can cause corruption of memory management state in Xen.
- CVE-2026-62432High
The EVTCHNOP_expand_array hypercall checks for FIFO event channels being enabled, but without holding the correct lock. It can race with EVTCHNOP_reset, resulting in dereferencing a NULL pointer.
- CVE-2026-62431High
The logic to handle periodic Viridian STIMERs performs a division with an unchecked user-controlled divisor value, that can be set to zero to cause a #DE fault.
- CVE-2026-62430High
Accesses to CMOS memory contents are done using an indirect IO port pair. Xen needs to cache the guest chosen index, and one of the usages of the index didn't take the necessary locking to avoid concurrent changes, allowing a guest to change the index after it being checked, causing an out-of-bound read access.
- CVE-2026-62429Medium
Accessing vNUMA configuration data of a guest is still possible when domain destruction has already started. The cleanup of that configuration information is not synchronized with its retrieval by a device model controlling the guest.
- CVE-2026-62428High
When grant-copy operations are processed, permission checks may be carried out on a page different from the one involved in the copy when the grant is already pinned, leading to inconsistency.
- CVE-2026-62427High
Platform-op operations use a system-wide lock, but the lock acquisition lacks fairness, and with XSM/Flask enabled, the lock is acquired before permission checks. This is the platform-op issue.
- CVE-2026-62426High
Sysctl operations use a system-wide lock, but the lock acquisition lacks fairness, and with XSM/Flask enabled, the lock is acquired before permission checks. This is the sysctl issue.
- CVE-2026-42493High
Addressing certain issues related to long-running operations has proven overly costly. Since alternatives (HVM/PVH: HAP, PV: shim) are commonly available, the decision was to deprecate the functionality, while still retaining it for use at own risk. Memory-wise small guests may still be okay to run.
Original NVD description (English source)
[This CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] With the introduction of Grant Table v2 came the requirement to be able to switch between versions. Switching from v1 to v2 reduces the number of valid grant references, as a bigger shared entry structure is then needed while the shared table doesn't change size. Switching from v2 back to v1 the status frames, which are separate in v2, go away. Code holding, but intermediately dropping and then re-acquiring the grant table lock, sometimes wrongly assumes that said properties wouldn't change across the window in time where the lock is not being held. The v1 -> v2 issue is CVE-2026-62435. The v2 -> v1 issue is CVE-2026-62436.