Linux Kernel EUVD-2026-93108

Requires local access to the msm DRM device node (/dev/dri/*) on a system running the Linux kernel's drm/msm driver - i.e., Qualcomm Adreno GPU hardware; this flaw is NOT present on x86 or non-Qualcomm configurations where the msm driver is not loaded. The attacker must (1) obtain a fence exported to userspace - a submit out-fence or a VM_BIND fence delivered via sync_file or drm_syncobj - and (2) cause the containing msm_ringbuffer or msm_gem_vm object to be freed, then (3) invoke SYNC_IOC_FILE_INFO against the stale fence to reach drm_sched_fence_get_timeline_name(). Limiting factors: exploitation is strictly local (AV:L), needs a valid local login/session with GPU access, depends on the specific msm driver being built/loaded, and is bounded by the RCU timing window the fix closes; no user interaction by a victim is required.

This is a genuine but comparatively low-urgency flaw. The CVSS 3.1 vector (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H, base 7.1 HIGH) correctly reflects that exploitation is LOCAL and requires a logged-in, low-privileged user - not remotely reachable. All real-world exploitation signals point low: EPSS is 0.21% (10th percentile), it is NOT listed in CISA KEV, and no public exploit code was identified in the provided data. These signals are mutually consistent - a local-only kernel info-leak in a hardware-specific driver is exactly the kind of issue that scores HIGH on technical impact (C:H kernel memory disclosure, A:H potential kernel crash) yet shows negligible mass-exploitation probability. The practical risk is as a secondary primitive: a local attacker or malicious app on affected Qualcomm/Adreno hardware could chain this slab use-after-free read into a broader privilege-escalation or KASLR-defeat effort, but it is not a standalone remote threat. Note the description emphasizes an information-disclosure READ (KASAN slab-use-after-free read), which aligns with C:H; the A:H rating is plausible because a UAF dereference of freed slab can also crash the kernel, though the writeup does not explicitly claim a weaponized DoS - treat A:H as inferred rather than demonstrated.

A local unprivileged user (or malicious Android app) with access to the msm DRM device opens the GPU, submits work to obtain an exported out-fence (or a VM_BIND fence) via sync_file/drm_syncobj, then causes the containing ringbuffer or GEM VM object to be freed. Issuing SYNC_IOC_FILE_INFO on the still-held fence then triggers drm_sched_fence_get_timeline_name() to dereference the freed scheduler, reading stale kernel slab memory. No public proof-of-concept was identified at time of analysis, but the path is described concretely and is reachable without privilege.