CVE-2026-68382

The patch replacing guc_submit_sw_fini()'s wait-for-GuC-fini with an assertion that GuC IDs are already gone isn't a cleanup optimization or an architectural retreat — it's a structural redesign of how queue lifetime is managed. The old code tried to synchronize after the fact; the new code prevents the race by having queue-held drm_device references block drmm cleanup from running while async GuC destruction is pending. This is a fundamentally stronger invariant, but it shifts the failure mode from a deadlock you can observe to an assertion failure that means your lifetime model has been violated. The 12 iterations this fix required aren't evidence of architectural rot — they're evidence of a team exploring the right abstraction boundary for async destruction in a subsystem (DRM) built around synchronous resource management. What emerged is an asymmetric design: SVM pagemap work uses per-device workqueue scope because devres constrains lifetime, while GuC work can use module scope because the reference model happens to prevent the race. This asymmetry is a maintenance trap. Future developers inheriting this code will see two destroy workqueues with different scopes and no obvious reason for the split. The real question isn't whether the assertion holds today — it's what the failure cascade looks like when it doesn't. A leaked drm_device reference during async GuC teardown doesn't just corrupt xe driver state; it corrupts the contract between DRM core and every subsystem holding a device reference. GPU reset handlers, hotplug paths, and debugfs interfaces are high-connectivity nodes where failures propagate fastest. The assertion doesn't need to be wrong to be dangerous; it just needs to be the only thing between a leaked async work item and a cascade that takes down the whole device. This vulnerability fits a documented genealogy: CVE-2019-2080 (amdgpu), CVE-2021-47177 (i915), and CVE-2023-52485 (xe) all share async destruction paths outliving their synchronization primitives, followed by workqueue-scope migrations, followed by assertions encoding new invariants. The failure mode is never the originally-modeled race — it's the interaction with something the modeler didn't scope. If you're maintaining DRM drivers, audit for this pattern: async destroy paths that depend on invariants outside their immediate control, where the fix landed as an assertion rather than a wait. The comment in guc_submit_sw_fini() should explicitly state why GuC IDs are guaranteed gone — the invariant lives in commit message archaeology, not in code contracts, and that's where the next failure will hide.

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