CVE-2025-38554

Estado: ModificadaAlta (7.8)—

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.

Leer descripción completaMostrar menos

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.

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]

Detalles técnicos trazas, registros y código del informe original

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]

CVSS

Versión: 3.1
Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Puntuación base: 7.8

Probabilidad de explotación (EPSS)

Probabilidad de explotación en los próximos 30 días: 0.17%
Percentil entre todas las CVEs puntuadas: 5
Fecha de la puntuación: 6/10/2026

EPSS (Exploit Prediction Scoring System, de FIRST) estima la probabilidad de que una vulnerabilidad sea explotada en 30 días. Complementa a CVSS (impacto) y a CISA KEV (explotación confirmada).

🎯 Técnicas ATT&CK

Cómo se explota esta vulnerabilidad y qué consigue el atacante, en el lenguaje de MITRE ATT&CK.

ExplotaciónT1068 Exploitation for Privilege Escalationprivilege escalation85 %
Impacto principalT1059 Command and Scripting Interpreterexecution75 %

Vulnerabilidad de UAF en kernel Linux con acceso local (AV:L, PR:L) explotable sin interacción. El CWE-416 (Use After Free) permite ejecución de código arbitrario desde contexto de usuario con privilegios locales.

Inferido por nuestro agente de análisis a partir de la descripción oficial, el vector CVSS y la CWE, y comprobado por un supervisor. Puede contener errores.

🛡️ Mitigaciones ATT&CK que cubren estas técnicas

Execution Prevention Threat Intelligence Program Restrict Web-Based Content Privileged Account Management Limit Software Installation Behavior Prevention on Endpoint

Tecnologías afectadas (1)

Linux — Linux Kernel

CWE

CWE-416

Referencias

JSON original (NVD)

Mostrar

