Double Free Affecting kernel package, versions <0:4.18.0-553.134.1.el8_10


Severity

Recommended
0.0
high
0
10

Based on Oracle Linux security rating.

Threat Intelligence

EPSS
0.18% (9th percentile)

Do your applications use this vulnerable package?

In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.

Test your applications

Snyk Learn

Learn about Double Free vulnerabilities in an interactive lesson.

Start learning
  • Snyk IDSNYK-ORACLE8-KERNEL-17375266
  • published18 Jun 2026
  • disclosed30 Apr 2026

Introduced: 30 Apr 2026

CVE-2026-31787  (opens in a new tab)
CWE-415  (opens in a new tab)

How to fix?

Upgrade Oracle:8 kernel to version 0:4.18.0-553.134.1.el8_10 or higher.
This issue was patched in ELSA-2026-26427.

NVD Description

Note: Versions mentioned in the description apply only to the upstream kernel package and not the kernel package as distributed by Oracle. See How to fix? for Oracle:8 relevant fixed versions and status.

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

CVSS Base Scores

version 3.1