CVE-2026-68384

HIGHPre-NVD 7.87.8
EchelonGraph scoreHIGH confidence

Score 7.8 from GitHub Security Advisory (severity: HIGH) published 2026-08-10. a secondary CVSS source baseline 7.8; sources differ by 0.0.

Triggered by: GitHub Security Advisory CVSS
Sources: epss, ghsa, secondary
Trending — 3 sources updated this week
7.8EG
EchelonGraph verdictPlan a fixSerious severity, but no confirmed exploitation yet.
  • High severity, but no confirmed exploitation yet
CISA-KEV: Not listedEPSS PROB: 0%CVSS: 7.8Exploit: None knownExposed: 0

No vendor fix yet — apply a workaround or compensating control (WAF / firewall / segmentation) and watch for a patch.

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

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

xe_bo_move() 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. xe_migrate_ccs_rw_copy() 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 xe_sriov_vf_ccs_attach_bo() 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 xe_migrate_ccs_rw_copy_clear() instead of reusing xe_sriov_vf_ccs_detach_bo(), which requires both contexts to be attached before it will clean up either one.

(cherry picked from commit d45ad0aa7a1eb5d7288b5ed948b05695611dc39e)

CVSS v3
7.8
EG Score
7.8(high)
EG Risk
40(Track)
EG Risk 40/100SSVC: Track

EG Risk is EchelonGraph's 0–100 priority score: it fuses intrinsic severity with real-world exploitation and automatability so you can rank equal-severity CVEs and fix the most dangerous first. Higher = act sooner. Distinct from the 0–10 EG Score (severity).

How it’s computed
Severity78% × 45%
Exploitation0% × 40%
Automatability30% × 15%
Action: Routine — remediate on your standard cadence.
EPSS PROB
0%
EPSS %ILE
3%
KEV
Not listed

Published

August 10, 2026

Last Modified

August 17, 2026

Advisory Details (3)

Auto-updated Aug 14, 2026
No patch confirmed yet.
generic

drm/xe/vf: Fix VF CCS attach/detach race with in-flight BO moves - kernel/git/stable/linux.git - Linux kernel stable tree

https://git.kernel.org/stable/c/f2ebfd5cc87f1393a30c8b8b0a6c20cb22cffa97
generic

drm/xe/vf: Fix VF CCS attach/detach race with in-flight BO moves - kernel/git/stable/linux.git - Linux kernel stable tree

https://git.kernel.org/stable/c/56441f9e08ad68697295b8835266d2bc48ab59b5
generic

drm/xe/vf: Fix VF CCS attach/detach race with in-flight BO moves - kernel/git/stable/linux.git - Linux kernel stable tree

https://git.kernel.org/stable/c/35ba43b541117bfb595e4b807ba447cf4335cc7d

Vendor Advisories for CVE-2026-68384(1)

These vendors published their own advisory mentioning this CVE — often with vendor-specific remediation steps + affected product lists not in NVD.

Data Freshness Timeline

(refreshed 32× in last 7d / 44× in last 30d)

Each row is a source pipeline that fetched or updated this CVE on that date, with what changed. For example, "NVD update" means NVD published or revised its analysis for this CVE; "MITRE cvelistV5" means we ingested or refreshed it from the CNA feed. Most recent first.

  1. 2026-08-21 00:49 UTCEG score recompute
  2. 2026-08-21 00:49 UTCGHSA enrichment
  3. 2026-08-20 22:56 UTCEPSS rescore
  4. 2026-08-20 12:05 UTCGHSA enrichment
  5. 2026-08-19 23:09 UTCEG score recompute
  6. 2026-08-19 23:09 UTCGHSA enrichment
  7. 2026-08-19 17:04 UTCEPSS rescore
  8. 2026-08-19 10:24 UTCGHSA enrichment
  9. 2026-08-18 21:40 UTCEG score recompute
  10. 2026-08-18 21:39 UTCGHSA enrichment
  11. 2026-08-18 13:49 UTCEPSS rescore
  12. 2026-08-18 13:49 UTCEPSS rescore
  13. 2026-08-18 08:22 UTCGHSA enrichment
  14. 2026-08-17 19:19 UTCEG score recompute
  15. 2026-08-17 19:19 UTCGHSA enrichment
  16. 2026-08-17 13:47 UTCEPSS rescore
  17. 2026-08-17 06:32 UTCEG score recompute
  18. 2026-08-17 06:31 UTCGHSA enrichment
  19. 2026-08-17 05:36 UTCEG score recompute
  20. 2026-08-17 05:36 UTCGHSA enrichment
  21. 2026-08-17 04:11 UTCGHSA enrichment
  22. 2026-08-16 15:26 UTCEG score recompute
  23. 2026-08-16 15:26 UTCGHSA enrichment
  24. 2026-08-16 14:56 UTCEPSS rescore
  25. 2026-08-16 02:42 UTCEG score recompute
Show 19 more
  1. 2026-08-16 02:42 UTCGHSA enrichment
  2. 2026-08-15 13:58 UTCEG score recompute
  3. 2026-08-15 13:58 UTCGHSA enrichment
  4. 2026-08-15 01:30 UTCEPSS rescore
  5. 2026-08-15 01:13 UTCGHSA enrichment
  6. 2026-08-14 12:28 UTCEG score recompute
  7. 2026-08-14 12:28 UTCGHSA enrichment
  8. 2026-08-13 23:44 UTCEG score recompute
  9. 2026-08-13 23:44 UTCGHSA enrichment
  10. 2026-08-13 23:03 UTCEG score recompute 7.80
  11. 2026-08-13 23:03 UTCGHSA enrichment
  12. 2026-08-13 23:03 UTCMITRE cvelistV5CVSS v3 → 7.8 · severity → HIGH
  13. 2026-08-13 22:00 UTCEPSS rescore
  14. 2026-08-13 09:24 UTCEG score recompute
  15. 2026-08-13 09:24 UTCGHSA enrichment
  16. 2026-08-12 13:51 UTCEPSS rescore
  17. 2026-08-10 13:24 UTCNVD update
  18. 2026-08-10 12:18 UTCEG score recompute
  19. 2026-08-10 12:17 UTCMITRE cvelistV5first tracked

Frequently asked(5)

What is CVE-2026-68384?
CVE-2026-68384 is a high vulnerability published on August 10, 2026. 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…
When was CVE-2026-68384 disclosed?
CVE-2026-68384 was first published in the National Vulnerability Database on August 10, 2026, with the most recent update on August 17, 2026. EchelonGraph re-ingests CVE updates from NVD on a 2-hour cycle, so this page reflects the latest published state.
Is CVE-2026-68384 actively exploited?
CVE-2026-68384 is not currently on CISA's Known Exploited Vulnerabilities catalog. FIRST EPSS estimates a 0% probability of exploitation in the next 30 days, which ranks it in the top 96.6% of all scored CVEs.
What is the CVSS score of CVE-2026-68384?
CVE-2026-68384 has a CVSS v3 base score of 7.8 (NVD).
How do I remediate CVE-2026-68384?
Patch to the fixed version published by the affected vendor. Where vendor advisories exist for CVE-2026-68384, EchelonGraph cross-links them in the Vendor Advisories panel below — those typically contain the canonical remediation steps, fixed version numbers, and any vendor-specific mitigations.

Dependency Blast Radius

Explore the affected products and dependency analysis for CVE-2026-68384

Explore →

Is Your Infrastructure Affected by CVE-2026-68384?

EchelonGraph automatically scans your cloud infrastructure and maps CVE exposure using blast radius analysis.