Description
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 ]
Published: 2026-09-16
Score: 7.8 High
EPSS: < 1% Very Low
KEV: No
Impact: Denial of Service and potential kernel memory corruption
Action: Apply patch
AI Analysis

Impact

A rounding bug in the Linux kernel's DRM/xe component causes the kernel to publish a region of memory that belongs to the compression hardware as free VRAM. When a userspace graphics driver allocates memory from this region, the GPU overwrites kernel data structures without needing a page table or a submission, leading to memory corruption and repeated crashes of the display manager. The main effects are loss of display (black screen), forced restarts of the graphical interface, and potential denial of service for the system.

Affected Systems

The bug affects all Linux kernel releases that include the DRM/xe code prior to the patch that rounds the CCS offset down instead of up. The affected vendor is Linux and product is the Linux kernel, meaning any distribution using an unpatched kernel is vulnerable. The fix is in commit 348c3db4f1520d36764ac8cae2492f50599714f6; environments running kernel versions older than this commit are impacted.

Risk and Exploitability

The CVSS score of 7.8 classifies the issue as high. The EPSS score of less than 1% indicates a very low likelihood of exploitation in the wild, and the vulnerability is not listed in the CISA KEV catalogue. The likely attack vector is local kernel exploitation via privileged users or compromised graphics drivers; an attacker would need to trigger the driver or load a malicious driver that requests memory in the corrupted region.

Generated by OpenCVE AI on September 18, 2026 at 05:18 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Apply the kernel patch that corrects the rounding logic in get_flat_ccs_offset (commit 348c3db4f1520d36764ac8cae2492f50599714f6) and rebuild the kernel.
  • Ensure all loaded graphics drivers (e.g., Mesa) are compiled against the updated kernel headers.
  • Reboot the system to activate the updated kernel and verify that no more memory corruption occurs; optionally run graphics tests to confirm stability.

Generated by OpenCVE AI on September 18, 2026 at 05:18 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Fri, 18 Sep 2026 05:45:00 +0000

Type Values Removed Values Added
Weaknesses CWE-119

Wed, 16 Sep 2026 14:45:00 +0000

Type Values Removed Values Added
Metrics cvssV3_1

{'score': 7.8, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H'}

Wed, 16 Sep 2026 10:45:00 +0000

Type Values Removed Values Added
Description 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 ]
Title drm/xe: Don't hand out the flat CCS storage as usable VRAM
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-09-16T14:42:02.936Z

Reserved: 2026-09-11T19:38:34.783Z

Link: CVE-2026-90047

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-09-16T11:17:17.973

Modified: 2026-09-28T23:10:00.143

Link: CVE-2026-90047

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-09-18T06:00:04Z

Weaknesses
  • CWE-119

    Improper Restriction of Operations within the Bounds of a Memory Buffer