Close-up of programming code on a computer screen, illustrating the Linux kernel vulnerability disclosed as CVE-2026-31431

KSMBD RCE Reports Land on Public LKML

October 22, 2026 · 8 min read · By API User
Cybersecurity

Five Linux kernel vulnerability reports from Trend Micro’s Zero Day Initiative were sent to [email protected] with public mailing lists in Cc before fixes were available; a sixth ConnMan report went to a public ConnMan list. Two of the kernel issues are CVSS 9.0 KSMBD bugs: an SMB Direct integer underflow and a protocol-dispatch race. The public messages included reproducers, not just summaries.

Item Detail
Reports Five kernel issues and one ConnMan issue; ZDI-CAN IDs, no CVE identifiers yet
Worst cases KSMBD SMB Direct integer underflow and KSMBD protocol-dispatch race, both CVSS 9.0
Exposure KSMBD is optional. The race affects KSMBD on port 445 with a guest-accessible share; the SMB Direct bug also needs RDMA and a writable share.
Patch status No mainline fix for either KSMBD report; one branch patch exists for the SMB Direct bug
Disclosure issue Kernel reports were addressed to [email protected] but Cc’d public subsystem lists, with reproducers attached

What Happened

Sponsored

Tired of "file too large" and broken links when sending to the world and to China? Sesame Disk by NiHao Cloud Upload once, share anywhere — China,Logo Sesame Disk USA, Europe, APAC. Pay only for what you use.

 

 

 

ZDI sent the reports on Oct. 20 and Oct. 21. The kernel messages were addressed to [email protected] but copied public lists including linux-kernel, linux-cifs, netdev, and dri-devel. The ConnMan report went to the public ConnMan list. The messages are now indexed by LKML and lore, so the technical detail is public regardless of what happens next.

Phoronix described the routing as accidental. The headers show the public Cc, and Greg Kroah-Hartman’s replies focus on the practical result: the reports arrived without patches, on public lists. This was not a compromise of the private security address. It was a disclosure-path failure that put full reproducers in public before fixes.

ZDI’s upcoming-advisory page lists the same cases with scores. The reports themselves are the better source for preconditions and impact. Neither KSMBD issue has a CVE identifier yet.

The Two KSMBD RCEs

KSMBD is the Linux kernel’s in-tree SMB server, not the Samba user-space daemon. It is optional, but when loaded it listens on port 445 and serves shares. Both reports were tested against Linux 7.3-rc3.

ZDI ID Flaw CVSS Preconditions What the report shows
ZDI-CAN-33549 SMB Direct integer underflow 9.0 RDMA-capable interface, writable KSMBD share, SMB Direct negotiated A descriptor longer than the declared payload clamps the remaining length to zero, then subtracts again and wraps. A later copy overruns an allocation; the reproducer triggers an 8 KB KASAN out-of-bounds write in rxe_mr_copy.
ZDI-CAN-33774 Protocol-dispatch race 9.0 KSMBD reachable on port 445, guest-accessible share, race conn->ops is selected when work is queued but read when it runs. A queued SMB1 request can be handled by an SMB2 handler, parsing a 40-byte buffer as a 64-byte header. The report shows an out-of-bounds read and a path to an out-of-bounds write through smb2_set_info.
Sponsored


Logo Sesame DiskOne cloud drive your whole global team can actually access. Sesame Disk by NiHao Cloud From $4/mo — unlimited on-demand storage, no VPN required, even in China.

 

ZDI classes both as remote code execution and scores them 9.0 with high attack complexity, no privileges, and no user interaction. The public messages show reproducers that trigger the out-of-bounds conditions; the CVSS rating is an impact assessment, not a promise that every deployment has a reliable exploit chain.

The race is the broader problem. It requires no credentials, only a guest-accessible share and a reachable KSMBD service. The SMB Direct bug is narrower: an RDMA device or the rxe software driver, SMB Direct negotiation, and a writable share. Neither affects a Linux host that does not load KSMBD.

The Rest of the Batch

The two KSMBD reports are the headline, but they were part of a wider set. The others are not remote KSMBD bugs, and they should not be conflated with the SMB server exposure.

ZDI ID Subsystem Impact CVSS
ZDI-CAN-33367 Networking, skb_zerocopy Local privilege escalation through improper ownership management 7.8
ZDI-CAN-34068 VMware vmwgfx driver Local privilege escalation through an out-of-bounds write in dirty tracking 8.8
ZDI-CAN-34076 NVMe target, nvmet Information disclosure through use of an uninitialized resource in Get Log Page 8.6
ZDI-CAN-32005 ConnMan DNS proxy Local privilege escalation through a stack-based buffer overflow in search-domain TCP queries 7.8

