ZDI-26-573: Linux Kernel KSMBD Out-of-Bounds Read — Detection and Remediation Guide

The Zero Day Initiative has disclosed ZDI-26-573, a remotely exploitable, unauthenticated out-of-bounds read vulnerability in the Linux kernel's in-kernel SMB3 server, ksmbd. ZDI has assigned it a CVSS score of 9.3 (Critical). The flaw lives in the handling of SMB response header construction and allows a remote attacker — no credentials, no valid session — to coax the server into returning kernel memory contents that sit beyond the bounds of the intended response buffer.

Let me be blunt about why this matters. An information disclosure bug in kernel space, reachable over TCP/445 without authentication, is one of the worst classes of findings we see in infrastructure reviews for three reasons:

1. Kernel memory is the crown jewels. Leaked bytes can contain credentials in transit, cryptographic key material, page fragments from other processes, or kernel pointers that defeat KASLR — turning this 'info leak' into the first stage of a full remote code execution chain.
2. KSMBD is invisible to most inventory tools. Because it's an in-kernel server rather than a userspace daemon like Samba's smbd, many asset-management and EDR inventories simply don't report it as a 'running SMB service.' Organizations routinely discover ksmbd only after an incident.
3. The vulnerable component listens on the network by design. Wherever ksmbd is enabled, port 445 is exposed at kernel privilege to any host that can route to it.

The good news: only systems with ksmbd explicitly enabled are vulnerable. That makes scoping fast — if you know where to look.

Technical Analysis

Affected Component and Platforms

