CVE-2026-63847

What it actually does

This is a local Linux kernel vulnerability in the AMDGPU DRM driver affecting JPEG v2.5 command submission handling. The vulnerable code allowed userspace command submissions to request user-fence behavior on a JPEG ring that does not support 64-bit user-fence writes. Because the driver did not reject that unsupported input, a local authenticated user with access to the GPU device node could potentially trigger incorrect kernel/GPU memory handling. Given the CVSS impact profile, successful exploitation may allow local privilege escalation, kernel memory corruption, information disclosure, or denial of service depending on kernel configuration, GPU model, and surrounding mitigations.

Why it matters to the business

Systems using affected Linux kernels with AMD GPUs may be exposed to a local privilege-escalation or crash risk. The attacker must already have local code execution, but exploitation could allow compromise of workloads running on shared Linux desktops, GPU workstations, render nodes, CI workers, or multi-user compute systems. This is not listed in CISA KEV, has no known ransomware association, and has a very low EPSS score, so urgency is lower than for remotely exploitable or actively exploited flaws; however, organizations that rely on shared GPU-enabled Linux systems should still prioritize kernel updates because kernel privilege-escalation bugs can turn limited account access into full system compromise.

How an attack unfolds

An attacker first obtains the ability to run code as an unprivileged local user on a Linux system with an affected AMDGPU driver and compatible AMD GPU hardware. They then open the relevant DRM render or card device, such as a /dev/dri node, and submit crafted GPU command streams targeting the JPEG v2.5 ring. The malicious submission requests user-fence behavior that the JPEG ring cannot safely support. On vulnerable kernels, the driver accepts the invalid command submission instead of rejecting it. This may cause unsafe fence write behavior or memory corruption in kernel/GPU-managed memory, which the attacker may attempt to shape into privilege escalation, sensitive memory exposure, or a system crash. In fixed kernels, command submissions using user fences on this JPEG ring are rejected.

How to fix it

Upgrade to a Linux kernel build that includes the upstream AMDGPU fix that rejects JPEG v2.5 command submissions using user fences. Because no distribution-specific fixed versions were provided, use the fixed kernel versions published by the relevant Linux distribution or vendor and ensure the AMDGPU DRM driver is updated as part of the kernel package. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting access to /dev/dri/card* and /dev/dri/renderD* device nodes, disabling untrusted GPU workloads, isolating GPU-enabled workloads onto dedicated hosts, and applying standard kernel hardening controls. Reboot after kernel update so the corrected driver is loaded.

How to confirm the fix worked

Confirm the running kernel is a vendor-fixed build that contains the AMDGPU change rejecting user-fence command submissions on the JPEG v2.5 ring. Validate with the package manager or vendor advisory rather than only checking installed-but-not-running packages. After reboot, verify the running kernel version with uname -a and confirm the active amdgpu module comes from the updated kernel. On systems with AMD GPUs, review dmesg or journal logs for AMDGPU initialization and ensure there are no recurring GPU ring faults, kernel warnings, or oops messages after normal GPU workloads. If a proof-of-concept or vendor regression test is available, the expected fixed behavior is rejection of JPEG-ring command submissions that use user fences, not a crash or successful submission.

Typical attack path

1. Gain local code execution on a Linux host with an affected kernel and AMDGPU hardware.
2. Confirm access to AMD DRM device nodes such as /dev/dri/renderD* or /dev/dri/card*.
3. Identify that the AMDGPU JPEG v2.5 ring is present and usable from userspace.
4. Submit crafted AMDGPU command streams that request unsupported user-fence behavior on the JPEG ring.
5. Trigger incorrect driver behavior, potentially leading to kernel memory corruption, information disclosure, or denial of service.
6. If exploitation is reliable, use the kernel-level impact to elevate privileges or destabilize the host.

How to detect it

There are no public, reliable, exploitation-specific indicators for this vulnerability based on the available information. Detection should focus on evidence of attempted local GPU driver abuse and post-exploitation activity. Review kernel logs from journald, dmesg, syslog, and crash dump systems for AMDGPU faults, JPEG ring errors, command-submission failures, GPU resets, kernel warnings, oops messages, or panics near activity by local users or containers. Audit access to /dev/dri/card* and /dev/dri/renderD* where auditd, eBPF, or endpoint telemetry is available, especially unexpected GPU device access by shells, compilers, temporary binaries, scripting runtimes, or containerized workloads. Correlate GPU-driver crashes with privilege changes, new setuid files, kernel module loading attempts, suspicious process execution from /tmp or /dev/shm, and abnormal sudo or account activity. For forensic review, preserve kernel logs, crash dumps, process execution telemetry, audit logs for DRM device access, and container runtime logs from the time window surrounding any amdgpu crash or reset.

• /dev/dri/card
• /dev/dri/renderD
• amdgpu
• JPEG ring
• user fence
• ring jpeg
• GPU reset
• amdgpu_cs_ioctl
• kernel BUG
• kernel panic
• Oops:
• general protection fault
• WARNING: CPU

What your security team should do

• Inventory Linux systems with AMDGPU hardware, especially multi-user GPU workstations, render nodes, shared compute hosts, and developer systems.
• Prioritize kernel updates for shared or untrusted-user systems first, then single-user endpoints and lower-risk servers.
• Confirm systems are rebooted into the fixed kernel; installed kernel packages alone are not sufficient.
• Restrict unnecessary access to /dev/dri device nodes on systems where untrusted users or containers run workloads.
• Review container and workload isolation for GPU passthrough or shared GPU access, because local kernel bugs can cross workload boundaries if device access is granted.
• Monitor for kernel oops, GPU ring reset, amdgpu command-submission errors, and suspicious local activity around DRM device nodes.
• Because this is not currently known to be exploited and has low EPSS, track vendor advisories and threat intelligence for changes in exploit maturity rather than treating it as an internet-facing emergency.