Linux KSMBD RCE: Two CVSS 9.0 Kernel Flaws Posted Publicly Before a Fix

Linux KSMBD, the kernel's built-in SMB file server, has two flaws that Trend Micro's Zero Day Initiative (ZDI) rated CVSS 9.0 and posted to public kernel mailing lists on October 20-21, 2026, before any released kernel carried a fix. The ratings say remote code execution, but the public proofs of concept reviewed for this post show a kernel memory leak and crashes. The real exposure is narrower than the score suggests: you only have a problem if the ksmbd service is running.

This is a news post with a lot of conflicting early coverage, so it separates what is sourced from what is not. It also corrects a mix-up that spread in some write-ups, where the public root exploit from the same ZDI batch was attached to the KSMBD story. That exploit belongs to a different bug. If you run self-hosted agent machines, GPU boxes, CI runners or dev servers on Linux, the check takes under a minute.

TL;DR

What is KSMBD and who runs it?

KSMBD is a file server for the SMB protocol that lives inside the Linux kernel instead of in a userspace daemon like Samba. Because it runs in kernel space, a memory-safety bug in its packet handling is a kernel bug, not just a service bug.

Few machines run it. Per the reporting from CloudLinux and Ostorlab, Red Hat Enterprise Linux does not include KSMBD by default, and AlmaLinux and CloudLinux 9 and 10 do not build it. Debian and Ubuntu build it, but it runs only after an administrator installs ksmbd-tools and starts the service. Per Sysdig, Ubuntu builds SMB Direct support and Debian does not.

How do the two flaws work?

ZDI-CAN-33774 (pre-authentication). KSMBD decides per request whether to use SMB1 or SMB2 handlers. Ostorlab describes a race: the receive thread can read the next protocol data unit before the negotiation worker finishes, and a pipelined SMB2 request can replace the connection's handler table (conn->ops) while an earlier SMB1 request is still queued. A burst of short SMB1 packets followed by an SMB2 packet in one TCP write makes an SMB2 handler read past the end of a shorter SMB1 buffer. No authentication is needed.

ZDI-CAN-33549 (SMB Direct). An integer underflow in the RDMA transport: the first buffer descriptor can be longer than the declared payload, so a size counter wraps and a later copy can overrun a heap buffer (Sysdig says up to 8 KB). It needs an RDMA-capable interface (hardware or the rxe software driver), a writable share and a client that negotiates SMB Direct, so it is much harder to reach than the first.

What the public code actually does:

• The ZDI-CAN-33774 proof of concept leaks 28 bytes of kernel heap per attempt before authentication and can crash the kernel.
• The ZDI-CAN-33549 proof of concept crashes the kernel; a separate public write-up reports a KASAN-flagged out-of-bounds heap write and does not claim code execution.
• Sysdig and CloudLinux both say no public source shows code execution for either flaw.

A memory leak before authentication is still not harmless, since kernel heap contents can help a later exploit. It is a different risk from "anyone can run code as root over port 445," which is what a bare CVSS 9.0 invites you to imagine.

Timeline

Is the fix merged or not?

Sources disagree, and this is the item to re-check before you rely on it. The Hacker News and Sysdig say commit 68f410faedaf sits in the maintainer's ksmbd-for-next branch. Ostorlab says it merged into the mainline development tree on October 20. All of them agree that no released kernel carried it as of October 26, so the practical answer is the same: wait for your distribution's kernel advisory and search it for that commit. For ZDI-CAN-33549, Metzmacher's fix is reported as targeting Linux 7.5, and The Hacker News says that was not confirmed.

Why were there no CVE ids?

The Hacker News notes the kernel project assigns CVEs only after a fix exists in a stable tree, per the kernel CVE process. It also says ZDI copied public lists alongside the private security address and attached no patches. Kernel security-bugs documentation was updated in May 2026 to say bugs found by AI tools are treated as already public. Per that report, ZDI credits TrendAI, Trend Micro's AI scanner, as the finder, and Kroah-Hartman wrote on one report that there was "not much we can do with this" without a patch. Expect the ids to appear once fixes land in stable.

How do I check if I am exposed?

# Is the module loaded?
lsmod | grep ksmbd

# Is the service active?
systemctl status ksmbd
systemctl is-active ksmbd

# Is anything listening on SMB's port?
ss -tlnp | grep :445

