CVE-2026-45972

What it actually does

This is a memory-safety flaw in the Linux kernel SMB/CIFS client code path, specifically in smb2_open_file(). During a retry of SMB2_open(), error-related buffers may not be cleared correctly. If the client receives certain SMB2 error handling data, the kernel can later reuse or free stale memory, creating a use-after-free condition when data is present or a double-free condition otherwise. Because this occurs in kernel space, successful exploitation can potentially cause kernel memory corruption, system crash, information disclosure, or, in the worst case, arbitrary code execution with kernel privileges. Practical exploitation likely requires the vulnerable system to connect to, or be redirected to, an attacker-controlled SMB server or SMB man-in-the-middle path.

Why it matters to the business

Systems that use the Linux kernel SMB/CIFS client to access Windows or Samba file shares may be exposed to a high-impact kernel memory corruption issue. A malicious or compromised SMB server could potentially crash affected Linux systems or compromise them at the operating-system level. This can affect file access services, application servers, backup jobs, user workstations, and any workloads that mount SMB shares. Although this issue is not currently listed in CISA KEV, has no known public exploit maturity in the provided data, and has a low EPSS score, the CVSS severity is critical because successful exploitation can affect confidentiality, integrity, and availability of the host.

How an attack unfolds

An attacker first needs a way to make a vulnerable Linux system use the kernel SMB/CIFS client against a malicious SMB endpoint. This could occur if a user or service mounts an attacker-controlled SMB share, if an existing SMB server is compromised, or if network redirection techniques cause the client to connect to a hostile SMB service. The attacker then responds to an SMB2 open request in a way that exercises the retry path in smb2_open_file(). By manipulating the SMB2 open response and associated error data, the attacker can trigger stale pointer handling in the client. On retry, the kernel may reference memory that has already been freed or attempt to free the same buffer twice. The immediate and most reliable outcome is likely a kernel crash or denial of service. With a reliable exploit and favorable kernel memory layout conditions, the same primitive may be abused for kernel-level code execution or privilege escalation on the client host.

How to fix it

Apply the vendor-provided Linux kernel update that contains the fix for the SMB client smb2_open_file() retry handling issue. No exact fixed package versions were provided in the input, so use distribution-specific advisories from vendors such as Red Hat, Ubuntu, Debian, SUSE, Amazon Linux, Oracle Linux, Alpine, and appliance vendors that ship Linux kernels. Prioritize systems that mount SMB/CIFS shares, especially servers and workloads that automatically mount remote shares at boot or through scheduled jobs. If immediate patching is not possible, reduce exposure by disabling unnecessary SMB/CIFS mounts, preventing systems from connecting to untrusted SMB servers, restricting outbound SMB traffic to approved file servers only, and blocking TCP/445 to untrusted networks. Consider temporarily using alternative file transfer mechanisms for high-risk systems until the kernel is updated. After patching, reboot into the fixed kernel; merely installing the package is not sufficient if the running kernel remains vulnerable.

How to confirm the fix worked

Confirm the running kernel, not just the installed kernel package, has been updated using commands such as uname -r and the relevant package manager query for the distribution. Review vendor advisories to map the running kernel build to the fixed release. Confirm whether the cifs kernel module is loaded with lsmod or /proc/modules and identify active SMB/CIFS mounts using mount, findmnt, or /proc/mounts. Validate exposure reduction by confirming systems only connect to approved SMB servers and that outbound TCP/445 is blocked where not required. After remediation, perform a controlled reboot and verify that the system is running the fixed kernel. For fleet validation, inventory Linux hosts with active cifs mounts and compare their running kernel versions against vendor-fixed builds.

Typical attack path

1. Identify Linux systems that mount SMB/CIFS shares using the kernel cifs/smb client.
2. Gain control of an SMB server used by the target, stand up a malicious SMB server, or redirect the client to an attacker-controlled SMB endpoint.
3. Wait for or induce the vulnerable client to perform an SMB2 file open operation.
4. Return crafted SMB2 open/error responses that force the smb2_open_file() retry path.
5. Trigger use-after-free or double-free behavior in kernel SMB client memory handling.
6. Cause a kernel crash, corrupt kernel memory, or attempt further exploitation for kernel-level control.

How to detect it

To determine whether this may already have been exploited, review kernel logs and system journals for crashes, memory corruption warnings, and SMB/CIFS client errors around times when systems accessed SMB shares. Relevant sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, /var/log/syslog, crash dumps, kdump/vmcore artifacts, endpoint telemetry, and network logs showing outbound SMB connections. Look for kernel oops, panic, slab corruption, KASAN use-after-free, double-free, general protection fault, or BUG messages that reference cifs, smb2_open_file, SMB2_open, or CIFS VFS. Correlate host crashes with outbound connections to unusual SMB servers over TCP/445 or TCP/139. Also investigate any recent changes to SMB mount targets, DNS or NetBIOS name resolution, WPAD/LLMNR/NBNS activity, or connections to SMB servers outside approved file-server ranges. Because public exploit maturity is listed as none and no known threat actors were provided, detection should focus on suspicious SMB connectivity plus kernel memory-corruption artifacts rather than a single definitive exploit signature.

• smb2_open_file
• SMB2_open
• CIFS VFS
• cifs
• kernel BUG
• BUG: KASAN: use-after-free
• KASAN: use-after-free
• use-after-free in smb2_open_file
• double free
• general protection fault
• kernel panic
• Oops:
• slab corruption
• invalid opcode: 0000
• TCP/445
• TCP/139
• mount.cifs
• /proc/fs/cifs/DebugData
• /proc/mounts
• /var/log/kern.log
• /var/log/messages
• /var/log/syslog

What your security team should do

• Prioritize patching Linux systems that actively mount SMB/CIFS shares or communicate with Windows/Samba file servers.
• Identify all systems with the cifs kernel module loaded or active SMB/CIFS mounts and treat them as the primary exposure set.
• Restrict outbound SMB traffic, especially TCP/445, to known and approved file servers only.
• Review SMB server trust boundaries; do not allow production Linux systems to mount shares from untrusted or user-controlled SMB servers.
• Monitor for kernel crashes, oops messages, KASAN reports, or CIFS VFS errors involving SMB2 open operations.
• Confirm patched systems have rebooted into the fixed kernel, since old vulnerable kernels may remain active after package updates.
• If SMB access is business-critical and patching is delayed, isolate affected hosts and limit SMB connectivity to tightly controlled network segments.
• Track distribution advisories for exact fixed kernel package versions because no fixed versions were provided in the input.