cve-2024-41009
Vulnerability from cvelistv5
Published
2024-07-17 06:10
Modified
2024-12-19 09:09
Severity ?
Summary
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix overrunning reservations in ringbuf The BPF ring buffer internally is implemented as a power-of-2 sized circular buffer, with two logical and ever-increasing counters: consumer_pos is the consumer counter to show which logical position the consumer consumed the data, and producer_pos which is the producer counter denoting the amount of data reserved by all producers. Each time a record is reserved, the producer that "owns" the record will successfully advance producer counter. In user space each time a record is read, the consumer of the data advanced the consumer counter once it finished processing. Both counters are stored in separate pages so that from user space, the producer counter is read-only and the consumer counter is read-write. One aspect that simplifies and thus speeds up the implementation of both producers and consumers is how the data area is mapped twice contiguously back-to-back in the virtual memory, allowing to not take any special measures for samples that have to wrap around at the end of the circular buffer data area, because the next page after the last data page would be first data page again, and thus the sample will still appear completely contiguous in virtual memory. Each record has a struct bpf_ringbuf_hdr { u32 len; u32 pg_off; } header for book-keeping the length and offset, and is inaccessible to the BPF program. Helpers like bpf_ringbuf_reserve() return `(void *)hdr + BPF_RINGBUF_HDR_SZ` for the BPF program to use. Bing-Jhong and Muhammad reported that it is however possible to make a second allocated memory chunk overlapping with the first chunk and as a result, the BPF program is now able to edit first chunk's header. For example, consider the creation of a BPF_MAP_TYPE_RINGBUF map with size of 0x4000. Next, the consumer_pos is modified to 0x3000 /before/ a call to bpf_ringbuf_reserve() is made. This will allocate a chunk A, which is in [0x0,0x3008], and the BPF program is able to edit [0x8,0x3008]. Now, lets allocate a chunk B with size 0x3000. This will succeed because consumer_pos was edited ahead of time to pass the `new_prod_pos - cons_pos > rb->mask` check. Chunk B will be in range [0x3008,0x6010], and the BPF program is able to edit [0x3010,0x6010]. Due to the ring buffer memory layout mentioned earlier, the ranges [0x0,0x4000] and [0x4000,0x8000] point to the same data pages. This means that chunk B at [0x4000,0x4008] is chunk A's header. bpf_ringbuf_submit() / bpf_ringbuf_discard() use the header's pg_off to then locate the bpf_ringbuf itself via bpf_ringbuf_restore_from_rec(). Once chunk B modified chunk A's header, then bpf_ringbuf_commit() refers to the wrong page and could cause a crash. Fix it by calculating the oldest pending_pos and check whether the range from the oldest outstanding record to the newest would span beyond the ring buffer size. If that is the case, then reject the request. We've tested with the ring buffer benchmark in BPF selftests (./benchs/run_bench_ringbufs.sh) before/after the fix and while it seems a bit slower on some benchmarks, it is still not significantly enough to matter.
References
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/0f98f40eb1ed52af8b81f61901b6c0289ff59de4
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/47416c852f2a04d348ea66ee451cbdcf8119f225Mailing List, Patch
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/511804ab701c0503b72eac08217eabfd366ba069Mailing List, Patch
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/be35504b959f2749bab280f4671e8df96dcf836f
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/cfa1a2329a691ffd991fcf7248a57d752e712881Mailing List, Patch
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/d1b9df0435bc61e0b44f578846516df8ef476686Mailing List, Patch
af854a3a-2127-422b-91ae-364da2661108https://git.kernel.org/stable/c/0f98f40eb1ed52af8b81f61901b6c0289ff59de4
af854a3a-2127-422b-91ae-364da2661108https://git.kernel.org/stable/c/47416c852f2a04d348ea66ee451cbdcf8119f225Mailing List, Patch
af854a3a-2127-422b-91ae-364da2661108https://git.kernel.org/stable/c/511804ab701c0503b72eac08217eabfd366ba069Mailing List, Patch
af854a3a-2127-422b-91ae-364da2661108https://git.kernel.org/stable/c/be35504b959f2749bab280f4671e8df96dcf836f
af854a3a-2127-422b-91ae-364da2661108https://git.kernel.org/stable/c/cfa1a2329a691ffd991fcf7248a57d752e712881Mailing List, Patch
af854a3a-2127-422b-91ae-364da2661108https://git.kernel.org/stable/c/d1b9df0435bc61e0b44f578846516df8ef476686Mailing List, Patch
Impacted products
Vendor Product Version
Linux Linux Version: 5.8
Show details on NVD website

