Two CVSS 9.0 flaws hit Linux's in-kernel SMB server on October 22, 2026. Before you panic, find out whether you even run it.

If you run a home server, you probably saw the headlines: two remote code execution flaws, both rated 9.0 out of 10, in a Linux SMB server. For anyone with a NAS full of family photos and backups, that sounds like a drop-everything emergency.

It usually isn't. The flaws are not in Samba. They are in KSMBD, the SMB server built into the Linux kernel itself — two different codebases, two different services. Confusing them is how a lot of self-hosters spend a weekend patching a problem they never had.

The question every homelab owner should ask first: which SMB server is actually running on my box?

Samba is not KSMBD

Most NAS systems and Linux distributions share files with Samba, the userspace implementation that has been around for decades. You know it as the `smb` or `smbd` service. It is the default on the setups most of us run, and it is not affected by these two flaws at all.

KSMBD is the newer alternative: an SMB server that lives inside the kernel, designed for speed. It is not the default everywhere — Red Hat Enterprise Linux, for example, does not include it by default — and plenty of homelabs have never enabled it.

As of October 26, 2026, the two flaws have no CVE numbers and no confirmed fix in a stable or distribution kernel. They are tracked by Trend Micro's Zero Day Initiative as ZDI-CAN-33774 and ZDI-CAN-33549, both rated 9.0. The kernel project only assigns CVE numbers once a stable-tree fix exists, so until then, the ZDI-CAN IDs are the correct references. There are unverified secondary reports of a fix in a branch aimed at Linux 7.5, but that is not confirmed, and it is unclear which flaw it would even cover — so don't plan around it.

The 30-second check

Run one of these on your NAS or Linux server:

  • systemctl status ksmbd
  • lsmod | grep ksmbd

If neither shows KSMBD running, you can stop here. You are not exposed to these two flaws. If you run normal Samba, you are not affected either. Only a system with the KSMBD kernel module active is in scope.

The question is not "is Linux vulnerable?" It is "is KSMBD running on my box, and is port 445 reachable?" Answer those two, and you know your risk.

Why the two flaws are not equal

Lumping them together as “two 9.0s” hides how different their exposure really is.

ZDI-CAN-33774 is the dangerous one. It 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 can make 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 it exposes any server running KSMBD on port 445.

ZDI-CAN-33549 is far narrower. It is 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. But 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 even among KSMBD users, the practical risk concentrates in the first flaw, and the first flaw concentrates on one thing: a reachable port 445.

If KSMBD is running, lock it down now

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

First, stop the KSMBD service and unload the module if you do not need kernel SMB. Commands vary by distribution, so check your distro's documentation. If the module is built into your kernel rather than loadable, the firewall step below is your control.

Second, 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, and it is the single highest-value thing on this list.

Third, disable SMB Direct if you use it, unless you have a specific RDMA need. That closes the second flaw's path.

Fourth, consider switching file sharing to userspace Samba if your setup allows it. Normal Samba is a different codebase and is not affected by these two flaws.

Fifth, check your kernel and distribution version and note it down, so you recognise the fixed version when it arrives.

One warning while you do this: don't 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 story is only about the two KSMBD flaws.

What to watch for the fix

Watch three things, in this order. First, a fix landing in the stable kernel tree, then in your distribution's kernel — that trip typically takes weeks. Second, CVE numbers being assigned to ZDI-CAN-33774 and ZDI-CAN-33549 — that assignment itself signals a stable fix exists. Third, your distribution's security advisory naming the fixed kernel version — that is the version to upgrade to.

Until then, the check commands above plus a blocked port 445 are your protection.

The bottom line for self-hosters

The correct response here starts with thirty seconds and one command. Your NAS probably runs Samba, not KSMBD, and if it does, these two 9.0s are not your problem. If you are running the kernel server, stop it or firewall it today — the unauthenticated flaw needs nothing more than a reachable port 445, and closing that door costs you nothing.