Cloudanix VulnDB

CVE-2026-98180

High · 7.1

CVSS

7.1

EPSS

0.1%

Published

Oct 6, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A flaw in Linux graphics handling for certain devices can let a logged-in user read parts of protected memory that should have been cleaned up.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Low
Impact
Data Exposure
Component
OS kernel
Class
Use After Free
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Use-after-free read in drm_sched_fence_get_timeline_name() after kfree() of objects embedding drm_gpu_scheduler (msm_ringbuffer and msm_gem_vm), reachable via exported signaled fences through SYNC_IOC_FILE_INFO.

Why it matters to the business

Local attackers on affected Linux systems can read kernel memory, potentially leading to information disclosure or privilege escalation; systems using MSM DRM graphics (common on ARM devices) face elevated local risk until patched.

How an attack unfolds

An attacker with local access triggers creation and export of a submit or VM_BIND fence, waits for signaling, frees the containing ring or VM object, then invokes SYNC_IOC_FILE_INFO on the fence to dereference the freed scheduler name field.

How to fix it

Update the Linux kernel to a version containing the referenced patch that replaces kfree() with kfree_rcu() for msm_ringbuffer and msm_gem_vm objects; rebuild and reboot after applying the fix.

How to confirm the fix worked

Confirm the patch is present by checking for kfree_rcu calls in msm_ringbuffer_destroy() and msm_gem_vm_free(); run KASAN-enabled tests exercising fence export and SYNC_IOC_FILE_INFO after object destruction.

Typical attack path

  1. Obtain local unprivileged access on a system with msm DRM driver loaded
  2. Perform GPU submission or VM_BIND operation that exports a sync_file or drm_syncobj fence
  3. Allow the fence to signal and be exported to userspace
  4. Free the underlying msm_ringbuffer or msm_gem_vm via normal object destruction paths
  5. Call SYNC_IOC_FILE_INFO on the still-valid fence fd to trigger the use-after-free read

How to detect it

Review kernel logs for KASAN slab-use-after-free reports referencing drm_sched_fence or msm_ringbuffer; inspect audit logs for unusual SYNC_IOC_FILE_INFO calls on DRM fences followed by object destruction; correlate with local process activity creating GPU submissions.

What your security team should do

  • Prioritize kernel updates on all systems exposing MSM DRM (mobile/embedded ARM devices first)
  • Monitor upstream stable branches for the merged fix and schedule distribution updates
  • Restrict unprivileged access to DRM render nodes where feasible until patched

The record

In the Linux kernel, the following vulnerability has been resolved: drm/msm: RCU-free the scheduler-containing ring and VM objects Both struct msm_ringbuffer and struct msm_gem_vm embed a struct drm_gpu_scheduler. msm_ringbuffer_destroy() and the VM free callback msm_gem_vm_free() call drm_sched_fini() on the embedded scheduler and then free the containing object with plain kfree(). drm_sched_fence_get_timeline_name() returns fence->sched->name, and the scheduler fence keeps a .release callback so it is not ops-detached on signalling. A finished fence exported to userspace (the submit out-fence, or a VM_BIND fence, via sync_file / drm_syncobj) keeps pointing at the embedded scheduler after the ring/VM is freed, so a later get_timeline_name() -- reachable unprivileged through SYNC_IOC_FILE_INFO -- dereferences freed slab memory (KASAN slab-use-after-free read). Per the dma-fence lifetime contract the exporter must keep the data backing a signalled fence alive for an RCU grace period. Free the scheduler-containing objects with kfree_rcu() instead of kfree(). Patchwork: https://patchwork.freedesktop.org/patch/750234/

Affected packages

Ecosystem Package Introduced Fixed