Cloudanix VulnDB

CVE-2025-68211

Medium · 5.5

CVSS

5.5

EPSS

0.1%

Published

Dec 16, 2025

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A Linux kernel process that merges identical memory pages can waste huge amounts of CPU time when applications reserve enormous blocks of memory but only use tiny portions of them, slowing the whole system.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Low
Impact
Denial Of Service
Component
OS kernel
Class
Denial of service
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

scan_get_next_rmap_item walks every virtual address in a VMA instead of using walk_page_range to skip unmapped holes, causing ksmd to perform an unbounded number of per-page lookups on large sparse mappings.

Why it matters to the business

ksmd consumes 100% CPU for extended periods on systems that enable KSM and host processes with large mostly-unmapped virtual address spaces, starving other workloads and preventing useful page deduplication.

How an attack unfolds

A local attacker maps a multi-terabyte virtual region with only a single populated page, marks the region MADV_MERGEABLE, and starts KSM; the unpatched kernel then walks every address in the region, exhausting CPU without producing merges.

How to fix it

Upgrade the Linux kernel to a version containing commit 220cb3e425e17587f560335924cba9f16a842c64 or later; for the listed GitLab Chainguard images apply the 17.7.4-r0 packages that include the fixed kernel.

How to confirm the fix worked

Confirm the running kernel contains commit 220cb3e425e17587f560335924cba9f16a842c64; reproduce the 32 TiB sparse-mapping test and verify ksmd CPU usage drops from sustained 100% to near zero within seconds.

Typical attack path

  1. Create a very large anonymous mapping with MAP_NORESERVE
  2. Touch a single page to obtain an anon_vma
  3. Apply MADV_MERGEABLE to the entire mapping
  4. Enable KSM via /sys/kernel/mm/ksm/run
  5. Observe sustained 100% ksmd CPU usage while the process remains resident

How to detect it

Inspect kernel logs and ksmd process statistics for prolonged high CPU with no corresponding increase in pages_shared; correlate with processes that have created multi-terabyte anonymous mappings via mmap.

What your security team should do

  • Prioritize kernel updates on any system where KSM is enabled
  • Disable KSM (echo 0 > /sys/kernel/mm/ksm/run) on systems that cannot be patched immediately
  • Monitor ksmd CPU usage and alert on sustained high utilization coinciding with large anonymous mappings

The record

In the Linux kernel, the following vulnerability has been resolved: ksm: use range-walk function to jump over holes in scan_get_next_rmap_item Currently, scan_get_next_rmap_item() walks every page address in a VMA to locate mergeable pages. This becomes highly inefficient when scanning large virtual memory areas that contain mostly unmapped regions, causing ksmd to use large amount of cpu without deduplicating much pages. This patch replaces the per-address lookup with a range walk using walk_page_range(). The range walker allows KSM to skip over entire unmapped holes in a VMA, avoiding unnecessary lookups. This problem was previously discussed in [1]. Consider the following test program which creates a 32 TiB mapping in the virtual address space but only populates a single page: #include <unistd.h> #include <stdio.h> #include <sys/mman.h> /* 32 TiB */ const size_t size = 32ul * 1024 * 1024 * 1024 * 1024; int main() { char *area = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_NORESERVE | MAP_PRIVATE | MAP_ANON, -1, 0); if (area == MAP_FAILED) { perror("mmap() failed\n"); return -1; } /* Populate a single page such that we get an anon_vma. */ *area = 0; /* Enable KSM. */ madvise(area, size, MADV_MERGEABLE); pause(); return 0; } $ ./ksm-sparse & $ echo 1 > /sys/kernel/mm/ksm/run Without this patch ksmd uses 100% of the cpu for a long time (more then 1 hour in my test machine) scanning all the 32 TiB virtual address space that contain only one mapped page. This makes ksmd essentially deadlocked not able to deduplicate anything of value. With this patch ksmd walks only the one mapped page and skips the rest of the 32 TiB virtual address space, making the scan fast using little cpu.

Affected packages

Ecosystem Package Introduced Fixed
Linux Kernel 2.6.32 5.10.249
Linux Kernel 2.6.32 6.12.59
openSUSE:Leap 16.0 dtb-aarch64 0 6.12.0-160000.26.1
openSUSE:Leap 16.0 kernel-64kb 0 6.12.0-160000.26.1
openSUSE:Leap 16.0 kernel-azure 0 6.12.0-160000.26.1
openSUSE:Leap 16.0 kernel-default 0 6.12.0-160000.26.1
openSUSE:Leap 16.0 kernel-default-base 0 6.12.0-160000.26.1.160000.2.7
openSUSE:Leap 16.0 kernel-docs 0 6.12.0-160000.26.1
openSUSE:Leap 16.0 kernel-kvmsmall 0 6.12.0-160000.26.1
openSUSE:Leap 16.0 kernel-obs-build 0 6.12.0-160000.26.1
openSUSE:Leap 16.0 kernel-obs-qa 0 6.12.0-160000.26.1
openSUSE:Leap 16.0 kernel-rt 0 6.12.0-160000.26.1
openSUSE:Leap 16.0 kernel-source 0 6.12.0-160000.26.1
openSUSE:Leap 16.0 kernel-syms 0 6.12.0-160000.26.1
openSUSE:Leap 16.0 kernel-zfcpdump 0 6.12.0-160000.26.1

Related vulnerabilities