CVE-2026-53271

What it actually does

The flaw is a race condition in the Linux kernel ksmbd SMB server. During SMB2 oplock or lease break notification handling, ksmbd can read an operation structure's connection pointer after another thread handling SMB2 LOGOFF has set that pointer to NULL. The vulnerable path then dereferences the NULL pointer in kernel context, causing a kernel oops and potentially a system panic or service crash. The practical impact is remotely triggerable denial of service against systems running the in-kernel SMB server; the provided details do not indicate code execution, privilege escalation, or data disclosure.

Why it matters to the business

Organizations using Linux systems as SMB file servers through ksmbd may experience unexpected file-sharing outages, kernel crashes, forced reboots, interrupted user access to shared files, and possible disruption to dependent business workflows. Internet- or broadly network-exposed SMB services carry higher operational risk, although current exploitation signals are low: EPSS is 0.00114, it is not listed in CISA KEV, no ransomware association is indicated, and exploit maturity is currently reported as none.

How an attack unfolds

An attacker needs network access to an SMB service backed by the Linux kernel ksmbd server. The attacker establishes SMB2 sessions and performs file operations that create oplock or lease state, then races session teardown, such as SMB2 LOGOFF, against oplock or lease break notification handling. If the timing window is won, ksmbd observes a connection pointer that has been cleared by the logoff path but still attempts to increment connection reference state through that pointer. This produces a NULL pointer dereference in kernel space at a small offset, resulting in a kernel oops and, depending on kernel panic settings and service supervision, a host crash, reboot, or loss of SMB service availability.

How to fix it

Apply a vendor-supplied Linux kernel update that includes the ksmbd fix for the oplock and lease break notifier NULL pointer race. Because no exact fixed package versions were provided, use the distribution or appliance vendor advisory as the source of truth and ensure the deployed kernel contains the patch that reads opinfo->conn safely and returns early when it is NULL. Reboot into the updated kernel where required. If immediate patching is not possible, reduce exposure by disabling ksmbd, unloading or preventing use of the ksmbd module where feasible, blocking untrusted access to TCP/445, restricting SMB access to trusted networks or VPNs, and considering migration to a non-affected SMB implementation if appropriate. Avoid exposing ksmbd directly to the internet.

How to confirm the fix worked

Confirm whether ksmbd is enabled and reachable by checking loaded modules, kernel configuration, service status, and listeners on TCP/445. Validate remediation by confirming the running kernel version is the vendor-fixed build, not merely that an updated package is installed on disk. Review vendor changelogs or kernel source/backport notes for the ksmbd oplock/lease break notifier fix. After patching, verify that SMB shares remain functional and that repeated SMB2 session creation, file opens using leases/oplocks, and logoff cycles do not generate kernel oops messages. Check dmesg, journalctl, kern.log, syslog, and crash dump storage for absence of ksmbd NULL pointer dereference traces after the update.

Typical attack path

1. Identify a Linux host exposing SMB, typically TCP port 445, and determine or assume it is using ksmbd rather than a user-space SMB server.
2. Authenticate if the share configuration requires credentials, or connect anonymously if guest access is allowed.
3. Open files or otherwise create SMB2 oplock or lease state that can later require break notifications.
4. Rapidly trigger SMB2 LOGOFF or session teardown while oplock or lease break notification work is being processed.
5. Repeat concurrent lease/oplock and logoff sequences to increase the chance of hitting the race window.
6. Cause a kernel NULL pointer dereference in the ksmbd code path, resulting in SMB service disruption or a system-level crash.

How to detect it

Look for evidence of prior exploitation primarily in host kernel logs and crash artifacts, because successful exploitation manifests as a kernel oops or panic rather than a persistent file artifact. Review dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, /var/log/syslog, systemd-coredump records, kdump/vmcore storage, hypervisor reset events, and availability monitoring for crashes involving ksmbd, oplock break, lease break, or NULL pointer dereference at address/offset 0xc4. Correlate any crash with SMB network telemetry showing repeated SMB2 session setup/logoff activity, file open/close bursts, lease or oplock negotiation, or many short-lived TCP/445 connections from the same source. Because this is a race-triggered denial-of-service issue, absence of persistent files or malware does not rule out exploitation. If packet capture or Zeek/Suricata SMB logs are available, search for high-rate SMB2 LOGOFF commands close in time to file operations that request leases or oplocks. Also investigate unexplained reboots of ksmbd file servers since the vulnerability became public, especially where the preceding logs show active SMB client churn.

• ksmbd_conn_r_count_inc
• smb2_oplock_break_noti
• smb2_lease_break_noti
• oplock_break
• BUG: kernel NULL pointer dereference
• unable to handle kernel NULL pointer dereference
• address: 00000000000000c4
• 00000000000000c4
• Oops:
• ksmbd
• SMB2 LOGOFF
• SMB2_OPLOCK_BREAK
• SMB2_LEASE_BREAK
• TCP/445

What your security team should do

• Inventory Linux systems exposing SMB and distinguish ksmbd-based servers from Samba or other SMB implementations.
• Prioritize patching ksmbd-enabled systems that expose TCP/445 to untrusted networks, shared user networks, or high-availability file service environments.
• Apply the vendor-fixed kernel and reboot into it; verify the running kernel, not just installed packages.
• If patching must be delayed, restrict SMB access using host firewalls, network ACLs, VPN-only access, and segmentation; disable ksmbd where it is not required.
• Review kernel logs and crash records from the period since publication for ksmbd-related NULL pointer dereferences, oops events, panics, or unexplained reboots.
• Monitor SMB telemetry for unusual bursts of session setup, lease/oplock activity, and LOGOFF operations from the same client sources.
• Ensure file service availability plans account for host-level crashes, including clustering, backups, and documented recovery procedures.