CVE-2024-56786
Vulnerability from cvelistv5
Published
2025-01-08 17:52
Modified
2025-02-11 15:45
Severity ?
7.8 (High) - CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Summary
In the Linux kernel, the following vulnerability has been resolved: bpf: put bpf_link's program when link is safe to be deallocated In general, BPF link's underlying BPF program should be considered to be reachable through attach hook -> link -> prog chain, and, pessimistically, we have to assume that as long as link's memory is not safe to free, attach hook's code might hold a pointer to BPF program and use it. As such, it's not (generally) correct to put link's program early before waiting for RCU GPs to go through. More eager bpf_prog_put() that we currently do is mostly correct due to BPF program's release code doing similar RCU GP waiting, but as will be shown in the following patches, BPF program can be non-sleepable (and, thus, reliant on only "classic" RCU GP), while BPF link's attach hook can have sleepable semantics and needs to be protected by RCU Tasks Trace, and for such cases BPF link has to go through RCU Tasks Trace + "classic" RCU GPs before being deallocated. And so, if we put BPF program early, we might free BPF program before we free BPF link, leading to use-after-free situation. So, this patch defers bpf_prog_put() until we are ready to perform bpf_link's deallocation. At worst, this delays BPF program freeing by one extra RCU GP, but that seems completely acceptable. Alternatively, we'd need more elaborate ways to determine BPF hook, BPF link, and BPF program lifetimes, and how they relate to each other, which seems like an unnecessary complication. Note, for most BPF links we still will perform eager bpf_prog_put() and link dealloc, so for those BPF links there are no observable changes whatsoever. Only BPF links that use deferred dealloc might notice slightly delayed freeing of BPF programs. Also, to reduce code and logic duplication, extract program put + link dealloc logic into bpf_link_dealloc() helper.
References
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/2fcb921c2799c49ac5e365cf4110f94a64ae4885Patch
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/5fe23c57abadfd46a7a66e81f3536e4757252a0bPatch
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/f44ec8733a8469143fde1984b5e6931b2e2f6f3fPatch
Impacted products
Vendor Product Version
Linux Linux Version: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
Version: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
Version: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
 Create a notification for this product.
   Linux Linux Create a notification for this product.
Show details on NVD website