{
  "id": "CVE-2025-38554",
  "cveTags": [],
  "metrics": {
    "cvssMetricV31": [
      {
        "type": "Secondary",
        "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "cvssData": {
          "scope": "UNCHANGED",
          "version": "3.1",
          "baseScore": 7.8,
          "attackVector": "LOCAL",
          "baseSeverity": "HIGH",
          "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
          "integrityImpact": "HIGH",
          "userInteraction": "NONE",
          "attackComplexity": "LOW",
          "availabilityImpact": "HIGH",
          "privilegesRequired": "LOW",
          "confidentialityImpact": "HIGH"
        },
        "impactScore": 5.9,
        "exploitabilityScore": 1.8
      },
      {
        "type": "Primary",
        "source": "nvd@nist.gov",
        "cvssData": {
          "scope": "UNCHANGED",
          "version": "3.1",
          "baseScore": 7.8,
          "attackVector": "LOCAL",
          "baseSeverity": "HIGH",
          "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
          "integrityImpact": "HIGH",
          "userInteraction": "NONE",
          "attackComplexity": "LOW",
          "availabilityImpact": "HIGH",
          "privilegesRequired": "LOW",
          "confidentialityImpact": "HIGH"
        },
        "impactScore": 5.9,
        "exploitabilityScore": 1.8
      }
    ]
  },
  "affected": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "affectedData": [
        {
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "product": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "3104138517fc66aad21f4a2487bb572e9fc2e3ec",
              "lessThan": "6e88fe54721dee17d3496bc998f0c7d243896348",
              "versionType": "git"
            },
            {
              "status": "affected",
              "version": "3104138517fc66aad21f4a2487bb572e9fc2e3ec",
              "lessThan": "1bcd236a2536a451e385f8d6d2bb589689ec812f",
              "versionType": "git"
            },
            {
              "status": "affected",
              "version": "3104138517fc66aad21f4a2487bb572e9fc2e3ec",
              "lessThan": "9bbffee67ffd16360179327b57f3b1245579ef08",
              "versionType": "git"
            }
          ],
          "programFiles": [
            "include/linux/mmap_lock.h",
            "mm/mmap_lock.c"
          ],
          "defaultStatus": "unaffected"
        },
        {
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "product": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "6.15"
            },
            {
              "status": "unaffected",
              "version": "0",
              "lessThan": "6.15",
              "versionType": "semver"
            },
            {
              "status": "unaffected",
              "version": "6.15.10",
              "versionType": "semver",
              "lessThanOrEqual": "6.15.*"
            },
            {
              "status": "unaffected",
              "version": "6.16.1",
              "versionType": "semver",
              "lessThanOrEqual": "6.16.*"
            },
            {
              "status": "unaffected",
              "version": "6.17",
              "versionType": "original_commit_for_fix",
              "lessThanOrEqual": "*"
            }
          ],
          "programFiles": [
            "include/linux/mmap_lock.h",
            "mm/mmap_lock.c"
          ],
          "defaultStatus": "affected"
        }
      ]
    }
  ],
  "published": "2025-08-19T17:15:31.510",
  "references": [
    {
      "url": "https://git.kernel.org/stable/c/1bcd236a2536a451e385f8d6d2bb589689ec812f",
      "tags": [
        "Patch"
      ],
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
    },
    {
      "url": "https://git.kernel.org/stable/c/6e88fe54721dee17d3496bc998f0c7d243896348",
      "tags": [
        "Patch"
      ],
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
    },
    {
      "url": "https://git.kernel.org/stable/c/9bbffee67ffd16360179327b57f3b1245579ef08",
      "tags": [
        "Patch"
      ],
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
    }
  ],
  "vulnStatus": "Modified",
  "weaknesses": [
    {
      "type": "Primary",
      "source": "nvd@nist.gov",
      "description": [
        {
          "lang": "en",
          "value": "CWE-416"
        }
      ]
    }
  ],
  "descriptions": [
    {
      "lang": "en",
      "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm: fix a UAF when vma->mm is freed after vma->vm_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's 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->vm_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 ->vm_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->vm_mm. \nThis is wrong: It implicitly assumes that the caller is keeping the VMA's\nmm alive, but in this scenario the caller has no relation to the VMA's 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          <VMA gets removed from mm>\n                      mmap\n                        <the same VMA is reallocated>\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                            <finish operation>\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->vm_mm verification into vma_start_read() and\ngrab vma->vm_mm to stabilize it before vma_refcount_put() operation.\n\n[surenb@google.com: v3]"
    },
    {
      "lang": "es",
      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm: se corrige un UAF cuando vma-&gt;mm se libera después de que vma-&gt;vm_refcnt se eliminara. Al inducir retrasos en los lugares adecuados, Jann Horn creó un reproductor para un problema de UAF difícil de alcanzar que se hizo posible después de que se permitiera reciclar los VMA agregando SLAB_TYPESAFE_BY_RCU a su caché. La descripción de la ejecución se tomó prestada del informe de descubrimiento de Jann: lock_vma_under_rcu() busca un VMA sin bloqueo con mas_walk() bajo rcu_read_lock(). En ese punto, el VMA puede liberarse simultáneamente y puede reciclarse por otro proceso. vma_start_read() luego incrementa vma-&gt;vm_refcnt (si está en un rango aceptable) y, si esto tiene éxito, vma_start_read() puede devolver un VMA reciclado. En este escenario, donde el VMA se ha reciclado, lock_vma_under_rcu() detectará el puntero -&gt;vm_mm no coincidente y eliminará el VMA mediante vma_end_read(), que llama a vma_refcount_put(). vma_refcount_put() elimina el recuento de referencias y luego llama a rcuwait_wake_up() usando una copia de vma-&gt;vm_mm. Esto es incorrecto: asume implícitamente que quien llama mantiene activo el mm del VMA, pero en este escenario, quien llama no tiene relación con el mm del VMA, por lo que rcuwait_wake_up() puede causar UAF. El diagrama que representa la ejecución: T1 T2 T3 == == == lock_vma_under_rcu mas_walk  mmap  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  rcuwait_wake_up [UAF] Tenga en cuenta que rcuwait_wait_event() en T3 no se bloquea porque refcount ya fue descartado por T1. En este punto, T3 puede salir y liberar el mm que causa UAF en T1. Para evitar esto, movemos la verificación vma-&gt;vm_mm a vma_start_read() y tomamos vma-&gt;vm_mm para estabilizarlo antes de la operación vma_refcount_put(). [surenb@google.com: v3]"
    }
  ],
  "lastModified": "2026-07-30T06:23:25.660",
  "configurations": [
    {
      "nodes": [
        {
          "negate": false,
          "cpeMatch": [
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
              "vulnerable": true,
              "matchCriteriaId": "2EA7D98E-F04C-44BE-AC61-F5ADC4C88EC6",
              "versionEndExcluding": "6.15.10",
              "versionStartIncluding": "6.15"
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
              "vulnerable": true,
              "matchCriteriaId": "58182352-D7DF-4CC9-841E-03C1D852C3FB",
              "versionEndExcluding": "6.16.1",
              "versionStartIncluding": "6.16"
            }
          ],
          "operator": "OR"
        }
      ]
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}