Two remote code execution flaws in the Linux kernel’s in-kernel SMB server, KSMBD, became public on October 22, 2026 before the kernel had a fix. Trend Micro’s Zero Day Initiative (ZDI) rated both CVSS 9.0. As of this writing neither has a mainline fix, and no CVE identifiers have been assigned.

How it leaked

ZDI sent a batch of vulnerability reports to the public Linux kernel mailing list instead of the private kernel security list. The batch covered six unpatched kernel issues, and two of them are the KSMBD RCEs. The kernel project assigns CVEs only after a fix lands in a stable tree, so these are currently tracked only by ZDI’s internal identifiers.

The two flaws

ZDI-CAN-33774 is the one to worry about. It is a race condition that mixes SMB1 and SMB2 handling on a single connection and can lead to an out-of-bounds read past the end of a buffer. Per ZDI’s analysis it can be triggered before network authentication, so any host running KSMBD and reachable on TCP/445 is exposed. ZDI rates it CVSS 9.0.

ZDI-CAN-33549 is an integer underflow in the SMB Direct path. Exploiting it needs an RDMA-capable interface, a writable share, and a client negotiating SMB Direct. SMB Direct support is a separate kernel build option that is off by default, which narrows the exposed population considerably. Phoronix reported that a fix is already sitting in a Git branch aimed at the Linux 7.5 cycle and will likely be fast-tracked.

Impact

KSMBD runs in kernel space, so a successful exploit yields kernel-level code execution rather than a sandboxed daemon compromise. That is the reason for the high score despite the “complex attack” conditions around the race.

Real-world exposure is limited by deployment habits. Most production Linux file servers use userspace Samba, not KSMBD. KSMBD is more common on NAS appliances, embedded devices, and lightweight file-sharing setups where the kernel module was chosen for performance. Inventory is the first problem: many admins will not know whether the module is loaded.

There is no evidence of exploitation in the wild so far. However, the reports are public, they describe the bug locations, and kernel race conditions in SMB parsers have a history of getting working exploits quickly once details circulate. Treat the window before a patch as the dangerous one.

What to do now

  1. Find out whether you run KSMBD. Check lsmod | grep ksmbd, look for the ksmbd kernel thread and ksmbd.mountd user helper, and review NAS and appliance firmware that bundles it.
  2. Block TCP/445 (and RDMA SMB Direct ports) at the network edge and restrict it to trusted segments internally. Do not expose KSMBD to the internet.
  3. If you do not need it, unload the module (modprobe -r ksmbd) and blacklist it until fixes ship.
  4. Switch to userspace Samba where in-kernel SMB was not a hard requirement.
  5. Watch the stable kernel trees and your distribution advisories. CVEs should appear once fixes are merged; track them then and update your vulnerability scanners.
  6. For custom kernels, confirm CONFIG_SMB_SERVER_SMBDIRECT is unset unless you need it.

Sources