Cloudanix VulnDB

CVE-2025-68802

None

CVSS

—

EPSS

0.2%

Published

Jan 13, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A graphics driver bug lets programs ask for too much memory at once, which can make the system log warnings or become unstable until the kernel is updated.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Low
Impact
Denial Of Service
Component
OS kernel
Class
Improper Input Validation
Remediation
Patch
Effort
Low
Patch risk
Low

What it actually does

The exec and vm_bind ioctls in the Linux kernel drm/xe driver accept an unbounded num_syncs value from userspace, allowing an arbitrarily large allocation via kmalloc_array that triggers page allocator warnings and potential resource exhaustion.

Why it matters to the business

Systems using Intel Xe graphics hardware may experience kernel warnings, reduced stability, or denial-of-service conditions when untrusted applications issue crafted graphics commands; the issue affects a wide range of Linux distributions and kernels published after the vulnerability window.

How an attack unfolds

An attacker with access to the DRM device node crafts an ioctl request containing an excessively large num_syncs parameter; this reaches xe_exec_ioctl without bounds checking, causing an oversized kmalloc that triggers allocator warnings visible in kernel logs.

How to fix it

Update the Linux kernel to a version containing commit e281d1fd6903a081ef023c341145ae92258e38d2 or later; the fix introduces DRM_XE_MAX_SYNCS set to 1024 and rejects larger values at the start of the exec handler.

How to confirm the fix worked

Confirm the running kernel contains commit e281d1fd6903a081ef023c341145ae92258e38d2; test by attempting an ioctl with num_syncs=1025 and verify the request is rejected before allocation.

Typical attack path

  1. Obtain access to a system with the vulnerable drm/xe driver loaded
  2. Open the DRM device file descriptor
  3. Invoke the exec or vm_bind ioctl supplying num_syncs greater than 1024
  4. Observe kernel page allocator warnings and potential follow-on instability

How to detect it

Review kernel logs for page allocator warnings containing __alloc_frozen_pages_noprof and call traces that include xe_exec_ioctl or drm_ioctl_kernel; correlate with processes issuing DRM ioctls.

What your security team should do

  • Prioritize kernel updates on all systems exposing the Xe DRM device to untrusted users
  • Monitor kernel logs for page allocator warnings referencing xe_exec_ioctl or __kmalloc_large_node
  • Restrict DRM device access via permissions or SELinux/AppArmor until patches are applied

The record

In the Linux kernel, the following vulnerability has been resolved: drm/xe: Limit num_syncs to prevent oversized allocations The exec and vm_bind ioctl allow userspace to specify an arbitrary num_syncs value. Without bounds checking, a very large num_syncs can force an excessively large allocation, leading to kernel warnings from the page allocator as below. Introduce DRM_XE_MAX_SYNCS (set to 1024) and reject any request exceeding this limit. " ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1217 at mm/page_alloc.c:5124 __alloc_frozen_pages_noprof+0x2f8/0x2180 mm/page_alloc.c:5124 ... Call Trace: <TASK> alloc_pages_mpol+0xe4/0x330 mm/mempolicy.c:2416 ___kmalloc_large_node+0xd8/0x110 mm/slub.c:4317 __kmalloc_large_node_noprof+0x18/0xe0 mm/slub.c:4348 __do_kmalloc_node mm/slub.c:4364 [inline] __kmalloc_noprof+0x3d4/0x4b0 mm/slub.c:4388 kmalloc_noprof include/linux/slab.h:909 [inline] kmalloc_array_noprof include/linux/slab.h:948 [inline] xe_exec_ioctl+0xa47/0x1e70 drivers/gpu/drm/xe/xe_exec.c:158 drm_ioctl_kernel+0x1f1/0x3e0 drivers/gpu/drm/drm_ioctl.c:797 drm_ioctl+0x5e7/0xc50 drivers/gpu/drm/drm_ioctl.c:894 xe_drm_ioctl+0x10b/0x170 drivers/gpu/drm/xe/xe_device.c:224 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:598 [inline] __se_sys_ioctl fs/ioctl.c:584 [inline] __x64_sys_ioctl+0x18b/0x210 fs/ioctl.c:584 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xbb/0x380 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f ... " v2: Add "Reported-by" and Cc stable kernels. v3: Change XE_MAX_SYNCS from 64 to 1024. (Matt & Ashutosh) v4: s/XE_MAX_SYNCS/DRM_XE_MAX_SYNCS/ (Matt) v5: Do the check at the top of the exec func. (Matt) (cherry picked from commit b07bac9bd708ec468cd1b8a5fe70ae2ac9b0a11c)

Affected packages

Ecosystem Package Introduced Fixed
Linux Kernel 6.8.0 6.12.64
openSUSE:Leap 16.0 dtb-aarch64 0 6.12.0-160000.26.1
openSUSE:Leap 16.0 kernel-64kb 0 6.12.0-160000.26.1
openSUSE:Leap 16.0 kernel-azure 0 6.12.0-160000.26.1
openSUSE:Leap 16.0 kernel-default 0 6.12.0-160000.26.1
openSUSE:Leap 16.0 kernel-default-base 0 6.12.0-160000.26.1.160000.2.7
openSUSE:Leap 16.0 kernel-docs 0 6.12.0-160000.26.1
openSUSE:Leap 16.0 kernel-kvmsmall 0 6.12.0-160000.26.1
openSUSE:Leap 16.0 kernel-obs-build 0 6.12.0-160000.26.1
openSUSE:Leap 16.0 kernel-obs-qa 0 6.12.0-160000.26.1
openSUSE:Leap 16.0 kernel-rt 0 6.12.0-160000.26.1
openSUSE:Leap 16.0 kernel-source 0 6.12.0-160000.26.1
openSUSE:Leap 16.0 kernel-syms 0 6.12.0-160000.26.1
openSUSE:Leap 16.0 kernel-zfcpdump 0 6.12.0-160000.26.1

Related vulnerabilities