GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration

CVE-2025-38554 (GCVE-0-2025-38554)

Vulnerability from cvelistv5 – Published: 2025-08-19 17:02 – Updated: 2026-08-05 12:02
VLAI
Title
mm: fix a UAF when vma->mm is freed after vma->vm_refcnt got dropped
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]
Severity
7.8 (High)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Assigner
References
Impacted products
Vendor Product Version CPE status
Linux Linux Affected: 3104138517fc66aad21f4a2487bb572e9fc2e3ec , < 6e88fe54721dee17d3496bc998f0c7d243896348 (git)
Affected: 3104138517fc66aad21f4a2487bb572e9fc2e3ec , < 1bcd236a2536a451e385f8d6d2bb589689ec812f (git)
Affected: 3104138517fc66aad21f4a2487bb572e9fc2e3ec , < 9bbffee67ffd16360179327b57f3b1245579ef08 (git)
guessed Create a notification for this product.
Linux Linux Affected: 6.15
Unaffected: 0 , < 6.15 (semver)
Unaffected: 6.15.10 , ≤ 6.15.* (semver)
Unaffected: 6.16.1 , ≤ 6.16.* (semver)
Unaffected: 6.17 , ≤ * (original_commit_for_fix)
guessed Create a notification for this product.
Show details on NVD website
To clipboard 