To clipboard 

{
  "containers": {
    "adp": [
      {
        "providerMetadata": {
          "dateUpdated": "2024-08-02T04:39:56.138Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/be35504b959f2749bab280f4671e8df96dcf836f"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/0f98f40eb1ed52af8b81f61901b6c0289ff59de4"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/d1b9df0435bc61e0b44f578846516df8ef476686"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/511804ab701c0503b72eac08217eabfd366ba069"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/47416c852f2a04d348ea66ee451cbdcf8119f225"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/cfa1a2329a691ffd991fcf7248a57d752e712881"
          }
        ],
        "title": "CVE Program Container"
      },
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2024-41009",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2024-09-10T16:25:12.740807Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2024-09-11T17:34:06.763Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "kernel/bpf/ringbuf.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "be35504b959f2749bab280f4671e8df96dcf836f",
              "status": "affected",
              "version": "457f44363a8894135c85b7a9afd2bd8196db24ab",
              "versionType": "git"
            },
            {
              "lessThan": "0f98f40eb1ed52af8b81f61901b6c0289ff59de4",
              "status": "affected",
              "version": "457f44363a8894135c85b7a9afd2bd8196db24ab",
              "versionType": "git"
            },
            {
              "lessThan": "d1b9df0435bc61e0b44f578846516df8ef476686",
              "status": "affected",
              "version": "457f44363a8894135c85b7a9afd2bd8196db24ab",
              "versionType": "git"
            },
            {
              "lessThan": "511804ab701c0503b72eac08217eabfd366ba069",
              "status": "affected",
              "version": "457f44363a8894135c85b7a9afd2bd8196db24ab",
              "versionType": "git"
            },
            {
              "lessThan": "47416c852f2a04d348ea66ee451cbdcf8119f225",
              "status": "affected",
              "version": "457f44363a8894135c85b7a9afd2bd8196db24ab",
              "versionType": "git"
            },
            {
              "lessThan": "cfa1a2329a691ffd991fcf7248a57d752e712881",
              "status": "affected",
              "version": "457f44363a8894135c85b7a9afd2bd8196db24ab",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "kernel/bpf/ringbuf.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "5.8"
            },
            {
              "lessThan": "5.8",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.10.*",
              "status": "unaffected",
              "version": "5.10.223",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.15.*",
              "status": "unaffected",
              "version": "5.15.164",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.1.*",
              "status": "unaffected",
              "version": "6.1.97",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.6.*",
              "status": "unaffected",
              "version": "6.6.37",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.9.*",
              "status": "unaffected",
              "version": "6.9.8",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "6.10",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix overrunning reservations in ringbuf\n\nThe BPF ring buffer internally is implemented as a power-of-2 sized circular\nbuffer, with two logical and ever-increasing counters: consumer_pos is the\nconsumer counter to show which logical position the consumer consumed the\ndata, and producer_pos which is the producer counter denoting the amount of\ndata reserved by all producers.\n\nEach time a record is reserved, the producer that \"owns\" the record will\nsuccessfully advance producer counter. In user space each time a record is\nread, the consumer of the data advanced the consumer counter once it finished\nprocessing. Both counters are stored in separate pages so that from user\nspace, the producer counter is read-only and the consumer counter is read-write.\n\nOne aspect that simplifies and thus speeds up the implementation of both\nproducers and consumers is how the data area is mapped twice contiguously\nback-to-back in the virtual memory, allowing to not take any special measures\nfor samples that have to wrap around at the end of the circular buffer data\narea, because the next page after the last data page would be first data page\nagain, and thus the sample will still appear completely contiguous in virtual\nmemory.\n\nEach record has a struct bpf_ringbuf_hdr { u32 len; u32 pg_off; } header for\nbook-keeping the length and offset, and is inaccessible to the BPF program.\nHelpers like bpf_ringbuf_reserve() return `(void *)hdr + BPF_RINGBUF_HDR_SZ`\nfor the BPF program to use. Bing-Jhong and Muhammad reported that it is however\npossible to make a second allocated memory chunk overlapping with the first\nchunk and as a result, the BPF program is now able to edit first chunk\u0027s\nheader.\n\nFor example, consider the creation of a BPF_MAP_TYPE_RINGBUF map with size\nof 0x4000. Next, the consumer_pos is modified to 0x3000 /before/ a call to\nbpf_ringbuf_reserve() is made. This will allocate a chunk A, which is in\n[0x0,0x3008], and the BPF program is able to edit [0x8,0x3008]. Now, lets\nallocate a chunk B with size 0x3000. This will succeed because consumer_pos\nwas edited ahead of time to pass the `new_prod_pos - cons_pos \u003e rb-\u003emask`\ncheck. Chunk B will be in range [0x3008,0x6010], and the BPF program is able\nto edit [0x3010,0x6010]. Due to the ring buffer memory layout mentioned\nearlier, the ranges [0x0,0x4000] and [0x4000,0x8000] point to the same data\npages. This means that chunk B at [0x4000,0x4008] is chunk A\u0027s header.\nbpf_ringbuf_submit() / bpf_ringbuf_discard() use the header\u0027s pg_off to then\nlocate the bpf_ringbuf itself via bpf_ringbuf_restore_from_rec(). Once chunk\nB modified chunk A\u0027s header, then bpf_ringbuf_commit() refers to the wrong\npage and could cause a crash.\n\nFix it by calculating the oldest pending_pos and check whether the range\nfrom the oldest outstanding record to the newest would span beyond the ring\nbuffer size. If that is the case, then reject the request. We\u0027ve tested with\nthe ring buffer benchmark in BPF selftests (./benchs/run_bench_ringbufs.sh)\nbefore/after the fix and while it seems a bit slower on some benchmarks, it\nis still not significantly enough to matter."
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2024-12-19T09:09:58.741Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/be35504b959f2749bab280f4671e8df96dcf836f"
        },
        {
          "url": "https://git.kernel.org/stable/c/0f98f40eb1ed52af8b81f61901b6c0289ff59de4"
        },
        {
          "url": "https://git.kernel.org/stable/c/d1b9df0435bc61e0b44f578846516df8ef476686"
        },
        {
          "url": "https://git.kernel.org/stable/c/511804ab701c0503b72eac08217eabfd366ba069"
        },
        {
          "url": "https://git.kernel.org/stable/c/47416c852f2a04d348ea66ee451cbdcf8119f225"
        },
        {
          "url": "https://git.kernel.org/stable/c/cfa1a2329a691ffd991fcf7248a57d752e712881"
        }
      ],
      "title": "bpf: Fix overrunning reservations in ringbuf",
      "x_generator": {
        "engine": "bippy-5f407fcff5a0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2024-41009",
    "datePublished": "2024-07-17T06:10:11.351Z",
    "dateReserved": "2024-07-12T12:17:45.610Z",
    "dateUpdated": "2024-12-19T09:09:58.741Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1",
  "vulnerability-lookup:meta": {
    "nvd": "{\"cve\":{\"id\":\"CVE-2024-41009\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2024-07-17T07:15:01.973\",\"lastModified\":\"2024-11-21T09:32:03.470\",\"vulnStatus\":\"Modified\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"In the Linux kernel, the following vulnerability has been resolved:\\n\\nbpf: Fix overrunning reservations in ringbuf\\n\\nThe BPF ring buffer internally is implemented as a power-of-2 sized circular\\nbuffer, with two logical and ever-increasing counters: consumer_pos is the\\nconsumer counter to show which logical position the consumer consumed the\\ndata, and producer_pos which is the producer counter denoting the amount of\\ndata reserved by all producers.\\n\\nEach time a record is reserved, the producer that \\\"owns\\\" the record will\\nsuccessfully advance producer counter. In user space each time a record is\\nread, the consumer of the data advanced the consumer counter once it finished\\nprocessing. Both counters are stored in separate pages so that from user\\nspace, the producer counter is read-only and the consumer counter is read-write.\\n\\nOne aspect that simplifies and thus speeds up the implementation of both\\nproducers and consumers is how the data area is mapped twice contiguously\\nback-to-back in the virtual memory, allowing to not take any special measures\\nfor samples that have to wrap around at the end of the circular buffer data\\narea, because the next page after the last data page would be first data page\\nagain, and thus the sample will still appear completely contiguous in virtual\\nmemory.\\n\\nEach record has a struct bpf_ringbuf_hdr { u32 len; u32 pg_off; } header for\\nbook-keeping the length and offset, and is inaccessible to the BPF program.\\nHelpers like bpf_ringbuf_reserve() return `(void *)hdr + BPF_RINGBUF_HDR_SZ`\\nfor the BPF program to use. Bing-Jhong and Muhammad reported that it is however\\npossible to make a second allocated memory chunk overlapping with the first\\nchunk and as a result, the BPF program is now able to edit first chunk\u0027s\\nheader.\\n\\nFor example, consider the creation of a BPF_MAP_TYPE_RINGBUF map with size\\nof 0x4000. Next, the consumer_pos is modified to 0x3000 /before/ a call to\\nbpf_ringbuf_reserve() is made. This will allocate a chunk A, which is in\\n[0x0,0x3008], and the BPF program is able to edit [0x8,0x3008]. Now, lets\\nallocate a chunk B with size 0x3000. This will succeed because consumer_pos\\nwas edited ahead of time to pass the `new_prod_pos - cons_pos \u003e rb-\u003emask`\\ncheck. Chunk B will be in range [0x3008,0x6010], and the BPF program is able\\nto edit [0x3010,0x6010]. Due to the ring buffer memory layout mentioned\\nearlier, the ranges [0x0,0x4000] and [0x4000,0x8000] point to the same data\\npages. This means that chunk B at [0x4000,0x4008] is chunk A\u0027s header.\\nbpf_ringbuf_submit() / bpf_ringbuf_discard() use the header\u0027s pg_off to then\\nlocate the bpf_ringbuf itself via bpf_ringbuf_restore_from_rec(). Once chunk\\nB modified chunk A\u0027s header, then bpf_ringbuf_commit() refers to the wrong\\npage and could cause a crash.\\n\\nFix it by calculating the oldest pending_pos and check whether the range\\nfrom the oldest outstanding record to the newest would span beyond the ring\\nbuffer size. If that is the case, then reject the request. We\u0027ve tested with\\nthe ring buffer benchmark in BPF selftests (./benchs/run_bench_ringbufs.sh)\\nbefore/after the fix and while it seems a bit slower on some benchmarks, it\\nis still not significantly enough to matter.\"},{\"lang\":\"es\",\"value\":\"En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: corrige el exceso de reservas en ringbuf. El b\u00fafer de anillo BPF se implementa internamente como un b\u00fafer circular de tama\u00f1o potencia de 2, con dos contadores l\u00f3gicos y en constante aumento: consumer_pos es el consumidor contador para mostrar en qu\u00e9 posici\u00f3n l\u00f3gica el consumidor consumi\u00f3 los datos, y productor_pos, que es el contador del productor que indica la cantidad de datos reservados por todos los productores. Cada vez que se reserva un registro, el productor \\\"due\u00f1o\\\" del registro avanzar\u00e1 exitosamente el contador de productores. En el espacio de usuario, cada vez que se lee un registro, el consumidor de los datos avanza el contador del consumidor una vez que finaliza el procesamiento. Ambos contadores se almacenan en p\u00e1ginas separadas de modo que, desde el espacio del usuario, el contador del productor sea de solo lectura y el contador del consumidor sea de lectura y escritura. Un aspecto que simplifica y, por lo tanto, acelera la implementaci\u00f3n tanto de productores como de consumidores es c\u00f3mo el \u00e1rea de datos se mapea dos veces de forma contigua y consecutiva en la memoria virtual, lo que permite no tomar medidas especiales para las muestras que tienen que envolverse en el mismo lugar. al final del \u00e1rea de datos del b\u00fafer circular, porque la p\u00e1gina siguiente despu\u00e9s de la \u00faltima p\u00e1gina de datos volver\u00eda a ser la primera p\u00e1gina de datos y, por lo tanto, la muestra seguir\u00e1 apareciendo completamente contigua en la memoria virtual. Cada registro tiene una estructura bpf_ringbuf_hdr { u32 len; u32 p\u00e1gina_apagada; } encabezado para la contabilidad de la longitud y el desplazamiento, y es inaccesible para el programa BPF. Ayudantes como bpf_ringbuf_reserve() devuelven `(void *)hdr + BPF_RINGBUF_HDR_SZ` para que lo use el programa BPF. Bing-Jhong y Muhammad informaron que, sin embargo, es posible hacer que un segundo fragmento de memoria asignado se superponga con el primer fragmento y, como resultado, el programa BPF ahora puede editar el encabezado del primer fragmento. Por ejemplo, considere la creaci\u00f3n de un mapa BPF_MAP_TYPE_RINGBUF con un tama\u00f1o de 0x4000. A continuaci\u00f3n, consumer_pos se modifica a 0x3000 /antes/ se realiza una llamada a bpf_ringbuf_reserve(). Esto asignar\u00e1 un fragmento A, que est\u00e1 en [0x0,0x3008], y el programa BPF podr\u00e1 editar [0x8,0x3008]. Ahora, asignemos un fragmento B con tama\u00f1o 0x3000. Esto tendr\u00e1 \u00e9xito porque consumer_pos se edit\u00f3 con anticipaci\u00f3n para pasar la verificaci\u00f3n `new_prod_pos - cons_pos \u0026gt; rb-\u0026gt;mask`. El fragmento B estar\u00e1 en el rango [0x3008,0x6010] y el programa BPF podr\u00e1 editar [0x3010,0x6010]. Debido al dise\u00f1o de la memoria del b\u00fafer en anillo mencionado anteriormente, los rangos [0x0,0x4000] y [0x4000,0x8000] apuntan a las mismas p\u00e1ginas de datos. Esto significa que el fragmento B en [0x4000,0x4008] es el encabezado del fragmento A. bpf_ringbuf_submit() / bpf_ringbuf_discard() usa el pg_off del encabezado para luego ubicar el bpf_ringbuf a trav\u00e9s de bpf_ringbuf_restore_from_rec(). Una vez que el fragmento B modific\u00f3 el encabezado del fragmento A, bpf_ringbuf_commit() hace referencia a la p\u00e1gina incorrecta y podr\u00eda causar un bloqueo. Solucionelo calculando el pendiente_pos m\u00e1s antiguo y verifique si el rango desde el registro pendiente m\u00e1s antiguo hasta el m\u00e1s nuevo abarcar\u00eda m\u00e1s all\u00e1 del tama\u00f1o del b\u00fafer circular. Si ese es el caso, rechace la solicitud. Hemos probado con el punto de referencia del b\u00fafer de anillo en las autopruebas de BPF (./benchs/run_bench_ringbufs.sh) antes/despu\u00e9s de la correcci\u00f3n y, aunque parece un poco m\u00e1s lento en algunos puntos de referencia, todav\u00eda no es lo suficientemente significativo como para importar.\"}],\"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}]},\"weaknesses\":[{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"description\":[{\"lang\":\"en\",\"value\":\"CWE-770\"}]}],\"configurations\":[{\"nodes\":[{\"operator\":\"OR\",\"negate\":false,\"cpeMatch\":[{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"5.8\",\"versionEndExcluding\":\"6.1.97\",\"matchCriteriaId\":\"5F2E2CF9-E512-4F81-AD6C-400701BDBF04\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"6.2\",\"versionEndExcluding\":\"6.6.37\",\"matchCriteriaId\":\"D72E033B-5323-4C4D-8818-36E1EBC3535F\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"6.7\",\"versionEndExcluding\":\"6.9.8\",\"matchCriteriaId\":\"E95105F2-32E3-4C5F-9D18-7AEFD0E6275C\"}]}]}],\"references\":[{\"url\":\"https://git.kernel.org/stable/c/0f98f40eb1ed52af8b81f61901b6c0289ff59de4\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/47416c852f2a04d348ea66ee451cbdcf8119f225\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Mailing List\",\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/511804ab701c0503b72eac08217eabfd366ba069\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Mailing List\",\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/be35504b959f2749bab280f4671e8df96dcf836f\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/cfa1a2329a691ffd991fcf7248a57d752e712881\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Mailing List\",\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/d1b9df0435bc61e0b44f578846516df8ef476686\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Mailing List\",\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/0f98f40eb1ed52af8b81f61901b6c0289ff59de4\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\"},{\"url\":\"https://git.kernel.org/stable/c/47416c852f2a04d348ea66ee451cbdcf8119f225\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\",\"tags\":[\"Mailing List\",\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/511804ab701c0503b72eac08217eabfd366ba069\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\",\"tags\":[\"Mailing List\",\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/be35504b959f2749bab280f4671e8df96dcf836f\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\"},{\"url\":\"https://git.kernel.org/stable/c/cfa1a2329a691ffd991fcf7248a57d752e712881\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\",\"tags\":[\"Mailing List\",\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/d1b9df0435bc61e0b44f578846516df8ef476686\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\",\"tags\":[\"Mailing List\",\"Patch\"]}]}}"
  }
}


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.