CVE-2026-90047
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:
Leer descripción completaMostrar menos
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:
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.
Detalles técnicos trazas, registros y código del informe original
flat CCS base: raw 0x3fafff800, rounded 0x3fb000000 [369] 0xcccc000000000000 [371] 0xcc77000000000000 [373] 0xcccc000000000000 [375] 0xcc77000000000000 [ 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 ]
CVSS
- Versión: 3.1
- Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
- Puntuación base: 7.8
Probabilidad de explotación (EPSS)
- Probabilidad de explotación en los próximos 30 días: 0.17%
- Percentil entre todas las CVEs puntuadas: 6
- Fecha de la puntuación: 6/10/2026
EPSS (Exploit Prediction Scoring System, de FIRST) estima la probabilidad de que una vulnerabilidad sea explotada en 30 días. Complementa a CVSS (impacto) y a CISA KEV (explotación confirmada).
🎯 Técnicas ATT&CK
Cómo se explota esta vulnerabilidad y qué consigue el atacante, en el lenguaje de MITRE ATT&CK.
- Explotación
T1068Exploitation for Privilege Escalationprivilege escalation75 % - Impacto principal
T1565.001Stored Data Manipulationimpact70 % - Impacto secundario
T1499.004Application or System Exploitationimpact65 %
Privilegio local (PR:L) permite explotar fallo en gestor de memoria del kernel Linux para corromper datos críticos (tablas de página) o provocar DoS mediante sobrescritura no autorizada por hardware de compresión.
Inferido por nuestro agente de análisis a partir de la descripción oficial, el vector CVSS y la CWE, y comprobado por un supervisor. Puede contener errores.
🛡️ Mitigaciones ATT&CK que cubren estas técnicas
Tecnologías afectadas (1)
⚠ Inferidas por IA a partir de la descripción — NVD aún no ha analizado esta CVE; no son CPE verificados.
Referencias
JSON original (NVD)
Mostrar
{
"id": "CVE-2026-90047",
"cveTags": [],
"metrics": {
"cvssMetricV31": [
{
"type": "Secondary",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"cvssData": {
"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"
},
"impactScore": 5.9,
"exploitabilityScore": 1.8
}
]
},
"affected": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"affectedData": [
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"product": "Linux",
"versions": [
{
"status": "affected",
"version": "37173392741c425191b959acb3adf70c9a4610c0",
"lessThan": "c96477e0cabf55bfbdf078078e9de1c8024f8060",
"versionType": "git"
},
{
"status": "affected",
"version": "37173392741c425191b959acb3adf70c9a4610c0",
"lessThan": "348c3db4f1520d36764ac8cae2492f50599714f6",
"versionType": "git"
},
{
"status": "affected",
"version": "37173392741c425191b959acb3adf70c9a4610c0",
"lessThan": "818bebeb63dd6bf5f4e07e145f6cdbace520a34c",
"versionType": "git"
}
],
"programFiles": [
"drivers/gpu/drm/xe/xe_vram.c"
],
"defaultStatus": "unaffected"
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"product": "Linux",
"versions": [
{
"status": "affected",
"version": "6.13"
},
{
"status": "unaffected",
"version": "0",
"lessThan": "6.13",
"versionType": "semver"
},
{
"status": "unaffected",
"version": "6.18.51",
"versionType": "semver",
"lessThanOrEqual": "6.18.*"
},
{
"status": "unaffected",
"version": "7.2.5",
"versionType": "semver",
"lessThanOrEqual": "7.2.*"
},
{
"status": "unaffected",
"version": "7.3-rc1",
"versionType": "original_commit_for_fix",
"lessThanOrEqual": "*"
}
],
"programFiles": [
"drivers/gpu/drm/xe/xe_vram.c"
],
"defaultStatus": "affected"
}
]
}
],
"published": "2026-09-16T11:17:17.973",
"references": [
{
"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",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"vulnStatus": "Received",
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/xe: Don't 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's\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's level-3 page table landed on that page on\nevery cold boot. It lost the entry covering the compositor's\nbatch-buffer heap, so the compositor's 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's 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'd 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úmero de nodos L3 habilitados y redondea el resultado al alza a 128K. Todo lo que está por debajo de ese desplazamiento se entrega entonces al asignador de VRAM como memoria utilizable.\n\nRedondear un límite que significa 'la memoria utilizable termina aquí' 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ón. El valor escalado no tiene razón para estar alineado a 128K, y en un Battlemage G21 con 16 GiB no lo está:\n\n\tbase CCS plana: en bruto 0x3fafff800, redondeado 0x3fb000000\n\nasí que los últimos 2 KiB de la página 0x3fafff000 son almacenamiento CCS, en el pool del asignador. Lo que sea que se asigne allí ve esa cola sobrescrita por el hardware de compresión, el cual no necesita una entrada en la tabla de páginas, ningún objeto de búfer y ninguna envío a la GPU para hacerlo, y lo hace antes de que exista el espacio de usuario.\n\nEn esta máquina, la tabla de páginas de nivel 3 de una VM de Mesa aterrizó en esa página en cada arranque en frío. Perdió la entrada que cubría el heap del búfer de lotes del compositor, por lo que el primer envío del compositor falló al recuperar su lote y gdm lo reinició indefinidamente: una pantalla negra en una máquina que, por lo demás, funcionaba. Reiniciar gdm lo solucionó porque las tablas de páginas de la siguiente VM se asignaron en otro lugar.\n\nRedondear hacia abajo en su lugar, al tamaño de página en el que trabaja el asignador. En esta máquina, eso excluye exactamente una página.\n\nLeer la página reservada después muestra lo que la había estado escribiendo:\n\n\t[369] 0xcccc000000000000\n\t[371] 0xcc77000000000000\n\t[373] 0xcccc000000000000\n\t[375] 0xcc77000000000000\n\nmetadatos de compresión, dos bytes por cada dieciséis, ubicados donde el controlador solía entregar memoria.\n\nLa aserción que debería haber detectado esto compara el desplazamiento con GSMBASE - ccs_size para igualdad. Ese valor está alineado a 128K, por lo que concuerda con el desplazamiento redondeado al alza precisamente cuando la base no está alineada; la verificación no puede fallar en el caso que existe para detectar, y se compila fuera a menos que CONFIG_DRM_XE_DEBUG esté configurado. Reemplácela con una que pueda fallar: El almacenamiento CCS no debe invadir GSM.\n\n[ Y esta fue una sesión de depuración infernal, enormemente ayudada por una IA que hizo gran parte del trabajo pesado.\n\nMe gustaría llamarlo mi ayudante incansable, pero la IA varias veces afirmó rotundamente que esto era imposible e irresoluble y que simplemente deberíamos escribir un informe al respecto.\n\nSospecho que esas cosas han sido entrenadas por personas que quizás no sean tan tercas como yo.\n\nPero aunque la IA estuvo lista para rendirse varias veces, siguió añadiendo código de depuración y analizándolo fielmente cuando la presioné. Así que, al César lo que es del César, y dejé que la IA escribiera el mensaje de commit anterior.\n\nEsto es básicamente una línea que corrige un “round_up()” erróneo a un “round_down()”, pero hubo 24 parches que añadieron cada vez más información de depuración a esto, y 18 arranques del kernel para finalmente reducirlo a esto. - Linus ]"
}
],
"lastModified": "2026-09-28T23:10:00.143",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}