CVE-2026-90047 (GCVE-0-2026-90047)

Vulnerability from cvelistv5 – Published: 2026-09-16 10:33 – Updated: 2026-09-16 14:42
VLAI
Title
drm/xe: Don't hand out the flat CCS storage as usable VRAM
Summary
In the Linux kernel, the following vulnerability has been resolved: drm/xe: Don't hand out the flat CCS storage as usable VRAM get_flat_ccs_offset() reads the base of the flat CCS storage from the hardware, scales it by the number of enabled L3 nodes, and rounds the result up to 128K. Everything below that offset is then handed to the VRAM allocator as usable memory. Rounding a limit that means "usable memory ends here" upwards publishes whatever lies between the real base and the rounded one as free memory, and that memory belongs to the compression hardware. The scaled value has no reason to be 128K aligned, and on a Battlemage G21 with 16 GiB it is not: flat CCS base: raw 0x3fafff800, rounded 0x3fb000000 so the last 2 KiB of page 0x3fafff000 is CCS storage, in the allocator's pool. Whatever is allocated there gets that tail overwritten by the compression hardware, which needs no page-table entry, no buffer object and no GPU submission to do it, and does it before userspace exists. On this machine a Mesa VM's level-3 page table landed on that page on every cold boot. It lost the entry covering the compositor's batch-buffer heap, so the compositor's first submission faulted fetching its batch and gdm restarted it forever: a black screen on an otherwise working machine. Restarting gdm cleared it because the next VM's page tables were allocated somewhere else. Round down instead, to the page size the allocator works in. On this machine that excludes exactly one page. Reading the reserved page afterwards shows what had been writing it: [369] 0xcccc000000000000 [371] 0xcc77000000000000 [373] 0xcccc000000000000 [375] 0xcc77000000000000 compression metadata, two bytes per sixteen, sitting where the driver used to hand out memory. The assertion that should have caught this compares the offset against GSMBASE - ccs_size for equality. That value is 128K aligned, so it agrees with the rounded-up offset precisely when the base is not aligned - the check cannot fail in the case it exists to catch, and is compiled out unless CONFIG_DRM_XE_DEBUG is set. Replace it with one that can fail: CCS storage must not run into GSM. [ And this was a debug session from hell, enormously helped by an AI doing much of the grunt-work. I'd like to call it my tireless helper, but the AI several times stated flat out that this was impossible and unsolvable and that we should just write a report about it. I suspect those things have been trained by people who may not be quite as stubborn as I am. But while the AI was ready to give up several times, it did keep adding debug code and analyzing it faithfully when I pushed. So credit where credit is due and I let the AI write the commit message above. This is basically a one-liner fixing a bogus "round_up()" to a "round_down()", but there were 24 patches adding more and more debug information to this, and 18 kernel boot to finally narrow it down to this. - Linus ]
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: 37173392741c425191b959acb3adf70c9a4610c0 , < c96477e0cabf55bfbdf078078e9de1c8024f8060 (git)
Affected: 37173392741c425191b959acb3adf70c9a4610c0 , < 348c3db4f1520d36764ac8cae2492f50599714f6 (git)
Affected: 37173392741c425191b959acb3adf70c9a4610c0 , < 818bebeb63dd6bf5f4e07e145f6cdbace520a34c (git)
Create a notification for this product.
Linux Linux Affected: 6.13
Unaffected: 0 , < 6.13 (semver)
Unaffected: 6.18.51 , ≤ 6.18.* (semver)
Unaffected: 7.2.5 , ≤ 7.2.* (semver)
Unaffected: 7.3-rc1 , ≤ * (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": [
            "drivers/gpu/drm/xe/xe_vram.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "c96477e0cabf55bfbdf078078e9de1c8024f8060",
              "status": "affected",
              "version": "37173392741c425191b959acb3adf70c9a4610c0",
              "versionType": "git"
            },
            {
              "lessThan": "348c3db4f1520d36764ac8cae2492f50599714f6",
              "status": "affected",
              "version": "37173392741c425191b959acb3adf70c9a4610c0",
              "versionType": "git"
            },
            {
              "lessThan": "818bebeb63dd6bf5f4e07e145f6cdbace520a34c",
              "status": "affected",
              "version": "37173392741c425191b959acb3adf70c9a4610c0",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "drivers/gpu/drm/xe/xe_vram.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "6.13"
            },
            {
              "lessThan": "6.13",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.18.*",
              "status": "unaffected",
              "version": "6.18.51",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "7.2.*",
              "status": "unaffected",
              "version": "7.2.5",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "7.3-rc1",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.18.51",
                  "versionStartIncluding": "6.13",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "7.2.5",
                  "versionStartIncluding": "6.13",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "7.3-rc1",
                  "versionStartIncluding": "6.13",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/xe: Don\u0027t hand out the flat CCS storage as usable VRAM\n\nget_flat_ccs_offset() reads the base of the flat CCS storage from the\nhardware, scales it by the number of enabled L3 nodes, and rounds the\nresult up to 128K.  Everything below that offset is then handed to the\nVRAM allocator as usable memory.\n\nRounding a limit that means \"usable memory ends here\" upwards publishes\nwhatever lies between the real base and the rounded one as free memory,\nand that memory belongs to the compression hardware.  The scaled value\nhas no reason to be 128K aligned, and on a Battlemage G21 with 16 GiB it\nis not:\n\n\tflat CCS base: raw 0x3fafff800, rounded 0x3fb000000\n\nso the last 2 KiB of page 0x3fafff000 is CCS storage, in the allocator\u0027s\npool.  Whatever is allocated there gets that tail overwritten by the\ncompression hardware, which needs no page-table entry, no buffer object\nand no GPU submission to do it, and does it before userspace exists.\n\nOn this machine a Mesa VM\u0027s level-3 page table landed on that page on\nevery cold boot.  It lost the entry covering the compositor\u0027s\nbatch-buffer heap, so the compositor\u0027s first submission faulted fetching\nits batch and gdm restarted it forever: a black screen on an otherwise\nworking machine.  Restarting gdm cleared it because the next VM\u0027s page\ntables were allocated somewhere else.\n\nRound down instead, to the page size the allocator works in.  On this\nmachine that excludes exactly one page.\n\nReading the reserved page afterwards shows what had been writing it:\n\n\t[369] 0xcccc000000000000\n\t[371] 0xcc77000000000000\n\t[373] 0xcccc000000000000\n\t[375] 0xcc77000000000000\n\ncompression metadata, two bytes per sixteen, sitting where the driver\nused to hand out memory.\n\nThe assertion that should have caught this compares the offset against\nGSMBASE - ccs_size for equality.  That value is 128K aligned, so it\nagrees with the rounded-up offset precisely when the base is not\naligned - the check cannot fail in the case it exists to catch, and is\ncompiled out unless CONFIG_DRM_XE_DEBUG is set.  Replace it with one\nthat can fail: CCS storage must not run into GSM.\n\n[ And this was a debug session from hell, enormously helped by an AI\n  doing much of the grunt-work.\n\n  I\u0027d like to call it my tireless helper, but the AI several times\n  stated flat out that this was impossible and unsolvable and that we\n  should just write a report about it.\n\n  I suspect those things have been trained by people who may not be\n  quite as stubborn as I am.\n\n  But while the AI was ready to give up several times, it did keep\n  adding debug code and analyzing it faithfully when I pushed. So credit\n  where credit is due and I let the AI write the commit message above.\n\n  This is basically a one-liner fixing a bogus \"round_up()\" to a\n  \"round_down()\", but there were 24 patches adding more and more debug\n  information to this, and 18 kernel boot to finally narrow it down to\n  this.   - Linus ]"
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "baseScore": 7.8,
            "baseSeverity": "HIGH",
            "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
            "version": "3.1"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "AV:L - The oversized VRAM pool is used through local DRM render-node ioctls (DRM_IOCTL_XE_GEM_CREATE, DRM_IOCTL_XE_VM_CREATE/BIND) on /dev/dri/renderD*; xe_vram_probe() only runs at PCI driver init. There is no network, Bluetooth, or USB path into this Xe VRAM accounting code.\nAC:L - On affected Xe2 discrete GPUs the flat CCS base is not 128K-aligned, so one extra 4K CCS page is always in the TTM pool. 4K GPU page-table BOs land on that leftover fragment (every cold boot on the reported hardware), and CCS hardware overwrites it with no GPU submission required.\nPR:L - XE_GEM_CREATE and XE_VM_CREATE are DRM_RENDER_ALLOW, so any unprivileged local user who can open the Xe render node (typical desktop, workstation, and GPU-compute clients) can allocate VRAM and GPU page tables from the oversized pool; root or init-namespace capabilities are not required.\nUI:N - Exploitation uses only the attacker\u0027s own GEM/VM ioctls, and the compression hardware writes CCS into the overlapping page with no victim GPU submission. The compositor-fault/black-screen outcome also occurs on ordinary GPU bring-up with no separate user action.\nS:U - Aliasing CCS storage with allocated VRAM corrupts GPU page tables and buffer objects inside the host kernel\u0027s Xe/TTM security authority. This is not a guest-to-host VM escape or IOMMU/DMA bypass; the SR-IOV VF probe path skips get_flat_ccs_offset() entirely.\nC:H - A client can receive the overlapping page as a mappable VRAM BO (XE_GEM_CREATE plus XE_GEM_MMAP_OFFSET) and read Flat CCS metadata for other surfaces. When that page is a GPU page table, CCS overwrites PTEs so the GPU may translate into unintended physical pages, disclosing other clients\u0027 GPU memory.\nI:H - CCS hardware writes into kernel-managed GPU page tables and user BOs with no PTE, corrupting translations and buffer contents. A client that maps the overlapping page can also write CCS storage, breaking other clients\u0027 compression state and GPU PTEs, which is memory corruption scored as High integrity impact.\nA:H - Overwritten GPU page-table entries cause GPU page faults on batch fetch; the reported effect is a compositor crash and persistent gdm restart/black-screen loop, and the same corruption can wedge or reset the Xe GT. Kernel CVSS treats GPU hangs and crashes as High availability impact."
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-09-16T14:42:02.936Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/c96477e0cabf55bfbdf078078e9de1c8024f8060"
        },
        {
          "url": "https://git.kernel.org/stable/c/348c3db4f1520d36764ac8cae2492f50599714f6"
        },
        {
          "url": "https://git.kernel.org/stable/c/818bebeb63dd6bf5f4e07e145f6cdbace520a34c"
        }
      ],
      "title": "drm/xe: Don\u0027t hand out the flat CCS storage as usable VRAM",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2026-90047",
    "datePublished": "2026-09-16T10:33:43.851Z",
    "dateReserved": "2026-09-11T19:38:34.783Z",
    "dateUpdated": "2026-09-16T14:42:02.936Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2026-90047",
      "date": "2026-10-02",
      "epss": "0.00173",
      "percentile": "0.06085"
    },
    "nvd": {
      "cve": {
        "affected": [
          {
            "affectedData": [
              {
                "defaultStatus": "unaffected",
                "product": "Linux",
                "programFiles": [
                  "drivers/gpu/drm/xe/xe_vram.c"
                ],
                "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
                "vendor": "Linux",
                "versions": [
                  {
                    "lessThan": "c96477e0cabf55bfbdf078078e9de1c8024f8060",
                    "status": "affected",
                    "version": "37173392741c425191b959acb3adf70c9a4610c0",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "348c3db4f1520d36764ac8cae2492f50599714f6",
                    "status": "affected",
                    "version": "37173392741c425191b959acb3adf70c9a4610c0",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "818bebeb63dd6bf5f4e07e145f6cdbace520a34c",
                    "status": "affected",
                    "version": "37173392741c425191b959acb3adf70c9a4610c0",
                    "versionType": "git"
                  }
                ]
              },
              {
                "defaultStatus": "affected",
                "product": "Linux",
                "programFiles": [
                  "drivers/gpu/drm/xe/xe_vram.c"
                ],
                "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
                "vendor": "Linux",
                "versions": [
                  {
                    "status": "affected",
                    "version": "6.13"
                  },
                  {
                    "lessThan": "6.13",
                    "status": "unaffected",
                    "version": "0",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "6.18.*",
                    "status": "unaffected",
                    "version": "6.18.51",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "7.2.*",
                    "status": "unaffected",
                    "version": "7.2.5",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "*",
                    "status": "unaffected",
                    "version": "7.3-rc1",
                    "versionType": "original_commit_for_fix"
                  }
                ]
              }
            ],
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
          }
        ],
        "cveTags": [],
        "descriptions": [
          {
            "lang": "en",
            "value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/xe: Don\u0027t hand out the flat CCS storage as usable VRAM\n\nget_flat_ccs_offset() reads the base of the flat CCS storage from the\nhardware, scales it by the number of enabled L3 nodes, and rounds the\nresult up to 128K.  Everything below that offset is then handed to the\nVRAM allocator as usable memory.\n\nRounding a limit that means \"usable memory ends here\" upwards publishes\nwhatever lies between the real base and the rounded one as free memory,\nand that memory belongs to the compression hardware.  The scaled value\nhas no reason to be 128K aligned, and on a Battlemage G21 with 16 GiB it\nis not:\n\n\tflat CCS base: raw 0x3fafff800, rounded 0x3fb000000\n\nso the last 2 KiB of page 0x3fafff000 is CCS storage, in the allocator\u0027s\npool.  Whatever is allocated there gets that tail overwritten by the\ncompression hardware, which needs no page-table entry, no buffer object\nand no GPU submission to do it, and does it before userspace exists.\n\nOn this machine a Mesa VM\u0027s level-3 page table landed on that page on\nevery cold boot.  It lost the entry covering the compositor\u0027s\nbatch-buffer heap, so the compositor\u0027s first submission faulted fetching\nits batch and gdm restarted it forever: a black screen on an otherwise\nworking machine.  Restarting gdm cleared it because the next VM\u0027s page\ntables were allocated somewhere else.\n\nRound down instead, to the page size the allocator works in.  On this\nmachine that excludes exactly one page.\n\nReading the reserved page afterwards shows what had been writing it:\n\n\t[369] 0xcccc000000000000\n\t[371] 0xcc77000000000000\n\t[373] 0xcccc000000000000\n\t[375] 0xcc77000000000000\n\ncompression metadata, two bytes per sixteen, sitting where the driver\nused to hand out memory.\n\nThe assertion that should have caught this compares the offset against\nGSMBASE - ccs_size for equality.  That value is 128K aligned, so it\nagrees with the rounded-up offset precisely when the base is not\naligned - the check cannot fail in the case it exists to catch, and is\ncompiled out unless CONFIG_DRM_XE_DEBUG is set.  Replace it with one\nthat can fail: CCS storage must not run into GSM.\n\n[ And this was a debug session from hell, enormously helped by an AI\n  doing much of the grunt-work.\n\n  I\u0027d like to call it my tireless helper, but the AI several times\n  stated flat out that this was impossible and unsolvable and that we\n  should just write a report about it.\n\n  I suspect those things have been trained by people who may not be\n  quite as stubborn as I am.\n\n  But while the AI was ready to give up several times, it did keep\n  adding debug code and analyzing it faithfully when I pushed. So credit\n  where credit is due and I let the AI write the commit message above.\n\n  This is basically a one-liner fixing a bogus \"round_up()\" to a\n  \"round_down()\", but there were 24 patches adding more and more debug\n  information to this, and 18 kernel boot to finally narrow it down to\n  this.   - Linus ]"
          },
          {
            "lang": "es",
            "value": "En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:\n\ndrm/xe: No entregar el almacenamiento CCS plano como VRAM utilizable\n\nget_flat_ccs_offset() lee la base del almacenamiento CCS plano del hardware, lo escala por el n\u00famero de nodos L3 habilitados y redondea el resultado al alza a 128K. Todo lo que est\u00e1 por debajo de ese desplazamiento se entrega entonces al asignador de VRAM como memoria utilizable.\n\nRedondear un l\u00edmite que significa \u0027la memoria utilizable termina aqu\u00ed\u0027 hacia arriba publica lo que se encuentra entre la base real y la redondeada como memoria libre, y esa memoria pertenece al hardware de compresi\u00f3n. El valor escalado no tiene raz\u00f3n para estar alineado a 128K, y en un Battlemage G21 con 16 GiB no lo est\u00e1:\n\n\tbase CCS plana: en bruto 0x3fafff800, redondeado 0x3fb000000\n\nas\u00ed que los \u00faltimos 2 KiB de la p\u00e1gina 0x3fafff000 son almacenamiento CCS, en el pool del asignador. Lo que sea que se asigne all\u00ed ve esa cola sobrescrita por el hardware de compresi\u00f3n, el cual no necesita una entrada en la tabla de p\u00e1ginas, ning\u00fan objeto de b\u00fafer y ninguna env\u00edo a la GPU para hacerlo, y lo hace antes de que exista el espacio de usuario.\n\nEn esta m\u00e1quina, la tabla de p\u00e1ginas de nivel 3 de una VM de Mesa aterriz\u00f3 en esa p\u00e1gina en cada arranque en fr\u00edo. Perdi\u00f3 la entrada que cubr\u00eda el heap del b\u00fafer de lotes del compositor, por lo que el primer env\u00edo del compositor fall\u00f3 al recuperar su lote y gdm lo reinici\u00f3 indefinidamente: una pantalla negra en una m\u00e1quina que, por lo dem\u00e1s, funcionaba. Reiniciar gdm lo solucion\u00f3 porque las tablas de p\u00e1ginas de la siguiente VM se asignaron en otro lugar.\n\nRedondear hacia abajo en su lugar, al tama\u00f1o de p\u00e1gina en el que trabaja el asignador. En esta m\u00e1quina, eso excluye exactamente una p\u00e1gina.\n\nLeer la p\u00e1gina reservada despu\u00e9s muestra lo que la hab\u00eda estado escribiendo:\n\n\t[369] 0xcccc000000000000\n\t[371] 0xcc77000000000000\n\t[373] 0xcccc000000000000\n\t[375] 0xcc77000000000000\n\nmetadatos de compresi\u00f3n, dos bytes por cada diecis\u00e9is, ubicados donde el controlador sol\u00eda entregar memoria.\n\nLa aserci\u00f3n que deber\u00eda haber detectado esto compara el desplazamiento con GSMBASE - ccs_size para igualdad. Ese valor est\u00e1 alineado a 128K, por lo que concuerda con el desplazamiento redondeado al alza precisamente cuando la base no est\u00e1 alineada; la verificaci\u00f3n no puede fallar en el caso que existe para detectar, y se compila fuera a menos que CONFIG_DRM_XE_DEBUG est\u00e9 configurado. Reempl\u00e1cela con una que pueda fallar: El almacenamiento CCS no debe invadir GSM.\n\n[ Y esta fue una sesi\u00f3n de depuraci\u00f3n infernal, enormemente ayudada por una IA que hizo gran parte del trabajo pesado.\n\nMe gustar\u00eda llamarlo mi ayudante incansable, pero la IA varias veces afirm\u00f3 rotundamente que esto era imposible e irresoluble y que simplemente deber\u00edamos escribir un informe al respecto.\n\nSospecho que esas cosas han sido entrenadas por personas que quiz\u00e1s no sean tan tercas como yo.\n\nPero aunque la IA estuvo lista para rendirse varias veces, sigui\u00f3 a\u00f1adiendo c\u00f3digo de depuraci\u00f3n y analiz\u00e1ndolo fielmente cuando la presion\u00e9. As\u00ed que, al C\u00e9sar lo que es del C\u00e9sar, y dej\u00e9 que la IA escribiera el mensaje de commit anterior.\n\nEsto es b\u00e1sicamente una l\u00ednea que corrige un \u201cround_up()\u201d err\u00f3neo a un \u201cround_down()\u201d, pero hubo 24 parches que a\u00f1adieron cada vez m\u00e1s informaci\u00f3n de depuraci\u00f3n a esto, y 18 arranques del kernel para finalmente reducirlo a esto. - Linus ]"
          }
        ],
        "id": "CVE-2026-90047",
        "lastModified": "2026-09-28T23:10:00.143",
        "metrics": {
          "cvssMetricV31": [
            {
              "cvssData": {
                "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"
              },
              "exploitabilityScore": 1.8,
              "impactScore": 5.9,
              "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
              "type": "Secondary"
            }
          ]
        },
        "published": "2026-09-16T11:17:17.973",
        "references": [
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/348c3db4f1520d36764ac8cae2492f50599714f6"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/818bebeb63dd6bf5f4e07e145f6cdbace520a34c"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/c96477e0cabf55bfbdf078078e9de1c8024f8060"
          }
        ],
        "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "vulnStatus": "Received"
      }
    }
  }
}



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.



Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.