CVE-2025-68211

ksm: use range-walk function to jump over holes in scan_get_next_rmap_item

5.5 MediumFix available

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.

Attack profile

How easy it is to exploit

Attack vector: Local
Complexity: Low
Privileges needed: Low
User interaction: None

What an attacker can affect

Confidentiality: None
Integrity: None
Availability: High

Exploit likelihood

0.15%Up 0.1 points since Dec 17, 2025

What each source reports

NVD Score used 5.5

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

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

Record: CVE-2025-68211
CVSS 3.1: 5.5 MediumCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Updated: 2026-11-02

CVE List No score

ksm: use range-walk function to jump over holes in scan_get_next_rmap_item

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

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

Record: CVE-2025-68211
Updated: 2026-11-02

EUVDEUVD-2025-203685 No score

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

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

Record: EUVD-2025-203685
Updated: 2026-11-02

GitHub AdvisoriesGHSA-qhqr-mc3h-hmjp 5.5

In the Linux kernel, the following vulnerability has been resolved: ksm: use range-walk function...

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

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

Record: GHSA-qhqr-mc3h-hmjp
CVSS 3.1: 5.5 MediumCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Updated: 2026-11-02

OSVBELL-CVE-2025-68211 5.5

Record: BELL-CVE-2025-68211
CVSS 3.1: 5.5 MediumCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Updated: 2026-11-02

OSVDEBIAN-CVE-2025-68211 5.5

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.

Record: DEBIAN-CVE-2025-68211
CVSS 3.1: 5.5 MediumCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Updated: 2026-11-02

Show 45 moreShow less

OSVOESA-2026-1566 7.8

kernel security update

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

udp: Deal with race between UDP socket address change and rehash

If a UDP socket changes its local address while it's receiving datagrams, as a result of connect(), there is a period during which a lookup operation might fail to find it, after the address is changed but before the secondary hash (port and address) and the four-tuple hash (local and remote ports and addresses) are updated.

Secondary hash chains were introduced by commit 30fff9231fad ("udp: bind() optimisation") and, as a result, a rehash operation became needed to make a bound socket reachable again after a connect().

This operation was introduced by commit 719f835853a9 ("udp: add rehash on connect()") which isn't however a complete fix: the socket will be found once the rehashing completes, but not while it's pending.

This is noticeable with a socat(1) server in UDP4-LISTEN mode, and a client sending datagrams to it. After the server receives the first datagram (cf. _xioopen_ipdgram_listen()), it issues a connect() to the address of the sender, in order to set up a directed flow.

Now, if the client, running on a different CPU thread, happens to send a (subsequent) datagram while the server's socket changes its address, but is not rehashed yet, this will result in a failed lookup and a port unreachable error delivered to the client, as apparent from the following reproducer:

LEN=$(($(cat /proc/sys/net/core/wmem_default) / 4)) dd if=/dev/urandom bs=1 count=${LEN} of=tmp.in

while :; do taskset -c 1 socat UDP4-LISTEN:1337,null-eof OPEN:tmp.out,create,trunc & sleep 0.1 || sleep 1 taskset -c 2 socat OPEN:tmp.in UDP4:localhost:1337,shut-null wait done

where the client will eventually get ECONNREFUSED on a write() (typically the second or third one of a given iteration):

2024/11/13 21:28:23 socat[46901] E write(6, 0x556db2e3c000, 8192): Connection refused

This issue was first observed as a seldom failure in Podman's tests checking UDP functionality while using pasta(1) to connect the container's network namespace, which leads us to a reproducer with the lookup error resulting in an ICMP packet on a tap device:

LOCAL_ADDR="$(ip -j -4 addr show|jq -rM '.[] | .addr_info[0] | select(.scope == "global").local')"

while :; do ./pasta --config-net -p pasta.pcap -u 1337 socat UDP4-LISTEN:1337,null-eof OPEN:tmp.out,create,trunc & sleep 0.2 || sleep 1 socat OPEN:tmp.in UDP4:${LOCAL_ADDR}:1337,shut-null wait cmp tmp.in tmp.out done

Once this fails:

tmp.in tmp.out differ: char 8193, line 29

we can finally have a look at what's going on:

$ tshark -r pasta.pcap 1 0.000000 :: ? ff02::16 ICMPv6 110 Multicast Listener Report Message v2 2 0.168690 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192 3 0.168767 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192 4 0.168806 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192 5 0.168827 c6:47:05:8d:dc:04 ? Broadcast ARP 42 Who has 88.198.0.161? Tell 88.198.0.164 6 0.168851 9a:55:9a:55:9a:55 ? c6:47:05:8d:dc:04 ARP 42 88.198.0.161 is at 9a:55:9a:55:9a:55 7 0.168875 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192 8 0.168896 88.198.0.164 ? 88.198.0.161 ICMP 590 Destination unreachable (Port unreachable) 9 0.168926 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192 10 0.168959 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192 11 0.168989 88.198.0.161 ? 88.198.0.164 UDP 4138 60260 ? 1337 Len=4096 12 0.169010 88.198.0.161 ? 88.198.0.164 UDP 42 60260 ? 1337 Len=0

On the third datagram received, the network namespace of the container initiates an ARP lookup to deliver the ICMP message.

In another…

Record: OESA-2026-1566
CVSS 3.1: 7.8 HighCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Updated: 2026-11-02

OSVOESA-2026-1567 7.8