CVE-2026-68380 is a use-after-free in the amdxdna driver where the DRM scheduler captures current->mm at job submission time but dereferences job->mm from an asynchronous worker thread—potentially after the submitting task has exited or replaced its memory descriptor via execve(). The CVSS 7.8 undersells this: while the immediate impact is a crash via dangling pointer dereference, the vulnerability sits at a task-boundary race that creates more nuanced risk vectors.
The mm_struct is reference-counted precisely because its lifetime is tied to the active task. When the scheduler worker dereferences a freed mm_struct from a privileged context, controlled corruption of page table pointers, pgd, or context ID fields becomes possible—even without winning a full reallocation race. Partial corruption of a GPU scheduler worker touching shared hardware state could corrupt command streams for unrelated processes, creating cross-process contamination that CVSS doesn't model.
The deeper problem is structural. This exact pattern—raw pointer captured in task context, dereferenced in async worker—has appeared in i915 (circa 2019-2020), amdgpu (2021-2022), and now amdxdna, each receiving identical mmgrab/mmdrop patches. Each fix addresses the symptom in one driver while the DRM scheduler API continues to expose raw pointers without lifecycle markers. The API invites the mistake: a developer using current->mm in submission context and reading it in worker context is using the API as designed, not making an exotic error.
Defenders should: prioritize patching this in GPU-heavy workloads; treat any GPU hang or scheduler worker crash in production as potentially related until proven otherwise; and flag the DRM scheduler async model as architecturally risky for any driver passing task-bound pointers. The mmgrab/mmdrop fix is correct but insufficient—the real exposure is the API that keeps producing this flaw across drivers.