Linux KSMBD Pre-Auth Flaw, ZDI-Rated CVSS 9.0 RCE, No Released Fix Yet (ZDI-CAN-33774)

TL;DR

• ZDI-CAN-33774: a pre-authentication race in KSMBD's protocol handler dispatch, triggered by one TCP write that pipelines a burst of SMB1 packets ahead of an SMB2 packet.
• ZDI-CAN-33549: an integer underflow in KSMBD's SMB Direct (RDMA) path.
• Every host running KSMBD with TCP port 445 reachable by untrusted peers is exposed. ZDI-CAN-33774 needs no authentication. ZDI-CAN-33549 additionally needs the SMB Direct transport negotiated, an RDMA-capable interface and a writable share.
• The public proof-of-concept code, posted with the reports on the public kernel lists, demonstrates a 28-byte kernel heap memory leak per attempt before authentication and a kernel crash, not code execution. ZDI rates both flaws as remote code execution and describes a write path for ZDI-CAN-33774, but nothing public shows it reaching code execution. No exploitation in the wild has been reported as of October 24, 2026 (Sysdig).
• There is no fix to install yet. The ZDI-CAN-33774 fix merged into the mainline development tree on October 20, 2026 but no released kernel carries it, ZDI-CAN-33549 has a proposed patch but no confirmed released fix, and neither flaw has a CVE id. Stop exposing KSMBD: disable the service where it is not needed, keep port 445 off untrusted networks, and leave SMB Direct off unless you need it.

Trend Micro's Zero Day Initiative rates both flaws CVSS 9.0 and credits Hyeontae Lee with both.

Am I affected?

ZDI-CAN-33774 exposes you to the demonstrated leak and crash if the first two conditions hold; ZDI-CAN-33549 additionally requires the third:

• Your kernel build includes KSMBD and the service is running. systemctl status ksmbd reports the service state; lsmod | grep ksmbd reports whether the kernel module is loaded. A loaded module alone does not establish exposure: use the ss command below to check for a port 445 listener and confirm that KSMBD serves it.
• TCP port 445 is reachable by the internet, tenant networks, or any other peer you do not fully trust.
• For ZDI-CAN-33549 only: the connection can negotiate SMB Direct over an RDMA-capable interface, hardware or the rxe software driver, and a writable KSMBD share exists.

The two flaws differ in what they need and where they stand:

Check what you run:

systemctl status ksmbd          # is the KSMBD service running?
lsmod | grep ksmbd              # is the module loaded?
ss -tlnp | grep :445            # is the SMB port listening, and on which address?

Where KSMBD actually runs:

How do I fix it?

There is no released fix to install for either flaw, so the action is to remove the exposure rather than to patch:

1. Stop and disable KSMBD where you do not need kernel-space SMB serving: systemctl stop ksmbd && systemctl disable ksmbd. Trade-off: this removes the file service entirely.
2. Where you must keep serving, restrict port 445 to networks whose hosts you trust, at the host firewall and any perimeter firewall. Trade-off: the service stays up, but only trusted peers can reach either flaw. Untrusted reach through any path leaves ZDI-CAN-33774 open, because it needs no authentication.
3. Leave SMB Direct and RDMA off unless you specifically use them, which closes ZDI-CAN-33549. Trade-off: it does nothing for ZDI-CAN-33774, which is the pre-authentication flaw.

Watch for fixed kernels rather than guessing dates. Fixes that reach the mainline tree typically take weeks to reach stable branches and distribution kernels after that, and the kernel project assigns CVE ids only after a stable-tree fix is available. When your distribution ships a kernel that carries commit 68f410faedaf ("ksmbd: wait for negotiation before receiving another PDU"), ZDI-CAN-33774 is closed on that host. For ZDI-CAN-33549, ask your vendor whether it includes the October 23 patch, "smb: smbdirect: fix buffer length underflow in RDMA transfers".

What is the root cause?

The KSMBD receive thread could read the next protocol data unit before the negotiation worker finished, so a pipelined SMB2 request could replace the connection's handler table while a worker was still handling an earlier, shorter SMB1 request.

The maintainer's own fix commit, 68f410faedaf, describes the mechanics exactly:

The receive thread queues a request and can read the next PDU before the negotiation worker finishes. While need_neg is set, the next PDU can cause ksmbd_init_smb_server() to replace conn->ops. A pipelined SMB2 request can therefore make the worker handle an earlier, shorter SMB1 request with SMB2 operations and read beyond its buffer.

