CVE-2025-38554 (GCVE-0-2025-38554)
Vulnerability from cvelistv5
Published
2025-08-19 17:02
Modified
2026-08-05 12:02
Summary
In the Linux kernel, the following vulnerability has been resolved: mm: fix a UAF when vma->mm is freed after vma->vm_refcnt got dropped By inducing delays in the right places, Jann Horn created a reproducer for a hard to hit UAF issue that became possible after VMAs were allowed to be recycled by adding SLAB_TYPESAFE_BY_RCU to their cache. Race description is borrowed from Jann's discovery report: lock_vma_under_rcu() looks up a VMA locklessly with mas_walk() under rcu_read_lock(). At that point, the VMA may be concurrently freed, and it can be recycled by another process. vma_start_read() then increments the vma->vm_refcnt (if it is in an acceptable range), and if this succeeds, vma_start_read() can return a recycled VMA. In this scenario where the VMA has been recycled, lock_vma_under_rcu() will then detect the mismatching ->vm_mm pointer and drop the VMA through vma_end_read(), which calls vma_refcount_put(). vma_refcount_put() drops the refcount and then calls rcuwait_wake_up() using a copy of vma->vm_mm. This is wrong: It implicitly assumes that the caller is keeping the VMA's mm alive, but in this scenario the caller has no relation to the VMA's mm, so the rcuwait_wake_up() can cause UAF. The diagram depicting the race: T1 T2 T3 == == == lock_vma_under_rcu mas_walk <VMA gets removed from mm> mmap <the same VMA is reallocated> vma_start_read __refcount_inc_not_zero_limited_acquire munmap __vma_enter_locked refcount_add_not_zero vma_end_read vma_refcount_put __refcount_dec_and_test rcuwait_wait_event <finish operation> rcuwait_wake_up [UAF] Note that rcuwait_wait_event() in T3 does not block because refcount was already dropped by T1. At this point T3 can exit and free the mm causing UAF in T1. To avoid this we move vma->vm_mm verification into vma_start_read() and grab vma->vm_mm to stabilize it before vma_refcount_put() operation. [surenb@google.com: v3]
Impacted products
Vendor Product Version
Linux Linux Version: 3104138517fc66aad21f4a2487bb572e9fc2e3ec
Version: 3104138517fc66aad21f4a2487bb572e9fc2e3ec
Version: 3104138517fc66aad21f4a2487bb572e9fc2e3ec
Create a notification for this product.
Show details on NVD website


