CVE-2026-43215

What it actually does

This is a race condition in the Linux kernel CIFS/SMB client code. The vulnerable code used an overly broad lock, cifs_tcp_ses_lock, to protect CIFS tree connection (tcon) fields that should instead be protected by the per-tree-connection tc_lock. Under concurrent CIFS activity, tcon fields can be read or modified without the correct synchronization, creating inconsistent kernel state. Depending on timing and code path, this can lead to kernel memory corruption, use of stale or inconsistent connection metadata, denial of service through kernel crash, or potentially broader confidentiality and integrity impact in the kernel context.

Why it matters to the business

Systems that mount or access SMB/CIFS shares from Linux may be exposed to crashes or compromise if they interact with a malicious or compromised SMB server or network path. The most likely operational impact is instability or outage of Linux hosts that rely on SMB file shares, including file servers, application servers, backup systems, and user workstations. Although public exploitation is not currently reported, the CVSS rating is high and the flaw is in kernel code, so successful exploitation could have severe consequences. EPSS is currently low and flat, and it is not listed in CISA KEV or known ransomware use, which suggests prioritization should be risk-based but still timely for systems using CIFS mounts.

How an attack unfolds

An attacker would need to cause a vulnerable Linux system to exercise the affected CIFS client code, typically by having the victim connect to, mount, or otherwise access an SMB/CIFS share controlled by the attacker or by compromising an SMB server already trusted by the victim. The attacker then triggers concurrent CIFS operations and carefully timed responses that cause the kernel to access or update tcon fields without the correct lock. If the race is won, the kernel may enter an inconsistent state, crash, or potentially corrupt memory in a way that could be shaped toward further impact. Exploitation is timing-dependent and kernel-specific, and no public exploit maturity is reported, but the vulnerable component operates in kernel space, making any reliable exploit high impact.

How to fix it

Update affected Linux kernels to a vendor-supported version that includes the CIFS locking fix replacing remaining cifs_tcp_ses_lock protection of tcon fields with tc_lock. Because no exact fixed versions were provided, use the latest security kernel packages from the relevant distribution or appliance vendor and confirm the changelog includes the CIFS client locking fix for this CVE. Reboot systems after kernel updates so the patched kernel is running. Where immediate patching is not possible, reduce exposure by disabling unnecessary CIFS/SMB client usage, removing unused CIFS mounts from /etc/fstab and automount configurations, restricting outbound SMB traffic to trusted servers only, and avoiding connections to untrusted SMB shares. Harden SMB paths with network segmentation and monitor any Linux hosts that must mount external or third-party SMB shares.

How to confirm the fix worked

Confirm the running kernel, not only the installed package, is updated using commands such as uname -r and the distribution package manager. Verify vendor advisories or package changelogs show the CIFS locking fix for this CVE. Inventory CIFS usage by checking mounted filesystems, /proc/mounts, /etc/fstab, systemd mount units, autofs maps, and application configurations for cifs or smb mounts. Validate that systems no longer able or expected to use CIFS cannot initiate outbound SMB connections except to approved destinations. After patching and rebooting, monitor kernel logs for absence of CIFS-related crashes, kernel oopses, lock warnings, and unexpected disconnect or reconnect storms during normal SMB workload testing.

Typical attack path

1. Identify Linux systems that mount SMB/CIFS shares or automatically connect to network file shares.
2. Gain control of an SMB/CIFS server the target accesses, position a malicious SMB service, or influence a user or service to connect to an attacker-controlled share.
3. Trigger CIFS session and tree connection activity from the victim system.
4. Send crafted or carefully timed SMB responses while inducing concurrent CIFS operations on the client.
5. Exploit the race in tcon field locking to create inconsistent kernel state.
6. Cause denial of service through kernel crash or attempt to leverage memory corruption for deeper compromise.

How to detect it

To assess possible prior exploitation, review Linux kernel logs and system journals on hosts that use CIFS/SMB mounts. Focus on the period after the vulnerability became known and on systems that connected to unfamiliar, recently changed, or externally controlled SMB servers. Relevant log sources include journalctl -k, /var/log/kern.log, /var/log/messages, /var/log/syslog, crash dump directories, kdump/vmcore artifacts, audit logs for mount activity, systemd mount unit logs, autofs logs, endpoint network telemetry, DNS logs, firewall/proxy logs for outbound SMB, and SMB server logs where available. Look for kernel oopses, panics, BUG or WARNING traces involving fs/cifs, cifs.ko, tcon, tree connections, reconnect handling, or SMB session teardown. Also investigate unexpected outbound connections to TCP 445 or 139, new or modified CIFS mount entries, and repeated CIFS disconnect/reconnect activity shortly before a crash. There are no unique public exploit strings for this issue, so detection should correlate CIFS activity, unusual SMB destinations, and kernel instability rather than rely on a single signature.

• cifs.ko
• CIFS: VFS:
• CIFS VFS:
• fs/cifs
• mount -t cifs
• type cifs
• unc=
• //
• TCP/445
• TCP/139
• kernel BUG at fs/cifs
• WARNING: CPU:
• Oops:
• general protection fault
• NULL pointer dereference
• unable to handle kernel paging request
• Kernel panic - not syncing
• Call Trace:
• cifs_mount
• cifs_tree_connect
• cifs_reconnect
• cifs_put_tcon
• cifs_tcon
• smb2_tree_connect
• smb2_reconnect
• /proc/mounts
• /etc/fstab
• /etc/auto.master
• /etc/auto.smb

What your security team should do

• Prioritize patching Linux systems that mount SMB/CIFS shares, especially servers, backup hosts, file-processing systems, and endpoints that access untrusted or externally managed SMB shares.
• Confirm patched kernels are actually running after reboot; installed-but-not-booted kernel updates do not remediate this issue.
• Inventory CIFS/SMB client use across Linux fleets and remove stale or unnecessary mounts.
• Restrict outbound TCP 445 and 139 from Linux systems to approved SMB servers only.
• Treat any unexpected Linux connection to an unknown SMB server as suspicious and investigate.
• Increase monitoring for kernel oops, panic, CIFS reconnect storms, and crashes on systems using CIFS until remediation is complete.
• If a system crashes repeatedly while accessing SMB shares, preserve kernel logs, crash dumps, and mount history before rebuilding or reboot cycling.
• Track vendor kernel advisories because exact fixed versions vary by distribution and backport policy.