EUVD-2026-103757
GHSA-3g6p-gg5m-mwxx
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessGain local access to nouveau DRM device
-
DeliveryAllocate GEM BO left in TTM_PL_SYSTEM
-
ExploitSubmit UVMM VM bind job
-
ExecutionTrigger use-after-free read in nouveau_uvmm_sm
-
ImpactKernel memory corruption / potential privilege escalation
Vulnerability Assessment
| Exploitation Conditions | Requires the nouveau driver loaded and bound to an NVIDIA GPU, plus local access to the DRM device node to issue the nouveau GEM allocation and UVMM VM-bind ioctls (PR:L per the CVSS vector, so an authenticated local user). The specific trigger is a buffer object left in TTM_PL_SYSTEM whose bo->resource is only a struct ttm_resource (not backed by struct nouveau_mem), as stated in the description. Limiting factors: no remote vector (AV:L), no network path, and real exposure is confined to systems actually running nouveau on NVIDIA hardware - servers without a GPU or systems using the proprietary NVIDIA driver are not affected. Fixed in stable releases 6.12.112, 6.18.55, 7.2.9, and 7.3-rc5 per the EUVD data. |
| Impact | Signals are consistent and point to a moderate, not emergency, priority. The provided CVSS is 7.8 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H): the high base score is driven by full confidentiality/integrity/availability impact typical of a kernel use-after-free, but the attack vector is strictly local (AV:L) and requires low privileges (PR:L), not network-reachable and not unauthenticated. EPSS is only 0.20% (9th percentile), indicating very low modeled probability of widespread exploitation, which aligns with the absence of a CISA KEV listing and no public exploit reference in the input (no public exploit identified at time of analysis). The vuln.today decision label is 'this_week', which is a patch-promptly signal rather than act_now/emergency. The one caveat limiting real-world exposure is that triggering requires the nouveau driver bound to an NVIDIA GPU and local access to the DRM device to issue the GEM/UVMM bind ioctls, so the exploitable population is narrower than the ubiquity of the Linux kernel as a whole. Net: a genuine local kernel memory-corruption bug worth patching this cycle, but not a high-real-risk, mass-exploitation issue. |
| Exploit ScenarioDerived | A local user with access to the nouveau DRM device creates a GEM buffer object that is left in TTM_PL_SYSTEM and then submits a VM bind job; the driver treats the plain ttm_resource as a nouveau_mem and reads mem->mem.type past the end of the allocation, triggering a use-after-free in a kernel workqueue (confirmed by the KASAN slab-use-after-free report). Exploitation is local only (AV:L) with low privileges (PR:L) and low complexity (AC:L). No public exploit identified at time of analysis. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 24, 2026
A local user able to issue nouveau GEM allocation and UVMM VM-bind ioctls against the Linux kernel's nouveau DRM driver can trigger a slab-use-after-free read when a buffer object remains in TTM_PL_SYSTEM, because nouveau_uvmm_sm's map operation treats the plain struct ttm_resource as a struct nouveau_mem and reads mem->mem.type past the end of the allocation. The CVSS vector is AV:L/AC:L/PR:L/UI:N with high confidentiality, integrity and availability impact, so exploitation requires an authenticated local user on a host with nouveau bound to an NVIDIA GPU; systems without such a GPU, or using the proprietary NVIDIA driver, are not exposed. No public exploit code was identified at time of analysis and EPSS is 0.20 percent (9th percentile), so the practical priority is moderate rather than emergency; vendor fixes are published for stable branches 6.12.112, 6.18.55, 7.2.9 and 7.3-rc5.
RemediationAI
Vendor-released patch: update to Linux 6.12.112, 6.18.55, 7.2.9 or 7.3-rc5, or backport the corresponding stable commit (1245b4b43da67596be61600dbd746539c79495ac, 0d29bf51f8dddcf8556bf76710d3dd3024a1a717, 3359a372efb6d585c97019ee1b7f1874442bcebe, 5b2fffbba290ed74f381911b9986570bc10feaa4 or 34d9dffaf0ff43ac395a7955b3f7b5d9d6154bf3, available at https://git.kernel.org/stable/c/1245b4b43da67596be61600dbd746539c79495ac) so that UVMM checks the actual resource type before treating bo->resource as a struct nouveau_mem. Because the trigger requires local access to the DRM device node to issue the nouveau GEM allocation and UVMM bind ioctls, interim mitigation is to restrict permissions on /dev/dri/card* and /dev/dri/renderD* to trusted local users or revoke them from untrusted sessions (for example via a dedicated group or seat policy), at the cost of blocking legitimate GPU compute and rendering for those users; systems that do not require nouveau can instead run the proprietary NVIDIA driver or blacklist the nouveau module, which removes the attack surface but also removes open-source driver support for the GPU.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The flaw lives in nouveau's user-mode virtual memory manager (nouveau_uvmm.c), the component that maps buffer objects into a per-client GPU virtual address space through the DRM scheduler workqueue (nouveau_sched_wq / drm_sched_run_job_work). The UVMM state machine's op_map path passes bo->resource through nouveau_mem() into nouveau_uvma_map(), and nouveau_uvmm_vmm_map() then dereferences mem->mem.type. That container-of assumption only holds for VRAM and TT placements, where the TTM resource is embedded in a struct nouveau_mem. When the BO is left in TTM_PL_SYSTEM, bo->resource is a bare struct ttm_resource, so the mem->mem.type read lands past the end of the allocation and KASAN reports a slab-use-after-free read (the backing slab being the dma_resv fence list allocated during ttm_bo_alloc_resource from the GEM creation ioctl). The report traces the read through nouveau_uvmm_sm, nouveau_uvmm_sm_unmap and nouveau_uvmm_bind_job_run, with the memory previously allocated via nouveau_gem_ioctl_new. No CWE class is assigned in the source data, but the defect is a type-confusion/lifetime error driven by placement-dependent resource layout rather than a race or a heap-grooming primitive.
Know when the next one hits your stack
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Triggered by local DRM ioctls from an unprivileged user (AV:L, PR:L, AC:L, UI:N); a kernel use-after-free plausibly yields full C/I/A impact within the same component (S:U).
Primary rating from Vendor (Linux).
CVSS VectorVendor: Linux
Lifecycle Timeline
4DescriptionCVE.org
In the Linux kernel, the following vulnerability has been resolved:
drm/nouveau/uvmm: fix UAF in nouveau_uvmm_sm when BO is in TTM_PL_SYSTEM
nouveau_uvmm_sm() calls op_map(), which passes bo->resource through nouveau_mem() to nouveau_uvma_map(). nouveau_uvmm_vmm_map() then reads mem->mem.type.
But this is only valid when bo->resource is backed by struct nouveau_mem, as is the case for VRAM and TT resources. If the BO is left in TTM_PL_SYSTEM, bo->resource is only a struct ttm_resource. Treating it as struct nouveau_mem makes the mem->mem.type read past the end of the resource, causing a KASAN: slab-use-after-free Read in nouveau_uvmm_sm report:
BUG: KASAN: slab-use-after-free in nouveau_uvmm_vmm_map drivers/gpu/drm/nouveau/nouveau_uvmm.c:152 [inline] BUG: KASAN: slab-use-after-free in nouveau_uvma_map drivers/gpu/drm/nouveau/nouveau_uvmm.c:199 [inline] BUG: KASAN: slab-use-after-free in op_map drivers/gpu/drm/nouveau/nouveau_uvmm.c:849 [inline] BUG: KASAN: slab-use-after-free in nouveau_uvmm_sm.constprop.0+0x6ab/0x900 drivers/gpu/drm/nouveau/nouveau_uvmm.c:903 Read of size 1 at addr ffff888127d3e3a0 by task kworker/0:1/11
CPU: 0 UID: 0 PID: 11 Comm: kworker/0:1 Not tainted 7.2.0 #5 PREEMPT(lazy) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Workqueue: nouveau_sched_wq_2224 drm_sched_run_job_work Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x95/0xe0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xcb/0x5a0 mm/kasan/report.c:482 kasan_report+0xca/0x100 mm/kasan/report.c:595 nouveau_uvmm_vmm_map drivers/gpu/drm/nouveau/nouveau_uvmm.c:152 [inline] nouveau_uvma_map drivers/gpu/drm/nouveau/nouveau_uvmm.c:199 [inline] op_map drivers/gpu/drm/nouveau/nouveau_uvmm.c:849 [inline] nouveau_uvmm_sm.constprop.0+0x6ab/0x900 drivers/gpu/drm/nouveau/nouveau_uvmm.c:903 nouveau_uvmm_sm_unmap drivers/gpu/drm/nouveau/nouveau_uvmm.c:932 [inline] nouveau_uvmm_bind_job_run+0xd6/0x250 drivers/gpu/drm/nouveau/nouveau_uvmm.c:1532 nouveau_job_run drivers/gpu/drm/nouveau/nouveau_sched.c:350 [inline] nouveau_sched_run_job+0x62/0xd0 drivers/gpu/drm/nouveau/nouveau_sched.c:364 drm_sched_run_job_work+0x356/0xa10 drivers/gpu/drm/scheduler/sched_main.c:1061 process_one_work+0x8a5/0x1900 kernel/workqueue.c:3322 process_scheduled_works kernel/workqueue.c:3405 [inline] worker_thread+0x5dd/0xd80 kernel/workqueue.c:3486 kthread+0x31d/0x420 kernel/kthread.c:436 ret_from_fork+0x662/0x940 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 </TASK>
Allocated by task 2224 on cpu 0 at 66.550027s: kasan_save_stack+0x24/0x50 mm/kasan/common.c:57 kasan_save_track+0x17/0x60 mm/kasan/common.c:78 poison_kmalloc_redzone mm/kasan/common.c:398 [inline] __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:415 kasan_kmalloc include/linux/kasan.h:263 [inline] __do_kmalloc_node mm/slub.c:5334 [inline] __kmalloc_noprof+0x304/0x7c0 mm/slub.c:5359 _kmalloc_noprof include/linux/slab.h:992 [inline] dma_resv_list_alloc+0x27/0x90 drivers/dma-buf/dma-resv.c:106 dma_resv_reserve_fences+0x60e/0xa30 drivers/dma-buf/dma-resv.c:205 ttm_bo_alloc_resource+0x12c/0xbd0 drivers/gpu/drm/ttm/ttm_bo.c:721 ttm_bo_validate+0x1bc/0x4a0 drivers/gpu/drm/ttm/ttm_bo.c:856 ttm_bo_init_reserved+0x2c3/0x570 drivers/gpu/drm/ttm/ttm_bo.c:970 nouveau_bo_init+0x159/0x2c0 drivers/gpu/drm/nouveau/nouveau_bo.c:359 nouveau_gem_new+0x234/0x5f0 drivers/gpu/drm/nouveau/nouveau_gem.c:272 nouveau_gem_ioctl_new+0x1eb/0x420 drivers/gpu/drm/nouveau/nouveau_gem.c:352 drm_ioctl_kernel+0x192/0x350 drivers/gpu/drm/drm_ioctl.c:817 drm_ioctl+0x4f8/0xb40 drivers/gpu/drm/drm_ioctl.c:914 nouveau_drm_ioctl+0xea/0x2c0 drivers/gpu/drm/nouveau/nouveau_drm.c:1338 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl fs/ioctl.c:583 [inline] __x64_sys_ioctl+0x180/0x1d0 fs/ioctl.c:583 do_syscall_x64 ar ---truncated---
Executive ViewAI
CVE-2026-98517 is a high-severity local privilege escalation vulnerability in the Linux kernel's nouveau driver, affecting systems with NVIDIA GPUs using open-source nouveau. A local attacker could exploit this to compromise confidentiality, integrity, and availability, but only if they have authenticated access. Given low exploitation likelihood, we recommend prompt patching on affected systems to mitigate risk while avoiding emergency response.
Apply vendor patch.
Threat Intelligence Overview
NVD
CVE.org
EPSS
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
Exploit-DB