CVE-2026-64284: Linux kernel · Race Condition
Affects Linux kernelSource CVE Database V5
Not known to be exploited · CVSS 7.1 High · fixed in f2ca2b5326211bd38490f0497eb583721ce0bbc0 : patch Linux kernel soon.
Data as of 26 Oct 2026, 14:18 UTC
- EPSS
- 0.1% chance of exploitation in 30 days – higher than 2% 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
- Limited control over the software or limited information exposure
CISA SSVC assessment, 2026-10-16.
- Patch
- Available – fixed in f2ca2b5326211bd38490f0497eb583721ce0bbc0, b3436d9b9b1affe1c3191ac9831308923f5f03c3, 4ad73ef0e7966ecfe67de0060537b4cb14d9acd4 +1
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:HExploitation evidence
Disclosed: evidence found.
CVE published 25 Jul 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by 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 f2ca2b5326211bd38490f0497eb583721ce0bbc0, b3436d9b9b1affe1c3191ac9831308923f5f03c3, 4ad73ef0e7966ecfe67de0060537b4cb14d9acd4 or 0ffedf43910e44b76c2c1db4e9fbf12b268190c1.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in– |
Description
In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Ensure vendor's exit handler runs before fastpath userspace exits Move the handling of fastpath userspace exits into vendor code to ensure KVM runs vendor specific operations that need to run before userspace gains control of the vCPU. E.g. for VMX (and soon to be for SVM as well), KVM needs to flush the PML buffer prior to exiting to userspace, otherwise any memory written by the final KVM_RUN might never be flagged as dirty. Note, waiting to snapshot CR0 and CR3 until svm_handle_exit() is flawed in general, as that risks consuming stale state in a fastpath handler. That will be addressed in a future change.
References
- git.kernel.org/stable/c/b3436d9b9b1affe1c3191ac9831308923f5f03c3 (opens in a new tab)
- git.kernel.org/stable/c/4ad73ef0e7966ecfe67de0060537b4cb14d9acd4 (opens in a new tab)
- git.kernel.org/stable/c/f2ca2b5326211bd38490f0497eb583721ce0bbc0 (opens in a new tab)
- git.kernel.org/stable/c/0ffedf43910e44b76c2c1db4e9fbf12b268190c1 (opens in a new tab)