CVE-2026-31787

What it actually does

This is a Linux kernel memory-corruption flaw in the Xen privcmd driver. A local user with access to Xen privcmd mappings can partially unmap a privcmd-backed VMA, causing the kernel to split the VMA while copying the same vm_private_data pointer into both VMA objects. When each VMA is later closed, the same pages array can be unmapped and freed twice, creating a double-free condition in kernel memory. Depending on kernel configuration, allocator state, and exploit reliability, this can result in a kernel crash, denial of service, or potentially local privilege escalation through controlled kernel heap corruption.

Why it matters to the business

Systems running Linux kernels with Xen privcmd support are exposed to local compromise or outage if an attacker can run code with access to the Xen privcmd interface, which is most relevant to Xen hosts, dom0/toolstack environments, and privileged virtualization management components. A successful attack could disrupt virtualization services, crash a host, or potentially give an attacker elevated control over the host. The issue is not listed in CISA KEV, is not known to be used in ransomware campaigns, and has a low EPSS score with no observed 30-day increase, but the high technical severity means affected Xen infrastructure should still be patched during normal urgent kernel maintenance windows.

How an attack unfolds

An attacker first needs local execution on a system where the Xen privcmd driver is available and where the attacker can open and use the privcmd device. The attacker creates a Xen privcmd mapping that stores a pages array in the VMA private data. They then invoke a partial munmap operation against that mapping. Because the vulnerable kernel allows the VMA to be split and lacks an open callback to create independent private data for the new VMA, both the original and split VMAs point to the same pages array. When one portion is unmapped, privcmd_close releases Xen mappings, frees unpopulated pages, and frees the pages array. The remaining VMA still contains a dangling pointer. When it is later closed, the kernel repeats the same cleanup against already-freed memory, triggering a double free. A simple exploit may crash the kernel; a more advanced exploit would try to shape kernel heap allocations between the first and second free to gain code execution or privilege escalation.

How to fix it

Apply the vendor-provided Linux kernel update that includes the XSA-487 fix for the Xen privcmd driver. The corrected implementation adds a .may_split callback that denies splitting privcmd VMAs, preventing the duplicated vm_private_data pointer and double free. No exact fixed package versions were provided in the input, so use distribution security advisories for the deployed kernel stream and confirm that the kernel changelog references CVE-2026-31787, XSA-487, or the xen/privcmd VMA splitting fix. Reboot systems after installing the updated kernel so the fixed kernel is active. As interim mitigation, restrict access to the Xen privcmd device to only trusted administrative users and Xen management services, remove unnecessary users from groups that can access Xen control interfaces, and avoid running untrusted workloads or tooling in dom0 or privileged Xen management domains.

How to confirm the fix worked

Confirm exposure by checking whether the system runs an affected Linux kernel with Xen support and exposes the Xen privcmd interface. Verify remediation by confirming the running kernel, not only the installed package, is updated to a vendor build containing the XSA-487 fix. Review kernel package changelogs or vendor advisories for references to CVE-2026-31787, XSA-487, xen/privcmd, privcmd VMA splitting, or .may_split. Confirm /dev/xen/privcmd permissions are restricted to trusted users and services. If safe in a non-production test environment, attempt to reproduce the partial-munmap behavior against a privcmd mapping; a fixed kernel should deny the VMA split rather than allowing duplicated private data. Do not run exploit-style validation on production virtualization hosts.

Typical attack path

1. Gain local code execution on an affected Linux system running Xen privcmd support.
2. Confirm access to the Xen privcmd interface, commonly through /dev/xen/privcmd or equivalent Xen tooling access.
3. Create a privcmd-backed mapping that allocates and associates a pages array with the VMA.
4. Call partial munmap on the mapping to force the kernel to split the VMA.
5. Allow one split VMA to close, causing privcmd_close to unmap and free the shared pages array.
6. Manipulate timing or heap allocations while the surviving VMA retains a dangling pointer.
7. Close the remaining VMA to trigger the second free of the same memory.
8. Use the resulting kernel memory corruption to crash the host or attempt local privilege escalation.

How to detect it

There are no reliable network-only indicators for this vulnerability because exploitation is local and occurs inside the kernel memory manager. To assess possible prior exploitation, review kernel logs, crash dumps, audit logs, and endpoint telemetry from Xen hosts and privileged Xen management systems. Look for kernel warnings or panics involving double free, KASAN, SLUB allocator corruption, privcmd_close, xen_unmap_domain_gfn_range, xen_free_unpopulated_pages, __split_vma, or VMA/munmap activity around Xen privcmd mappings. Review auditd or EDR telemetry for unusual processes opening /dev/xen/privcmd, especially non-standard users or binaries outside expected Xen management tooling. Correlate suspicious privcmd access with immediate kernel crashes, host reboots, hypervisor management disruption, or core/vmcore creation. If crash dumps are available, inspect stack traces for the Xen privcmd cleanup path and memory allocator double-free diagnostics. Absence of these artifacts does not prove non-exploitation, because a successful privilege-escalation attempt may leave minimal logs unless it causes a crash.

• /dev/xen/privcmd
• /proc/xen/privcmd
• privcmd_close
• xen_unmap_domain_gfn_range
• xen_free_unpopulated_pages
• alloc_empty_pages
• __split_vma
• vm_area_dup
• KASAN: double-free
• KASAN: use-after-free
• double free
• kernel BUG at mm/slub.c
• BUG: unable to handle kernel paging request
• general protection fault
• slab: double free detected
• XSA-487
• CVE-2026-31787

What your security team should do

• Inventory Linux systems that run Xen, especially dom0, Xen toolstack hosts, and privileged management domains.
• Prioritize kernel updates on systems exposing /dev/xen/privcmd or equivalent Xen privcmd interfaces.
• Reboot after patching and verify the active running kernel contains the vendor fix for XSA-487.
• Restrict privcmd device access to trusted administrative accounts and required Xen services only.
• Audit local users, service accounts, and automation with permission to access Xen control devices.
• Monitor kernel logs for double-free, KASAN, SLUB, or privcmd-related crashes until patching is complete.
• Treat unexpected crashes on Xen hosts as potentially security relevant and preserve kernel logs, crash dumps, and audit logs for investigation.
• Because the issue is local and currently has low EPSS, prioritize based on Xen host criticality and local access risk rather than internet exposure alone.