Cyber Resilience

CVE-2024-35877

Linux Kernel 2.6.29 – 4.19.312

Published
19 May 2024
Modified
12 May 2026
Patch / advisory
CVSS Score v3.1 5.5
Click a component to see what it means
Raw vectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score 0.0025 16th percentile
Risk Priority 42 floored blend · peak EPSS

CVSS and EPSS are reproduced from their sources (NVD, FIRST EPSS). Risk Priority is our own derived reading, not an NVD score.

Summary

CVE-2024-35877 is a medium-severity Missing Release of Memory after Effective Lifetime (CWE-401) vulnerability in Linux Linux Kernel. Its CVSS base score is 5.5 (Medium).

Operationally, exploitation aligns with the MITRE ATT&CK technique Endpoint Denial of Service (T1499); ranked at the 16th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.

The strongest mitigations our analysis identified map to SA-11 (Developer Testing and Evaluation) and SA-15 (Development Process, Standards, and Tools) — see the control section below for these in your framework.

EU & UK References

Vulnerability Data

In the Linux kernel, the following vulnerability has been resolved: x86/mm/pat: fix VM_PAT handling in COW mappings PAT handling won't do the right thing in COW mappings: the first PTE (or, in fact, all PTEs) can be replaced during write…

more

faults to point at anon folios. Reliably recovering the correct PFN and cachemode using follow_phys() from PTEs will not work in COW mappings. Using follow_phys(), we might just get the address+protection of the anon folio (which is very wrong), or fail on swap/nonswap entries, failing follow_phys() and triggering a WARN_ON_ONCE() in untrack_pfn() and track_pfn_copy(), not properly calling free_pfn_range(). In free_pfn_range(), we either wouldn't call memtype_free() or would call it with the wrong range, possibly leaking memory. To fix that, let's update follow_phys() to refuse returning anon folios, and fallback to using the stored PFN inside vma->vm_pgoff for COW mappings if we run into that. We will now properly handle untrack_pfn() with COW mappings, where we don't need the cachemode. We'll have to fail fork()->track_pfn_copy() if the first page was replaced by an anon folio, though: we'd have to store the cachemode in the VMA to make this work, likely growing the VMA size. For now, lets keep it simple and let track_pfn_copy() just fail in that case: it would have failed in the past with swap/nonswap entries already, and it would have done the wrong thing with anon folios. Simple reproducer to trigger the WARN_ON_ONCE() in untrack_pfn(): <--- C reproducer ---> #include <stdio.h> #include <sys/mman.h> #include <unistd.h> #include <liburing.h> int main(void) { struct io_uring_params p = {}; int ring_fd; size_t size; char *map; ring_fd = io_uring_setup(1, &p); if (ring_fd < 0) { perror("io_uring_setup"); return 1; } size = p.sq_off.array + p.sq_entries * sizeof(unsigned); /* Map the submission queue ring MAP_PRIVATE */ map = mmap(0, size, PROT_READ | PROT_WRITE, MAP_PRIVATE, ring_fd, IORING_OFF_SQ_RING); if (map == MAP_FAILED) { perror("mmap"); return 1; } /* We have at least one page. Let's COW it. */ *map = 0; pause(); return 0; } <--- C reproducer ---> On a system with 16 GiB RAM and swap configured: # ./iouring & # memhog 16G # killall iouring [ 301.552930] ------------[ cut here ]------------ [ 301.553285] WARNING: CPU: 7 PID: 1402 at arch/x86/mm/pat/memtype.c:1060 untrack_pfn+0xf4/0x100 [ 301.553989] Modules linked in: binfmt_misc nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_g [ 301.558232] CPU: 7 PID: 1402 Comm: iouring Not tainted 6.7.5-100.fc38.x86_64 #1 [ 301.558772] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebu4 [ 301.559569] RIP: 0010:untrack_pfn+0xf4/0x100 [ 301.559893] Code: 75 c4 eb cf 48 8b 43 10 8b a8 e8 00 00 00 3b 6b 28 74 b8 48 8b 7b 30 e8 ea 1a f7 000 [ 301.561189] RSP: 0018:ffffba2c0377fab8 EFLAGS: 00010282 [ 301.561590] RAX: 00000000ffffffea RBX: ffff9208c8ce9cc0 RCX: 000000010455e047 [ 301.562105] RDX: 07fffffff0eb1e0a RSI: 0000000000000000 RDI: ffff9208c391d200 [ 301.562628] RBP: 0000000000000000 R08: ffffba2c0377fab8 R09: 0000000000000000 [ 301.563145] R10: ffff9208d2292d50 R11: 0000000000000002 R12: 00007fea890e0000 [ 301.563669] R13: 0000000000000000 R14: ffffba2c0377fc08 R15: 0000000000000000 [ 301.564186] FS: 0000000000000000(0000) GS:ffff920c2fbc0000(0000) knlGS:0000000000000000 [ 301.564773] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 301.565197] CR2: 00007fea88ee8a20 CR3: 00000001033a8000 CR4: 0000000000750ef0 [ 301.565725] PKRU: 55555554 [ 301.565944] Call Trace: [ 301.566148] <TASK> [ 301.566325] ? untrack_pfn+0xf4/0x100 [ 301.566618] ? __warn+0x81/0x130 [ 301.566876] ? untrack_pfn+0xf4/0x100 [ 3 ---truncated---

