cve-2022-48760
Vulnerability from cvelistv5
Published
2024-06-20 11:13
Modified
2024-12-19 08:07
Severity ?
Summary
In the Linux kernel, the following vulnerability has been resolved: USB: core: Fix hang in usb_kill_urb by adding memory barriers The syzbot fuzzer has identified a bug in which processes hang waiting for usb_kill_urb() to return. It turns out the issue is not unlinking the URB; that works just fine. Rather, the problem arises when the wakeup notification that the URB has completed is not received. The reason is memory-access ordering on SMP systems. In outline form, usb_kill_urb() and __usb_hcd_giveback_urb() operating concurrently on different CPUs perform the following actions: CPU 0 CPU 1 ---------------------------- --------------------------------- usb_kill_urb(): __usb_hcd_giveback_urb(): ... ... atomic_inc(&urb->reject); atomic_dec(&urb->use_count); ... ... wait_event(usb_kill_urb_queue, atomic_read(&urb->use_count) == 0); if (atomic_read(&urb->reject)) wake_up(&usb_kill_urb_queue); Confining your attention to urb->reject and urb->use_count, you can see that the overall pattern of accesses on CPU 0 is: write urb->reject, then read urb->use_count; whereas the overall pattern of accesses on CPU 1 is: write urb->use_count, then read urb->reject. This pattern is referred to in memory-model circles as SB (for "Store Buffering"), and it is well known that without suitable enforcement of the desired order of accesses -- in the form of memory barriers -- it is entirely possible for one or both CPUs to execute their reads ahead of their writes. The end result will be that sometimes CPU 0 sees the old un-decremented value of urb->use_count while CPU 1 sees the old un-incremented value of urb->reject. Consequently CPU 0 ends up on the wait queue and never gets woken up, leading to the observed hang in usb_kill_urb(). The same pattern of accesses occurs in usb_poison_urb() and the failure pathway of usb_hcd_submit_urb(). The problem is fixed by adding suitable memory barriers. To provide proper memory-access ordering in the SB pattern, a full barrier is required on both CPUs. The atomic_inc() and atomic_dec() accesses themselves don't provide any memory ordering, but since they are present, we can use the optimized smp_mb__after_atomic() memory barrier in the various routines to obtain the desired effect. This patch adds the necessary memory barriers.
References
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/26fbe9772b8c459687930511444ce443011f86bf
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/546ba238535d925254e0b3f12012a5c55801e2f3
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/5904dfd3ddaff3bf4a41c3baf0a8e8f31ed4599b
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/5f138ef224dffd15d5e5c5b095859719e0038427
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/9340226388c66a7e090ebb00e91ed64a753b6c26
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/9c61fce322ac2ef7fecf025285353570d60e41d6
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/b50f5ca60475710bbc9a3af32fbfc17b1e69c2f0
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/c9a18f7c5b071dce5e6939568829d40994866ab0
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/e3b131e30e612ff0e32de6c1cb4f69f89db29193
af854a3a-2127-422b-91ae-364da2661108https://git.kernel.org/stable/c/26fbe9772b8c459687930511444ce443011f86bf
af854a3a-2127-422b-91ae-364da2661108https://git.kernel.org/stable/c/546ba238535d925254e0b3f12012a5c55801e2f3
af854a3a-2127-422b-91ae-364da2661108https://git.kernel.org/stable/c/5904dfd3ddaff3bf4a41c3baf0a8e8f31ed4599b
af854a3a-2127-422b-91ae-364da2661108https://git.kernel.org/stable/c/5f138ef224dffd15d5e5c5b095859719e0038427
af854a3a-2127-422b-91ae-364da2661108https://git.kernel.org/stable/c/9340226388c66a7e090ebb00e91ed64a753b6c26
af854a3a-2127-422b-91ae-364da2661108https://git.kernel.org/stable/c/9c61fce322ac2ef7fecf025285353570d60e41d6
af854a3a-2127-422b-91ae-364da2661108https://git.kernel.org/stable/c/b50f5ca60475710bbc9a3af32fbfc17b1e69c2f0
af854a3a-2127-422b-91ae-364da2661108https://git.kernel.org/stable/c/c9a18f7c5b071dce5e6939568829d40994866ab0
af854a3a-2127-422b-91ae-364da2661108https://git.kernel.org/stable/c/e3b131e30e612ff0e32de6c1cb4f69f89db29193
Impacted products
Vendor Product Version
Linux Linux
Show details on NVD website

