CVE-2026-23077 (GCVE-0-2026-23077)

Vulnerability from cvelistv5 – Published: 2026-02-04 16:08 – Updated: 2026-05-11 21:59
VLAI?
Title
mm/vma: fix anon_vma UAF on mremap() faulted, unfaulted merge
Summary
In the Linux kernel, the following vulnerability has been resolved: mm/vma: fix anon_vma UAF on mremap() faulted, unfaulted merge Patch series "mm/vma: fix anon_vma UAF on mremap() faulted, unfaulted merge", v2. Commit 879bca0a2c4f ("mm/vma: fix incorrectly disallowed anonymous VMA merges") introduced the ability to merge previously unavailable VMA merge scenarios. However, it is handling merges incorrectly when it comes to mremap() of a faulted VMA adjacent to an unfaulted VMA. The issues arise in three cases: 1. Previous VMA unfaulted: copied -----| v |-----------|.............| | unfaulted |(faulted VMA)| |-----------|.............| prev 2. Next VMA unfaulted: copied -----| v |.............|-----------| |(faulted VMA)| unfaulted | |.............|-----------| next 3. Both adjacent VMAs unfaulted: copied -----| v |-----------|.............|-----------| | unfaulted |(faulted VMA)| unfaulted | |-----------|.............|-----------| prev next This series fixes each of these cases, and introduces self tests to assert that the issues are corrected. I also test a further case which was already handled, to assert that my changes continues to correctly handle it: 4. prev unfaulted, next faulted: copied -----| v |-----------|.............|-----------| | unfaulted |(faulted VMA)| faulted | |-----------|.............|-----------| prev next This bug was discovered via a syzbot report, linked to in the first patch in the series, I confirmed that this series fixes the bug. I also discovered that we are failing to check that the faulted VMA was not forked when merging a copied VMA in cases 1-3 above, an issue this series also addresses. I also added self tests to assert that this is resolved (and confirmed that the tests failed prior to this). I also cleaned up vma_expand() as part of this work, renamed vma_had_uncowed_parents() to vma_is_fork_child() as the previous name was unduly confusing, and simplified the comments around this function. This patch (of 4): Commit 879bca0a2c4f ("mm/vma: fix incorrectly disallowed anonymous VMA merges") introduced the ability to merge previously unavailable VMA merge scenarios. The key piece of logic introduced was the ability to merge a faulted VMA immediately next to an unfaulted VMA, which relies upon dup_anon_vma() to correctly handle anon_vma state. In the case of the merge of an existing VMA (that is changing properties of a VMA and then merging if those properties are shared by adjacent VMAs), dup_anon_vma() is invoked correctly. However in the case of the merge of a new VMA, a corner case peculiar to mremap() was missed. The issue is that vma_expand() only performs dup_anon_vma() if the target (the VMA that will ultimately become the merged VMA): is not the next VMA, i.e. the one that appears after the range in which the new VMA is to be established. A key insight here is that in all other cases other than mremap(), a new VMA merge either expands an existing VMA, meaning that the target VMA will be that VMA, or would have anon_vma be NULL. Specifically: * __mmap_region() - no anon_vma in place, initial mapping. * do_brk_flags() - expanding an existing VMA. * vma_merge_extend() - expanding an existing VMA. * relocate_vma_down() - no anon_vma in place, initial mapping. In addition, we are in the unique situation of needing to duplicate anon_vma state from a VMA that is neither the previous or next VMA being merged with. dup_anon_vma() deals exclusively with the target=unfaulted, src=faulted case. This leaves four possibilities, in each case where the copied VMA is faulted: 1. Previous VMA unfaulted: copied -----| ---truncated---
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
Linux Linux Affected: 879bca0a2c4f40b08d09a95a2a0c3c6513060b5c , < a4d9dbfc1bab16e25fefd34b5e537a46bed8fc96 (git)
Affected: 879bca0a2c4f40b08d09a95a2a0c3c6513060b5c , < 61f67c230a5e7c741c352349ea80147fbe65bfae (git)
Create a notification for this product.
Linux Linux Affected: 6.16
Unaffected: 0 , < 6.16 (semver)
Unaffected: 6.18.8 , ≤ 6.18.* (semver)
Unaffected: 6.19 , ≤ * (original_commit_for_fix)
Create a notification for this product.
Show details on NVD website
To clipboard 

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "mm/vma.c",
            "mm/vma.h"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "a4d9dbfc1bab16e25fefd34b5e537a46bed8fc96",
              "status": "affected",
              "version": "879bca0a2c4f40b08d09a95a2a0c3c6513060b5c",
              "versionType": "git"
            },
            {
              "lessThan": "61f67c230a5e7c741c352349ea80147fbe65bfae",
              "status": "affected",
              "version": "879bca0a2c4f40b08d09a95a2a0c3c6513060b5c",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "mm/vma.c",
            "mm/vma.h"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "6.16"
            },
            {
              "lessThan": "6.16",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.18.*",
              "status": "unaffected",
              "version": "6.18.8",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "6.19",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.18.8",
                  "versionStartIncluding": "6.16",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.19",
                  "versionStartIncluding": "6.16",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/vma: fix anon_vma UAF on mremap() faulted, unfaulted merge\n\nPatch series \"mm/vma: fix anon_vma UAF on mremap() faulted, unfaulted\nmerge\", v2.\n\nCommit 879bca0a2c4f (\"mm/vma: fix incorrectly disallowed anonymous VMA\nmerges\") introduced the ability to merge previously unavailable VMA merge\nscenarios.\n\nHowever, it is handling merges incorrectly when it comes to mremap() of a\nfaulted VMA adjacent to an unfaulted VMA.  The issues arise in three\ncases:\n\n1. Previous VMA unfaulted:\n\n              copied -----|\n                          v\n\t|-----------|.............|\n\t| unfaulted |(faulted VMA)|\n\t|-----------|.............|\n\t     prev\n\n2. Next VMA unfaulted:\n\n              copied -----|\n                          v\n\t            |.............|-----------|\n\t            |(faulted VMA)| unfaulted |\n                    |.............|-----------|\n\t\t                      next\n\n3. Both adjacent VMAs unfaulted:\n\n              copied -----|\n                          v\n\t|-----------|.............|-----------|\n\t| unfaulted |(faulted VMA)| unfaulted |\n\t|-----------|.............|-----------|\n\t     prev                      next\n\nThis series fixes each of these cases, and introduces self tests to assert\nthat the issues are corrected.\n\nI also test a further case which was already handled, to assert that my\nchanges continues to correctly handle it:\n\n4. prev unfaulted, next faulted:\n\n              copied -----|\n                          v\n\t|-----------|.............|-----------|\n\t| unfaulted |(faulted VMA)|  faulted  |\n\t|-----------|.............|-----------|\n\t     prev                      next\n\nThis bug was discovered via a syzbot report, linked to in the first patch\nin the series, I confirmed that this series fixes the bug.\n\nI also discovered that we are failing to check that the faulted VMA was\nnot forked when merging a copied VMA in cases 1-3 above, an issue this\nseries also addresses.\n\nI also added self tests to assert that this is resolved (and confirmed\nthat the tests failed prior to this).\n\nI also cleaned up vma_expand() as part of this work, renamed\nvma_had_uncowed_parents() to vma_is_fork_child() as the previous name was\nunduly confusing, and simplified the comments around this function.\n\n\nThis patch (of 4):\n\nCommit 879bca0a2c4f (\"mm/vma: fix incorrectly disallowed anonymous VMA\nmerges\") introduced the ability to merge previously unavailable VMA merge\nscenarios.\n\nThe key piece of logic introduced was the ability to merge a faulted VMA\nimmediately next to an unfaulted VMA, which relies upon dup_anon_vma() to\ncorrectly handle anon_vma state.\n\nIn the case of the merge of an existing VMA (that is changing properties\nof a VMA and then merging if those properties are shared by adjacent\nVMAs), dup_anon_vma() is invoked correctly.\n\nHowever in the case of the merge of a new VMA, a corner case peculiar to\nmremap() was missed.\n\nThe issue is that vma_expand() only performs dup_anon_vma() if the target\n(the VMA that will ultimately become the merged VMA): is not the next VMA,\ni.e.  the one that appears after the range in which the new VMA is to be\nestablished.\n\nA key insight here is that in all other cases other than mremap(), a new\nVMA merge either expands an existing VMA, meaning that the target VMA will\nbe that VMA, or would have anon_vma be NULL.\n\nSpecifically:\n\n* __mmap_region() - no anon_vma in place, initial mapping.\n* do_brk_flags() - expanding an existing VMA.\n* vma_merge_extend() - expanding an existing VMA.\n* relocate_vma_down() - no anon_vma in place, initial mapping.\n\nIn addition, we are in the unique situation of needing to duplicate\nanon_vma state from a VMA that is neither the previous or next VMA being\nmerged with.\n\ndup_anon_vma() deals exclusively with the target=unfaulted, src=faulted\ncase.  This leaves four possibilities, in each case where the copied VMA\nis faulted:\n\n1. Previous VMA unfaulted:\n\n              copied -----|\n                       \n---truncated---"
        }
      ],
      "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"
          }
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-05-11T21:59:33.441Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/a4d9dbfc1bab16e25fefd34b5e537a46bed8fc96"
        },
        {
          "url": "https://git.kernel.org/stable/c/61f67c230a5e7c741c352349ea80147fbe65bfae"
        }
      ],
      "title": "mm/vma: fix anon_vma UAF on mremap() faulted, unfaulted merge",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2026-23077",
    "datePublished": "2026-02-04T16:08:02.274Z",
    "dateReserved": "2026-01-13T15:37:45.959Z",
    "dateUpdated": "2026-05-11T21:59:33.441Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2026-23077",
      "date": "2026-05-20",
      "epss": "0.00019",
      "percentile": "0.05379"
    },
    "nvd": "{\"cve\":{\"id\":\"CVE-2026-23077\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2026-02-04T17:16:18.443\",\"lastModified\":\"2026-04-03T14:16:22.800\",\"vulnStatus\":\"Modified\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"In the Linux kernel, the following vulnerability has been resolved:\\n\\nmm/vma: fix anon_vma UAF on mremap() faulted, unfaulted merge\\n\\nPatch series \\\"mm/vma: fix anon_vma UAF on mremap() faulted, unfaulted\\nmerge\\\", v2.\\n\\nCommit 879bca0a2c4f (\\\"mm/vma: fix incorrectly disallowed anonymous VMA\\nmerges\\\") introduced the ability to merge previously unavailable VMA merge\\nscenarios.\\n\\nHowever, it is handling merges incorrectly when it comes to mremap() of a\\nfaulted VMA adjacent to an unfaulted VMA.  The issues arise in three\\ncases:\\n\\n1. Previous VMA unfaulted:\\n\\n              copied -----|\\n                          v\\n\\t|-----------|.............|\\n\\t| unfaulted |(faulted VMA)|\\n\\t|-----------|.............|\\n\\t     prev\\n\\n2. Next VMA unfaulted:\\n\\n              copied -----|\\n                          v\\n\\t            |.............|-----------|\\n\\t            |(faulted VMA)| unfaulted |\\n                    |.............|-----------|\\n\\t\\t                      next\\n\\n3. Both adjacent VMAs unfaulted:\\n\\n              copied -----|\\n                          v\\n\\t|-----------|.............|-----------|\\n\\t| unfaulted |(faulted VMA)| unfaulted |\\n\\t|-----------|.............|-----------|\\n\\t     prev                      next\\n\\nThis series fixes each of these cases, and introduces self tests to assert\\nthat the issues are corrected.\\n\\nI also test a further case which was already handled, to assert that my\\nchanges continues to correctly handle it:\\n\\n4. prev unfaulted, next faulted:\\n\\n              copied -----|\\n                          v\\n\\t|-----------|.............|-----------|\\n\\t| unfaulted |(faulted VMA)|  faulted  |\\n\\t|-----------|.............|-----------|\\n\\t     prev                      next\\n\\nThis bug was discovered via a syzbot report, linked to in the first patch\\nin the series, I confirmed that this series fixes the bug.\\n\\nI also discovered that we are failing to check that the faulted VMA was\\nnot forked when merging a copied VMA in cases 1-3 above, an issue this\\nseries also addresses.\\n\\nI also added self tests to assert that this is resolved (and confirmed\\nthat the tests failed prior to this).\\n\\nI also cleaned up vma_expand() as part of this work, renamed\\nvma_had_uncowed_parents() to vma_is_fork_child() as the previous name was\\nunduly confusing, and simplified the comments around this function.\\n\\n\\nThis patch (of 4):\\n\\nCommit 879bca0a2c4f (\\\"mm/vma: fix incorrectly disallowed anonymous VMA\\nmerges\\\") introduced the ability to merge previously unavailable VMA merge\\nscenarios.\\n\\nThe key piece of logic introduced was the ability to merge a faulted VMA\\nimmediately next to an unfaulted VMA, which relies upon dup_anon_vma() to\\ncorrectly handle anon_vma state.\\n\\nIn the case of the merge of an existing VMA (that is changing properties\\nof a VMA and then merging if those properties are shared by adjacent\\nVMAs), dup_anon_vma() is invoked correctly.\\n\\nHowever in the case of the merge of a new VMA, a corner case peculiar to\\nmremap() was missed.\\n\\nThe issue is that vma_expand() only performs dup_anon_vma() if the target\\n(the VMA that will ultimately become the merged VMA): is not the next VMA,\\ni.e.  the one that appears after the range in which the new VMA is to be\\nestablished.\\n\\nA key insight here is that in all other cases other than mremap(), a new\\nVMA merge either expands an existing VMA, meaning that the target VMA will\\nbe that VMA, or would have anon_vma be NULL.\\n\\nSpecifically:\\n\\n* __mmap_region() - no anon_vma in place, initial mapping.\\n* do_brk_flags() - expanding an existing VMA.\\n* vma_merge_extend() - expanding an existing VMA.\\n* relocate_vma_down() - no anon_vma in place, initial mapping.\\n\\nIn addition, we are in the unique situation of needing to duplicate\\nanon_vma state from a VMA that is neither the previous or next VMA being\\nmerged with.\\n\\ndup_anon_vma() deals exclusively with the target=unfaulted, src=faulted\\ncase.  This leaves four possibilities, in each case where the copied VMA\\nis faulted:\\n\\n1. Previous VMA unfaulted:\\n\\n              copied -----|\\n                       \\n---truncated---\"},{\"lang\":\"es\",\"value\":\"En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:  mm/vma: corrige UAF de anon_vma en mremap() con fusi\u00f3n de VMA faulted y unfaulted  Serie de parches \\\"mm/vma: corrige UAF de anon_vma en mremap() con fusi\u00f3n de VMA faulted y unfaulted\\\", v2.  El commit 879bca0a2c4f (\u0027mm/vma: corrige fusiones de VMA an\u00f3nimas incorrectamente denegadas\u0027) introdujo la capacidad de fusionar escenarios de fusi\u00f3n de VMA previamente no disponibles.  Sin embargo, est\u00e1 manejando las fusiones incorrectamente cuando se trata de mremap() de un VMA faulted adyacente a un VMA unfaulted. Los problemas surgen en tres casos:  1. VMA anterior unfaulted:copiado -----|           v  .............|  | unfaulted |(VMA faulted)|  .............|       anterior  2. Siguiente VMA unfaulted:copiado -----|           v                            |(VMA faulted)| unfaulted |              siguiente  3. Ambos VMA adyacentes unfaulted:copiado -----|           v  .............  | unfaulted |(VMA faulted)| unfaulted |  .............       anterior  siguiente  Esta serie corrige cada uno de estos casos e introduce auto-pruebas para afirmar que los problemas est\u00e1n corregidos.  Tambi\u00e9n pruebo un caso adicional que ya estaba manejado, para afirmar que mis cambios contin\u00faan manej\u00e1ndolo correctamente:  4. anterior unfaulted, siguiente faulted:copiado -----| v  .............  | unfaulted |(VMA faulted)|  faulted  |  .............       anterior  siguiente  Este error fue descubierto a trav\u00e9s de un informe de syzbot, enlazado en el primer parche de la serie, confirm\u00e9 que esta serie corrige el error.  Tambi\u00e9n descubr\u00ed que no estamos verificando que el VMA faulted no fue bifurcado al fusionar un VMA copiado en los casos 1-3 anteriores, un problema que esta serie tambi\u00e9n aborda.  Tambi\u00e9n agregu\u00e9 auto-pruebas para afirmar que esto est\u00e1 resuelto (y confirm\u00e9 que las pruebas fallaron antes de esto).  Tambi\u00e9n limpi\u00e9 vma_expand() como parte de este trabajo, renombr\u00e9 vma_had_uncowed_parents() a vma_is_fork_child() ya que el nombre anterior era indebidamente confuso, y simplifiqu\u00e9 los comentarios alrededor de esta funci\u00f3n.   Este parche (de 4):  El commit 879bca0a2c4f (\u0027mm/vma: corrige fusiones de VMA an\u00f3nimas incorrectamente denegadas\u0027) introdujo la capacidad de fusionar escenarios de fusi\u00f3n de VMA previamente no disponibles.  La pieza clave de l\u00f3gica introducida fue la capacidad de fusionar un VMA faulted inmediatamente adyacente a un VMA unfaulted, lo cual se basa en dup_anon_vma() para manejar correctamente el estado de anon_vma.  En el caso de la fusi\u00f3n de un VMA existente (es decir, cambiando propiedades de un VMA y luego fusionando si esas propiedades son compartidas por VMA adyacentes), dup_anon_vma() se invoca correctamente.  Sin embargo, en el caso de la fusi\u00f3n de un nuevo VMA, se pas\u00f3 por alto un caso particular peculiar de mremap().  El problema es que vma_expand() solo realiza dup_anon_vma() si el objetivo (el VMA que finalmente se convertir\u00e1 en el VMA fusionado): no es el siguiente VMA, es decir, el que aparece despu\u00e9s del rango en el que se establecer\u00e1 el nuevo VMA.  Una idea clave aqu\u00ed es que en todos los dem\u00e1s casos, aparte de mremap(), una nueva fusi\u00f3n de VMA o bien expande un VMA existente, lo que significa que el VMA objetivo ser\u00e1 ese VMA, o anon_vma ser\u00eda NULL.  Espec\u00edficamente:  * __mmap_region() - no hay anon_vma en su lugar, mapeo inicial. * do_brk_flags() - expandiendo un VMA existente. * vma_merge_extend() - expandiendo un VMA existente. * relocate_vma_down() - no hay anon_vma en su lugar, mapeo inicial.  Adem\u00e1s, nos encontramos en la situaci\u00f3n \u00fanica de necesitar duplicar el estado de anon_vma de un VMA que no es ni el VMA anterior ni el siguiente con el que se est\u00e1 fusionando.  dup_anon_vma() se ocupa exclusivamente del caso objetivo=unfaulted, fuente=faulted. Esto deja cuatro posibilidades, en cada caso donde el VMA copiado es faulted:  1. VMA anterior unfaulted:copiado -----|         ---truncado---\"}],\"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.16\",\"versionEndExcluding\":\"6.18.8\",\"matchCriteriaId\":\"467E1359-7F6A-4790-AC45-172024944460\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.19:rc1:*:*:*:*:*:*\",\"matchCriteriaId\":\"17B67AA7-40D6-4AFA-8459-F200F3D7CFD1\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.19:rc2:*:*:*:*:*:*\",\"matchCriteriaId\":\"C47E4CC9-C826-4FA9-B014-7FE3D9B318B2\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.19:rc3:*:*:*:*:*:*\",\"matchCriteriaId\":\"F71D92C0-C023-48BD-B3B6-70B638EEE298\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.19:rc4:*:*:*:*:*:*\",\"matchCriteriaId\":\"13580667-0A98-40CC-B29F-D12790B91BDB\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.19:rc5:*:*:*:*:*:*\",\"matchCriteriaId\":\"CAD1FED7-CF48-47BF-AC7D-7B6FA3C065FC\"}]}]}],\"references\":[{\"url\":\"https://git.kernel.org/stable/c/61f67c230a5e7c741c352349ea80147fbe65bfae\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/a4d9dbfc1bab16e25fefd34b5e537a46bed8fc96\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]}]}}"
  }
}


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.