Two remote code execution flaws in KSMBD, the SMB server built into the Linux kernel, were published on the kernel mailing lists on 21 and 22 October with no fix in mainline and no CVE identifier assigned.
What happened
Trend Micro's Zero Day Initiative rated both 9.0 and sent the reports with public lists copied alongside the private kernel security address, without patches attached. The more serious one, ZDI-CAN-33774, needs no authentication and is reachable on TCP port 445 on any host running KSMBD. It is a race in how KSMBD assigns its protocol handler table: a burst of short SMB1 packets followed by an SMB2 packet in the same TCP write can make a worker process SMB1 data with an SMB2 handler, which reads past the end of the shorter buffer. A write-past-buffer path exists once the attacker has access to a share.
The second, ZDI-CAN-33549, is an integer underflow in the SMB Direct path where a length counter wraps and a later memory copy overruns its buffer. It needs an RDMA-capable interface, a writable share and a client that negotiates SMB Direct, so far fewer hosts qualify. The fix for the dispatch race is commit 68f410faedaf in the KSMBD maintainer tree, not in mainline or linux-next. The kernel project assigns CVEs only once a fix lands in a stable tree, so vulnerability scanners keyed on CVE identifiers will not flag either bug. No active exploitation has been reported.
Who is affected
- Any Linux host with the ksmbd module loaded and TCP 445 reachable, no credentials required for the dispatch flaw.
- NAS appliances and ARM boards whose firmware ships the in-kernel SMB server, where it often arrives enabled and undocumented.
- Custom kernels built with CONFIG_SMB_SERVER, and hosts with SMB Direct plus an RDMA device for the second flaw.
- Not affected: anything running Samba, which is userspace and shares no code with KSMBD. Red Hat does not ship ksmbd in RHEL, and ksmbd is off by default upstream.
What to do now
Inventory every host with ksmbd running and close port 445 to untrusted networks before you do anything else, because there is no patch to apply.
- Check with systemctl status ksmbd, systemctl is-active ksmbd and lsmod | grep ksmbd. Also grep for CONFIG_SMB_SERVER in /boot/config-$(uname -r).
- Where the in-kernel server is not needed, stop the service, run modprobe -r ksmbd and blacklist the module so it does not return on reboot.
- Block inbound TCP 445 at the perimeter and the host firewall. Do not expose SMB to the internet, and do not rely on a share password as the control.
- Remove guest-accessible shares, and leave SMB Direct disabled unless the network genuinely depends on RDMA.
- Watch your distribution's security tracker for the backported fix. A CVE-based scan will stay silent until then.
What this means for South African businesses
KSMBD is not a product anyone chooses deliberately, and that is the risk: it turns up inside a NAS firmware image or a small Linux file server someone set up years ago. Most South African SMEs run Samba or a Windows file server and are not exposed at all, so this is not a panic item. Where it does apply, though, the host is unpatched with reproduction detail already public and no vendor date to wait for, which is a worse position than a normal patch cycle.
Source: The Hacker News, two CVSS 9.0 Linux KSMBD RCE flaws disclosed before kernel fixes.
Also on the blog
Next step: If this is on your network or a client's, ask Matthews Enterprises to check exposure.