CVE-2026-63843

What it actually does

The kernel accepted command stream submissions containing user fences for JPEG v4.0.5 rings that lack 64-bit user fence write support, bypassing intended input validation and allowing invalid fence operations to reach the hardware ring.

Why it matters to the business

Local attackers can leverage the flaw for privilege escalation on systems using affected AMD GPUs, potentially compromising the entire host and any workloads running on it.

How an attack unfolds

An attacker with local access crafts a command submission that includes a user fence and submits it to an AMD JPEG ring; the missing validation permits the submission to proceed, resulting in undefined behavior that can be turned into kernel memory corruption or code execution.

How to fix it

Update the Linux kernel to a version containing commit f05d0a4f21fc720116d6e238f23308b199891058 or later that enforces no_user_fence on JPEG v4.0.5 rings.

How to confirm the fix worked

Confirm the presence of the no_user_fence flag setting and rejection logic for user-fence CS submissions in drm/amdgpu/jpeg source after applying the fix; test by attempting a user-fence submission and verifying it is rejected.

Typical attack path

1. Obtain local shell on target Linux system with AMD GPU
2. Load or trigger a userspace graphics client that issues CS with user fences to JPEG ring
3. Trigger invalid fence handling to corrupt kernel structures
4. Escalate to root via resulting memory corruption

How to detect it

Review kernel logs for amdgpu JPEG ring submissions that previously succeeded with user fences; look for unexpected fence-related errors or crashes in drm/amdgpu after the vulnerable period.

What your security team should do

• Prioritize kernel updates on all systems exposing AMD GPUs to untrusted local users
• Monitor upstream stable and distribution kernels for backports of the referenced commit
• Restrict local access for untrusted users until patches are applied