CVE-2026-68245

CVE-2026-68245 is a use-after-unlock in the amdgpu driver's PASID-to-VM lookup path. The function amdgpu_vm_get_vm_from_pasid() returns a pointer into data protected by an xarray lock, but the function signature encodes no lifetime contract. The caller amdgpu_vm_get_task_info_vm() released the lock via xa_unlock_irqrestore and then dereferenced the now-invalid vm->task_info pointer. This is a temporal safety violation—accessing data after the synchronization boundary that guarantees its validity. The upstream fix removes the function entirely and inlines the lookup logic, ensuring the lock remains held through the entire access pattern. This is correct for the immediate bug but reveals a deeper issue: kernel APIs that return pointers with implicit lifetime guarantees tied to caller-controlled locks create conditions where this class of bug is nearly inevitable. The function signature says nothing about lifetime constraints; the guarantee exists only in documentation and developer memory. Every new caller or refactor faces the same implicit contract and the same easy mistake. What makes this CVE instructive is the pattern it exposes. This is not an isolated coding error—it follows the same temporal safety violation lineage as CVE-2019-20811 in the kernel's interval tree code and CVE-2021-39698 in i915's vma lookup. Functions wrapping xarray lookups that return pointers into locked data create a cognitive contract that developers violate through reasonable assumptions about what function signatures mean. The inlining fix makes the lock timeline visible at one call site, but it does not prevent the next developer from extracting a helper for code reuse and recreating the same trap. For defenders: audit your codebase for functions that return pointers into xarray or similar data structures where the pointer's validity depends on locks held by the caller. If such functions exist, verify every caller holds the lock through the entire dereference. Treat pointer-returning lookup helpers in synchronization-sensitive paths as high-risk patterns warranting extra scrutiny. The long-term direction should be APIs that either return owned data directly (eliminating the pointer), return opaque handles with explicit lifetime semantics, or use scope-based patterns where the lock is tied to the reference via RAII-style patterns—but the kernel's existing patterns like rcu_head and _safe iterators already demonstrate this infrastructure exists and can be applied to this access pattern.

Reviewed through automated stages and approved by a human before publication.