As reported by The Hacker News, two critical remote code execution vulnerabilities in Linux's KSMBD kernel subsystem have been disclosed on public mailing lists before any fix exists in the mainline kernel. Trend Micro's Zero Day Initiative rated both at CVSS 9.0. Neither has a CVE identifier yet, and no patch has landed in mainline or stable branches.

Security Impact: As reported by The Hacker News, two critical remote code execution vulnerabilities in Linux's KSMBD kernel subsystem have been disclosed on public mailing lists before any fix exists in the mainline kernel.

This is a textbook example of a vulnerability window: the details are public, exploit paths are documented, and defenders have no vendor-issued fix to deploy. The pre-auth nature of ZDI-CAN-33774 makes this particularly urgent for any organization running KSMBD on an internet-facing or even internal-facing port 445.

Vulnerability Summary

FieldZDI-CAN-33774ZDI-CAN-33549
CVSS9.0 (Critical)9.0 (Critical)
Authentication RequiredNoYes (requires share access)
TriggerBurst of SMB1 packets + SMB2 in same TCP write causes handler table raceInteger underflow in SMB Direct RDMA buffer handling
RequirementsKSMBD running on port 445RDMA-capable interface, writable share, SMB Direct negotiation
CVE AssignedNoNo
Patch AvailableNoNo (fix submitted to next dev cycle, unconfirmed)
Active ExploitationNot yet observedNot yet observed

Who Is at Risk

Vulnerability Summary
NAS appliances and custom Linux file servers running KSMBD as a high-performance SMB backend — these are the primary attack surface.
Environments with RDMA-capable networking (HPC, storage clusters, datacenter fabrics using InfiniBand or rxe soft-RDMA) are exposed to ZDI-CAN-33549.
Cloud and on-prem servers where KSMBD was enabled as a lightweight alternative to Samba's userspace SMB daemon.
RHEL and derivatives are not affected by default — KSMBD is not included in Red Hat's kernel builds. Check your distribution's kernel config to confirm.

The most dangerous aspect of ZDI-CAN-33774 is that it requires no credentials. Any host that can reach port 445 on a KSMBD-enabled server is a potential attacker. In segmented networks this is manageable; in flat or cloud environments with permissive security groups, it is not.

Broader Implications: AI-Driven Disclosure and the Public List Problem

The Linux kernel's May 2026 policy update, prompted by Linus Torvalds, effectively declares that bugs found by AI tools are already public and should be routed to developer mailing lists rather than held under embargo. This was a pragmatic response to the volume of AI-discovered bugs, but it shifts the burden sharply toward defenders. Stable-kernel maintainer Greg Kroah-Hartman's response underscores the gap: reports without patches on public lists leave maintainers with little to act on immediately.

We should expect more of this. AI fuzzing tools like TrendAI are scaling vulnerability discovery faster than the kernel community can patch. Organizations that depend on kernel subsystems with small maintainer teams — KSMBD, niche drivers, filesystem modules — face a structural exposure that traditional patch cycles were not designed for.

Shield53 Recommendations: Immediate Actions

1. Determine Exposure

  • Run systemctl status ksmbd and lsmod | grep ksmbd on all Linux hosts.
  • Check kernel config: zcat /proc/config.gz | grep CONFIG_SMB_SERVER. If the option is not set, KSMBD is not compiled in.
  • Inventory any appliance, NAS, or embedded Linux device that may ship KSMBD enabled by default.

2. Contain

  • Disable KSMBD immediately if it is not a documented business requirement: systemctl stop ksmbd && systemctl disable ksmbd.
  • If KSMBD must run, restrict port 445 to a tight allowlist of source IPs at the firewall, host-level iptables/nftables, and cloud security group layers.
  • For ZDI-CAN-33549 specifically, disable SMB Direct / RDMA transports if not required, removing the prerequisite attack path.
  • Block SMB1 protocol negotiation if your KSMBD configuration allows it — this is the trigger vector for ZDI-CAN-33774.

3. Detect

  • Monitor for anomalous SMB1 traffic to KSMBD hosts. The exploit signature involves a burst of short SMB1 packets followed by SMB2 in the same TCP session — this pattern is unusual in modern environments.
  • Alert on SMB Direct negotiation attempts from unexpected hosts.
  • Log and alert on any ksmbd process crashes or OOM kills, which may indicate exploitation attempts.

4. Plan for the Patch

  • Subscribe to your distribution's kernel security advisory feed. Once a fix lands in mainline, it will take additional weeks to reach stable branches and distribution kernels.
  • For critical environments, consider compiling a patched kernel from mainline once the fix is merged, but only after thorough testing.
  • Track ZDI advisory pages for CVE assignment and patch confirmation.

5. Reconsider Architecture

  • If you are using KSMBD purely for performance, evaluate whether Samba's userspace daemon with its mature security track record and faster patch pipeline is a safer trade-off for your threat model.
  • For internal file sharing, consider NFSv4 with Kerberos where feasible, reducing SMB attack surface entirely.

The combination of pre-auth exploitation, public disclosure, and no available patch makes this a high-priority exposure for any organization running KSMBD. The window between disclosure and patch availability is the entire risk period — treat containment as your primary control, not patching.