# Is SMB Direct (RDMA) in play?
lsmod | grep -E 'rdma|rxe'

A loaded module alone does not prove the service is serving, per Ostorlab, so check the listener too. If all three come back empty, you are not exposed to these two flaws. If you use Samba for file sharing, the in-kernel server is not what is answering.

What should I do now?

1. Inventory. Find every host running ksmbd or listening on 445, including lab machines and NAS-style boxes someone set up once.
2. Turn it off where it is not needed: sudo systemctl stop ksmbd && sudo systemctl disable ksmbd. This removes the file service, so confirm nothing depends on it.
3. Where it must stay, restrict TCP 445 at the host and perimeter firewall to trusted networks only.
4. Disable SMB Direct unless your storage network depends on RDMA.
5. Watch your distribution's kernel advisories for 68f410faedaf (Debian and Ubuntu trackers, or your vendor's), then reboot into the fixed kernel. Fixes can take weeks to move from mainline to stable and distribution kernels, per Ostorlab.
6. Hunt lightly. Look for unexpected sources on port 445, bursts of requests followed by abrupt disconnects, and kernel oops or panic lines mentioning ksmbd or fs/smb/server. No indicators of compromise have been published, and a burst pattern alone does not prove exploitation.

Is this the same as the public root exploit?

No, and this is the part some coverage blurs. The same ZDI batch also included ZDI-CAN-33367, a local privilege escalation in skb_zerocopy() rated CVSS 7.8. A public exploit for that one gave root on AlmaLinux 8, 9 and 10, CloudLinux 9 and 10, Debian 12 and 13, and Ubuntu 24.04 and 26.04, per CloudLinux and Sysdig. It is a gap in this year's Dirty Frag fix (CVE-2026-43284), so kernels carrying that fix are still exposed. It needs a local user and unprivileged user namespaces, which is why the user.max_user_namespaces=0 advice applies to it and not to KSMBD.

If you do triage that bug: setting user.max_user_namespaces to 0 takes effect without a reboot but breaks rootless containers and some sandboxes, and both CloudLinux and Sysdig say it has not been validated against the exploit. Sysdig reports Ubuntu's AppArmor namespace restriction did not stop it. A local-root bug matters on shared hosts, which is the setup many agent and CI machines have.

Does this matter for AI agent infrastructure?

Only on the margin, and it is easy to overstate. Typical agent machines (a developer laptop, a CI runner, a GPU box for inference) do not run a kernel SMB file server. For those hosts the honest answer is "check and move on."

Where it does matter is the machines that hold the most secrets: a self-hosted agent server with API keys in its environment, a build host with deploy tokens, a shared GPU node. A kernel memory disclosure is a bad property on a box like that, and a local-root bug (the 33367 case) turns any agent-run code into full host access. Agents do run arbitrary code in your shell, so a privilege escalation changes what a compromised or prompt-injected session can reach.

What we could not verify

• CVE ids: none had been assigned at the time of the sources above. We did not find an oss-security thread or kernel.org CVE announcement for these two flaws.
• Merge status of the 33774 fix: sources conflict (maintainer branch versus mainline development tree). We did not check the git tree ourselves.
• Code execution: no public source shows it for either flaw. ZDI's labels describe a write path, and we did not see ZDI's advisory text itself.
• Affected kernel version ranges: none were published in the sources we read.
• Other kernel reports: the batch also included vmwgfx, nvmet and a ConnMan report. Reports of an "Infinity Core" set of core-kernel bugs by Hyunwoo Kim on oss-security were not confirmed in the sources reviewed here, so we do not cover them.

Related reading

• October 2026 attacks timeline
• Anthropic's AI-built exploit chains: Chrome 156, Linux MPTCP and Windows QUIC fixes
• PHP2Shell patch guide for Ubuntu, Debian, RHEL and Docker
• Tailworm: 11 unpatched Tailscale and headscale flaws
• What to do after an attack on your app: an incident response playbook
• Your first 24 hours after a vendor breach: a rotation and monitoring runbook
• Monitor and control a Mac mini running OpenClaw or Hermes Agent with Beam

Primary sources: The Hacker News · Sysdig · CloudLinux · Ostorlab · Phoronix · ZDI upcoming advisories · Red Hat KSMBD note

Accurate as of October 26-29, 2026 reporting. Fix status and CVE ids are moving; check your distribution's security tracker before acting on this post.