CVE-2026-68384

This CVE exposes a fundamental modeling error in how xe_migrate handles CCS (Context Save/Restore) buffer binding during BO moves. There are two race windows, and they're not independent bugs—they're mirror images of the same underlying failure. The attach race occurs when the CCS BB metadata is bound too late: after the copy fence is acquired but before the job is submitted. This creates a window where the migration runs without the CCS context it needs, leading to silent data corruption. The detach race is worse. It occurs when CCS BBs are unbound too early—immediately after fence acquisition but while the actual blit is still in-flight. The VF migration handler then attempts to save/restore state using metadata that's already been torn down. This is use-after-free-adjacent state confusion, not just missing metadata. The root cause: the original code modeled attach/detach as discrete atomic operations that could be freely ordered around fence acquire/submit/wait calls. But VF migration exposes that these are actually state registration operations that must be transactionally coupled with the work they protect. The code was written against a model where these operations completed synchronously; VF migration introduced a third party that interrogates state mid-operation. There's a compounding error: the per-context attach loop never broke on error, silently discarding failures. The fix had to bypass the normal detach API entirely during error unwinding because that API requires both contexts attached before it will clean up either one—a circular dependency only visible when unwinding a partial attach. The correct fix reorders operations: attach must complete before fence acquisition for the copy, and detach cannot proceed until the fence signals. Crucially, xe_migrate_ccs_rw_copy()'s signature had to change to take the destination resource explicitly—the calling context's state wasn't what the function needed at the moment it was called. This indicates the original abstraction boundaries were wrong: different parts of the call chain were operating on different temporal slices of the same object state. The EPSS score of 0.00134 reflects low probability in the wild since VF migration is required to trigger this—but the vulnerability class matters beyond current exploitability. This reveals how xe_migrate's API forces callers into subtle temporal reasoning that the type system cannot enforce. The real question is whether the driver architecture should have explicit 'migration in progress' states that the VF migration handler can interrogate, rather than relying on implicit ordering of fence acquire/submit/wait calls.

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