{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "include/linux/mmap_lock.h",
            "mm/mmap_lock.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "6e88fe54721dee17d3496bc998f0c7d243896348",
              "status": "affected",
              "version": "3104138517fc66aad21f4a2487bb572e9fc2e3ec",
              "versionType": "git"
            },
            {
              "lessThan": "1bcd236a2536a451e385f8d6d2bb589689ec812f",
              "status": "affected",
              "version": "3104138517fc66aad21f4a2487bb572e9fc2e3ec",
              "versionType": "git"
            },
            {
              "lessThan": "9bbffee67ffd16360179327b57f3b1245579ef08",
              "status": "affected",
              "version": "3104138517fc66aad21f4a2487bb572e9fc2e3ec",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "include/linux/mmap_lock.h",
            "mm/mmap_lock.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "6.15"
            },
            {
              "lessThan": "6.15",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.15.*",
              "status": "unaffected",
              "version": "6.15.10",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.16.*",
              "status": "unaffected",
              "version": "6.16.1",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "6.17",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.15.10",
                  "versionStartIncluding": "6.15",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.16.1",
                  "versionStartIncluding": "6.15",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.17",
                  "versionStartIncluding": "6.15",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm: fix a UAF when vma-\u003emm is freed after vma-\u003evm_refcnt got dropped\n\nBy inducing delays in the right places, Jann Horn created a reproducer for\na hard to hit UAF issue that became possible after VMAs were allowed to be\nrecycled by adding SLAB_TYPESAFE_BY_RCU to their cache.\n\nRace description is borrowed from Jann\u0027s discovery report:\nlock_vma_under_rcu() looks up a VMA locklessly with mas_walk() under\nrcu_read_lock().  At that point, the VMA may be concurrently freed, and it\ncan be recycled by another process.  vma_start_read() then increments the\nvma-\u003evm_refcnt (if it is in an acceptable range), and if this succeeds,\nvma_start_read() can return a recycled VMA.\n\nIn this scenario where the VMA has been recycled, lock_vma_under_rcu()\nwill then detect the mismatching -\u003evm_mm pointer and drop the VMA through\nvma_end_read(), which calls vma_refcount_put().  vma_refcount_put() drops\nthe refcount and then calls rcuwait_wake_up() using a copy of vma-\u003evm_mm. \nThis is wrong: It implicitly assumes that the caller is keeping the VMA\u0027s\nmm alive, but in this scenario the caller has no relation to the VMA\u0027s mm,\nso the rcuwait_wake_up() can cause UAF.\n\nThe diagram depicting the race:\nT1         T2         T3\n==         ==         ==\nlock_vma_under_rcu\n  mas_walk\n          \u003cVMA gets removed from mm\u003e\n                      mmap\n                        \u003cthe same VMA is reallocated\u003e\n  vma_start_read\n    __refcount_inc_not_zero_limited_acquire\n                      munmap\n                        __vma_enter_locked\n                          refcount_add_not_zero\n  vma_end_read\n    vma_refcount_put\n      __refcount_dec_and_test\n                          rcuwait_wait_event\n                            \u003cfinish operation\u003e\n      rcuwait_wake_up [UAF]\n\nNote that rcuwait_wait_event() in T3 does not block because refcount was\nalready dropped by T1.  At this point T3 can exit and free the mm causing\nUAF in T1.\n\nTo avoid this we move vma-\u003evm_mm verification into vma_start_read() and\ngrab vma-\u003evm_mm to stabilize it before vma_refcount_put() operation.\n\n[surenb@google.com: v3]"
        }
      ],
      "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 vulnerable path is entered from the architecture user page-fault handler (`lock_vma_under_rcu()`), `madvise()`/`userfaultfd`/`process_vm` paths, and `/proc/pid/maps` traversal \u2014 all require local code execution. No remote peer can drive the mmap/munmap/exit sequence needed for the race.\nAC:L - The attacker controls every side of the race \u2014 the page-faulting thread, the thread unmapping the VMA, and the second process that recycles the VMA slab object and then exits to free its mm \u2014 and can spray VMA allocations and retry the loop indefinitely across CPUs. Although the window is narrow, no condition lies outside the attacker\u0027s influence.\nPR:L - Any unprivileged local process can reach the code simply by taking a page fault or reading `/proc/pid/maps`; no capability, namespace privilege, or configuration gate exists on the path.\nUI:N - The attacker drives the entire sequence with its own threads and child processes; no victim action is required.\nS:U - The use-after-free corrupts kernel memory within the same security authority; there is no VM, IOMMU, or sandbox boundary crossed.\nC:H - The freed `mm_struct` is read after being returned to `mm_cachep` and potentially reallocated, and the resulting UAF on a core mm object combined with the `wake_up_process()` primitive gives the attacker a path to arbitrary kernel memory disclosure.\nI:H - `rcuwait_wake_up()` loads a `task_struct *` out of freed, attacker-groomable memory and passes it to `wake_up_process()`, which writes into that object and dispatches through `p-\u003esched_class-\u003eenqueue_task()` \u2014 an attacker-controlled indirect call yielding arbitrary write and control-flow hijack.\nA:H - Even without successful grooming, dereferencing a freed `mm_struct` and waking a bogus task pointer corrupts scheduler state and causes a kernel oops or panic, and the race can be retried in a loop."
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-08-05T12:02:52.067Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/6e88fe54721dee17d3496bc998f0c7d243896348"
        },
        {
          "url": "https://git.kernel.org/stable/c/1bcd236a2536a451e385f8d6d2bb589689ec812f"
        },
        {
          "url": "https://git.kernel.org/stable/c/9bbffee67ffd16360179327b57f3b1245579ef08"
        }
      ],
      "title": "mm: fix a UAF when vma-\u003emm is freed after vma-\u003evm_refcnt got dropped",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2025-38554",
    "datePublished": "2025-08-19T17:02:33.315Z",
    "dateReserved": "2025-04-16T04:51:24.025Z",
    "dateUpdated": "2026-08-05T12:02:52.067Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.


Loading…

Loading…