{ "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" } } } }