An SMB1 multi-protocol negotiate may be followed by an SMB2 NEGOTIATE that changes conn->ops again.

The mechanics, step by step:

• conn->ops is the connection's handler table: the set of function pointers that turn a decoded SMB command into an action. SMB1 and SMB2 have different command layouts, so the server assigns one table or the other during negotiation, when need_neg is set.
• ksmbd_init_smb_server() is where that assignment happens. Re-running it mid-connection replaces conn->ops while work queued under the old table may still be running.
• A pipelined request — several protocol data units packed into one TCP write — is what forces the overlap: the receive thread reads the SMB2 packet and re-runs negotiation before the worker that was queued for the earlier, shorter SMB1 packet has finished.
• The worker then applies SMB2 handler logic to an SMB1-sized buffer and reads beyond its end.

For ZDI-CAN-33549, the report describes an integer underflow in the SMB Direct path: a client supplies RDMA buffer descriptors in which the first is longer than the declared payload, which makes the server's size counter wrap, so a subsequent memory copy overruns the end of an allocated buffer.

How is it exploited?

No exploitation in the wild has been reported, and the attack path is public in the reports themselves, posted to the public kernel mailing lists with proof-of-concept source code:

1. The attacker connects to port 445 on a host running KSMBD. For ZDI-CAN-33774, no authentication is needed, which is why it exposes any server running KSMBD on that port.
2. The attacker sends one TCP write containing a burst of short SMB1 packets followed by an SMB2 packet.
3. The receive thread queues work for the SMB1 packets and reads the SMB2 packet, which re-runs negotiation and replaces conn->ops with the SMB2 handler table.
4. The queued worker handles the earlier, shorter SMB1 request with SMB2 operations and reads past the end of the shorter buffer.
5. What the public proof of concept demonstrates: 28 bytes of kernel heap memory leak per attempt, before authentication, and a kernel crash. ZDI's report also describes a path to writing past the buffer once an attacker has access to a share, but nothing public shows that path reaching code execution, Sysdig reported.

For ZDI-CAN-33549, the attacker is a client that negotiates SMB Direct and supplies crafted RDMA buffer descriptors; it needs an RDMA-capable interface on the server, a writable share, and the SMB Direct transport, so it sits behind more conditions than ZDI-CAN-33774.

How does the attack flow?

The whole attack is one pipelined TCP write that makes the server swap its handler table under a queued worker.

The missing synchronization is at C: nothing makes the receive thread wait for the negotiation worker before it reads the next protocol data unit.

What can an attacker do?

Against an exposed host, the publicly demonstrated impact is kernel memory disclosure, 28 bytes of heap per attempt before authentication, and a kernel crash, which is a denial of service for a file server. ZDI rates both flaws CVSS 9.0 as remote code execution and its ZDI-CAN-33774 report describes a path to writing past the buffer once an attacker has share access, so memory corruption beyond the demonstrated leak is plausible. No public demonstration turns it into code execution, and no in-the-wild use has been reported.

The conditions each flaw needs:

• ZDI-CAN-33774: to trigger the leak and crash, a kernel build with KSMBD, the service running, and port 445 reachable; no account or share. ZDI's described write path additionally requires share access.
• ZDI-CAN-33549: all of the above plus SMB Direct negotiated, an RDMA-capable interface (hardware or the rxe software driver) and a writable share.
• Neither flaw affects userspace Samba (smbd), which is a separate codebase that does not share KSMBD's kernel dispatch path.

Why does the fix work?

The fix for ZDI-CAN-33774, commit 68f410faedaf by KSMBD maintainer Namjae Jeon, adds a wait to the receive path in fs/smb/server/server.c:

--- a/fs/smb/server/server.c
+++ b/fs/smb/server/server.c
@@ static int queue_ksmbd_work(struct ksmbd_conn *conn)
    struct ksmbd_work *work;
+   bool wait_for_neg = ksmbd_conn_new(conn) || ksmbd_conn_need_negotiate(conn);
    int err;
@@
    INIT_WORK(&work->work, handle_ksmbd_work);
    ksmbd_queue_work(work);
+   /* Negotiation can change conn->ops, finish it before reading another PDU. */
+   if (wait_for_neg)
+       wait_event(conn->req_running_q,
+              atomic_read(&conn->req_running) == 0);
    return 0;

