Skip to main content

Linux Kernel EUVDEUVD-2026-80655

| CVE-2026-90047 HIGH
2026-09-16 Linux GHSA-wrw4-jww2-vw64
7.8
CVSS 3.1 · Vendor: Linux
Share

Severity by source

Vendor (Linux) PRIMARY
7.8 HIGH
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
vuln.today AI
5.7 MEDIUM

No attacker or privilege triggers it (PR:N) and it depends on specific hardware/memory geometry (AV:L/AC:H); corruption is non-attacker-controlled metadata with no disclosure (C:N, I:L) but reliably crashes the GPU stack (A:H).

3.1 AV:L/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:H
4.0 AV:L/AC:H/AT:N/PR:N/UI:N/VC:N/VI:L/VA:H/SC:N/SI:N/SA:N

Primary rating from Vendor (Linux).

CVSS VectorVendor: Linux

Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

Lifecycle Timeline

6
Metadata Corrected
Sep 16, 2026 - 16:40 vuln.today
tag: Intel added
Analysis Generated
Sep 16, 2026 - 16:38 vuln.today
CVSS changed
Sep 16, 2026 - 15:22 NVD
7.8 (HIGH)
Patch available
Sep 16, 2026 - 11:03 EUVD
CVE Published
Sep 16, 2026 - 10:33 cve.org
HIGH 7.8
CVE Published
Sep 16, 2026 - 10:33 cve.org
UNKNOWN (no severity yet)

DescriptionCVE.org

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 ]

AnalysisAI

The Linux kernel's drm/xe Intel GPU driver mis-computes the end of usable VRAM by rounding the flat CCS compression-storage base upward instead of downward, so a small tail of memory that belongs to the GPU's compression hardware is handed to the normal VRAM allocator as free. On affected Intel Xe hardware whose scaled flat CCS base is not 128 KiB aligned - for example a Battlemage G21 with 16 GiB, where the raw base 0x3fafff800 sits just 2 KiB below an aligned boundary - the allocator can place live kernel structures on that page, and the compression hardware then overwrites them at boot with no page-table entry, buffer object or GPU submission required, producing deterministic corruption and, in the reported case, a persistent black screen with gdm restarting in a loop. …

Unlock full vulnerability intelligence

  • Risk assessment & exploitation conditions
  • Attack chain visualization
  • Remediation with exact patch versions
  • Threat intelligence from 22 sources
  • Personal watchlist & email alerts

Free forever · No credit card required

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata

Access
technique details hidden
Delivery
technique details hidden
Exploit
technique details hidden
Execution
technique details hidden
Persist
technique details hidden
Impact
technique details hidden

Vulnerability AssessmentAI

Exploitation Not attacker-triggered. … Additional conditions and limiting factors are described in the full assessment.
Risk Assessment This is a high-CVSS-but-low-real-security-risk case where the vendor CVSS of 7.8 (AV:L/AC:L/PR:L/UI:N/C:H/I:H/A:H) substantially overstates the security impact. … Full risk analysis with EPSS, KEV, and SSVC signal comparison available after sign-in.
Exploit Scenario Full exploit scenario with step-by-step reproduction available after sign-in.
Remediation Vendor-released patch: upgrade to Linux 7.3-rc1 or to the stable backports 6.18.51 / 7.2.5 (or later on those branches), which contain the fix commits c96477e0cabf55bfbdf078078e9de1c8024f8060, 348c3db4f1520d36764ac8cae2492f50599714f6 and 818bebeb63dd6bf5f4e07e145f6cdbace520a34c, obtainable via https://git.kernel.org/stable/c/c96477e0cabf55bfbdf078078e9de1c8024f8060, https://git.kernel.org/stable/c/348c3db4f1520d36764ac8cae2492f50599714f6 and https://git.kernel.org/stable/c/818bebeb63dd6bf5f4e07e145f6cdbace520a34c. … Detailed patch versions, workarounds, and compensating controls in full report.

Recommended ActionAI

Within 24 hours, inventory all Linux endpoints, workstations, and servers running Intel Xe graphics - specifically Battlemage (G21) parts with 16 GiB of VRAM - capturing GPU model, installed kernel version, and boot behaviour, and flag any host that fails to reach a graphical login as potentially affected. …

Sign in for detailed remediation steps and compensating controls.

Threat intelligence, references, and detailed analysis are available after sign-in.

More in Intel

View all
CVE-2021-44228 CRITICAL POC
10.0 Dec 10

Apache Log4j2 contains a critical JNDI injection vulnerability known as 'Log4Shell' that allows unauthenticated remote c

CVE-2017-5689 CRITICAL POC
9.8 May 02

An unprivileged network attacker could gain system privileges to provisioned Intel manageability SKUs: Intel Active Mana

CVE-2012-5958 CRITICAL POC
10.0 Jan 31

Stack-based buffer overflow in the unique_service_name function in ssdp/ssdp_server.c in the SSDP parser in the portable

CVE-2012-0217 HIGH POC
7.2 Jun 12

The x86-64 kernel system-call functionality in Xen 4.1.2 and earlier, as used in Citrix XenServer 6.0.2 and earlier and

CVE-2012-5959 CRITICAL POC
10.0 Jan 31

Stack-based buffer overflow in the unique_service_name function in ssdp/ssdp_server.c in the SSDP parser in the portable

CVE-2012-5964 CRITICAL POC
10.0 Jan 31

Stack-based buffer overflow in the unique_service_name function in ssdp/ssdp_server.c in the SSDP parser in the portable

CVE-2012-5963 CRITICAL POC
10.0 Jan 31

Stack-based buffer overflow in the unique_service_name function in ssdp/ssdp_server.c in the SSDP parser in the portable

CVE-2012-5961 CRITICAL POC
10.0 Jan 31

Stack-based buffer overflow in the unique_service_name function in ssdp/ssdp_server.c in the SSDP parser in the portable

CVE-2017-5753 MEDIUM POC
5.6 Jan 04

Systems with microprocessors utilizing speculative execution and branch prediction may allow unauthorized disclosure of

CVE-2012-5965 CRITICAL POC
10.0 Jan 31

Stack-based buffer overflow in the unique_service_name function in ssdp/ssdp_server.c in the SSDP parser in the portable

CVE-2012-5962 CRITICAL POC
10.0 Jan 31

Stack-based buffer overflow in the unique_service_name function in ssdp/ssdp_server.c in the SSDP parser in the portable

CVE-2012-5960 CRITICAL POC
10.0 Jan 31

Stack-based buffer overflow in the unique_service_name function in ssdp/ssdp_server.c in the SSDP parser in the portable

Share

EUVD-2026-80655 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy