CVE-2026-68384: drm/xe/vf: Fix VF CCS attach/detach race with in-flight BO moves

Published Aug 10, 2026
·
Updated

In the Linux kernel, the following vulnerability has been resolved:

drm/xe/vf: Fix VF CCS attach/detach race with in-flight BO moves

xebomove() attaches VF CCS read/write batch buffers (BBs) to a BO after it transitions NULL/SYSTEM -> TT, and detaches them after it transitions TT -> SYSTEM. Both operations were done synchronously on the CPU immediately after building the move's copy/clear fence, without waiting for that fence to signal. This creates two races with VF migration:

- Attach happens too late relative to the copy job it is meant to protect. If the copy job is submitted before the CCS BBs are attached, a VF migration event that pauses execution mid-copy can observe partially copied CCS metadata without the attach state needed to correctly save/restore it.

- Detach happens too early relative to the copy job that moves data out of TT. The CCS BBs are torn down right after the copy fence is obtained, while the actual blit may still be in flight. A VF migration event that pauses execution mid-copy can then race the save/restore path against the still-running blit, and the CCS BBs it would need to make sense of the paused state have already been removed.

Fix both races:

- Move the attach call to before the copy/clear job is submitted, so the CCS BBs are already registered by the time the copy runs. On attach failure, unwind and bail out of the move. xemigrateccsrwcopy() now takes the destination resource explicitly, since bo->ttm.resource is not updated to the new resource until after the move commits.

- Detach only after explicitly waiting for the copy fence to signal, instead of tearing down the CCS BBs immediately after obtaining it.

While here, also fix xesriovvfccsattachbo() to properly unwind and propagate errors: the per-context loop previously never broke out on error, silently discarding earlier failures. Unwind by clearing each attached context directly via xemigrateccsrwcopyclear() instead of reusing xesriovvfccsdetachbo(), which requires both contexts to be attached before it will clean up either one.

(cherry picked from commit d45ad0aa7a1eb5d7288b5ed948b05695611dc39e)

Affected Software

1 affected component
Linux Kernel

Event History

Aug 10, 2026
CVE Published
via MITRE·12:04 PM
Data Sourced
via MITRE·12:04 PM
Description
Data Sourced
via NVD·01:20 PM
Description
Free Weekly Intel

Don't miss critical vulnerabilities

Join thousands of security professionals who receive our weekly digest of trending CVEs, zero-days, and exploited vulnerabilities.

No spam. Unsubscribe anytime.

Frequently Asked Questions

1

What is the severity of CVE-2026-68384?

CVE-2026-68384 has a risk rating of 44, indicating a moderate severity level.

2

What systems are affected by CVE-2026-68384?

CVE-2026-68384 affects the Linux kernel, particularly related to the drm/xe/vf subsystem.

3

How do I fix CVE-2026-68384?

To fix CVE-2026-68384, update your Linux kernel to the latest version that resolves this vulnerability.

4

What are the consequences of CVE-2026-68384?

Exploitation of CVE-2026-68384 could lead to instability in handling batch buffers, potentially causing system crashes.

5

When was CVE-2026-68384 published?

CVE-2026-68384 was published on August 10, 2026.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203