{"api_version":"1","generated_at":"2026-09-16T16:13:33+00:00","cve":"CVE-2026-90047","urls":{"html":"https://cve.report/CVE-2026-90047","api":"https://cve.report/api/cve/CVE-2026-90047.json","docs":"https://cve.report/api","cve_org":"https://www.cve.org/CVERecord?id=CVE-2026-90047","nvd":"https://nvd.nist.gov/vuln/detail/CVE-2026-90047"},"summary":{"title":"drm/xe: Don't hand out the flat CCS storage as usable VRAM","description":"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 ]","state":"PUBLISHED","assigner":"Linux","published_at":"2026-09-16 11:17:17","updated_at":"2026-09-16 15:18:27"},"problem_types":[],"metrics":[{"version":"3.1","source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","type":"Secondary","score":"7.8","severity":"HIGH","vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","data":{"version":"3.1","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","baseScore":7.8,"baseSeverity":"HIGH","attackVector":"LOCAL","attackComplexity":"LOW","privilegesRequired":"LOW","userInteraction":"NONE","scope":"UNCHANGED","confidentialityImpact":"HIGH","integrityImpact":"HIGH","availabilityImpact":"HIGH"}},{"version":"3.1","source":"CNA","type":"DECLARED","score":"7.8","severity":"HIGH","vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","data":{"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"}}],"references":[{"url":"https://git.kernel.org/stable/c/818bebeb63dd6bf5f4e07e145f6cdbace520a34c","name":"https://git.kernel.org/stable/c/818bebeb63dd6bf5f4e07e145f6cdbace520a34c","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/348c3db4f1520d36764ac8cae2492f50599714f6","name":"https://git.kernel.org/stable/c/348c3db4f1520d36764ac8cae2492f50599714f6","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/c96477e0cabf55bfbdf078078e9de1c8024f8060","name":"https://git.kernel.org/stable/c/c96477e0cabf55bfbdf078078e9de1c8024f8060","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-90047","name":"CVE Program record","refsource":"CVE.ORG","tags":["canonical"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-90047","name":"NVD vulnerability detail","refsource":"NVD","tags":["canonical","analysis"]}],"affected":[{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 37173392741c425191b959acb3adf70c9a4610c0 c96477e0cabf55bfbdf078078e9de1c8024f8060 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 37173392741c425191b959acb3adf70c9a4610c0 348c3db4f1520d36764ac8cae2492f50599714f6 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 37173392741c425191b959acb3adf70c9a4610c0 818bebeb63dd6bf5f4e07e145f6cdbace520a34c git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 6.13","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.13 semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.18.51 6.18.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 7.2.5 7.2.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 7.3-rc1 * original_commit_for_fix","platforms":[]}],"timeline":[],"solutions":[],"workarounds":[],"exploits":[],"credits":[],"nvd_cpes":[],"vendor_comments":[],"enrichments":{"kev":null,"epss":null,"legacy_qids":[]},"source_records":{"cve_program":{"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'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 ]"}],"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's 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's 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' 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' 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't 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"},"nvd":{"publishedDate":"2026-09-16 11:17:17","lastModifiedDate":"2026-09-16 15:18:27","problem_types":[],"metrics":{"cvssMetricV31":[{"source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","type":"Secondary","cvssData":{"version":"3.1","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","baseScore":7.8,"baseSeverity":"HIGH","attackVector":"LOCAL","attackComplexity":"LOW","privilegesRequired":"LOW","userInteraction":"NONE","scope":"UNCHANGED","confidentialityImpact":"HIGH","integrityImpact":"HIGH","availabilityImpact":"HIGH"},"exploitabilityScore":1.8,"impactScore":5.9}]},"configurations":[]},"legacy_mitre":{"record":{"CveYear":"2026","CveId":"90047","Ordinal":"1","Title":"drm/xe: Don't hand out the flat CCS storage as usable VRAM","CVE":"CVE-2026-90047","Year":"2026"},"notes":[{"CveYear":"2026","CveId":"90047","Ordinal":"1","NoteData":"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 ]","Type":"Description","Title":"drm/xe: Don't hand out the flat CCS storage as usable VRAM"}]}}}