CVE-2026-68384

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe/vf: Fix VF CCS attach/detach race with in-flight BO moves<br /> <br /> xe_bo_move() attaches VF CCS read/write batch buffers (BBs) to a BO<br /> after it transitions NULL/SYSTEM -&gt; TT, and detaches them after it<br /> transitions TT -&gt; SYSTEM. Both operations were done synchronously on<br /> the CPU immediately after building the move&amp;#39;s copy/clear fence,<br /> without waiting for that fence to signal. This creates two races with<br /> VF migration:<br /> <br /> - Attach happens too late relative to the copy job it is meant to<br /> protect. If the copy job is submitted before the CCS BBs are<br /> attached, a VF migration event that pauses execution mid-copy can<br /> observe partially copied CCS metadata without the attach state<br /> needed to correctly save/restore it.<br /> <br /> - Detach happens too early relative to the copy job that moves data<br /> out of TT. The CCS BBs are torn down right after the copy fence is<br /> obtained, while the actual blit may still be in flight. A VF<br /> migration event that pauses execution mid-copy can then race the<br /> save/restore path against the still-running blit, and the CCS BBs<br /> it would need to make sense of the paused state have already been<br /> removed.<br /> <br /> Fix both races:<br /> <br /> - Move the attach call to before the copy/clear job is submitted, so<br /> the CCS BBs are already registered by the time the copy runs. On<br /> attach failure, unwind and bail out of the move. xe_migrate_ccs_rw_copy()<br /> now takes the destination resource explicitly, since bo-&gt;ttm.resource<br /> is not updated to the new resource until after the move commits.<br /> <br /> - Detach only after explicitly waiting for the copy fence to signal,<br /> instead of tearing down the CCS BBs immediately after obtaining it.<br /> <br /> While here, also fix xe_sriov_vf_ccs_attach_bo() to properly unwind and<br /> propagate errors: the per-context loop previously never broke out on<br /> error, silently discarding earlier failures. Unwind by clearing each<br /> attached context directly via xe_migrate_ccs_rw_copy_clear() instead of<br /> reusing xe_sriov_vf_ccs_detach_bo(), which requires both contexts to be<br /> attached before it will clean up either one.<br /> <br /> (cherry picked from commit d45ad0aa7a1eb5d7288b5ed948b05695611dc39e)