To clipboard 

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "cvssV3_1": {
              "attackComplexity": "LOW",
              "attackVector": "LOCAL",
              "availabilityImpact": "HIGH",
              "baseScore": 7.8,
              "baseSeverity": "HIGH",
              "confidentialityImpact": "HIGH",
              "integrityImpact": "HIGH",
              "privilegesRequired": "LOW",
              "scope": "UNCHANGED",
              "userInteraction": "NONE",
              "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
              "version": "3.1"
            }
          },
          {
            "other": {
              "content": {
                "id": "CVE-2024-56786",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "total"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2025-02-11T15:41:15.590405Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "problemTypes": [
          {
            "descriptions": [
              {
                "cweId": "CWE-416",
                "description": "CWE-416 Use After Free",
                "lang": "en",
                "type": "CWE"
              }
            ]
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2025-02-11T15:45:20.513Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "kernel/bpf/syscall.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "5fe23c57abadfd46a7a66e81f3536e4757252a0b",
              "status": "affected",
              "version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
              "versionType": "git"
            },
            {
              "lessThan": "2fcb921c2799c49ac5e365cf4110f94a64ae4885",
              "status": "affected",
              "version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
              "versionType": "git"
            },
            {
              "lessThan": "f44ec8733a8469143fde1984b5e6931b2e2f6f3f",
              "status": "affected",
              "version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "kernel/bpf/syscall.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThanOrEqual": "6.6.*",
              "status": "unaffected",
              "version": "6.6.66",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.12.*",
              "status": "unaffected",
              "version": "6.12.5",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "6.13",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: put bpf_link\u0027s program when link is safe to be deallocated\n\nIn general, BPF link\u0027s underlying BPF program should be considered to be\nreachable through attach hook -\u003e link -\u003e prog chain, and, pessimistically,\nwe have to assume that as long as link\u0027s memory is not safe to free,\nattach hook\u0027s code might hold a pointer to BPF program and use it.\n\nAs such, it\u0027s not (generally) correct to put link\u0027s program early before\nwaiting for RCU GPs to go through. More eager bpf_prog_put() that we\ncurrently do is mostly correct due to BPF program\u0027s release code doing\nsimilar RCU GP waiting, but as will be shown in the following patches,\nBPF program can be non-sleepable (and, thus, reliant on only \"classic\"\nRCU GP), while BPF link\u0027s attach hook can have sleepable semantics and\nneeds to be protected by RCU Tasks Trace, and for such cases BPF link\nhas to go through RCU Tasks Trace + \"classic\" RCU GPs before being\ndeallocated. And so, if we put BPF program early, we might free BPF\nprogram before we free BPF link, leading to use-after-free situation.\n\nSo, this patch defers bpf_prog_put() until we are ready to perform\nbpf_link\u0027s deallocation. At worst, this delays BPF program freeing by\none extra RCU GP, but that seems completely acceptable. Alternatively,\nwe\u0027d need more elaborate ways to determine BPF hook, BPF link, and BPF\nprogram lifetimes, and how they relate to each other, which seems like\nan unnecessary complication.\n\nNote, for most BPF links we still will perform eager bpf_prog_put() and\nlink dealloc, so for those BPF links there are no observable changes\nwhatsoever. Only BPF links that use deferred dealloc might notice\nslightly delayed freeing of BPF programs.\n\nAlso, to reduce code and logic duplication, extract program put + link\ndealloc logic into bpf_link_dealloc() helper."
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2025-01-20T06:28:09.164Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/5fe23c57abadfd46a7a66e81f3536e4757252a0b"
        },
        {
          "url": "https://git.kernel.org/stable/c/2fcb921c2799c49ac5e365cf4110f94a64ae4885"
        },
        {
          "url": "https://git.kernel.org/stable/c/f44ec8733a8469143fde1984b5e6931b2e2f6f3f"
        }
      ],
      "title": "bpf: put bpf_link\u0027s program when link is safe to be deallocated",
      "x_generator": {
        "engine": "bippy-5f407fcff5a0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2024-56786",
    "datePublished": "2025-01-08T17:52:02.435Z",
    "dateReserved": "2024-12-29T11:26:39.770Z",
    "dateUpdated": "2025-02-11T15:45:20.513Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1",
  "vulnerability-lookup:meta": {
    "nvd": "{\"cve\":{\"id\":\"CVE-2024-56786\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2025-01-08T18:15:19.633\",\"lastModified\":\"2025-02-11T16:15:48.100\",\"vulnStatus\":\"Modified\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"In the Linux kernel, the following vulnerability has been resolved:\\n\\nbpf: put bpf_link\u0027s program when link is safe to be deallocated\\n\\nIn general, BPF link\u0027s underlying BPF program should be considered to be\\nreachable through attach hook -\u003e link -\u003e prog chain, and, pessimistically,\\nwe have to assume that as long as link\u0027s memory is not safe to free,\\nattach hook\u0027s code might hold a pointer to BPF program and use it.\\n\\nAs such, it\u0027s not (generally) correct to put link\u0027s program early before\\nwaiting for RCU GPs to go through. More eager bpf_prog_put() that we\\ncurrently do is mostly correct due to BPF program\u0027s release code doing\\nsimilar RCU GP waiting, but as will be shown in the following patches,\\nBPF program can be non-sleepable (and, thus, reliant on only \\\"classic\\\"\\nRCU GP), while BPF link\u0027s attach hook can have sleepable semantics and\\nneeds to be protected by RCU Tasks Trace, and for such cases BPF link\\nhas to go through RCU Tasks Trace + \\\"classic\\\" RCU GPs before being\\ndeallocated. And so, if we put BPF program early, we might free BPF\\nprogram before we free BPF link, leading to use-after-free situation.\\n\\nSo, this patch defers bpf_prog_put() until we are ready to perform\\nbpf_link\u0027s deallocation. At worst, this delays BPF program freeing by\\none extra RCU GP, but that seems completely acceptable. Alternatively,\\nwe\u0027d need more elaborate ways to determine BPF hook, BPF link, and BPF\\nprogram lifetimes, and how they relate to each other, which seems like\\nan unnecessary complication.\\n\\nNote, for most BPF links we still will perform eager bpf_prog_put() and\\nlink dealloc, so for those BPF links there are no observable changes\\nwhatsoever. Only BPF links that use deferred dealloc might notice\\nslightly delayed freeing of BPF programs.\\n\\nAlso, to reduce code and logic duplication, extract program put + link\\ndealloc logic into bpf_link_dealloc() helper.\"},{\"lang\":\"es\",\"value\":\"En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: poner el programa de bpf_link cuando es seguro desasignarlo En general, se debe considerar que el programa BPF subyacente del enlace BPF es accesible a trav\u00e9s de la cadena de gancho de conexi\u00f3n -\u0026gt; enlace -\u0026gt; programa y, de manera pesimista, tenemos que asumir que mientras no sea seguro liberar la memoria del enlace, el c\u00f3digo del gancho de conexi\u00f3n podr\u00eda contener un puntero al programa BPF y usarlo. Como tal, no es (generalmente) correcto poner el programa del enlace antes de esperar a que pasen los GP de RCU. El bpf_prog_put() m\u00e1s ansioso que hacemos actualmente es mayormente correcto debido a que el c\u00f3digo de lanzamiento del programa BPF hace una espera similar de GP RCU, pero como se mostrar\u00e1 en los parches siguientes, el programa BPF puede no ser inactivo (y, por lo tanto, depender solo del GP RCU \\\"cl\u00e1sico\\\"), mientras que el gancho de conexi\u00f3n del enlace BPF puede tener sem\u00e1ntica inactiva y necesita estar protegido por el Seguimiento de tareas RCU, y para tales casos el enlace BPF tiene que pasar por el Seguimiento de tareas RCU + GP RCU \\\"cl\u00e1sicos\\\" antes de ser desasignado. Y entonces, si ponemos el programa BPF temprano, podr\u00edamos liberar el programa BPF antes de liberar el enlace BPF, lo que lleva a una situaci\u00f3n de use-after-free. Entonces, este parche pospone bpf_prog_put() hasta que estemos listos para realizar la desasignaci\u00f3n de bpf_link. En el peor de los casos, esto retrasa la liberaci\u00f3n del programa BPF por un GP RCU adicional, pero eso parece completamente aceptable. Alternativamente, necesitar\u00edamos formas m\u00e1s elaboradas de determinar el gancho BPF, el enlace BPF y la duraci\u00f3n del programa BPF, y c\u00f3mo se relacionan entre s\u00ed, lo que parece una complicaci\u00f3n innecesaria. Tenga en cuenta que, para la mayor\u00eda de los enlaces BPF, seguiremos ejecutando bpf_prog_put() y link dealloc con avidez, por lo que para esos enlaces BPF no hay cambios observables en absoluto. Solo los enlaces BPF que usan dealloc diferido pueden notar una liberaci\u00f3n ligeramente retrasada de los programas BPF. Adem\u00e1s, para reducir la duplicaci\u00f3n de c\u00f3digo y l\u00f3gica, extraiga la l\u00f3gica de put del programa + link dealloc en el asistente bpf_link_dealloc().\"}],\"metrics\":{\"cvssMetricV31\":[{\"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:N/I:N/A:H\",\"baseScore\":5.5,\"baseSeverity\":\"MEDIUM\",\"attackVector\":\"LOCAL\",\"attackComplexity\":\"LOW\",\"privilegesRequired\":\"LOW\",\"userInteraction\":\"NONE\",\"scope\":\"UNCHANGED\",\"confidentialityImpact\":\"NONE\",\"integrityImpact\":\"NONE\",\"availabilityImpact\":\"HIGH\"},\"exploitabilityScore\":1.8,\"impactScore\":3.6},{\"source\":\"134c704f-9b21-4f2e-91b3-4a467353bcc0\",\"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}]},\"weaknesses\":[{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"description\":[{\"lang\":\"en\",\"value\":\"NVD-CWE-noinfo\"}]},{\"source\":\"134c704f-9b21-4f2e-91b3-4a467353bcc0\",\"type\":\"Secondary\",\"description\":[{\"lang\":\"en\",\"value\":\"CWE-416\"}]}],\"configurations\":[{\"nodes\":[{\"operator\":\"OR\",\"negate\":false,\"cpeMatch\":[{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionEndExcluding\":\"6.6.66\",\"matchCriteriaId\":\"90A079EF-8212-45DF-84FB-C525A64635B0\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"6.7\",\"versionEndExcluding\":\"6.12.5\",\"matchCriteriaId\":\"9501D045-7A94-42CA-8B03-821BE94A65B7\"}]}]}],\"references\":[{\"url\":\"https://git.kernel.org/stable/c/2fcb921c2799c49ac5e365cf4110f94a64ae4885\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/5fe23c57abadfd46a7a66e81f3536e4757252a0b\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/f44ec8733a8469143fde1984b5e6931b2e2f6f3f\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]}]}}",
    "vulnrichment": {
      "containers": "{\"adp\": [{\"title\": \"CISA ADP Vulnrichment\", \"metrics\": [{\"cvssV3_1\": {\"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\"}}, {\"other\": {\"type\": \"ssvc\", \"content\": {\"id\": \"CVE-2024-56786\", \"role\": \"CISA Coordinator\", \"options\": [{\"Exploitation\": \"none\"}, {\"Automatable\": \"no\"}, {\"Technical Impact\": \"total\"}], \"version\": \"2.0.3\", \"timestamp\": \"2025-02-11T15:41:15.590405Z\"}}}], \"problemTypes\": [{\"descriptions\": [{\"lang\": \"en\", \"type\": \"CWE\", \"cweId\": \"CWE-416\", \"description\": \"CWE-416 Use After Free\"}]}], \"providerMetadata\": {\"orgId\": \"134c704f-9b21-4f2e-91b3-4a467353bcc0\", \"shortName\": \"CISA-ADP\", \"dateUpdated\": \"2025-02-11T15:41:16.892Z\"}}], \"cna\": {\"title\": \"bpf: put bpf_link\u0027s program when link is safe to be deallocated\", \"affected\": [{\"repo\": \"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\", \"vendor\": \"Linux\", \"product\": \"Linux\", \"versions\": [{\"status\": \"affected\", \"version\": \"1da177e4c3f41524e886b7f1b8a0c1fc7321cac2\", \"lessThan\": \"5fe23c57abadfd46a7a66e81f3536e4757252a0b\", \"versionType\": \"git\"}, {\"status\": \"affected\", \"version\": \"1da177e4c3f41524e886b7f1b8a0c1fc7321cac2\", \"lessThan\": \"2fcb921c2799c49ac5e365cf4110f94a64ae4885\", \"versionType\": \"git\"}, {\"status\": \"affected\", \"version\": \"1da177e4c3f41524e886b7f1b8a0c1fc7321cac2\", \"lessThan\": \"f44ec8733a8469143fde1984b5e6931b2e2f6f3f\", \"versionType\": \"git\"}], \"programFiles\": [\"kernel/bpf/syscall.c\"], \"defaultStatus\": \"unaffected\"}, {\"repo\": \"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\", \"vendor\": \"Linux\", \"product\": \"Linux\", \"versions\": [{\"status\": \"unaffected\", \"version\": \"6.6.66\", \"versionType\": \"semver\", \"lessThanOrEqual\": \"6.6.*\"}, {\"status\": \"unaffected\", \"version\": \"6.12.5\", \"versionType\": \"semver\", \"lessThanOrEqual\": \"6.12.*\"}, {\"status\": \"unaffected\", \"version\": \"6.13\", \"versionType\": \"original_commit_for_fix\", \"lessThanOrEqual\": \"*\"}], \"programFiles\": [\"kernel/bpf/syscall.c\"], \"defaultStatus\": \"affected\"}], \"references\": [{\"url\": \"https://git.kernel.org/stable/c/5fe23c57abadfd46a7a66e81f3536e4757252a0b\"}, {\"url\": \"https://git.kernel.org/stable/c/2fcb921c2799c49ac5e365cf4110f94a64ae4885\"}, {\"url\": \"https://git.kernel.org/stable/c/f44ec8733a8469143fde1984b5e6931b2e2f6f3f\"}], \"x_generator\": {\"engine\": \"bippy-5f407fcff5a0\"}, \"descriptions\": [{\"lang\": \"en\", \"value\": \"In the Linux kernel, the following vulnerability has been resolved:\\n\\nbpf: put bpf_link\u0027s program when link is safe to be deallocated\\n\\nIn general, BPF link\u0027s underlying BPF program should be considered to be\\nreachable through attach hook -\u003e link -\u003e prog chain, and, pessimistically,\\nwe have to assume that as long as link\u0027s memory is not safe to free,\\nattach hook\u0027s code might hold a pointer to BPF program and use it.\\n\\nAs such, it\u0027s not (generally) correct to put link\u0027s program early before\\nwaiting for RCU GPs to go through. More eager bpf_prog_put() that we\\ncurrently do is mostly correct due to BPF program\u0027s release code doing\\nsimilar RCU GP waiting, but as will be shown in the following patches,\\nBPF program can be non-sleepable (and, thus, reliant on only \\\"classic\\\"\\nRCU GP), while BPF link\u0027s attach hook can have sleepable semantics and\\nneeds to be protected by RCU Tasks Trace, and for such cases BPF link\\nhas to go through RCU Tasks Trace + \\\"classic\\\" RCU GPs before being\\ndeallocated. And so, if we put BPF program early, we might free BPF\\nprogram before we free BPF link, leading to use-after-free situation.\\n\\nSo, this patch defers bpf_prog_put() until we are ready to perform\\nbpf_link\u0027s deallocation. At worst, this delays BPF program freeing by\\none extra RCU GP, but that seems completely acceptable. Alternatively,\\nwe\u0027d need more elaborate ways to determine BPF hook, BPF link, and BPF\\nprogram lifetimes, and how they relate to each other, which seems like\\nan unnecessary complication.\\n\\nNote, for most BPF links we still will perform eager bpf_prog_put() and\\nlink dealloc, so for those BPF links there are no observable changes\\nwhatsoever. Only BPF links that use deferred dealloc might notice\\nslightly delayed freeing of BPF programs.\\n\\nAlso, to reduce code and logic duplication, extract program put + link\\ndealloc logic into bpf_link_dealloc() helper.\"}], \"providerMetadata\": {\"orgId\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\", \"shortName\": \"Linux\", \"dateUpdated\": \"2025-01-20T06:28:09.164Z\"}}}",
      "cveMetadata": "{\"cveId\": \"CVE-2024-56786\", \"state\": \"PUBLISHED\", \"dateUpdated\": \"2025-02-11T15:45:20.513Z\", \"dateReserved\": \"2024-12-29T11:26:39.770Z\", \"assignerOrgId\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\", \"datePublished\": \"2025-01-08T17:52:02.435Z\", \"assignerShortName\": \"Linux\"}",
      "dataType": "CVE_RECORD",
      "dataVersion": "5.1"
    }
  }
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




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.
  • 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.