Skip to main content
VulnerabilityPublished Updated

CVE-2026-68384: Linux kernel · Race Condition

Affects Linux kernelSource CVE Database V5

0

Not known to be exploited · CVSS 7.8 High · fixed in f2ebfd5cc87f1393a30c8b8b0a6c20cb22cffa97 : patch Linux kernel soon.

Data as of 26 Oct 2026, 14:05 UTC

CVSS 3.1 base score
7.8High
How severe the flaw is on the 0–10 CVSS scale.
EPSS
0.1% chance of exploitation in 30 days – higher than 1% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
CISA SSVC
Exploitation
No evidence of active exploitation and no public proof of concept
Automatable
Attackers cannot reliably automate steps 1–4 of the kill chain
Technical impact
Total control over the software or total information disclosure

CISA SSVC assessment, 2026-10-16.

Patch
Available – fixed in f2ebfd5cc87f1393a30c8b8b0a6c20cb22cffa97, 56441f9e08ad68697295b8835266d2bc48ab59b5, 35ba43b541117bfb595e4b807ba447cf4335cc7d
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 10 Aug 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

What to do

Upgrade Linux kernel to f2ebfd5cc87f1393a30c8b8b0a6c20cb22cffa97, 56441f9e08ad68697295b8835266d2bc48ab59b5 or 35ba43b541117bfb595e4b807ba447cf4335cc7d.

Affected software

ProductAffectedFixed in
LinuxLinuxAffected
  • ≥ 864690cf4dd62482b6dd049d82c509886c904303, < f2ebfd5cc87f1393a30c8b8b0a6c20cb22cffa97
Fixed in
  • f2ebfd5cc87f1393a30c8b8b0a6c20cb22cffa97
LinuxLinuxAffected
  • ≥ 864690cf4dd62482b6dd049d82c509886c904303, < 56441f9e08ad68697295b8835266d2bc48ab59b5
Fixed in
  • 56441f9e08ad68697295b8835266d2bc48ab59b5
LinuxLinuxAffected
  • ≥ 864690cf4dd62482b6dd049d82c509886c904303, < 35ba43b541117bfb595e4b807ba447cf4335cc7d
Fixed in
  • 35ba43b541117bfb595e4b807ba447cf4335cc7d
LinuxLinuxAffected
  • =6.18
Fixed in–

Description

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)

References

Community reviews

Loading reviews…