CVE-2026-63846

What it actually does

This is a local Linux kernel vulnerability in the AMDGPU DRM driver affecting JPEG v3.0 command submission handling. JPEG rings do not support 64-bit user fence writes, but insufficient validation allowed command submissions that requested user fences. A local authenticated user with access to the GPU device interface could submit crafted GPU command streams that exercise unsupported fence behavior, potentially causing kernel memory corruption, GPU/driver instability, privilege escalation, or denial of service. The CVSS vector indicates local access, low attack complexity, low privileges required, no user interaction, and high confidentiality, integrity, and availability impact.

Why it matters to the business

Systems using affected Linux kernels with AMDGPU hardware may be exposed to local privilege escalation or system instability from an unprivileged user or compromised application account. In multi-user workstations, GPU-enabled servers, VDI, build hosts, rendering nodes, or compute environments, this could allow a low-privileged foothold to become full host compromise or cause outages through kernel crashes and GPU resets. The issue is not currently listed in CISA KEV, has no known exploit maturity in the supplied data, and has low EPSS, so urgency is highest for shared systems, systems running untrusted workloads, and environments where local user isolation is important.

How an attack unfolds

An attacker first obtains local code execution as a low-privileged user on a Linux system using the affected AMDGPU driver and hardware path. The attacker opens the GPU DRM device, such as a render node, and submits a crafted AMDGPU command stream targeting the JPEG v3.0 ring while requesting a user fence operation that the ring does not support. Because the vulnerable kernel path does not reject these submissions, the driver may attempt unsupported 64-bit user fence handling. Depending on memory layout, kernel configuration, and driver behavior, this can lead to memory corruption or control-flow effects that may be developed into privilege escalation, or it may produce GPU hangs, kernel warnings, oopses, resets, or host denial of service. The fix marks the JPEG v3.0 ring as not supporting user fences so such command submissions are rejected before unsafe handling occurs.

How to fix it

Upgrade to a Linux kernel build that includes the AMDGPU fix which sets no_user_fence for the JPEG v3.0 ring and rejects command submissions with user fences on that ring. If using a distribution kernel, apply the vendor-provided security update rather than only relying on upstream version numbers, because fixes are commonly backported. If immediate patching is not possible, reduce exposure by restricting local shell access, limiting access to /dev/dri/card* and /dev/dri/renderD* device nodes to trusted users and workloads, disabling or removing AMDGPU access where not required, isolating untrusted GPU workloads in separate hosts, and considering temporary kernel module or hardware feature disablement where operationally acceptable. No exact fixed package versions were provided in the input, so use the relevant Linux distribution advisory or upstream stable kernel release notes to identify the corrected package for each platform.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel package includes the AMDGPU JPEG ring no_user_fence fix, either through the distribution security advisory, kernel changelog, or source/backport inspection. Validate that the running kernel is the patched kernel after reboot, not only that the package is installed. On source-based or custom kernels, inspect the AMDGPU JPEG ring initialization logic and confirm JPEG v3.0 rings are configured to reject user fence submissions. Confirm exposure reduction by checking whether AMDGPU is loaded and whether local users or containers can access /dev/dri device nodes. Functional validation should include normal GPU/JPEG workloads and confirmation that malformed command submissions with user fences to the JPEG ring are rejected rather than causing GPU hangs or kernel faults.

Typical attack path

1. Gain local low-privileged access to a Linux host with affected AMDGPU kernel driver support.
2. Identify accessible DRM render/card device nodes and confirm AMDGPU/JPEG ring availability.
3. Open the DRM device from user space and construct AMDGPU command submission requests.
4. Target the JPEG v3.0 ring and include a user fence request that should not be valid for that ring.
5. Trigger the vulnerable validation path repeatedly or with controlled parameters to cause corruption, driver failure, GPU reset, kernel crash, or potential privilege escalation.
6. If pursuing privilege escalation, use the resulting memory corruption primitive to modify kernel state or escape local privilege boundaries.

How to detect it

There are no stable public exploitation indicators provided for this vulnerability, and local kernel exploitation may leave few application-level traces. To assess possible prior exploitation, review kernel logs, persistent journal data, audit logs, and EDR telemetry for abnormal AMDGPU command submission activity, GPU ring hangs, GPU resets, kernel oops/panic events, and unexpected local processes opening DRM device nodes shortly before crashes or privilege changes. Useful sources include dmesg output, /var/log/kern.log, /var/log/messages, systemd journal entries for the kernel, auditd records for access to /dev/dri/card* and /dev/dri/renderD*, EDR process/file telemetry, crash dumps, kdump/vmcore artifacts, and authentication logs showing suspicious local account activity before or after GPU driver faults. Correlate AMDGPU JPEG/ring errors with processes that had DRM device handles open at the time. Because the issue can be used for local privilege escalation, also look for post-exploitation behavior such as unexpected root shells, new setuid binaries, suspicious kernel module loading, credential access, or tampering shortly after GPU instability events.

• amdgpu
• JPEG v3.0 ring
• user fence
• no_user_fence
• ring jpeg
• amdgpu: GPU reset
• amdgpu: ring
• ring timeout
• GPU fault detected
• amdgpu_cs_ioctl
• /dev/dri/card0
• /dev/dri/renderD128
• kernel BUG
• kernel NULL pointer dereference
• general protection fault
• Oops
• BUG: unable to handle kernel
• drm/amdgpu/jpeg

What your security team should do

• Prioritize patching shared Linux systems, GPU-enabled compute hosts, developer workstations, VDI hosts, and any environment where untrusted or semi-trusted users can run local code.
• Inventory Linux hosts with AMDGPU hardware and loaded amdgpu kernel modules; focus remediation on systems exposing /dev/dri render or card device nodes to non-administrative users.
• Apply vendor kernel updates and reboot systems to ensure the patched kernel is active.
• Where patching is delayed, restrict /dev/dri permissions and group membership to trusted users only, and avoid running untrusted workloads with GPU device passthrough.
• Review container, virtualization, and batch-compute configurations for GPU device exposure, especially direct mapping of /dev/dri into containers.
• Monitor kernel logs for AMDGPU command submission failures, GPU resets, ring hangs, kernel oopses, and suspicious local processes interacting with DRM devices.
• Treat confirmed exploitation indicators as potential full host compromise because the vulnerability has high confidentiality, integrity, and availability impact.
• Track distribution advisories for exact fixed package versions because the input does not provide per-package fixed versions and kernel fixes may be backported.