Vulnerability-Lookup

GHSA-VH2P-4GFM-V9V7

Vulnerability from github – Published: 2025-02-27 03:34 – Updated: 2026-04-22 15:31

Details

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

kernel: be more careful about dup_mmap() failures and uprobe registering

If a memory allocation fails during dup_mmap(), the maple tree can be left in an unsafe state for other iterators besides the exit path. All the locks are dropped before the exit_mmap() call (in mm/mmap.c), but the incomplete mm_struct can be reached through (at least) the rmap finding the vmas which have a pointer back to the mm_struct.

Up to this point, there have been no issues with being able to find an mm_struct that was only partially initialised. Syzbot was able to make the incomplete mm_struct fail with recent forking changes, so it has been proven unsafe to use the mm_struct that hasn't been initialised, as referenced in the link below.

Although 8ac662f5da19f ("fork: avoid inappropriate uprobe access to invalid mm") fixed the uprobe access, it does not completely remove the race.

This patch sets the MMF_OOM_SKIP to avoid the iteration of the vmas on the oom side (even though this is extremely unlikely to be selected as an oom victim in the race window), and sets MMF_UNSTABLE to avoid other potential users from using a partially initialised mm_struct.

When registering vmas for uprobe, skip the vmas in an mm that is marked unstable. Modifying a vma in an unstable mm may cause issues if the mm isn't fully initialised.

Severity

5.5 (Medium)


                  
                    CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2025-21709"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-27T02:15:14Z",
    "severity": "MODERATE"
  },
  "details": "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\u0027t 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\u0027t fully initialised.",
  "id": "GHSA-vh2p-4gfm-v9v7",
  "modified": "2026-04-22T15:31:31Z",
  "published": "2025-02-27T03:34:01Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21709"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/64c37e134b120fb462fb4a80694bfb8e7be77b14"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/74c2471eb891a7dcb3874b21c106cda75f52be30"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/da139948aeda677ac09cc0e7d837f8a314de7d55"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

CVE-2025-21709 (GCVE-0-2025-21709)

Vulnerability from cvelistv5 – Published: 2025-02-27 02:07 – Updated: 2026-10-15 21:51

Title

kernel: be more careful about dup_mmap() failures and uprobe registering

Summary

In the Linux kernel, the following vulnerability has been resolved: kernel: be more careful about dup_mmap() failures and uprobe registering If a memory allocation fails during dup_mmap(), the maple tree can be left in an unsafe state for other iterators besides the exit path. All the locks are dropped before the exit_mmap() call (in mm/mmap.c), but the incomplete mm_struct can be reached through (at least) the rmap finding the vmas which have a pointer back to the mm_struct. Up to this point, there have been no issues with being able to find an mm_struct that was only partially initialised. Syzbot was able to make the incomplete mm_struct fail with recent forking changes, so it has been proven unsafe to use the mm_struct that hasn't been initialised, as referenced in the link below. Although 8ac662f5da19f ("fork: avoid inappropriate uprobe access to invalid mm") fixed the uprobe access, it does not completely remove the race. This patch sets the MMF_OOM_SKIP to avoid the iteration of the vmas on the oom side (even though this is extremely unlikely to be selected as an oom victim in the race window), and sets MMF_UNSTABLE to avoid other potential users from using a partially initialised mm_struct. When registering vmas for uprobe, skip the vmas in an mm that is marked unstable. Modifying a vma in an unstable mm may cause issues if the mm isn't fully initialised.

Severity

7.8 (High)


                        
                          CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

SSVC

Exploitation: none Automatable: no Technical Impact: total

CISA Coordinator · CISA-ADP (v2.0.3)

Decision recorded 2026-10-15 21:42 UTC

Assigner

Linux CNA under the mitre root

CNA scorecard D 53/100 over 6653 records in the last 180 days details

References

3 references

URL	Tags
https://git.kernel.org/stable/c/74c2471eb891a7dcb…
https://git.kernel.org/stable/c/da139948aeda677ac…
https://git.kernel.org/stable/c/64c37e134b120fb46…

Impacted products

2 products

Vendor	Product	Version
Linux	Linux	Affected: d2406291483775ecddaee929231a39c70c08fda2 , < 74c2471eb891a7dcb3874b21c106cda75f52be30 (git) Affected: d2406291483775ecddaee929231a39c70c08fda2 , < da139948aeda677ac09cc0e7d837f8a314de7d55 (git) Affected: d2406291483775ecddaee929231a39c70c08fda2 , < 64c37e134b120fb462fb4a80694bfb8e7be77b14 (git)
Linux	Linux	Affected: 6.8 Unaffected: 0 , < 6.8 (semver) Unaffected: 6.12.83 , ≤ 6.12.* (semver) Unaffected: 6.13.2 , ≤ 6.13.* (semver) Unaffected: 6.14 , ≤ * (original_commit_for_fix)

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2025-21709",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "total"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-10-15T21:42:41.994494Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-10-15T21:51:52.263Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "kernel/events/uprobes.c",
            "kernel/fork.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "74c2471eb891a7dcb3874b21c106cda75f52be30",
              "status": "affected",
              "version": "d2406291483775ecddaee929231a39c70c08fda2",
              "versionType": "git"
            },
            {
              "lessThan": "da139948aeda677ac09cc0e7d837f8a314de7d55",
              "status": "affected",
              "version": "d2406291483775ecddaee929231a39c70c08fda2",
              "versionType": "git"
            },
            {
              "lessThan": "64c37e134b120fb462fb4a80694bfb8e7be77b14",
              "status": "affected",
              "version": "d2406291483775ecddaee929231a39c70c08fda2",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "kernel/events/uprobes.c",
            "kernel/fork.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "6.8"
            },
            {
              "lessThan": "6.8",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.12.*",
              "status": "unaffected",
              "version": "6.12.83",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.13.*",
              "status": "unaffected",
              "version": "6.13.2",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "6.14",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.12.83",
                  "versionStartIncluding": "6.8",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.13.2",
                  "versionStartIncluding": "6.8",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.14",
                  "versionStartIncluding": "6.8",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "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\u0027t 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\u0027t fully initialised."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "baseScore": 7.8,
            "baseSeverity": "HIGH",
            "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
            "version": "3.1"
          },
          "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 \u2014 any unprivileged local user or container process qualifies. No capability, namespace, or tracing privilege is required on the attacker\u0027s 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\u0027s own memory-management structures within the same security authority. No VM, IOMMU, or hypervisor boundary is crossed.\nC:H - The partially-initialised mm\u0027s 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\u0027s VMAs, so iterators read through invalid pointers and operate with mm != vma-\u003evm_mm \u2014 a cross-address-space mismatch that lets page-table walks touch another process\u0027s 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\u0027s check_stable_address_space() gate prevents), and the OOM reaper path guarded by the new MMF_OOM_SKIP would unmap the parent\u0027s VMAs through the child\u0027s mmu_gather, flushing the wrong mm\u0027s TLB and leaving stale writable mappings to freed pages \u2014 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(\u0026dup_mmap_sem), which are never released, hanging every subsequent fork() on the system."
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-08-05T11:53:48.428Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "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"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2025-21709",
    "datePublished": "2025-02-27T02:07:22.452Z",
    "dateReserved": "2024-12-29T08:45:45.752Z",
    "dateUpdated": "2026-10-15T21:51:52.263Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

Order JSON

How durations are calculated

Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.

Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.

Publication & reservation Sightings KEV catalogs Other timestamps

Loading timeline…

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.

Action not permitted