• Component: ksmbd — the in-kernel SMB3 file server (merged into the Linux kernel mainline in 5.15, filesystem path fs/ksmbd/, worker threads visible as kworker/*:ksmbd* and ksmbd-io processes).
• Attack surface: TCP port 445 (and 139 in legacy configurations), serviced directly by kernel worker threads rather than a userspace process.
• Vulnerable systems: Any Linux host or appliance with the ksmbd kernel module loaded and configured. This includes certain NAS distributions, embedded Linux appliances, and virtualization/storage platforms that adopted ksmbd for SMB3 performance.
• Not affected: Systems running Samba (smbd/nmbd userspace daemons) instead of ksmbd, and systems where the ksmbd module is not loaded.

The summary does not yet reference a CVE assignment; track ZDI-26-573 and monitor the ZDI advisory page and your distribution's security tracker for the CVE mapping and fixed kernel versions.

How the Vulnerability Works

From a defensive perspective, the mechanics are what matter:

• Flaw class: Out-of-bounds (OOB) read (CWE-125) in SMB response header processing.
• Root cause pattern: When ksmbd constructs an SMB response, a length or offset field derived from attacker-controlled request data is not adequately validated before being used to size or populate the response header. The result: the kernel copies bytes beyond the legitimate buffer into the SMB response that is transmitted back to the client.
• Exploitation requirements: Network reachability to the ksmbd listener on TCP/445. No authentication, no valid share access, and no user interaction are required. An attacker sends crafted SMB requests and parses the returned responses for leaked kernel memory.
• Impact chain for defenders to model: (1) unauthenticated leak of kernel memory → (2) recovery of sensitive data in-flight or kernel pointer disclosure → (3) KASLR defeat → (4) dramatically improved reliability of a subsequent memory-corruption exploit against the same host. Do not treat 'information disclosure only' as low urgency at CVSS 9.3 — ZDI scored it there precisely because of what it enables.

Exploitation Status

At the time of writing, ZDI has published the advisory; there is no confirmed in-the-wild exploitation and no CISA KEV listing associated with ZDI-26-573 yet. That is the window. Historical precedent with in-kernel SMB flaws is clear: once technical details circulate, weaponization follows quickly because the protocol parser is deterministic and remotely reachable. Treat this as patch-now, not patch-soon.

Detection & Response

Because the vulnerability is triggered inside the kernel by crafted SMB traffic, the highest-fidelity defensive signals are: (a) inventorying which hosts have ksmbd loaded at all, and (b) watching for anomalous connection behavior against port 445 on those hosts — high-rate unauthenticated session setups from single sources, or 445 connections from hosts that have no business initiating SMB sessions. Note that standard EDR network telemetry often under-reports in-kernel listeners, which is why the bash audit and Velociraptor hunt below check the kernel module state directly.

---
title: KSMBD Kernel Module Load or Configuration Activity
id: 3f9a2c71-8b4e-4d56-a1c9-2e7f5b8d1034
status: experimental
description: Detects loading of the ksmbd in-kernel SMB server module or execution of ksmbd management tools, identifying systems exposed to ZDI-26-573.
references:
  - http://www.zerodayinitiative.com/advisories/ZDI-26-573/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.exploitation
  - attack.t1210
logsource:
  category: process_creation
  product: linux
detection:
  selection_modprobe:
    Image|endswith:
      - '/modprobe'
      - '/insmod'
    CommandLine|contains: 'ksmbd'
  selection_tools:
    Image|endswith:
      - '/ksmbd.mountd'
      - '/ksmbd.adduser'
      - '/ksmbd.control'
  condition: 1 of selection_*
falsepositives:
  - Legitimate NAS or file-server administration enabling ksmbd intentionally
level: medium
---
title: High-Rate Unauthenticated SMB Session Attempts Against Linux Host
id: 8c1d4e62-5a37-4f98-b2d4-6c9a1f3e7058
status: experimental
description: Detects bursts of SMB session setup traffic to Linux-hosted port 445 from a single external or untrusted source, consistent with probing or exploitation attempts against ksmbd (ZDI-26-573).
references:
  - http://www.zerodayinitiative.com/advisories/ZDI-26-573/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.exploitation
  - attack.t1190
logsource:
  category: firewall
  product: linux
detection:
  selection:
    DestinationPort: 445
    Initiated: 'true'
  filter_known:
    SourceIp|cidr:
      - '10.0.0.0/8'
      - '172.16.0.0/12'
      - '192.168.0.0/16'
  condition: selection and not filter_known
falsepositives:
  - Misconfigured scanners or load balancer health checks from unexpected segments
level: high
---
title: Kernel Error or Oops Referencing KSMBD Worker
id: a27e5b90-4c61-4d83-9f1e-3b8c7a2d9516
status: experimental
description: Detects kernel log entries indicating faults, oops, or BUG reports tied to ksmbd worker threads, which may indicate failed or successful exploitation attempts causing memory access violations.
references:
  - http://www.zerodayinitiative.com/advisories/ZDI-26-573/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.exploitation
  - attack.t1210
logsource:
  service: kern
  product: linux
detection:
  selection:
    Message|contains:
      - 'ksmbd'
    Message|contains:
      - 'BUG:'
      - 'Oops'
      - 'general protection fault'
      - 'KASAN'
      - 'out-of-bounds'
  condition: all of selection*
falsepositives:
  - Kernel debugging or KASAN-enabled test builds
level: critical

// Hunt: external/untrusted sources initiating SMB sessions to Linux hosts (Syslog/CEF via Sentinel)
// Scope: identify potential probing or exploitation of ksmbd exposed on TCP/445 (ZDI-26-573)
let Window = 15m;
CommonSecurityLog
| where TimeGenerated > ago(24h)
| where DestinationPort == 445
| where DeviceVendor != "Microsoft" or DeviceProduct !contains "Windows"
| summarize ConnectionCount = count(), DistinctTargets = dcount(DestinationIP), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
    by SourceIP, bin(TimeGenerated, Window)
| where ConnectionCount > 50
| project TimeGenerated, SourceIP, ConnectionCount, DistinctTargets, FirstSeen, LastSeen
| order by ConnectionCount desc;

// Companion: kernel logs surfacing ksmbd faults (KASAN/oops) indicating attempted memory corruption
Syslog
| where TimeGenerated > ago(24h)
| where Facility == "kern"
| where SyslogMessage has_any ("ksmbd", "kworker") and SyslogMessage has_any ("BUG", "Oops", "general protection fault", "KASAN", "out-of-bounds")
| project TimeGenerated, Computer, SyslogMessage
| order by TimeGenerated desc;

// Companion: inventory hosts where ksmbd module load activity was observed
Syslog
| where TimeGenerated > ago(7d)
| where SyslogMessage has "ksmbd" and SyslogMessage has_any ("module", "loaded")
| summarize by Computer, SyslogMessage, TimeGenerated;

-- Hunt: identify endpoints with the ksmbd kernel module loaded and active
-- SMB listeners on TCP/445, per ZDI-26-573 exposure scoping
-- Artifact: check module state, listener ownership, and ksmbd worker threads

SELECT Pid, Name, CommandLine, Username, Status
FROM pslist()
WHERE Name =~ 'ksmbd'
   OR CommandLine =~ 'ksmbd'

// Companion: netstat view for port 445 listeners on Linux endpoints
SELECT Pid, Name, LocalAddress, LocalPort, RemoteAddress, RemotePort, Status
FROM netstat()
WHERE LocalPort == 445
   OR LocalPort == 139

#!/bin/bash
# ZDI-26-573 KSMBD Exposure Audit and Hardening Script
# Run as root on candidate Linux hosts. Audits ksmbd presence and optionally disables it.

echo "=== KSMBD Exposure Audit (ZDI-26-573) ==="
echo "Hostname: $(hostname) | Kernel: $(uname -r)"
echo

# 1. Check if ksmbd module is currently loaded
if lsmod | grep -q '^ksmbd'; then
    echo "[ALERT] ksmbd kernel module IS LOADED — system is potentially vulnerable"
    lsmod | grep '^ksmbd'
    VULN=1
else
    echo "[OK] ksmbd module not currently loaded"
fi

# 2. Check if ksmbd is configured to load at boot
echo
echo "--- Boot-time configuration check ---"
grep -rEi 'ksmbd' /etc/modules /etc/modules-load.d/ /etc/modprobe.d/ 2>/dev/null || echo "[OK] No boot-time ksmbd load directives found"

# 3. Check for ksmbd userspace tools (indicates intentional deployment)
echo
echo "--- Userspace tooling check ---"
for tool in ksmbd.mountd ksmbd.adduser ksmbd.control; do
    command -v "$tool" >/dev/null 2>&1 && echo "[INFO] Found: $tool ($(command -v $tool))"
done
ls /etc/ksmbd/ 2>/dev/null && echo "[INFO] ksmbd configuration directory present"

# 4. Verify listener on 445 belongs to kernel (ksmbd) vs userspace smbd
echo
echo "--- Port 445 listener check ---"
if ss -tlnp 2>/dev/null | grep -q ':445'; then
    ss -tlnp | grep ':445'
    echo "[NOTE] If no process name appears above, the listener is IN-KERNEL (ksmbd)"
else
    echo "[OK] No SMB listener detected on TCP/445"
fi

# 5. OPTIONAL HARDENING — uncomment to disable ksmbd until patched
# WARNING: This will terminate in-kernel SMB service. Confirm no production shares depend on ksmbd.
#
# echo "--- Disabling ksmbd ---"
# systemctl stop ksmbd 2>/dev/null || true
# rmmod ksmbd 2>/dev/null && echo "[DONE] ksmbd module unloaded"
# echo 'install ksmbd /bin/true' > /etc/modprobe.d/disable-ksmbd.conf
# echo 'blacklist ksmbd' >> /etc/modprobe.d/disable-ksmbd.conf
# echo "[DONE] ksmbd blacklisted at boot — remove /etc/modprobe.d/disable-ksmbd.conf after patching"

# 6. Post-patch verification helper: confirm kernel version after update
echo
echo "--- Post-patch verification ---"
echo "After applying your vendor kernel update, reboot and re-run this script."
echo "Expected: '[OK] ksmbd module not currently loaded' OR vendor-fixed kernel version in 'uname -r'."

exit ${VULN:-0}

Remediation

Act in this order. The audit script above accelerates steps 1 and 4.

1. Inventory exposure immediately (today). Identify every Linux host with ksmbd loaded: lsmod | grep ksmbd, check for port-445 listeners with no owning userspace process, and query appliance/NAS vendors directly — many embedded platforms enable ksmbd silently. Do not trust EDR service inventories alone.

2. Apply vendor kernel patches as they ship. ZDI coordinated disclosure with the Linux kernel maintainers; fixed kernels will land through distribution channels (Red Hat, Ubuntu, SUSE, Debian, and appliance vendors). Track the ZDI-26-573 advisory for the CVE mapping and patch references, and subscribe to your distribution's security-announce list. Reboot into the fixed kernel — a kernel patch without reboot provides zero protection.

3. If you cannot patch yet, remove the attack surface.

   • If ksmbd is not business-critical: unload it (rmmod ksmbd) and blacklist it via /etc/modprobe.d/ so it cannot reload at boot (commands in the script above).
   • If SMB service is required: migrate file serving to userspace Samba (smbd), which is not affected by this flaw, until a patched kernel is deployed.
   • If ksmbd must remain: restrict TCP/445 with host firewall rules (nftables/iptables security groups) to only the specific trusted subnets that legitimately consume those shares. The vulnerability requires network reachability — deny it.

4. Validate the fix. After patching and rebooting, confirm the kernel version matches your vendor's fixed release, confirm ksmbd (if re-enabled) is the patched build, and run the detection rules above against historical logs to check whether probing occurred while you were exposed. Any host showing ksmbd-related kernel faults (BUG, Oops, KASAN) prior to patching warrants a memory forensics review — treat unexplained kernel faults on an exposed SMB server as a potential compromise indicator, not noise.

5. Watch for the follow-on. Monitor CISA KEV, your distro tracker, and ZDI for the CVE assignment and any exploitation reports. If this bug is weaponized — and unauthenticated kernel info-leaks on port 445 historically do get weaponized — expect it to be chained with a memory-corruption primitive. Your window to patch quietly is right now.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub