CVE-2026-43378

What it actually does

This is a use-after-free vulnerability in the Linux kernel SMB server code path for SMB2 open handling. The kernel obtains an SMB file/open-state pointer under RCU protection, exits the RCU read-side critical section, and then continues to dereference that pointer, creating a race window where another thread can free or replace the referenced object. If reachable through the SMB server, a remote unauthenticated attacker may be able to trigger memory corruption in kernel context. The likely outcomes include kernel crash and denial of service; because the flaw occurs in kernel memory and has a CVSS score of 9.8 with high confidentiality, integrity, and availability impact, successful exploitation may also allow arbitrary code execution or privilege escalation in the kernel depending on memory layout, timing, and exploit reliability.

Why it matters to the business

Systems running an affected Linux kernel with the in-kernel SMB server enabled could be remotely crashed or potentially compromised over the network. For organizations using Linux-based file sharing, NAS appliances, storage gateways, or embedded products built on affected kernels, exploitation could interrupt file access, corrupt active operations, expose sensitive data, or give an attacker deep control of the host. The vulnerability is high severity and network-reachable, but it is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, and has low EPSS at 0.00308, so prioritization should focus first on internet-exposed or untrusted-network SMB services and high-value file servers.

How an attack unfolds

An attacker first identifies a Linux host exposing the in-kernel SMB server, commonly on TCP port 445. The attacker then initiates SMB2 sessions and sends crafted or carefully timed open-related requests intended to exercise the vulnerable smb2_open() path while another code path releases the referenced open-state object. By winning the race, the attacker causes the kernel to dereference memory after it has been freed. In less controlled attempts this may produce kernel warnings, an oops, or a system crash. A more capable attacker could attempt heap grooming and timing control to replace the freed object with attacker-influenced data, potentially steering kernel execution or corrupting kernel data structures. There is no public exploit maturity indicated in the supplied data, but the network reachability, lack of required privileges, and kernel execution context make exposed SMB services high-value targets.

How to fix it

Upgrade affected Linux kernels to a vendor-provided version that includes the fix for the SMB server use-after-free in smb2_open(). Because no exact fixed versions were provided, use distribution and appliance vendor advisories for the precise package release, kernel build, or backported security update. After updating the kernel, reboot into the patched kernel and verify the running kernel version, not only the installed package version. If immediate patching is not possible, disable the in-kernel SMB server if it is not required, restrict SMB access to trusted networks, block inbound TCP/445 and related SMB exposure at network boundaries, and prefer isolation behind VPN or private network controls. These mitigations reduce reachability but do not remove the vulnerable code from the kernel.

How to confirm the fix worked

Confirm whether the system is running a patched kernel from the relevant Linux distribution or product vendor. Validate with commands such as uname -r, package-manager kernel inventory, and vendor security advisory mapping to ensure the active booted kernel contains the fix. Confirm whether the in-kernel SMB server is enabled by checking for ksmbd-related services, loaded modules, active listeners on TCP/445, and SMB server configuration. Validate network exposure using internal and external scans for TCP/445. After remediation, reboot and re-check the active kernel version and SMB exposure. Where safe, use vulnerability scanners or authenticated configuration checks that map the running kernel build to the vendor-fixed release; avoid untrusted proof-of-concept testing against production file servers because failed exploitation may crash the host.

Typical attack path

1. Scan for hosts exposing SMB services, especially TCP/445, and fingerprint systems likely running Linux SMB server functionality.
2. Establish an SMB2 connection to the target service without requiring user interaction or prior local access.
3. Send SMB2 open/create requests designed to reach the vulnerable smb2_open() code path.
4. Trigger a race in which the referenced SMB open-state object is freed after RCU protection ends but before later dereference.
5. Cause kernel memory corruption, often resulting in a kernel oops, panic, service interruption, or host reboot.
6. If exploit development is reliable, use heap manipulation to attempt kernel-level code execution or data corruption.

How to detect it

To determine whether this was already exploited, review host and centralized logs for kernel memory-corruption events, crashes, reboots, or panics correlated with SMB traffic. Relevant sources include journald, syslog, kern.log, dmesg captures, kdump/vmcore records, audit logs, EDR kernel-crash telemetry, SMB server logs, firewall logs, NetFlow, and packet captures for TCP/445. Look for kernel oops or KASAN reports referencing smb2_open, ksmbd, SMB2 create/open handling, RCU dereference misuse, or use-after-free shortly before a reboot or service outage. Correlate these events with bursts of SMB2 CREATE/Open requests, repeated unauthenticated SMB sessions, failed negotiate/session setup attempts, or unusual SMB traffic from unfamiliar network sources. Absence of these indicators does not prove non-exploitation because a reliable exploit may leave limited application-level evidence, but kernel crashes and allocator diagnostics are the most likely observable artifacts.

• BUG: KASAN: use-after-free
• use-after-free in smb2_open
• smb2_open
• ksmbd
• ksmbd:
• RIP: smb2_open
• Call Trace:
• general protection fault
• kernel BUG
• Oops:
• kernel panic
• RCU
• TCP/445
• SMB2 CREATE
• SMB2 CREATE Request

What your security team should do

• Inventory Linux systems and appliances exposing SMB, especially internet-facing or untrusted-network TCP/445 services.
• Prioritize patching SMB-exposed Linux kernels and high-value file servers even though KEV status is false and EPSS is currently low.
• Apply the vendor kernel update that contains the smb2_open() use-after-free fix, then reboot and verify the patched kernel is active.
• Disable the in-kernel SMB server where it is not required, or limit access with host firewalls, network ACLs, and segmentation.
• Monitor kernel logs, crash dumps, SMB service logs, and EDR telemetry for crashes or memory-corruption indicators involving ksmbd or smb2_open().
• Review any recent unexplained SMB server crashes, kernel panics, or reboots since publication for possible exploitation attempts.
• Ensure file servers have recoverable backups and tested restoration procedures because kernel-level compromise or repeated crashes can disrupt file availability.