What is the CVSS score of EUVD-2026-45524?

EUVD-2026-45524 has a contested CVSS base score of 7.8 from a third party (e.g. CISA-ADP), while the vendor rates it High. vuln.today uses the vendor rating as authoritative.

Which versions of Linux Kernel are affected by EUVD-2026-45524?

The Linux kernel's AMD GPU JPEG v5.3.0 driver contains a memory corruption flaw that could allow local users with GPU device access to compromise data confidentiality or disrupt system availability.. A patch is available.

How to fix or mitigate EUVD-2026-45524?

Within 24 hours, identify all systems running AMD GPUs with the amdgpu JPEG driver and document local user populations with GPU device access; coordinate with platform teams on patch availability for your kernel versions. Within 7 days, apply the available upstream stable kernel patch to test and staging systems, validate GPU functionality and workload stability (particularly JPEG codec operations), and plan a phased production rollout by severity tier. Within 30 days, complete production kernel patching and implement file system permission restrictions (chmod 0660 or stricter) and mandatory access controls (SELinux/AppArmor) on GPU/DRM devices to further limit unprivileged GPU access.

Linux Kernel EUVD-2026-45524

| CVE-2026-63840 HIGH

2026-07-19 Linux

GHSA-9f56-6f5c-c8vx

Information Disclosure Linux

High

Disputed · 7.8 Vendor: Linux

Severity by source

Sources disagree (Low–High)

Vendor (Linux) PRIMARY

7.8 HIGH

AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

vuln.today AI

7.8 HIGH

Local DRM device access with an unprivileged account (AV:L, PR:L) triggers an unsupported kernel write path with no user interaction, yielding high CIA impact.

3.1 AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

4.0 AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

Red Hat

5.5 LOW

qualitative

vuln.today treats the vendor’s rating as authoritative. A higher third-party CVSS (e.g. CISA-ADP) is shown for transparency but does not drive the headline severity.

CVSS VectorVendor: Linux

Attack Vector

Local

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

High

Lifecycle Timeline

Analysis Generated

Jul 20, 2026 - 15:48 vuln.today

CVSS changed

Jul 20, 2026 - 15:22 NVD

7.8 (HIGH)

Patch available

Jul 19, 2026 - 16:19 EUVD

CVE Published

Jul 19, 2026 - 14:04 cve.org

HIGH 7.8

CVE Published

Jul 19, 2026 - 14:04 cve.org

UNKNOWN (no severity yet)

DescriptionCVE.org

In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu/jpeg: set no_user_fence for JPEG v5.3.0 ring

JPEG rings do not support 64-bit user fence writes, reject CS submissions with user fences.

(cherry picked from commit 86ac011ae234c03fb872f4945913391ea1d8862e)

AnalysisAI

Local privilege-adjacent memory corruption in the Linux kernel's AMD GPU (amdgpu) JPEG v5.3.0 driver arises because the ring did not set the no_user_fence flag, allowing command-stream (CS) submissions carrying 64-bit user fence writes that the JPEG ring cannot support. A local user with GPU/DRM device access can submit crafted CS with user fences, leading to undefined ring behavior and high impact on confidentiality, integrity, and availability. No public exploit identified at time of analysis and EPSS exploitation probability is low (0.16%), but a vendor (upstream stable) patch is available.

Technical ContextAI

The affected component is the AMD GPU driver (amdgpu) in the Linux DRM subsystem, specifically the JPEG decode engine at IP version 5.3.0. Userspace submits work to the GPU via command streams (CS) through the DRM ioctl interface; each ring can optionally support 'user fences' - 64-bit fence values written back to a userspace-visible address to signal completion. The JPEG v5.3.0 ring hardware does not support 64-bit user fence writes, yet the driver failed to advertise this by setting the ring's no_user_fence attribute, so the CS validation path did not reject fence-bearing submissions. The fix (cherry-picked from commit 86ac011ae234) sets no_user_fence so such submissions are rejected. No CWE was assigned by NVD; functionally this is a missing-validation / improper-restriction class defect that can drive out-of-bounds or unexpected memory writes via an unsupported hardware path.

RemediationAI

Apply the upstream stable kernel fix: update to a patched Linux kernel that includes commit 3b0ea2021351b6b813b34fac940957f1f4fad85b / 46ad73aec27d020f103b4262e4da2d2c22f54799 (backported from mainline 86ac011ae234), available in the stable series noted by EUVD (approximately 7.0.10 and 7.1). Distribution users should install the corresponding vendor kernel update once released; the patch itself is the definitive remediation since it makes the JPEG ring reject unsupported user-fence submissions. If immediate patching is not possible, reduce exposure by restricting access to the DRM render/card device nodes (e.g., tightening /dev/dri/renderD* and /dev/dri/card* permissions to trusted users/groups) so untrusted local accounts and unprivileged containers cannot submit GPU command streams - the trade-off is that this can break legitimate unprivileged GPU workloads (containers, sandboxed apps, multi-user rendering). Advisory and patch references: https://git.kernel.org/stable/c/46ad73aec27d020f103b4262e4da2d2c22f54799 and https://git.kernel.org/stable/c/3b0ea2021351b6b813b34fac940957f1f4fad85b.