CVE-2026-80539: Linux Kernel Privilege Escalation Vulnerability

CVE-2026-80539 Overview

CVE-2026-80539 is a memory leak vulnerability in the Linux kernel's AMD GPU (amdgpu) Direct Rendering Manager (DRM) driver. The flaw resides in amdgpu_cs_pass1(), which dispatches on chunk_id once per chunk without rejecting repeated identifiers. A submission carrying multiple AMDGPU_CHUNK_ID_FENCE chunks invokes amdgpu_cs_p1_user_fence() more than once, causing subsequent runs to overwrite p->uf_bo without releasing the previously referenced buffer object (BO). The leaked BO reference persists beyond handle close and process exit, exhausting kernel resources over time.

Critical Impact
Local unprivileged users can exhaust kernel memory by submitting crafted command streams with duplicate FENCE chunks, resulting in persistent buffer object reference leaks that outlive the calling process.

Affected Products

Linux kernel builds shipping the drm/amdgpu driver prior to the fix
Distributions carrying the vulnerable amdgpu_cs_pass1() implementation
Systems using AMD GPUs with the kernel-mode DRM submission interface

Discovery Timeline

2026-08-26 - CVE-2026-80539 published to NVD
2026-08-27 - Last updated in NVD database

Technical Details for CVE-2026-80539

Vulnerability Analysis

The vulnerability is a memory leak stemming from missing duplicate-chunk validation in the amdgpu command submission (CS) path. When userspace issues an ioctl submission through the DRM interface, amdgpu_cs_pass1() iterates each chunk and dispatches handlers based on chunk_id. Because the function does not reject repeated identifiers, a caller can include multiple AMDGPU_CHUNK_ID_FENCE chunks in a single submission.

Each FENCE chunk triggers amdgpu_cs_p1_user_fence(), which acquires a reference on a buffer object and stores it in the single-slot field p->uf_bo. The second and later invocations overwrite that pointer with a freshly referenced BO without dropping the reference taken by prior invocations. On teardown, amdgpu_cs_parser_fini() releases only the final p->uf_bo, so every FENCE chunk except the last leaks one BO reference.

Root Cause

The root cause is missing input validation in the CS parser. The dispatcher trusts userspace to supply well-formed chunk sets and does not enforce single-instance semantics for chunk types backed by single-slot parser state. This is the same class of defect previously addressed for BO_HANDLES chunks by upstream commit fec5f8e8c6bc ("drm/amdgpu: disallow multiple BO_HANDLES chunks in one submit"), which enforced uniqueness for p->bo_list.

Attack Vector

A local user with access to the /dev/dri/renderD* device node — the default for graphics-capable sessions — can craft a submission containing repeated AMDGPU_CHUNK_ID_FENCE entries. Each malformed submission leaks one or more BO references that remain pinned after the process exits. Repeated submissions accumulate leaked references and can pressure GPU memory and kernel allocators, degrading system stability. The vulnerability requires no elevated privileges and no user interaction beyond invoking the DRM ioctl interface.

The fix rejects any submission containing more than one FENCE chunk, mirroring the earlier BO_HANDLES remediation. Refer to the upstream kernel commits for the exact reject logic.

Detection Methods for CVE-2026-80539

Indicators of Compromise

Sustained growth of amdgpu BO allocations reported by /sys/kernel/debug/dri/*/amdgpu_gem_info without corresponding process activity
Kernel log entries showing GPU memory pressure, TTM eviction failures, or allocation retries in dmesg
Processes that have exited but whose GPU buffer objects remain accounted for in driver statistics

Detection Strategies

Instrument the DRM ioctl path with tracing (for example, ftrace on amdgpu_cs_ioctl) to identify submissions carrying repeated AMDGPU_CHUNK_ID_FENCE entries
Baseline expected amdgpu BO counts per workload and alert on sustained upward drift not explained by legitimate workloads
Correlate abnormal GPU memory growth with local process telemetry to identify the origin binary

Monitoring Recommendations

Ship dmesg and DRM debugfs statistics into a centralized logging pipeline for long-term trend analysis
Monitor unprivileged process access to /dev/dri/renderD* nodes on servers where GPU compute workloads are not expected
Track kernel version and patch level across the fleet to confirm the fixed amdgpu driver is deployed

How to Mitigate CVE-2026-80539

Immediate Actions Required

Update the Linux kernel to a version containing the upstream fix that rejects duplicate FENCE chunks in amdgpu_cs_pass1()
Prioritize patching on multi-tenant hosts, shared GPU compute nodes, and workstations exposing the DRM render node to untrusted local users
Reboot systems after kernel update to load the corrected amdgpu module

Patch Information

The fix is a cherry-pick of upstream commit 665b1fc2a1845206408f9a2c6da67101789edb82 and has been backported across multiple stable branches. See the referenced stable commits: 070229262ede, 5f46322e0b84, 71aa45f7bfe4, 7e9954e72120, 931cd1d1baea, and e3ee74d6dbbe.

Workarounds

Restrict access to /dev/dri/renderD* nodes to trusted users and service accounts via group membership and udev rules where GPU access is not required
Unload the amdgpu module on systems that do not require AMD GPU acceleration until the patch can be applied
Enforce resource quotas and cgroup memory limits on user sessions to bound the impact of repeated malformed submissions

bash

# Verify amdgpu driver source contains the duplicate-FENCE reject
grep -n "AMDGPU_CHUNK_ID_FENCE" drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c

# Restrict render node access to a trusted group
sudo chgrp render /dev/dri/renderD128
sudo chmod 660 /dev/dri/renderD128