After queuing work on a connection that is new or still negotiating, the receive thread now waits on conn->req_running_q until every queued request has finished. The handler table cannot be replaced while a worker is still handling an earlier request, so SMB1 data can never be handled with SMB2 operations. The commit keeps need_neg semantics unchanged. Its message frames the change as keeping the operations stable for both stages of negotiation.

The fix is complete for this race, and it is written against a related earlier report, crediting ihopenre-eng. Two limits stand: it lives in the mainline development tree, merged October 20, 2026, so no released kernel carries it yet, and it does not touch the SMB Direct path, so ZDI-CAN-33549 requires its separate SMB Direct patch.

How do I check if I was compromised?

No exploitation has been reported and no indicators of compromise have been published for either flaw. If you run KSMBD exposed to untrusted networks and want to audit:

• Review port 445 connection and firewall logs for unexpected source addresses. Where packet captures are available, look for bursts of requests followed by abrupt disconnects; this pattern alone does not establish exploitation.
• Check kernel logs for oops or panic records referencing ksmbd or fs/smb/server, since the public proof of concept can crash the kernel.
• Treat the 28-byte-per-attempt heap leak as a real exposure: each attempt discloses kernel heap content, so repeated attempts against an exposed host may have harvested memory contents even without a crash. If compromise is suspected on a host, the standard response for a suspected kernel-level incident applies: isolate the host, rotate every credential it holds, and rebuild from a known-good image.

Timeline

• 2026-09-30: KSMBD maintainer Namjae Jeon writes fix commit 68f410faedaf, "ksmbd: wait for negotiation before receiving another PDU", crediting ihopenre-eng, responding to an earlier report.
• 2026-10-20: the fix commit merges into the mainline Linux development tree (committer timestamp October 20, 23:55 UTC).
• 2026-10-21: ZDI discloses ZDI-CAN-33774 and ZDI-CAN-33549, each rated CVSS 9.0 and credited to Hyeontae Lee, to the public kernel mailing lists with no patches attached (UTC timestamps).
• 2026-10-21: SMB Direct maintainer Stefan Metzmacher asks the reporter to test the for-7.5/smbdirect development branch as a possible fix for ZDI-CAN-33549.
• 2026-10-22: KSMBD maintainer Namjae Jeon replies that commit 68f410faedaf already fixes the race.
• 2026-10-22: stable-kernel maintainer Greg Kroah-Hartman replies asking for patches rather than public disclosures.
• 2026-10-22: The Hacker News covers the disclosures.
• 2026-10-23: Namjae Jeon posts a smaller SMB Direct underflow patch after Stefan Metzmacher recommends a minimal fix.
• 2026-10-23 to 25: AlmaLinux, CloudLinux and Sysdig publish analyses; the public proof of concept is documented as a 28-byte kernel heap leak per attempt before authentication plus a crash, not code execution.
• 2026-10-26: this post. No exploitation in the wild has been reported, and neither flaw is in the CISA KEV catalog.

FAQ

Why do these flaws have no CVE id?

The Linux kernel project assigns CVE numbers only after a fix is available in a released, stable kernel, per its published CVE policy. Both flaws were disclosed to public lists before any released kernel carries a fix, so they are tracked by their ZDI-CAN identifiers. Expect CVE ids to appear once stable kernels pick the fixes up.

Does the public proof of concept give attackers remote code execution?

No. What it demonstrates is a 28-byte kernel heap memory leak per attempt before authentication and a kernel crash. ZDI's CVSS 9.0 ratings treat the flaws as remote code execution, and its ZDI-CAN-33774 report describes a path to writing past the buffer once an attacker has share access, but no public demonstration shows code execution, Sysdig reported.

Is my distribution's kernel affected?

Only if the distribution builds KSMBD and the service has been started. Red Hat Enterprise Linux does not include KSMBD by default, AlmaLinux and CloudLinux 9 and 10 kernels do not build it, and Debian and Ubuntu run it only after ksmbd-tools is installed and the service started. Hosts to audit are NAS appliances and storage servers that ship kernels with KSMBD enabled to serve files.

Are Samba servers affected?

No. Samba's userspace smbd is a separate implementation that does not share KSMBD's kernel dispatch code. The exposed software is KSMBD, the in-kernel SMB server, identifiable with systemctl status ksmbd or lsmod | grep ksmbd.

