Look up another CVE · open CVE-2026-63845 in the interactive tracker
CVE-2026-63845
drm/amdgpu/jpeg: set no_user_fence for JPEG v4.0 ring
Published 2026-07-19 (3 months ago) by the Linux kernel CNA. Subsystem drivers/gpu. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-63845 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | vulnerable | 6.1.190-1 | No fix published anywhere yet, neither in Debian nor upstream for the series bookworm tracks. Watch the Debian tracker page for this CVE. Advisories for bookworm have historically landed a median of 23 days after publication. |
| Debian 13trixie | fixed | 6.12.94-1 | Update the kernel and reboot. Fixed in 6.12.94-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.0.10-1 | Update the kernel and reboot. Fixed in 7.0.10-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.0.10-1 | Update the kernel and reboot. Fixed in 7.0.10-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
JPEG rings do not support 64-bit user fence writes, reject CS submissions with user fences. (cherry picked from commit 8d0cac9478a3f046279c657d6a2545de49ae675a)
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
drivers/gpu/drm/amd/amdgpu/jpeg_v4_0.c
- What this is
- RADEON and AMDGPU DRM DRIVERSMAINTAINERS section matched on drivers/gpu/drm/amd/ · amd-gfx@lists.freedesktop.org · Supported
- Kernel module
- amdgpu
Check it on the machine
grep -w CONFIG_DRM_AMDGPU /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
lsmod | grep -w amdgpuPrints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.
Show whether Debian builds this, per release
Debian builds this, but not on every flavour. At least one release below builds the code on some of its kernel flavours and not on others, so the answer depends on the architecture and flavour installed.
- bookwormMnot built on amd64/cloud-amd64, arm64/cloud-arm64, armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp
- trixieMnot built on amd64/cloud-amd64, arm64/cloud-arm64, armel/rpi, armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp, s390x/s390x
- forky, sidMnot built on amd64/cloud-amd64, arm64/cloud-arm64, s390x/s390x
- M
- a module where it is built at all; some flavours do not build it
- Build switch
- CONFIG_DRM_AMDGPU
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-07-19 (3 months ago)source
- CVSS
- 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.18%, higher than 6.6% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- drivers/gpu
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 5.19 | 6.6.141 | d4e0172a1b61 |
| 5.19 | 6.12.91 | a676f16ea9a7 |
| 5.19 | 6.18.33 | 6876d05b8991 |
| 5.19 | 7.0.10 | af4b458daa59 |
| 5.19 | 7.1 | e7e90b5839ae |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- Exploitation requires a local DRM render-node client to issue DRM_IOCTL_AMDGPU_CS; the vulnerable path runs when amdgpu_cs_ioctl accepts a command submission with an AMDGPU_CHUNK_ID_FENCE user fence targeting the JPEG v4.0 decode ring (AMDGPU_HW_IP_VCN_JPEG).
- AC:LAttack complexity, low
- An attacker with render-node access can deterministically submit a JPEG-ring CS with a user-fence chunk; no race or victim-dependent timing is required beyond having an affected VCN 4.0.0/4.0.2/4.0.4 AMD GPU (RDNA3-class hardware).
- PR:LPrivileges required, low
- Only a local unprivileged user able to open /dev/dri/renderD* and submit CS jobs is needed; amdgpu_cs_ioctl is exposed to render clients (DRM_RENDER_ALLOW) without requiring root or DRM master privileges.
- UI:NUser interaction, none
- No victim interaction is required; the attacker directly crafts and submits the malicious ioctl from their own GPU client process.
- S:UScope, unchanged
- The corrupted GPU fence write is performed through the submitting context's GPU VM and does not cross a VM/host or IOMMU security boundary; impact remains within the attacker's kernel/GPU security scope (local privilege escalation scenario).
- C:HConfidentiality impact, high
- amdgpu_ib.c always emits user fences with AMDGPU_FENCE_FLAG_64BIT, but jpeg_v2_0_dec_ring_emit_fence (used by JPEG v4.0) only supports 32-bit writes and WARN_ONs the 64-bit flag, causing the hardware to perform an unsupported GPU memory write that can corrupt memory and be leveraged for information disclosure.
- I:HIntegrity impact, high
- The unsupported fence path issues a GPU MEM_WR to an attacker-chosen GPU virtual address, providing a memory-corruption primitive that can be developed into arbitrary writes and potential kernel code execution.
- A:HAvailability impact, high
- Submitting an unsupported 64-bit user fence to the JPEG ring can hang or reset the GPU and destabilize the amdgpu driver, causing denial of service to GPU workloads and potential system-wide availability impact.