Linux Kernel CVE-2026-63848

Exploitation requires local access to a host running a vulnerable Linux kernel with an AMD GPU using the amdgpu JPEG v2.0 IP block, plus permission to open the DRM render/GPU device node and issue command submissions (PR:L, per CVSS AV:L/AC:L/PR:L/UI:N). The specific trigger is submitting a CS request carrying a user fence to the JPEG v2.0 ring - a ring that does not support 64-bit user fence writes. Limiting factors: it is not remotely reachable (local only), it requires the amdgpu driver and specific JPEG v2.0-capable hardware/IP to be present and in use, and it needs an existing local account or GPU-enabled container with DRM device access; systems without AMD JPEG v2.0 hardware or without exposing GPU access to untrusted users are not realistically exploitable.

The CVSS 3.1 vector (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H = 7.8 High) indicates a local, low-complexity attack requiring low privileges and no user interaction, with high impact on all three properties. That impact profile is consistent with a GPU ring write-path defect that can corrupt kernel-managed memory. However, real-world exploitation signals are modest: EPSS is only 0.17% (7th percentile), there is no CISA KEV listing, and no public exploit is identified. The vendor tag labels this 'Information Disclosure,' which is narrower than the C:H/I:H/A:H triad the CVSS asserts - this is a mild conflict worth noting: the CVSS may reflect worst-case memory-corruption potential while the practical observed impact is information leakage. Prioritization should treat this as a routine local kernel hardening fix (patch in normal cycle) rather than an emergency, unless the host runs untrusted local users or containers with GPU passthrough, where local privilege boundaries matter more.

A logged-in local user (or a process inside a container granted GPU passthrough) with access to the amdgpu DRM device opens a render node and issues a command-submission ioctl targeting the JPEG v2.0 ring with a user fence set to a chosen address. Because the unpatched driver accepts the submission despite the ring's inability to perform 64-bit user fence writes, the resulting write corrupts kernel-managed memory or leaks data, potentially enabling information disclosure or escalation. No public proof-of-concept has been identified, and the low attack complexity means a crafted ioctl call is sufficient once local GPU access is available.