CVE-2026-63848

What it actually does

This is a local Linux kernel flaw in the AMDGPU DRM driver affecting JPEG v2.0 rings. The driver accepted command-stream submissions that included user fences even though JPEG rings do not support 64-bit user-fence writes. A local authenticated user with access to the GPU render device could submit an invalid or malicious command stream that abuses this validation gap, potentially causing GPU faults, kernel memory corruption, privilege escalation, information disclosure, or denial of service. The CVSS vector indicates local access, low attack complexity, required low privileges, no user interaction, and high confidentiality, integrity, and availability impact.

Why it matters to the business

Systems that expose AMDGPU devices to local users, desktop sessions, compute workloads, containers, or shared Linux hosts could be at risk of local privilege escalation or service disruption. The risk is highest where untrusted users or workloads can access /dev/dri render nodes. Current public exploitation signals are low: EPSS is very low, the vulnerability is not listed in CISA KEV, and no mature public exploit is reported, but kernel privilege-escalation flaws should still be patched promptly because successful exploitation can compromise the entire host.

How an attack unfolds

An attacker first needs local code execution or an account on a Linux system using the affected AMDGPU driver with JPEG v2.0 ring support exposed. The attacker opens the GPU DRM/render device and prepares an AMDGPU command-stream submission targeting the JPEG ring. They include a user-fence request that the hardware ring does not correctly support. On vulnerable kernels, the driver fails to reject this unsupported submission before it reaches lower-level GPU scheduling or execution paths. Depending on system state and exploit reliability, this may trigger GPU resets, kernel faults, memory corruption, disclosure of kernel or process memory, or a path to elevate privileges from a low-privileged local user to kernel-level control.

How to fix it

Upgrade to a Linux kernel or vendor kernel package that includes the AMDGPU fix which sets no_user_fence for the JPEG v2.0 ring and rejects command-stream submissions using user fences on that ring. No exact fixed package versions were provided in the input, so use the relevant Linux distribution, appliance, or kernel vendor advisory and confirm the fix is present in the installed kernel changelog. Where immediate patching is not possible, reduce exposure by restricting access to GPU DRM devices to trusted users only, removing unnecessary users from video/render groups, avoiding passthrough of /dev/dri devices into untrusted containers, disabling GPU acceleration for untrusted workloads, or temporarily disabling/blacklisting AMDGPU on systems where the GPU is not required. Reboot into the patched kernel after installation; merely installing the package is not sufficient if the vulnerable kernel remains running.

How to confirm the fix worked

Confirm that the running kernel, not just the installed package, is updated to a version containing the AMDGPU JPEG v2.0 user-fence rejection fix. Validate with uname -a, distribution package metadata, and vendor changelogs referencing the AMDGPU JPEG ring no_user_fence change or upstream commit 96179da0c6b059eb31706a0abe8dd6381c533143. Check whether AMDGPU devices are present by reviewing loaded modules and /dev/dri device exposure. Confirm that untrusted users and containers do not have access to GPU render nodes unless required. For functional validation, use vendor-supported GPU test suites or workload tests after patching and monitor for absence of amdgpu JPEG ring faults, GPU resets, or kernel oops events under normal operation.

Typical attack path

1. Gain local access to a Linux system through an existing user account, compromised service, desktop session, or container with GPU device access.
2. Confirm that AMDGPU DRM devices are present and accessible, commonly through /dev/dri/card* or /dev/dri/renderD*.
3. Open the AMDGPU DRM/render device and construct a command-stream submission for a JPEG v2.0 ring.
4. Attach an unsupported 64-bit user-fence request to the JPEG command stream.
5. Submit the crafted command stream to the vulnerable kernel driver.
6. Trigger driver or GPU behavior that may result in a crash, memory corruption, information disclosure, or privilege escalation.
7. If privilege escalation is achieved, execute code with elevated privileges or disable security controls on the host.

How to detect it

There are no reliable public indicators that uniquely prove exploitation of this issue. Detection should focus on suspicious local access to AMDGPU DRM devices and correlated kernel instability. Review authentication, process accounting, auditd, EDR, and container runtime logs for unexpected users or workloads opening /dev/dri/card* or /dev/dri/renderD* devices. Review dmesg, journald, kern.log, syslog, and crash dumps for amdgpu GPU resets, JPEG ring faults, command submission failures, kernel oops, page faults, or crashes occurring shortly after activity by an untrusted local user or container. If auditd is available, add monitoring for opens of /dev/dri/renderD* and /dev/dri/card* by nonstandard processes. In forensic investigations, correlate GPU device access, process start times, privilege changes, kernel crash timestamps, and any new privileged processes or persistence established after a GPU-related fault.

What your security team should do

• Prioritize patching shared Linux workstations, multi-user compute systems, VDI hosts, GPU-enabled container platforms, and any environment where untrusted local users can access AMDGPU devices.
• Inventory systems with AMD GPUs and exposed /dev/dri devices, especially those granting access through render or video group membership.
• Deploy vendor-supported kernel updates and reboot systems into the fixed kernel; verify the running kernel version after reboot.
• Restrict GPU device access for untrusted users and containers until patching is complete.
• Review container runtime and orchestration configurations for unnecessary /dev/dri passthrough.
• Monitor kernel and system logs for amdgpu faults, GPU resets, kernel oops messages, and suspicious local GPU device access attempts.
• Because this is not currently KEV-listed and EPSS is low, treat it as an important local privilege-escalation patching item rather than an internet-facing emergency, unless AMDGPU access is exposed to untrusted workloads.