← All Advisories

CVE-2026-98180

Last refreshed2026-10-09

Status: UPDATED  |  Advisory ID: CVE-2026-98180

Key Details

CVECVE-2026-98180
CVSS Score / Version7.1 (High) / CVSS v3.1
Updated2026-10-07
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
CVSS Proseattack vector is local; attack complexity is low; privileges required is low; user interaction is none; scope is unchanged; confidentiality impact is high; integrity impact is none; availability impact is high.
Affected productsLinux Kernel

Affected Products, Subsystems & Sectors

VendorProductAffected VersionsPatch Status
LinuxLinux Kernel
SubsystemsOT Supporting Infrastructure
SectorsAll Sectors

What to Know

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/ (NVD)

What to Do

Monitor Linux's web page for any future patch releases.

References

SourceReference
NVDhttps://nvd.nist.gov/vuln/detail/CVE-2026-98180
CVEhttps://www.cve.org/CVERecord?id=CVE-2026-98180