{"dataType":"CVE_RECORD","dataVersion":"5.2","cveMetadata":{"cveId":"CVE-2025-21709","assignerOrgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","state":"PUBLISHED","assignerShortName":"Linux","dateReserved":"2024-12-29T08:45:45.752Z","datePublished":"2025-02-27T02:07:22.452Z","dateUpdated":"2026-08-05T11:53:48.428Z"},"containers":{"cna":{"providerMetadata":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-08-05T11:53:48.428Z"},"descriptions":[{"lang":"en","value":"In the Linux kernel, the following vulnerability has been resolved:\n\nkernel: be more careful about dup_mmap() failures and uprobe registering\n\nIf a memory allocation fails during dup_mmap(), the maple tree can be left\nin an unsafe state for other iterators besides the exit path.  All the\nlocks are dropped before the exit_mmap() call (in mm/mmap.c), but the\nincomplete mm_struct can be reached through (at least) the rmap finding\nthe vmas which have a pointer back to the mm_struct.\n\nUp to this point, there have been no issues with being able to find an\nmm_struct that was only partially initialised.  Syzbot was able to make\nthe incomplete mm_struct fail with recent forking changes, so it has been\nproven unsafe to use the mm_struct that hasn't been initialised, as\nreferenced in the link below.\n\nAlthough 8ac662f5da19f (\"fork: avoid inappropriate uprobe access to\ninvalid mm\") fixed the uprobe access, it does not completely remove the\nrace.\n\nThis patch sets the MMF_OOM_SKIP to avoid the iteration of the vmas on the\noom side (even though this is extremely unlikely to be selected as an oom\nvictim in the race window), and sets MMF_UNSTABLE to avoid other potential\nusers from using a partially initialised mm_struct.\n\nWhen registering vmas for uprobe, skip the vmas in an mm that is marked\nunstable.  Modifying a vma in an unstable mm may cause issues if the mm\nisn't fully initialised."}],"metrics":[{"cvssV3_1":{"version":"3.1","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","baseScore":7.8,"baseSeverity":"HIGH"},"scenarios":[{"lang":"en","value":"AV:L - The corrupted mm_struct is produced by the fork()/clone() syscall path (dup_mmap()), which requires local execution on the target system. There is no remote or adjacent-network path to dup_mmap().\nAC:L - The attacker deterministically creates the unsafe mm by forking a process with many VMAs and delivering SIGKILL mid-dup_mmap() (the fatal_signal_pending() bail-out), or by forcing -ENOMEM under a memcg/RLIMIT_AS/overcommit limit, and can repeat this continuously to widen the window; the same attacker-generated memory pressure simultaneously activates the OOM killer/reaper that iterates the broken tree, so both sides of the race are attacker-driven.\nPR:L - Only the ability to call fork()/clone() and allocate memory is needed — any unprivileged local user or container process qualifies. No capability, namespace, or tracing privilege is required on the attacker's side.\nUI:N - The attacker triggers the failed fork and the resulting corrupted mm_struct entirely on their own; no victim action is required. The consuming iterators (uprobe registration, swapoff, OOM reaper) are background/system activity, not user interaction.\nS:U - The corruption and its consequences are confined to the kernel's own memory-management structures within the same security authority. No VM, IOMMU, or hypervisor boundary is crossed.\nC:H - The partially-initialised mm's maple tree hands out an internal XA_ZERO_ENTRY (0x406) as a struct vm_area_struct * and, past that point, live pointers to the parent process's VMAs, so iterators read through invalid pointers and operate with mm != vma->vm_mm — a cross-address-space mismatch that lets page-table walks touch another process's memory; a sibling CLONE_VM thread munmap()ing during the unlocked window turns those entries into dangling freed-object pointers, giving a use-after-free read primitive.\nI:H - install_breakpoint()/uprobe_write_opcode() modifies VMAs and page tables of an mm that is not fully initialised (exactly what the fix's check_stable_address_space() gate prevents), and the OOM reaper path guarded by the new MMF_OOM_SKIP would unmap the parent's VMAs through the child's mmu_gather, flushing the wrong mm's TLB and leaving stale writable mappings to freed pages — memory corruption usable for arbitrary write.\nA:H - The demonstrated failure is a kernel OOPS dereferencing XA_ZERO_ENTRY at a low address (the sibling swapoff fix records a fault at 0x446), fatal with panic_on_oops; in register_for_each_vma() the oops occurs while holding mmap_write_lock(mm) and percpu_down_write(&dup_mmap_sem), which are never released, hanging every subsequent fork() on the system."}]}],"affected":[{"product":"Linux","vendor":"Linux","defaultStatus":"unaffected","repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","programFiles":["kernel/events/uprobes.c","kernel/fork.c"],"versions":[{"version":"d2406291483775ecddaee929231a39c70c08fda2","lessThan":"74c2471eb891a7dcb3874b21c106cda75f52be30","status":"affected","versionType":"git"},{"version":"d2406291483775ecddaee929231a39c70c08fda2","lessThan":"da139948aeda677ac09cc0e7d837f8a314de7d55","status":"affected","versionType":"git"},{"version":"d2406291483775ecddaee929231a39c70c08fda2","lessThan":"64c37e134b120fb462fb4a80694bfb8e7be77b14","status":"affected","versionType":"git"}]},{"product":"Linux","vendor":"Linux","defaultStatus":"affected","repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","programFiles":["kernel/events/uprobes.c","kernel/fork.c"],"versions":[{"version":"6.8","status":"affected"},{"version":"0","lessThan":"6.8","status":"unaffected","versionType":"semver"},{"version":"6.12.83","lessThanOrEqual":"6.12.*","status":"unaffected","versionType":"semver"},{"version":"6.13.2","lessThanOrEqual":"6.13.*","status":"unaffected","versionType":"semver"},{"version":"6.14","lessThanOrEqual":"*","status":"unaffected","versionType":"original_commit_for_fix"}]}],"cpeApplicability":[{"nodes":[{"operator":"OR","negate":false,"cpeMatch":[{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"6.8","versionEndExcluding":"6.12.83"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"6.8","versionEndExcluding":"6.13.2"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"6.8","versionEndExcluding":"6.14"}]}]}],"references":[{"url":"https://git.kernel.org/stable/c/74c2471eb891a7dcb3874b21c106cda75f52be30"},{"url":"https://git.kernel.org/stable/c/da139948aeda677ac09cc0e7d837f8a314de7d55"},{"url":"https://git.kernel.org/stable/c/64c37e134b120fb462fb4a80694bfb8e7be77b14"}],"title":"kernel: be more careful about dup_mmap() failures and uprobe registering","x_generator":{"engine":"bippy-1.2.0"}}}}