Look up another CVE · open CVE-2026-68274 in the interactive tracker
CVE-2026-68274
drm/xe/guc: Fix buffer overflow in steered register list allocation
Published 2026-08-10 (2 months ago) by the Linux kernel CNA. Subsystem drivers/gpu. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-68274 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | not affected | 6.1.190-1 | Nothing to do. bookworm never shipped the vulnerable code. |
| Debian 13trixie | not affected | 6.12.113-1 | Nothing to do. trixie never shipped the vulnerable code. |
| Debian 14forky | fixed | 7.1.6-1 | Update the kernel and reboot. Fixed in 7.1.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.1.6-1 | Update the kernel and reboot. Fixed in 7.1.6-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
The size calculation for the steered register extarray uses only the geometry DSS mask (g_dss_mask) to determine the number of entries to allocate: total = bitmap_weight(gt->fuse_topo.g_dss_mask, ...) * steer_reg_num; However, the filling loop uses for_each_dss_steering(), which iterates over for_each_dss(), defined as the union of g_dss_mask and c_dss_mask (geometry + compute DSS). On platforms with compute-only DSS bits, the loop writes past the allocated buffer, corrupting adjacent slab objects. This manifests as list_del corruption and SLUB redzone overwrites during drm_managed_release on device unbind, since the overflow corrupts the drmres list_head of neighboring allocations. Fix by computing the allocation size using the union of both DSS masks, matching the iteration pattern of for_each_dss_steering(). -- v2: - use bitmap_weighted_or() (Zhanjun) (cherry picked from commit 0a78a44f4901aa6c9263e66be7fce02282f1109f)
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
drivers/gpu/drm/xe/xe_guc_capture.c
- What this is
- INTEL DRM XE DRIVER (Lunar Lake and newer)MAINTAINERS section matched on drivers/gpu/drm/xe/ · intel-xe@lists.freedesktop.org · Supported
- Kernel module
- xe
Check it on the machine
grep -w CONFIG_DRM_XE /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
lsmod | grep -w xePrints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.
Show whether Debian builds this, per release
Debian builds this, but not on every flavour. At least one release below builds the code on some of its kernel flavours and not on others, so the answer depends on the architecture and flavour installed. The build rule could not be established for 2 releases, so nothing is claimed about those.
- bookworm, trixie?
- forky, sidMnot built on amd64/cloud-amd64, arm64/arm64-16k, arm64/cloud-arm64, loong64/loong64, ppc64el/powerpc64le-64k, s390x/s390x
- ?
- not established - no Makefile entry for the affected file
- M
- a module where it is built at all; some flavours do not build it
Where a release above reads "not established", no build rule for the affected file was found in that release's kernel tree. That is a gap in this lookup, not a finding that the code is absent.
- Build switch
- CONFIG_DRM_XE
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-08-10 (2 months ago)source
- CVSS
- 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.15%, higher than 3.8% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- Subsystem
- drivers/gpu
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 6.13 | 6.18.44 | b485bfb45555 |
| 6.13 | 7.1.6 | a9a020f3c11e |
| 6.13 | 7.2 | 632ecc90e1ca |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- The flaw is in the drm/xe GPU driver's GuC ADS/capture-list setup, reached only through local kernel device probe/GuC upload on the machine's own hardware; there is no network or remote-peer input anywhere on the path.
- AC:LAttack complexity, low
- On any affected platform (one whose compute DSS mask contains bits outside the geometry DSS mask) the undersized allocation and the for_each_dss_steering() fill loop mismatch is fully deterministic, so the out-of-bounds write occurs reliably on every driver load without needing a race or a lucky memory layout.
- PR:LPrivileges required, low
- The overflow happens in the xe driver's GuC initialization path, so an attacker needs only ordinary local access to a system with the affected Intel GPU present; no capability check or elevated privilege gates the corrupted code path itself.
- UI:NUser interaction, none
- No victim action is needed; the buffer overflow occurs automatically during xe_guc_ads_populate() at device probe, with no file to open, filesystem to mount, or user gesture involved.
- S:UScope, unchanged
- The out-of-bounds write corrupts kernel slab objects belonging to the same kernel security authority; there is no crossing of a VM, IOMMU, or sandbox boundary.
- C:HConfidentiality impact, high
- The overflow overwrites adjacent slab objects including drmres list_head pointers, and such heap metadata corruption can be leveraged to make subsequent list operations dereference attacker-influenceable heap contents, so an information-disclosure primitive cannot be ruled out.
- I:HIntegrity impact, high
- This is a heap out-of-bounds write past the end of the drmm_kzalloc'd extarray, overwriting neighboring allocations' contents and list linkage, which is exactly the class of corruption that yields arbitrary-write and control-flow-hijack primitives.
- A:HAvailability impact, high
- The corruption is confirmed to produce list_del corruption and SLUB redzone overwrites, causing kernel oops/panic during drm_managed_release on device unbind and unpredictable slab corruption beforehand.