When will a fix reach my kernel?

The ZDI-CAN-33774 fix reached the mainline development tree on October 20, 2026, and fixes to mainline typically take weeks to reach stable branches and distribution kernels after that. For ZDI-CAN-33549, Stefan Metzmacher initially asked the reporter to test the for-7.5/smbdirect development branch. Namjae Jeon then posted a smaller patch on October 23; that does not establish availability in your distribution's released kernel. Track your distribution's kernel advisories for commit 68f410faedaf (ZDI-CAN-33774) and the October 23 SMB Direct patch (ZDI-CAN-33549); confirm coverage of each separately.

Do I need SMB Direct to be worried about both flaws?

No. ZDI-CAN-33549 needs SMB Direct, an RDMA-capable interface and a writable share. ZDI-CAN-33774 needs none of that: it is reachable by any unauthenticated peer that can reach port 445 on a host running KSMBD, which is why it is the one to remove exposure to first.

Find exposed SMB servers before an attacker does

Follow Ostorlab's network scan guide: select New Scan → Network, enter your IP addresses or ranges, choose Full Network Scan, and start the scan. Review any port 445 findings, then confirm locally whether the service is KSMBD or userspace Samba. Restrict exposed KSMBD services while waiting for a fixed distribution kernel.

References

• Primary ZDI-CAN-33774 report, mirrored by Openwall, with the October 21 UTC disclosure timestamp and described write path: https://lists.openwall.net/linux-kernel/2026/10/21/2694
• Stefan Metzmacher's SMB Direct branch and minimal-fix discussion, October 23: https://lists.openwall.net/linux-kernel/2026/10/23/739
• Namjae Jeon's attached SMB Direct underflow patch, October 23: https://lists.openwall.net/linux-kernel/2026/10/23/971
• The Hacker News, "Two CVSS 9.0 Linux KSMBD RCE Flaws Disclosed on Public Mailing Lists Before Kernel Fixes", October 22, 2026, updated October 26, with the flaw mechanics, the maintainer replies, the proof-of-concept scope and the distribution status: https://thehackernews.com/2026/10/two-cvss-90-linux-ksmbd-rce-flaws.html (checked October 26, 2026)
• ZDI upcoming advisories, listing ZDI-CAN-33774 and ZDI-CAN-33549 at CVSS 9.0, vendor Linux, discovered by Hyeontae Lee: https://www.zerodayinitiative.com/advisories/upcoming/ (checked October 26, 2026)
• The ZDI report for ZDI-CAN-33774 on the public kernel lists: https://lore.kernel.org/lkml/BYAPR01MB383076AC412E19C48CFBEAE980662@BYAPR01MB3830.prod.exchangelabs.com/ (primary report)
• The ZDI report for ZDI-CAN-33549 on the public kernel lists: https://lore.kernel.org/lkml/BYAPR01MB3830472B5702C089B0BBB77D80662@BYAPR01MB3830.prod.exchangelabs.com/ (primary report)
• Fix commit 68f410faedaf, "ksmbd: wait for negotiation before receiving another PDU", in the mainline Linux tree, authored September 30, 2026, committer timestamp October 20, 2026: https://github.com/torvalds/linux/commit/68f410faedaf6ee74d81e574733c50ebcc1bd8ed (checked October 26, 2026)
• Sysdig on the six October kernel reports, the proof-of-concept scope and the unmerged fix status: https://www.sysdig.com/blog/detecting-and-mitigating-zdi-can-33367-and-five-other-linux-flaws (referenced via The Hacker News, October 26, 2026)
• AlmaLinux on the public kernel-list reports: https://almalinux.org/blog/2026-10-23-zdi-can-33367/ (referenced via The Hacker News, October 26, 2026)
• CloudLinux on the KSMBD proof of concept and distribution build status: https://blog.cloudlinux.com/zdi-can-33367 (referenced via The Hacker News, October 26, 2026)
• Red Hat solution document 6991749, KSMBD not included in RHEL by default: https://access.redhat.com/solutions/6991749 (referenced via The Hacker News, October 26, 2026)
• The Linux kernel CVE assignment policy, CVEs issued only after a stable-tree fix: https://docs.kernel.org/process/cve.html (referenced via The Hacker News, October 26, 2026)