{
  "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",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2025-38554",
      "date": "2026-09-14",
      "epss": "0.00167",
      "percentile": "0.06295"
    },
    "nvd": "{\"cve\":{\"id\":\"CVE-2025-38554\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2025-08-19T17:15:31.510\",\"lastModified\":\"2026-07-30T06:23:25.660\",\"vulnStatus\":\"Modified\",\"cveTags\":[],\"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]\"},{\"lang\":\"es\",\"value\":\"En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm: se corrige un UAF cuando vma-\u0026gt;mm se libera despu\u00e9s de que vma-\u0026gt;vm_refcnt se eliminara. Al inducir retrasos en los lugares adecuados, Jann Horn cre\u00f3 un reproductor para un problema de UAF dif\u00edcil de alcanzar que se hizo posible despu\u00e9s de que se permitiera reciclar los VMA agregando SLAB_TYPESAFE_BY_RCU a su cach\u00e9. La descripci\u00f3n de la ejecuci\u00f3n se tom\u00f3 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\u00e1neamente y puede reciclarse por otro proceso. vma_start_read() luego incrementa vma-\u0026gt;vm_refcnt (si est\u00e1 en un rango aceptable) y, si esto tiene \u00e9xito, vma_start_read() puede devolver un VMA reciclado. En este escenario, donde el VMA se ha reciclado, lock_vma_under_rcu() detectar\u00e1 el puntero -\u0026gt;vm_mm no coincidente y eliminar\u00e1 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-\u0026gt;vm_mm. Esto es incorrecto: asume impl\u00edcitamente que quien llama mantiene activo el mm del VMA, pero en este escenario, quien llama no tiene relaci\u00f3n con el mm del VMA, por lo que rcuwait_wake_up() puede causar UAF. El diagrama que representa la ejecuci\u00f3n: 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\u00f3n vma-\u0026gt;vm_mm a vma_start_read() y tomamos vma-\u0026gt;vm_mm para estabilizarlo antes de la operaci\u00f3n vma_refcount_put(). [surenb@google.com: v3]\"}],\"affected\":[{\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"affectedData\":[{\"vendor\":\"Linux\",\"product\":\"Linux\",\"defaultStatus\":\"unaffected\",\"programFiles\":[\"include/linux/mmap_lock.h\",\"mm/mmap_lock.c\"],\"repo\":\"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\",\"versions\":[{\"version\":\"3104138517fc66aad21f4a2487bb572e9fc2e3ec\",\"lessThan\":\"6e88fe54721dee17d3496bc998f0c7d243896348\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"3104138517fc66aad21f4a2487bb572e9fc2e3ec\",\"lessThan\":\"1bcd236a2536a451e385f8d6d2bb589689ec812f\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"3104138517fc66aad21f4a2487bb572e9fc2e3ec\",\"lessThan\":\"9bbffee67ffd16360179327b57f3b1245579ef08\",\"versionType\":\"git\",\"status\":\"affected\"}]},{\"vendor\":\"Linux\",\"product\":\"Linux\",\"defaultStatus\":\"affected\",\"programFiles\":[\"include/linux/mmap_lock.h\",\"mm/mmap_lock.c\"],\"repo\":\"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\",\"versions\":[{\"version\":\"6.15\",\"status\":\"affected\"},{\"version\":\"0\",\"lessThan\":\"6.15\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"6.15.10\",\"lessThanOrEqual\":\"6.15.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"6.16.1\",\"lessThanOrEqual\":\"6.16.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"6.17\",\"lessThanOrEqual\":\"*\",\"versionType\":\"original_commit_for_fix\",\"status\":\"unaffected\"}]}]}],\"metrics\":{\"cvssMetricV31\":[{\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"type\":\"Secondary\",\"cvssData\":{\"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\",\"attackVector\":\"LOCAL\",\"attackComplexity\":\"LOW\",\"privilegesRequired\":\"LOW\",\"userInteraction\":\"NONE\",\"scope\":\"UNCHANGED\",\"confidentialityImpact\":\"HIGH\",\"integrityImpact\":\"HIGH\",\"availabilityImpact\":\"HIGH\"},\"exploitabilityScore\":1.8,\"impactScore\":5.9},{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"cvssData\":{\"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\",\"attackVector\":\"LOCAL\",\"attackComplexity\":\"LOW\",\"privilegesRequired\":\"LOW\",\"userInteraction\":\"NONE\",\"scope\":\"UNCHANGED\",\"confidentialityImpact\":\"HIGH\",\"integrityImpact\":\"HIGH\",\"availabilityImpact\":\"HIGH\"},\"exploitabilityScore\":1.8,\"impactScore\":5.9}]},\"weaknesses\":[{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"description\":[{\"lang\":\"en\",\"value\":\"CWE-416\"}]}],\"configurations\":[{\"nodes\":[{\"operator\":\"OR\",\"negate\":false,\"cpeMatch\":[{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"6.15\",\"versionEndExcluding\":\"6.15.10\",\"matchCriteriaId\":\"2EA7D98E-F04C-44BE-AC61-F5ADC4C88EC6\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"6.16\",\"versionEndExcluding\":\"6.16.1\",\"matchCriteriaId\":\"58182352-D7DF-4CC9-841E-03C1D852C3FB\"}]}]}],\"references\":[{\"url\":\"https://git.kernel.org/stable/c/1bcd236a2536a451e385f8d6d2bb589689ec812f\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/6e88fe54721dee17d3496bc998f0c7d243896348\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/9bbffee67ffd16360179327b57f3b1245579ef08\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]}]}}",
    "redhat_vex": {
      "aggregate_severity": "None",
      "current_release_date": "2026-06-30T10:29:55+00:00",
      "cve": "CVE-2025-38554",
      "id": "CVE-2025-38554",
      "initial_release_date": "2025-08-19T00:00:00+00:00",
      "product_status:known_not_affected": "274",
      "source": "Red Hat CSAF VEX",
      "status": "final",
      "title": "kernel: mm: fix a UAF when vma-\u003emm is freed after vma-\u003evm_refcnt got dropped",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2025/cve-2025-38554.json",
      "version": "3"
    },
    "suse_vex": {
      "aggregate_severity": "important",
      "current_release_date": "2026-09-11T16:37:37Z",
      "cve": "CVE-2025-38554",
      "id": "CVE-2025-38554",
      "initial_release_date": "2025-08-19T23:24:03Z",
      "product_status:first_fixed": "2",
      "product_status:known_not_affected": "555",
      "product_status:recommended": "158",
      "source": "SUSE CSAF VEX",
      "status": "interim",
      "title": "SUSE CVE CVE-2025-38554",
      "url": "https://ftp.suse.com/pub/projects/security/csaf-vex/cve-2025-38554.json",
      "version": "36"
    }
  }
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

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.


Detection rules are retrieved from Rulezet.