CVE-2026-63845

What it actually does

This is a local Linux kernel vulnerability in the AMDGPU DRM driver affecting JPEG v4.0 command submission handling. The vulnerable code allowed command submissions using user fences on JPEG rings even though those rings do not support 64-bit user-fence writes. Because the kernel failed to reject an unsupported fence configuration, a local authenticated user with access to the AMDGPU device could potentially trigger unintended GPU memory writes or corrupt kernel/GPU driver state. Given the CVSS impact ratings, successful exploitation could lead to local privilege escalation, information disclosure, data corruption, or denial of service at the kernel level.

Why it matters to the business

Systems using affected Linux kernels with AMD GPUs may be exposed to local compromise by a non-administrative user or by malware that has already gained basic code execution. The main operational risk is that an attacker could escalate privileges to root or destabilize systems, which is especially relevant for shared Linux workstations, GPU-enabled servers, VDI hosts, rendering farms, ML/AI infrastructure, and multi-user compute environments. This issue is not known to be exploited in the wild, is not in CISA KEV, and currently has very low EPSS, so urgency is highest where untrusted local users or workloads can access AMD GPU devices.

How an attack unfolds

An attacker first needs local access to a Linux system where the vulnerable AMDGPU kernel driver is loaded and the attacker can open the relevant DRM render or card device. The attacker then submits a crafted AMDGPU command stream targeting a JPEG v4.0 ring while requesting a user fence configuration that the hardware ring does not properly support. On vulnerable kernels, the driver fails to reject this unsupported submission. The malformed submission may cause unintended fence handling, memory corruption, or driver state corruption. Depending on kernel configuration, GPU model, memory layout, and exploit reliability, the attacker may use the resulting corruption to crash the system, read sensitive memory, alter privileged state, or escalate privileges locally.

How to fix it

Apply a Linux kernel update that includes the AMDGPU fix which rejects command submissions with user fences on JPEG v4.0 rings by setting the appropriate no_user_fence behavior. Because no distribution-specific fixed package versions were provided, use the latest security kernel available from the operating system vendor and confirm that it contains the upstream AMDGPU JPEG-ring user-fence fix. Reboot after kernel installation so the patched kernel and AMDGPU module are active. As temporary mitigations, restrict local access to GPU DRM device nodes to trusted users only, remove untrusted users from groups that grant GPU access, avoid running untrusted workloads on AMD GPU-enabled systems, disable or blacklist the amdgpu driver where GPU functionality is not required, or use kernel lockdown/container isolation controls to reduce local attack surface.

How to confirm the fix worked

Confirm exposure by checking whether the system uses AMDGPU and a kernel build older than the vendor-fixed release. Validate remediation by booting into the updated kernel, confirming the active kernel version with standard OS tools, and verifying that the loaded amdgpu module comes from the patched kernel package. Where source or changelog access is available, confirm the AMDGPU JPEG-ring fix is present, specifically the change that rejects command submissions with user fences for JPEG v4.0 rings. Also verify that untrusted users cannot access AMDGPU DRM render or card device nodes unless required. For high-assurance validation, attempt a safe negative test in a non-production lab: submit a command stream using a user fence against the JPEG ring and confirm the patched driver rejects it rather than accepting or crashing.

Typical attack path

1. Obtain local code execution as an unprivileged user or inside a workload with access to AMDGPU DRM devices.
2. Verify that the AMDGPU kernel driver is loaded and that an AMD GPU exposing JPEG v4.0 rings is present.
3. Open an accessible DRM device such as a render node or card device associated with AMDGPU.
4. Submit a crafted GPU command stream that targets the JPEG ring and includes an unsupported 64-bit user-fence write request.
5. Trigger incorrect kernel driver handling because the vulnerable driver does not reject the unsupported user-fence submission.
6. Leverage resulting GPU/kernel memory corruption or driver instability for denial of service, information disclosure, or local privilege escalation.

How to detect it

There are no public, reliable exploit-specific indicators for this vulnerability, and successful local kernel exploitation may leave few direct artifacts. Review kernel logs, system journals, audit logs, and EDR telemetry for suspicious access to AMDGPU DRM devices followed by crashes, GPU resets, kernel warnings, privilege escalation, or abnormal process behavior. Useful log sources include dmesg, journalctl kernel logs, /var/log/kern.log, /var/log/messages, auditd records for /dev/dri access, EDR process/file telemetry, and crash dump systems such as kdump or apport. Focus on events where untrusted user processes access /dev/dri/renderD* or /dev/dri/card* and are temporally close to amdgpu faults, GPU ring timeouts, kernel oops messages, segmentation faults in GPU tooling, unexpected root shells, setuid binary modifications, or service crashes. If forensic memory or crash dumps are available, inspect for amdgpu command submission failures, JPEG ring activity, and user-fence-related faults. Absence of these artifacts does not prove non-exploitation.

• /dev/dri/renderD
• /dev/dri/card
• amdgpu
• amdgpu_cs_ioctl
• JPEG v4.0 ring
• user fence
• no_user_fence
• ring jpeg
• GPU fault detected
• amdgpu: ring
• ring timeout
• amdgpu: GPU reset
• drm:amdgpu_cs_ioctl
• kernel BUG
• Oops:
• general protection fault

What your security team should do

• Prioritize patching AMD GPU-enabled Linux systems that support multiple local users, run untrusted code, host containers, provide VDI/desktop access, or operate shared GPU compute workloads.
• Inventory Linux endpoints and servers with the amdgpu kernel module loaded and identify which are running vendor kernels that do not yet include the JPEG v4.0 user-fence rejection fix.
• Restrict permissions on DRM device nodes so only trusted users and workloads can access AMD GPU devices until patches are deployed.
• Review whether containers, batch jobs, CI runners, notebooks, or remote desktop sessions are unnecessarily granted access to /dev/dri devices.
• Monitor kernel, audit, and EDR telemetry for suspicious local GPU device access followed by privilege changes, kernel faults, or system instability.
• Because this is not currently KEV-listed and has low EPSS, treat it as a defense-in-depth local privilege escalation issue, but accelerate remediation on shared or high-value GPU systems.