Skip to main content

Linux Kernel CVE-2026-31787

| EUVDEUVD-2026-26365 HIGH
Double Free (CWE-415)
2026-04-30 Linux
7.8
CVSS 3.1 · NVD
Share

Severity by source

NVD PRIMARY
7.8 HIGH
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
SUSE
HIGH
qualitative
Red Hat
7.3 MEDIUM
qualitative

Primary rating from NVD.

CVSS VectorNVD

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

Lifecycle Timeline

7
Analysis Generated
May 06, 2026 - 22:01 vuln.today
CVSS changed
May 06, 2026 - 19:52 NVD
7.8 (HIGH)
Patch released
May 04, 2026 - 09:16 nvd
Patch available
Patch available
Apr 30, 2026 - 12:01 EUVD
EUVD ID Assigned
Apr 30, 2026 - 11:15 euvd
EUVD-2026-26365
CVE Published
Apr 30, 2026 - 10:31 nvd
N/A
CVE Published
Apr 30, 2026 - 10:31 nvd
HIGH 7.8

DescriptionCVE.org

In the Linux kernel, the following vulnerability has been resolved:

xen/privcmd: fix double free via VMA splitting

privcmd_vm_ops defines .close (privcmd_close), but neither .may_split nor .open. When userspace does a partial munmap() on a privcmd mapping, the kernel splits the VMA via __split_vma(). Since may_split is NULL, the split is allowed. vm_area_dup() copies vm_private_data (a pages array allocated in alloc_empty_pages()) into the new VMA without any fixup, because there is no .open callback.

Both VMAs now point to the same pages array. When the unmapped portion is closed, privcmd_close() calls:

  • xen_unmap_domain_gfn_range()
  • xen_free_unpopulated_pages()
  • kvfree(pages)

The surviving VMA still holds the dangling pointer. When it is later destroyed, the same sequence runs again, which leads to a double free.

Fix this issue by adding a .may_split callback denying the VMA split.

This is XSA-487 / CVE-2026-31787

AnalysisAI

Double-free vulnerability in Linux kernel Xen privcmd driver allows local authenticated attackers to corrupt memory and potentially execute arbitrary code or cause denial of service. When userspace performs partial munmap() on privcmd mappings, VMA splitting creates duplicate pointers to the same memory pages array, leading to kvfree() being called twice on the same allocation during VMA cleanup. Xen Security Advisory XSA-487 confirms this issue affects virtualization hosts running Xen paravirtualized domains. No public exploit identified at time of analysis, with EPSS score of 0.03% indicating low predicted exploitation probability. Vendor-released patches available for stable kernel versions 5.10.254, 5.15.204, 6.1.170, 6.6.137, 6.12.85, 6.18.26, and 7.0.3.

Technical ContextAI

This vulnerability resides in the Xen privcmd driver (drivers/xen/privcmd.c), which provides userspace access to Xen hypercalls for managing paravirtualized guest domains. The privcmd_vm_ops structure defines VMA operations including a .close callback (privcmd_close) but lacks .may_split and .open callbacks. When the kernel's __split_vma() function is invoked during partial munmap() operations, vm_area_dup() copies the vm_private_data pointer-which references a dynamically allocated pages array created by alloc_empty_pages()-without deep-copying the underlying allocation. This represents a classic CWE-415 (Double Free) scenario where improper handling of object lifecycle during VMA splitting creates aliased pointers. Both the original and split VMA retain references to the same pages array, but the memory management subsystem treats them as independent. During VMA destruction, privcmd_close() invokes xen_unmap_domain_gfn_range() followed by xen_free_unpopulated_pages() and kvfree(pages) on each VMA independently, causing use-after-free conditions and heap corruption. The fix implements a .may_split callback returning an error to prevent VMA splitting entirely for privcmd mappings.

RemediationAI

Apply vendor-released kernel updates immediately for Xen-enabled systems: upgrade to Linux kernel 5.10.254, 5.15.204, 6.1.170, 6.6.137, 6.12.85, 6.18.26, 7.0.3, or later stable releases incorporating the fix commits. Patches are available from kernel.org Git repository (references provided) and distribution-specific security channels. For systems unable to apply kernel updates immediately, disable the Xen privcmd driver by unloading the xen-privcmd kernel module (modprobe -r xen_privcmd) if not actively required for domain management, though this will break Xen toolstack functionality including xl/xm domain creation and management operations. Alternatively, restrict access to /dev/xen/privcmd device node to only trusted privileged users via filesystem permissions (chmod 600 /dev/xen/privcmd), recognizing this provides defense-in-depth but does not eliminate the vulnerability if those users are compromised. For production Xen environments, kernel patching is the only complete remediation-compensating controls merely reduce attack surface. Verify patch application by checking kernel version (uname -r) matches patched releases and reviewing git commit logs for presence of .may_split callback additions to privcmd_vm_ops structure. See official advisories at openwall.com/lists/oss-security/2026/04/28/14 and xenbits.xen.org/xsa/advisory-487.html for additional vendor guidance.

Vendor StatusVendor

SUSE

Severity: High
Product Status
openSUSE Tumbleweed Fixed
SUSE Linux Enterprise Desktop 15 SP7 Fixed
SUSE Linux Enterprise Desktop 15 SP7 Fixed
SUSE Linux Enterprise High Availability Extension 15 SP7 Fixed
SUSE Linux Enterprise High Availability Extension 15 SP7 Fixed

Share

CVE-2026-31787 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy