KSMBD Vulnerability: Your NAS Runs Samba — But Is It the Kernel One?

Originally published at https://thehomelabfixer.blogspot.com/2026/10/ksmbd-vulnerability-your-nas-runs-samba.html

Two remote code execution flaws rated 9.0 out of 10 were disclosed on October 22, 2026, in Linux's in-kernel SMB server — and the first thing you need to know is that they probably do not affect you at all. Most homelabs share files with normal Samba, which runs in userspace. These flaws are in KSMBD, the kernel's own built-in SMB server, which is a different thing entirely. This post gives you a 30-second check to find out which one your NAS runs, what to switch off if it is the kernel one, and what to watch for the fix.

Honesty first: as of today (Oct 26), these flaws have no CVE numbers and no confirmed fix in a stable or distribution kernel. They are tracked as ZDI-CAN-33774 and ZDI-CAN-33549 by Trend Micro's Zero Day Initiative, which rated both 9.0. The kernel project only assigns CVE numbers once a stable-tree fix exists, so until then, ZDI-CAN IDs are the correct references. Unverified secondary reports mention a fix in a branch aimed at Linux 7.5, but it is not confirmed and it is unclear which flaw it covers — so this post does not count on it.

The 30-second check: are you affected?

Run one of these on your NAS or Linux server:

• systemctl status ksmbd
• lsmod | grep ksmbd

If neither shows KSMBD running, stop here — you are not exposed to these two flaws. If you run normal Samba (the smb/smbd service most NAS systems and distros use), you are also not affected. Only a system with the KSMBD kernel module active is in scope.

Two more facts that narrow it further. First, KSMBD is not enabled by default on many distributions — Red Hat Enterprise Linux, for example, does not include it by default. Second, the two flaws have very different exposure:

• ZDI-CAN-33774 — the dangerous one. 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 makes workers 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. It needs no authentication and exposes any server running KSMBD on port 445.
• ZDI-CAN-33549 — the narrow one. An integer underflow in the SMB Direct path: a client supplies RDMA buffer descriptors where the first is longer than the declared payload, the server's size counter wraps, and a later memory copy overruns an allocated buffer. It needs three things at once: an RDMA-capable interface (hardware, or the rxe software driver), a writable KSMBD share, and a client negotiating SMB Direct. Most homelabs meet none of those, let alone all three.

So the real question is not "is Linux vulnerable" — it is "is KSMBD running on your box, and is port 445 reachable?" Answer those two and you know your risk.

If KSMBD is running: lock it down now

These are interim mitigations until a real fix lands in your distro's kernel — not vendor-certified guidance, because no vendor fix exists yet.

1. Stop the KSMBD service and unload the module if you do not need kernel SMB. (Commands vary by distro — check your distro's documentation. If the module is built into your kernel rather than loadable, the firewall step below is your control.)
2. Block port 445 inbound at your firewall for anything that does not strictly need SMB from outside your LAN. For most homelabs, SMB should never face the internet at all — this step alone removes the unauthenticated flaw's reach.
3. Disable SMB Direct if you use it, unless you have a specific RDMA need — that closes the second flaw's path.
4. Switch file sharing to userspace Samba if your setup allows it. Normal Samba is a different codebase and is not affected by these two flaws.
5. Check your kernel and distro version and note it down, so you recognise the fixed version when it arrives.

Do not confuse these with the other flaws disclosed in the same batch — a local privilege escalation in the networking stack, one in a virtual GPU driver, an information disclosure in an NVMe driver, and a buffer overflow in the ConnMan daemon. Those are separate issues with different fixes; this post is only about the two KSMBD flaws.

Fix-watch: what to look for

Watch three things, in this order:

1. A fix landing in the stable kernel tree, then in your distribution's kernel (fixes typically take weeks to travel from mainline to stable branches and distro kernels).
2. CVE numbers being assigned to ZDI-CAN-33774 and ZDI-CAN-33549 — that assignment itself is the signal a stable fix exists.
3. Your distro's security advisory naming the fixed kernel version — that is the version to upgrade to.

The original post will be updated when the fixed version is confirmed. Until then, the check commands above plus a blocked port 445 are your protection.

Bottom line

Your NAS probably runs Samba, not KSMBD — and if it does, these two 9.0s are not your problem. Thirty seconds with one command tells you for sure. If it turns out you ARE running the kernel server, stop it or firewall it today; the unauthenticated flaw needs nothing more than a reachable port 445.

FAQs

Does the KSMBD vulnerability affect my Samba NAS? Only if your NAS runs KSMBD, the kernel's built-in SMB server — not normal userspace Samba. Run systemctl status ksmbd or lsmod | grep ksmbd: if neither shows KSMBD active, you are not affected.

Is there a CVE number or patch for the KSMBD flaws? Not as of Oct 26, 2026. The flaws are tracked as ZDI-CAN-33774 and ZDI-CAN-33549. The kernel project assigns CVE numbers only after a stable-tree fix exists, and no confirmed stable or distribution fix has landed yet.

Which of the two KSMBD flaws is more dangerous? ZDI-CAN-33774 — it needs no authentication and exposes any KSMBD install on port 445. ZDI-CAN-33549 needs an RDMA interface, a writable share, and SMB Direct negotiation all at once, so its exposure is far narrower.

How do I protect my server until a fix lands? Stop the KSMBD service and unload the module if you don't need kernel SMB, block inbound port 445 at your firewall, disable SMB Direct if you use it, or switch file sharing to userspace Samba.

I run Red Hat Enterprise Linux. Am I affected? RHEL does not include KSMBD by default, so a stock RHEL system is not running it. Run the check commands above to confirm nothing has enabled it on your system.