Two CVSS 9.0 RCE flaws in KSMBD go public before any Linux kernel fix exists
On October 22, 2026, two remote code execution flaws rated CVSS 9.0 by Trend Micro’s Zero Day Initiative affect KSMBD, the SMB server built into the Linux kernel, with no fix in the mainline kernel. One triggers before any network authentication on port 445: check now whether the module is loaded on your servers.
October 22, 2026. Two remote code execution flaws rated CVSS 9.0 by Trend Micro’s Zero Day Initiative affect KSMBD, the SMB server built into the Linux kernel. October 22, 2026. No fix exists yet in the mainline kernel or in linux-next. October 22, 2026. One of the two flaws triggers before any network authentication, on port 445. Why it matters: kernel bugs found by AI tools are now being dumped on public lists without a patch — and defenders must learn to live with disclosure windows that no longer protect anyone.
Two flaws, one exploitable without authentication
The two flaws are tracked by ZDI as ZDI-CAN-33774 and ZDI-CAN-33549. The more serious, ZDI-CAN-33774, requires no authentication: it exposes any server running KSMBD on port 445.
The defect is a race in how KSMBD assigns its handler table. A burst of short SMB1 packets followed by an SMB2 packet in the same TCP write causes workers to handle SMB1 data with an SMB2 handler, reading past the end of the shorter buffer. A path to writing past the buffer also exists once an attacker has access to a share. The second, ZDI-CAN-33549, is an integer underflow in the SMB Direct path: a client supplies RDMA buffer descriptors in which the first is longer than the declared payload, causing the server’s size counter to wrap and letting a subsequent memory copy overrun an allocated buffer. It requires three things: an RDMA interface (hardware or the rxe software driver), a writable KSMBD share, and a client negotiating SMB Direct.
Neither flaw has a named fix in the mainline kernel as of October 22. Phoronix reports that Stefan Metzmacher, the SMB Direct maintainer, submitted a fix for ZDI-CAN-33549 targeting the next development cycle, though this is unconfirmed elsewhere. And neither flaw has a CVE identifier yet: the kernel project assigns one only after a fix lands in a stable tree. That is the first piece of the problem — a public vulnerability with no CVE and no fix is hard to track in an inventory that indexes everything by CVE.
Disclosure ran ahead of the fix, and that was a choice
This is not just two bugs: it exposes a strain in how AI-discovered flaws enter the kernel’s disclosure process. The ZDI reports credit TrendAI, Trend Micro’s AI scanner, as the finder. The Linux kernel’s security documentation, updated in May 2026 following guidance from Linus Torvalds, states that bugs found by AI tools are, by definition, already public and should be sent to subsystem developer lists.
ZDI followed that logic: it copied public mailing lists alongside the private kernel security address, without attaching a patch to any of the reports. Greg Kroah-Hartman, the stable-branch maintainer, replied to three of the five kernel reports within minutes. On the VMware GPU driver report: “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 driver report, seventeen seconds later: “Again, no patch, and sent to a public list? Please fix your submission process.”
The consequence is concrete for anyone running KSMBD: two 9.0-rated RCEs are public, neither has a fix, and promotion to stable branches and then distribution kernels will take “weeks” once a patch is written. Until then, the only defense is to shrink the exposure.
What you should check right now
Two commands tell you whether you are exposed. systemctl status ksmbd confirms whether the service is active, and lsmod | grep ksmbd whether the module is loaded. Red Hat Enterprise Linux does not ship KSMBD by default, per Red Hat’s support documentation — but distributions that enable it, often to expose lightweight SMB shares without Samba, do so precisely on port 445, the target of ZDI-CAN-33774.
The exact blast radius is worth knowing. ZDI-CAN-33774 requires no authentication, but its write-past-the-buffer path assumes access to a share; the read path stops at an out-of-bounds read. ZDI-CAN-33549 requires SMB Direct, hence an RDMA interface and a specific negotiation — a rarer subset, but present in storage clusters and high-performance environments. Either way, if you do not need KSMBD, disable it: that is the only immediate mitigation against a flaw with no fix.
The five ZDI kernel reports are not all SMB-related. ZDI-CAN-33367, discovered by researcher p1r0x, is a local privilege escalation in the networking stack; ZDI-CAN-34068 a local escalation in the VMware GPU driver; ZDI-CAN-34076 an information disclosure in the NVMe target; ZDI-CAN-32005 a buffer overflow in ConnMan. They share the same procedural defect: public reports, no patch, leaving operators with no lever.
Assessing SMB Direct exposure is worth two more commands. lsmod | grep rxe tells you whether the software RDMA driver is loaded, and rdma link show lists RDMA-capable interfaces — the prerequisites for ZDI-CAN-33549. In practice the pre-authentication flaw is the one to fear most: any host with KSMBD bound to a reachable port 445 is in scope for ZDI-CAN-33774, regardless of whether it exposes writable shares. A quick scan of your own CIDR ranges for open 445 — nmap -p 445 --open — is the fastest way to find servers you forgot were still running the module.
The disclosure policy for AI-found bugs is broken
The friction is visible in the exchanges: ZDI applies a literal reading of the May 2026 guidance — a bug found by an AI tool is public by definition, so it goes to public lists — while the kernel still expects a patch to exist before an exploitable flaw becomes public. The result is the worst of both worlds: the flaw is public, but the fix does not exist.
Greg Kroah-Hartman’s frustration targets precisely that imbalance. A report sent to a public list without a patch gives maintainers “not much” to work with: they learn of the flaw at the same time as attackers, without the patch that would let them fix it before the rush. Historically, the [email protected] process exists so that the patch is written before publication — that is the mechanism that was bypassed here.
For an operator, the consequence is an inversion of roles. Until now, watching for vulnerabilities meant tracking CVEs published after a fix and planning updates. With public flaws that have no fix and no CVE, watching must move one level up: follow public lists, ZDI reports and discussion threads, and anticipate mitigation before the patch descends. That is a shift in posture — from planned updates to configuration-based defense — that the community has not yet absorbed.
Verdict
If you do not use KSMBD, disable it now — systemctl disable --now ksmbd — and close port 445 at the firewall. That is the only mitigation available against a pre-authentication RCE with no fix. If you need SMB shares, prefer userspace Samba, which is unaffected by these kernel-module flaws, or strictly segment access to port 445 until the patch arrives, then apply it as soon as it reaches your distribution — these fixes will take weeks to descend. If you track the kernel, absorb the new fact: the line between “private discovery” and “public disclosure” has shifted for AI-found bugs, and the time between publication and fix, once near zero for serious flaws, is now an open interval you must cover with configuration. The lesson echoes our analyses of kernel hardening: default mitigations matter as much as the patch, because the patch can arrive too late.