CWE(s)

Related Threats

MITRE ATT&CK Enterprise Techniques

T1499 Endpoint Denial of Service Impact
Adversaries may perform Endpoint Denial of Service (DoS) attacks to degrade or block the availability of services to users.
T1499.003 Application Exhaustion Flood Impact
Adversaries may target resource intensive features of applications to cause a denial of service (DoS), denying availability to those applications.
Derived from this CVE’s CWE(s) via the direct CWE→ATT&CK cross-walk.

CVEs Like This One

CVE-2025-38419Same product: Debian Debian Linux
CVE-2025-37962Same product: Debian Debian Linux
CVE-2025-38409Same product: Debian Debian Linux
CVE-2025-38165Same product: Debian Debian Linux
CVE-2025-38148Same product: Debian Debian Linux
CVE-2024-36954Same product: Debian Debian Linux
CVE-2025-38015Same product: Debian Debian Linux
CVE-2025-37951Same product: Debian Debian Linux
CVE-2024-27388Same product: Debian Debian Linux
CVE-2025-38444Same product: Debian Debian Linux

Affected Assets

linux
linux kernel
6.9 · 2.6.29 — 4.19.312 · 4.20 — 5.4.274 · 5.5 — 5.10.215
debian
debian linux
10.0

Mitigating Controls

Mitigating Controls (NIST 800-53 r5) AI

Developer testing and evaluation (static analysis, fuzzing, or runtime leak detection) directly finds missing deallocation.

Requiring documented development standards and tools can mandate memory-management disciplines that avoid leaks at introduction.

Engineering principles applied during development can require explicit resource-release patterns that stop memory leaks from being coded.

Mitigating Controls (NIST CSF 2.0) AI

Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.

PR.PS-06 mostly match
prevents

Secure SDLC practices directly enforce proper memory allocation/deallocation via coding standards, reviews, and tooling.

Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI

Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.

finds

Security testing in development can detect unreleased memory, providing partial coverage of the weakness.

prevents

Secure development life cycle mandates memory-management practices that reduce missing-release defects.

prevents

Application security requirements can specify explicit memory-release rules, partially mitigating the weakness.

prevents

Secure system architecture and engineering principles include resource-management guidelines that address memory leaks.

prevents

Secure coding standards directly require proper allocation/deallocation, covering most of this weakness.

finds

Capacity management may detect memory exhaustion symptoms but does not prevent the coding flaw.

References