Unpatched KSMBD Bugs Hit Public Kernel Lists: What It Means for You

On October 22 (Manila time), Trend Micro's Zero Day Initiative (ZDI) sent a batch of Linux kernel vulnerability reports to the kernel security team, as it should. The problem was the CC line. The same reports went to public mailing lists, including linux-kernel and linux-cifs, with full technical detail and reproducers, and with no patches attached.

Two of them carry a CVSS score of 9.0 and target KSMBD, the SMB3 file server that lives inside the Linux kernel. That sounds alarming. For most Linux machines, it is not. Here is what was actually posted, what the maintainers said, and how to check your own systems in a minute.

What was posted

• ZDI-CAN-33549: "Linux Kernel KSMBD SMB Direct Integer Underflow Remote Code Execution Vulnerability," CVSS 9.0 (AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H). The bug is an integer underflow in smbdirect_connection_rdma_xmit(). The report lists three requirements: an RDMA device, a writable share, and SMB Direct. ZDI reproduced it on kernel 7.3-rc3 built with CONFIG_SMB_SERVER_SMBDIRECT=y, using the software RDMA driver (CONFIG_RDMA_RXE=y) and a guest share.
• ZDI-CAN-33774: "Linux Kernel KSMBD Protocol Dispatch Race Condition Remote Code Execution Vulnerability," also CVSS 9.0 with the same vector. Per the report, a 40-byte SMB1 buffer can be parsed as a 64-byte SMB2 header, leaking 28 bytes of heap in an error reply, and there is also a path to an out-of-bounds write. In ZDI's words: "The trigger requires race and guest share." Also tested on 7.3-rc3.

Neither report has a CVE ID yet. Both appear on ZDI's upcoming advisories list under these tracking IDs. The same batch included reports for other kernel areas (networking, the VMware graphics driver, the NVMe target), which are local issues and not the focus here.

Greg Kroah-Hartman was not amused

Greg Kroah-Hartman, the stable kernel maintainer, answered several of the reports on the list within minutes. To the VMware graphics report he wrote: "For some reason you sent this to public lists, and did not include a patch, so there's not much we can do with this." On the NVMe target report: "Again, no patch, and sent to a public list? Please fix your submission process..." And on ZDI-CAN-33774, the KSMBD race: "And again, no patch, and a public list?"

His point is fair. Kernel security reports normally reach maintainers privately so a fix can land before the details go public. Publishing a detailed report without a patch gives attackers a head start and gives defenders nothing to install.

Are there fixes?

Not in a released kernel yet, as far as I can see, but the maintainers were not starting from zero:

• ZDI-CAN-33774: KSMBD maintainer Namjae Jeon replied that "This issue has already been fixed," pointing to commit 68f410faedaf ("ksmbd: wait for negotiation before receiving another PDU"), dated September 30, 2026, in his ksmbd tree for the next merge window.
• ZDI-CAN-33549: Stefan Metzmacher asked ZDI to retest on his for-7.5/smbdirect branch, writing: "I guess it's already fixed with that." That is a likely fix, not a confirmed one.

Until these reach your distribution's kernel, treat both as unpatched on running systems.

Why the exposure is narrow

• KSMBD only. This is not "all Linux." Only hosts running the in-kernel SMB server are in scope.
• Guest shares. Both reproducers use a guest-accessible share.
• RDMA for 33549. The SMB Direct bug also needs SMB Direct support in the kernel and an RDMA device. No RDMA, no exposure to that one.
• No reported exploitation. I found no report of either bug being exploited in the wild, and no public exploit beyond the reproducers in ZDI's own reports.

Are you affected?

Run these on each Linux server, NAS, or appliance where you have shell access:

Who is listening on 445?

ss -ltnp | grep ':445'

Do you have RDMA devices? (relevant to ZDI-CAN-33549)

ls /sys/class/infiniband 2>/dev/null

Is it built into your kernel, and with SMB Direct?

grep -E 'CONFIG_SMB_SERVER(_SMBDIRECT)?=' /boot/config-$(uname -r)

Is the KSMBD userspace daemon running? KSMBD does not serve shares until ksmbd.mountd (from ksmbd-tools) starts it.

systemctl status ksmbd
pgrep -a ksmbd.mountd

Is the KSMBD module loaded?

lsmod | grep ksmbd

No output means it is not loaded.

What to do if you run KSMBD

• If you need it, drop guest access. Remove guest ok = yes from shares and map to guest = bad user from [global] in /etc/ksmbd/ksmbd.conf, then restart the service.
• Keep TCP 445 off the internet. Block it at the edge and allow it only from the networks that need file sharing.
• Watch your distribution's kernel updates for the fixes above, and for CVE IDs once they are assigned.

Turn it off if you do not need it:

sudo systemctl disable --now ksmbd
sudo modprobe -r ksmbd
echo 'install ksmbd /bin/false' | sudo tee /etc/modprobe.d/disable-ksmbd.conf

My take

The disclosure was sloppy, and the kernel's maintainers said so publicly. But the headline score oversells the risk for most people. If you never set up the in-kernel SMB server, you can stop worrying. If you did, especially with guest shares, spend five minutes on the checks above today.

Sources: ZDI reports on lore.kernel.org (ZDI-CAN-33549, ZDI-CAN-33774), Greg Kroah-Hartman's replies (1, 2, 3), ksmbd fix commit 68f410faedaf, for-7.5/smbdirect branch, ZDI upcoming advisories. First reported by Phoronix.