Bug reports for two remote code execution flaws in the Linux kernel's built-in SMB file server, KSMBD, ended up on public kernel mailing lists this week. Neither had a patch in the mainline kernel when it appeared. Both reports came from Trend Micro's Zero Day Initiative (ZDI), and each is rated 9.0 on the CVSS severity scale. One can be reached by an attacker who has no credentials at all.
No CVE numbers have been assigned, and neither source reports exploitation in the wild. Still, admins now face a familiar disclosure problem: the technical description is public and the fix isn't.
What Was Disclosed
KSMBD is an SMB3 file server that runs inside the Linux kernel. SMB (Server Message Block) is the protocol Windows file sharing uses. The more familiar Samba runs in user space, but KSMBD handles file-sharing requests in kernel space, mostly for speed. That design also means a memory-safety bug in KSMBD is a kernel bug, and in the worst case it gives an attacker kernel-level code execution.
According to The Hacker News, the two reports are:
- ZDI-CAN-33774: a race condition in how KSMBD assigns its request handlers. A race condition is a bug where the outcome depends on the timing of two operations running at once. An attacker who wins that timing can drive the code into a state its authors never expected. The Hacker News reports that this flaw needs no authentication: any reachable KSMBD instance on port 445, the standard SMB port, is exposed.
- ZDI-CAN-33549: an integer underflow in KSMBD's SMB Direct code. An integer underflow happens when a subtraction wraps a number around to a huge value, which can lead the kernel to mishandle memory. SMB Direct is the variant of SMB that runs over RDMA (remote direct memory access), a high-speed networking technology found mainly in data centers and storage clusters. The Hacker News says exploiting this bug requires an RDMA-capable interface, a writable KSMBD share and a client negotiating SMB Direct, which makes it much narrower than the first.
Phoronix says the batch included more than the two KSMBD bugs. It also listed a local privilege escalation in skb_zerocopy (part of the kernel's networking stack), a local privilege escalation in vmwgfx (the graphics driver for VMware virtual machines), and an information disclosure bug in nvmet, the kernel's NVMe-over-Fabrics target. "Local" means an attacker already needs some foothold on the machine. These are serious, but none is the unauthenticated network exposure that makes ZDI-CAN-33774 stand out.
Why There Is No Patch or CVE Yet
Patch status varies by bug, and the two sources describe it slightly differently. The Hacker News reported on October 22 that neither KSMBD flaw had a named fix in mainline or in linux-next, the integration tree that feeds the mainline kernel. Phoronix reported the same day that a patch for ZDI-CAN-33549, the SMB Direct underflow, sits in a Git branch of code intended for Linux v7.5. Both can be true: a fix that exists in a maintainer's branch has not yet been merged into mainline or shipped in a stable kernel. The Hacker News also notes that fixes to mainline typically take weeks to reach stable branches and distribution kernels.
Neither source reports a fix in any form for ZDI-CAN-33774, the unauthenticated race.
The missing CVE numbers are expected. As The Hacker News explains, the kernel project assigns CVE identifiers only after a fix is available in a stable tree. Until then, the ZDI-CAN tracking numbers are the only names these bugs have, so tools that key only on CVE IDs may not flag them yet.
Wrong List, or the Right One?
The disclosure set off an argument about process. Phoronix describes the reports as posted to the public Linux Kernel Mailing List (LKML) rather than the typical private security mailing list, and says it seemed to be a mistake. The Hacker News reports that ZDI also copied the private kernel security address, and that stable kernel maintainer Greg Kroah-Hartman, replying to some of the reports, objected to their being sent to public lists without patches.
The kernel project's own rules make the picture more complicated. The Hacker News says the bugs were credited to TrendAI, Trend Micro's AI scanner. The kernel's security bugs documentation says that if you used AI assistance to identify a bug, you must treat it as public, and that a public list is acceptable for issues found with AI-based tools. It also says not to share a reproducer, the input or program that triggers the bug, publicly; reporters should just mention that one is available, and maintainers may ask for it privately.
So the public posting may have been less of an accident than the first headlines suggested. The Hacker News says ZDI's routing appeared to follow that policy logic. The objection is to timing and context: these were high-severity remote bugs, posted without patches. The episode shows the tension in a policy built for a growing flood of automated findings. It treats many of them as public by default, and that includes the rare ones that turn out to be critical.
Who Is Actually Exposed
Most Linux systems are probably unaffected in practice. KSMBD is optional, and many organizations that serve SMB from Linux use Samba instead. The Hacker News notes that, according to Red Hat's support documentation, Red Hat Enterprise Linux does not include KSMBD by default.
The systems to worry about are the ones where someone deliberately turned KSMBD on. Any KSMBD instance that answers on port 445 is in scope for ZDI-CAN-33774. Only setups built around SMB Direct over RDMA, with a writable share, are exposed to ZDI-CAN-33549.
What It Means for Defenders
Find out whether you run KSMBD at all. This is the first step and the one that matters most. The Hacker News says that running systemctl status ksmbd or lsmod | grep ksmbd confirms whether the service and kernel module are active. If neither is present, these two bugs don't affect that machine. On RHEL, KSMBD is not included by default.
If you do run it, treat ZDI-CAN-33774 as urgent. It needs no authentication, and neither source reports a fix in any branch. The cleanest move is to stop and disable KSMBD on hosts that don't need it. Hosts that do need SMB serving could move to another SMB server until a patched kernel ships. Where KSMBD has to stay up, standard network hygiene applies: keep port 445 off the internet and limit it to the clients that actually need it. That reduces exposure but doesn't fix the bug.
Inventory your RDMA storage. ZDI-CAN-33549 only matters where SMB Direct runs over an RDMA-capable interface and a KSMBD share is writable. If that describes your environment, review who has write access to those shares. Then track the fix, which Phoronix says is in a branch intended for Linux v7.5, as it moves toward a stable release.
Don't wait for a CVE to show up in your scanner. These bugs won't have kernel CVE IDs until fixes reach stable trees. Track them by their ZDI-CAN numbers and watch your distribution's kernel updates and advisories for KSMBD fixes.
Federal contractors working through CMMC: a public, unpatched, critical-severity flaw on a system that handles controlled data belongs in your vulnerability tracking now, with the mitigation you chose recorded. "No CVE yet" doesn't count as a reason it was left off your records.
The other bugs in the batch (skb_zerocopy, vmwgfx and nvmet) are local privilege escalations or an information disclosure, according to the sources, and neither source says they affect KSMBD servers. Patch them through normal kernel updates as fixes ship, and give priority to multi-user hosts, VMware guests and NVMe-over-Fabrics targets.
As of the October 22 reports, neither source mentions exploitation. That could change faster than usual, because attackers can now read the bug descriptions.
