CVE-2026-64136
Critical · 9.8CVSS
9.8
EPSS
0.4%
Published
Jul 19, 2026
CISA due date
—
Cloudanix analysis
A missing lock in the Linux kernel's file-sharing code can let remote attackers interfere with connections and potentially take control of affected systems.
- Exploitation
- Remote Unauthenticated
- Attacker needs
- None
- Complexity
- Low
- Impact
- Full Compromise
- Component
- OS kernel
- Class
- Race Condition
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
Missing lock around tc_count increment in smb2_find_smb_sess_tcon_unlocked allows concurrent modification of tcon fields after refactoring to tc_lock, creating a race condition in SMB client session handling.
Why it matters to the business
Linux systems using SMB/CIFS clients face elevated risk of kernel instability or compromise; although EPSS is low and declining with no known exploitation campaigns 99 days after publication, the high CVSS score indicates potential for severe operational disruption if triggered.
How an attack unfolds
An attacker establishes multiple concurrent SMB connections or sessions to the Linux client and times operations to hit the unprotected tc_count increment window, resulting in inconsistent tcon state that can be leveraged for memory corruption or privilege escalation.
How to fix it
Apply the upstream fix from commit 96c4af418586 and subsequent locking correction to protect the tc_count increment; upgrade to a Linux kernel version containing the resolved smb client locking changes.
How to confirm the fix worked
Review kernel source for presence of tc_lock acquisition around tc_count modifications in smb2_find_smb_sess_tcon_unlocked; test concurrent SMB workloads for absence of tcon field corruption or panics.
Typical attack path
- Identify Linux kernel SMB client targets accepting network connections
- Initiate parallel SMB2 session and tree connect requests to widen the race window
- Trigger concurrent access to smb2_find_smb_sess_tcon_unlocked without holding tc_lock
- Exploit resulting inconsistent tc_count state for memory corruption or denial of service
How to detect it
Examine kernel logs and SMB client traces for concurrent session handling anomalies or tcon-related warnings around the time of suspected activity; no public exploitation artifacts are known.
What your security team should do
- Prioritize kernel updates on all Linux systems exposing SMB client functionality
- Monitor for new fixed kernel releases given 99 days since publication and high CVSS
- Restrict unnecessary SMB client access from untrusted networks until patched
The record
In the Linux kernel, the following vulnerability has been resolved: smb: client: protect tc_count increment in smb2_find_smb_sess_tcon_unlocked() Commit 96c4af418586 ("cifs: Fix locking usage for tcon fields") refactored cifs code to change cifs_tcp_ses_lock for tc_lock around tc_count changes. There was missing lock around tc_count increment inside smb2_find_smb_sess_tcon_unlocked().
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|