ZDI-CAN-32005 is a ConnMan issue, not a kernel issue, and it was sent to the ConnMan list a day earlier. The other three are kernel reports: a local networking privilege escalation, a VMware graphics driver out-of-bounds write, and an NVMe target information leak. They matter to patch tracking, but they do not expose a KSMBD server by themselves.

Why the Reports Went Public

The kernel security guide allows reporters to send an issue to a public list when there is a good reason to consider it already public or trivial to discover. It names widely available automated scanners and AI-based tools as examples. That exception is not a blanket rule, but it explains why an AI-assisted report might land on a public list instead of staying private.

The 33549 message credits HYEONTAE LEE working with TrendAI Zero Day Initiative. The kernel’s security documentation was already dealing with a flood of AI-generated reports. Linus Torvalds described the volume as making the security list “almost entirely unmanageable,” with duplication from different people finding the same issues with the same tools, and said AI-detected bugs are “pretty much by definition not secret.”

But the same guide draws a line that matters here: because an AI report may be posted publicly, the reproducer should only be shared when maintainers ask for it. The 33549 message included a reproduction script and PoC source in the initial public post. That turned a public disclosure into a public exploitation aid before a fix existed.

Maintainers reacted to the missing patches, not just the missing embargo. Kroah-Hartman replied to the vmwgfx 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.” To the nvmet report: “Again, no patch, and sent to a public list? Please fix your submission process.”

For the SMB Direct bug, KSMBD maintainer Stefan Metzmacher pointed the reporter at a for-7.5/smbdirect branch and said he guessed it was already fixed there. That is a branch under test, not a mainline fix. The race report had no equivalent public fix identified.

Who Is Actually Exposed

KSMBD is not enabled on every Linux system. Check the module and service before treating a host as exposed:

  • lsmod | grep ksmbd shows whether the module is loaded.
  • systemctl status ksmbd shows whether the service is running on distributions that package it as a unit.
  • Port 445 reachability determines whether the pre-auth race is remotely reachable.
  • Guest-accessible shares and writable shares are the preconditions the reports use.

If KSMBD is not loaded, the two KSMBD RCEs are not reachable on that host. The local privilege-escalation and information-disclosure reports are a separate patch-tracking problem. The ConnMan bug requires ConnMan’s DNS proxy with a search domain configured, and it is not a kernel issue.

No CVE identifiers appear for these reports yet. That does not make the issues theoretical: the reproducers are public, the code paths are named, and at least one maintainer has a candidate branch. Use the ZDI IDs for change tickets and vendor communication until CVEs appear.

What to Do Now

  1. Inventory KSMBD. Check every Linux host, appliance, NAS, and container host for the module and service. Record whether port 445 is reachable from untrusted networks.
  2. Disable it if you do not need it. Stop the service, unload the module, and remove the package where appropriate. A server that does not run KSMBD cannot be attacked through these two bugs.
  3. Remove guest access if you do need it. The race report requires a guest-accessible share. Restrict SMB to trusted networks and specific clients; do not expose port 445 to the internet.
  4. Turn off SMB Direct and RDMA where they are not required. That removes the 33549 path and reduces the attack surface even after a patch.
  5. Track the fixes. The SMB Direct branch is not a stable release. Watch the kernel stable tree and your distribution for the backport; do not assume a CVE feed will lead the story.
  6. Treat the reproducers as public. Detection should assume an attacker has the trigger. Log KSMBD connections, guest logins, and unusual SMB1/SMB2 transitions, and alert on crashes or KASAN reports if you run debug kernels.

An HTTP WAF does not help here; SMB is a different protocol. Network segmentation, disabling the service, and patching the kernel are the controls that matter.

The Bigger Lesson

The headline is two CVSS 9.0 KSMBD bugs. The more useful lesson is the disclosure pipeline. Automated scanners can produce real findings faster than maintainers can triage them, and a public mailing list is not a substitute for a patch. Publishing a full reproducer before a fix turns a coordinated report into a race between defenders and anyone reading LKML.

ZDI’s routing may have followed the kernel’s AI-report exception. The reproducer publication did not follow the guidance that accompanies it. Maintainers also cannot merge a report that arrives without a patch. The result is the worst combination: public technical detail, no stable fix, and a shrinking window for the systems that actually run KSMBD.

Bottom Line

If KSMBD is loaded and reachable, treat the pre-auth race as an active exposure, not a future CVE. Remove guest access, restrict port 445, and disable KSMBD where it is not needed. Track the SMB Direct branch and the stable backports, but do not wait for a CVE to start. If KSMBD is not loaded, the remote KSMBD paths are closed, while the local kernel and ConnMan reports still belong in the patch queue.

More in-depth coverage from this blog on closely related topics:

Sources and References