To clipboard 

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2022-48760",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2024-06-20T14:49:44.326446Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2024-06-20T14:50:00.838Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      },
      {
        "providerMetadata": {
          "dateUpdated": "2024-08-03T15:25:01.565Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/5f138ef224dffd15d5e5c5b095859719e0038427"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/b50f5ca60475710bbc9a3af32fbfc17b1e69c2f0"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/546ba238535d925254e0b3f12012a5c55801e2f3"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/5904dfd3ddaff3bf4a41c3baf0a8e8f31ed4599b"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/9c61fce322ac2ef7fecf025285353570d60e41d6"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/e3b131e30e612ff0e32de6c1cb4f69f89db29193"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/9340226388c66a7e090ebb00e91ed64a753b6c26"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/c9a18f7c5b071dce5e6939568829d40994866ab0"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/26fbe9772b8c459687930511444ce443011f86bf"
          }
        ],
        "title": "CVE Program Container"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "drivers/usb/core/hcd.c",
            "drivers/usb/core/urb.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "5f138ef224dffd15d5e5c5b095859719e0038427",
              "status": "affected",
              "version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
              "versionType": "git"
            },
            {
              "lessThan": "b50f5ca60475710bbc9a3af32fbfc17b1e69c2f0",
              "status": "affected",
              "version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
              "versionType": "git"
            },
            {
              "lessThan": "546ba238535d925254e0b3f12012a5c55801e2f3",
              "status": "affected",
              "version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
              "versionType": "git"
            },
            {
              "lessThan": "5904dfd3ddaff3bf4a41c3baf0a8e8f31ed4599b",
              "status": "affected",
              "version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
              "versionType": "git"
            },
            {
              "lessThan": "9c61fce322ac2ef7fecf025285353570d60e41d6",
              "status": "affected",
              "version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
              "versionType": "git"
            },
            {
              "lessThan": "e3b131e30e612ff0e32de6c1cb4f69f89db29193",
              "status": "affected",
              "version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
              "versionType": "git"
            },
            {
              "lessThan": "9340226388c66a7e090ebb00e91ed64a753b6c26",
              "status": "affected",
              "version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
              "versionType": "git"
            },
            {
              "lessThan": "c9a18f7c5b071dce5e6939568829d40994866ab0",
              "status": "affected",
              "version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
              "versionType": "git"
            },
            {
              "lessThan": "26fbe9772b8c459687930511444ce443011f86bf",
              "status": "affected",
              "version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "drivers/usb/core/hcd.c",
            "drivers/usb/core/urb.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThanOrEqual": "4.4.*",
              "status": "unaffected",
              "version": "4.4.302",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "4.9.*",
              "status": "unaffected",
              "version": "4.9.300",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "4.14.*",
              "status": "unaffected",
              "version": "4.14.265",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "4.19.*",
              "status": "unaffected",
              "version": "4.19.228",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.4.*",
              "status": "unaffected",
              "version": "5.4.176",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.10.*",
              "status": "unaffected",
              "version": "5.10.96",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.15.*",
              "status": "unaffected",
              "version": "5.15.19",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.16.*",
              "status": "unaffected",
              "version": "5.16.5",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "5.17",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nUSB: core: Fix hang in usb_kill_urb by adding memory barriers\n\nThe syzbot fuzzer has identified a bug in which processes hang waiting\nfor usb_kill_urb() to return.  It turns out the issue is not unlinking\nthe URB; that works just fine.  Rather, the problem arises when the\nwakeup notification that the URB has completed is not received.\n\nThe reason is memory-access ordering on SMP systems.  In outline form,\nusb_kill_urb() and __usb_hcd_giveback_urb() operating concurrently on\ndifferent CPUs perform the following actions:\n\nCPU 0\t\t\t\t\tCPU 1\n----------------------------\t\t---------------------------------\nusb_kill_urb():\t\t\t\t__usb_hcd_giveback_urb():\n  ...\t\t\t\t\t  ...\n  atomic_inc(\u0026urb-\u003ereject);\t\t  atomic_dec(\u0026urb-\u003euse_count);\n  ...\t\t\t\t\t  ...\n  wait_event(usb_kill_urb_queue,\n\tatomic_read(\u0026urb-\u003euse_count) == 0);\n\t\t\t\t\t  if (atomic_read(\u0026urb-\u003ereject))\n\t\t\t\t\t\twake_up(\u0026usb_kill_urb_queue);\n\nConfining your attention to urb-\u003ereject and urb-\u003euse_count, you can\nsee that the overall pattern of accesses on CPU 0 is:\n\n\twrite urb-\u003ereject, then read urb-\u003euse_count;\n\nwhereas the overall pattern of accesses on CPU 1 is:\n\n\twrite urb-\u003euse_count, then read urb-\u003ereject.\n\nThis pattern is referred to in memory-model circles as SB (for \"Store\nBuffering\"), and it is well known that without suitable enforcement of\nthe desired order of accesses -- in the form of memory barriers -- it\nis entirely possible for one or both CPUs to execute their reads ahead\nof their writes.  The end result will be that sometimes CPU 0 sees the\nold un-decremented value of urb-\u003euse_count while CPU 1 sees the old\nun-incremented value of urb-\u003ereject.  Consequently CPU 0 ends up on\nthe wait queue and never gets woken up, leading to the observed hang\nin usb_kill_urb().\n\nThe same pattern of accesses occurs in usb_poison_urb() and the\nfailure pathway of usb_hcd_submit_urb().\n\nThe problem is fixed by adding suitable memory barriers.  To provide\nproper memory-access ordering in the SB pattern, a full barrier is\nrequired on both CPUs.  The atomic_inc() and atomic_dec() accesses\nthemselves don\u0027t provide any memory ordering, but since they are\npresent, we can use the optimized smp_mb__after_atomic() memory\nbarrier in the various routines to obtain the desired effect.\n\nThis patch adds the necessary memory barriers."
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2024-12-19T08:07:12.339Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/5f138ef224dffd15d5e5c5b095859719e0038427"
        },
        {
          "url": "https://git.kernel.org/stable/c/b50f5ca60475710bbc9a3af32fbfc17b1e69c2f0"
        },
        {
          "url": "https://git.kernel.org/stable/c/546ba238535d925254e0b3f12012a5c55801e2f3"
        },
        {
          "url": "https://git.kernel.org/stable/c/5904dfd3ddaff3bf4a41c3baf0a8e8f31ed4599b"
        },
        {
          "url": "https://git.kernel.org/stable/c/9c61fce322ac2ef7fecf025285353570d60e41d6"
        },
        {
          "url": "https://git.kernel.org/stable/c/e3b131e30e612ff0e32de6c1cb4f69f89db29193"
        },
        {
          "url": "https://git.kernel.org/stable/c/9340226388c66a7e090ebb00e91ed64a753b6c26"
        },
        {
          "url": "https://git.kernel.org/stable/c/c9a18f7c5b071dce5e6939568829d40994866ab0"
        },
        {
          "url": "https://git.kernel.org/stable/c/26fbe9772b8c459687930511444ce443011f86bf"
        }
      ],
      "title": "USB: core: Fix hang in usb_kill_urb by adding memory barriers",
      "x_generator": {
        "engine": "bippy-5f407fcff5a0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2022-48760",
    "datePublished": "2024-06-20T11:13:38.532Z",
    "dateReserved": "2024-06-20T11:09:39.059Z",
    "dateUpdated": "2024-12-19T08:07:12.339Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1",
  "vulnerability-lookup:meta": {
    "nvd": "{\"cve\":{\"id\":\"CVE-2022-48760\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2024-06-20T12:15:14.110\",\"lastModified\":\"2024-11-21T07:33:57.913\",\"vulnStatus\":\"Awaiting Analysis\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"In the Linux kernel, the following vulnerability has been resolved:\\n\\nUSB: core: Fix hang in usb_kill_urb by adding memory barriers\\n\\nThe syzbot fuzzer has identified a bug in which processes hang waiting\\nfor usb_kill_urb() to return.  It turns out the issue is not unlinking\\nthe URB; that works just fine.  Rather, the problem arises when the\\nwakeup notification that the URB has completed is not received.\\n\\nThe reason is memory-access ordering on SMP systems.  In outline form,\\nusb_kill_urb() and __usb_hcd_giveback_urb() operating concurrently on\\ndifferent CPUs perform the following actions:\\n\\nCPU 0\\t\\t\\t\\t\\tCPU 1\\n----------------------------\\t\\t---------------------------------\\nusb_kill_urb():\\t\\t\\t\\t__usb_hcd_giveback_urb():\\n  ...\\t\\t\\t\\t\\t  ...\\n  atomic_inc(\u0026urb-\u003ereject);\\t\\t  atomic_dec(\u0026urb-\u003euse_count);\\n  ...\\t\\t\\t\\t\\t  ...\\n  wait_event(usb_kill_urb_queue,\\n\\tatomic_read(\u0026urb-\u003euse_count) == 0);\\n\\t\\t\\t\\t\\t  if (atomic_read(\u0026urb-\u003ereject))\\n\\t\\t\\t\\t\\t\\twake_up(\u0026usb_kill_urb_queue);\\n\\nConfining your attention to urb-\u003ereject and urb-\u003euse_count, you can\\nsee that the overall pattern of accesses on CPU 0 is:\\n\\n\\twrite urb-\u003ereject, then read urb-\u003euse_count;\\n\\nwhereas the overall pattern of accesses on CPU 1 is:\\n\\n\\twrite urb-\u003euse_count, then read urb-\u003ereject.\\n\\nThis pattern is referred to in memory-model circles as SB (for \\\"Store\\nBuffering\\\"), and it is well known that without suitable enforcement of\\nthe desired order of accesses -- in the form of memory barriers -- it\\nis entirely possible for one or both CPUs to execute their reads ahead\\nof their writes.  The end result will be that sometimes CPU 0 sees the\\nold un-decremented value of urb-\u003euse_count while CPU 1 sees the old\\nun-incremented value of urb-\u003ereject.  Consequently CPU 0 ends up on\\nthe wait queue and never gets woken up, leading to the observed hang\\nin usb_kill_urb().\\n\\nThe same pattern of accesses occurs in usb_poison_urb() and the\\nfailure pathway of usb_hcd_submit_urb().\\n\\nThe problem is fixed by adding suitable memory barriers.  To provide\\nproper memory-access ordering in the SB pattern, a full barrier is\\nrequired on both CPUs.  The atomic_inc() and atomic_dec() accesses\\nthemselves don\u0027t provide any memory ordering, but since they are\\npresent, we can use the optimized smp_mb__after_atomic() memory\\nbarrier in the various routines to obtain the desired effect.\\n\\nThis patch adds the necessary memory barriers.\"},{\"lang\":\"es\",\"value\":\"En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: USB: core: corrige el bloqueo en usb_kill_urb agregando barreras de memoria el syzbot fuzzer ha identificado un error en el que los procesos se bloquean esperando que regrese usb_kill_urb(). Resulta que el problema no es desvincular la URB; eso funciona bien. M\u00e1s bien, el problema surge cuando no se recibe la notificaci\u00f3n de activaci\u00f3n de que la URB ha completado. El motivo son los pedidos de acceso a la memoria en los sistemas SMP. En forma resumida, usb_kill_urb() y __usb_hcd_giveback_urb() operando simult\u00e1neamente en diferentes CPU realizan las siguientes acciones: CPU 0 CPU 1 ------------------------- --- --------------------------------- usb_kill_urb(): __usb_hcd_giveback_urb(): ... ... atomic_inc(\u0026amp;urb-\u0026gt;rechazar); atomic_dec(\u0026amp;urb-\u0026gt;use_count); ... ... wait_event(usb_kill_urb_queue, atomic_read(\u0026amp;urb-\u0026gt;use_count) == 0); if (atomic_read(\u0026amp;urb-\u0026gt;reject)) wake_up(\u0026amp;usb_kill_urb_queue); Limitando su atenci\u00f3n a urb-\u0026gt;reject y urb-\u0026gt;use_count, puede ver que el patr\u00f3n general de accesos en la CPU 0 es: escribir urb-\u0026gt;reject, luego leer urb-\u0026gt;use_count; mientras que el patr\u00f3n general de accesos en la CPU 1 es: escribir urb-\u0026gt;use_count, luego leer urb-\u0026gt;reject. En los c\u00edrculos de modelos de memoria se hace referencia a este patr\u00f3n como SB (por \\\"Store Buffering\\\"), y es bien sabido que sin una aplicaci\u00f3n adecuada del orden deseado de accesos (en forma de barreras de memoria) es completamente posible que una o ambas CPU para ejecutar sus lecturas antes de sus escrituras. El resultado final ser\u00e1 que a veces la CPU 0 ve el antiguo valor no incrementado de urb-\u0026gt;use_count mientras que la CPU 1 ve el antiguo valor no incrementado de urb-\u0026gt;reject. En consecuencia, la CPU 0 termina en la cola de espera y nunca se activa, lo que provoca el bloqueo observado en usb_kill_urb(). El mismo patr\u00f3n de accesos ocurre en usb_poison_urb() y la ruta de falla de usb_hcd_submit_urb(). El problema se soluciona agregando barreras de memoria adecuadas. Para proporcionar un orden adecuado de acceso a la memoria en el patr\u00f3n SB, se requiere una barrera completa en ambas CPU. Los accesos atomic_inc() y atomic_dec() en s\u00ed no proporcionan ning\u00fan orden de memoria, pero como est\u00e1n presentes, podemos usar la barrera de memoria optimizada smp_mb__after_atomic() en las distintas rutinas para obtener el efecto deseado. Este parche agrega las barreras de memoria necesarias.\"}],\"metrics\":{},\"references\":[{\"url\":\"https://git.kernel.org/stable/c/26fbe9772b8c459687930511444ce443011f86bf\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/546ba238535d925254e0b3f12012a5c55801e2f3\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/5904dfd3ddaff3bf4a41c3baf0a8e8f31ed4599b\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/5f138ef224dffd15d5e5c5b095859719e0038427\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/9340226388c66a7e090ebb00e91ed64a753b6c26\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/9c61fce322ac2ef7fecf025285353570d60e41d6\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/b50f5ca60475710bbc9a3af32fbfc17b1e69c2f0\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/c9a18f7c5b071dce5e6939568829d40994866ab0\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/e3b131e30e612ff0e32de6c1cb4f69f89db29193\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/26fbe9772b8c459687930511444ce443011f86bf\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\"},{\"url\":\"https://git.kernel.org/stable/c/546ba238535d925254e0b3f12012a5c55801e2f3\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\"},{\"url\":\"https://git.kernel.org/stable/c/5904dfd3ddaff3bf4a41c3baf0a8e8f31ed4599b\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\"},{\"url\":\"https://git.kernel.org/stable/c/5f138ef224dffd15d5e5c5b095859719e0038427\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\"},{\"url\":\"https://git.kernel.org/stable/c/9340226388c66a7e090ebb00e91ed64a753b6c26\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\"},{\"url\":\"https://git.kernel.org/stable/c/9c61fce322ac2ef7fecf025285353570d60e41d6\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\"},{\"url\":\"https://git.kernel.org/stable/c/b50f5ca60475710bbc9a3af32fbfc17b1e69c2f0\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\"},{\"url\":\"https://git.kernel.org/stable/c/c9a18f7c5b071dce5e6939568829d40994866ab0\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\"},{\"url\":\"https://git.kernel.org/stable/c/e3b131e30e612ff0e32de6c1cb4f69f89db29193\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\"}]}}"
  }
}


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.