Two Leaked ksmbd RCE Bugs, No CVE Yet: Is Your Linux Product Exposed?

The facts on both

How the two bugs work

ZDI-CAN-33774: the handler table changes under a queued request

ksmbd reads a request from the socket and queues it for a worker thread. While the connection is still negotiating, the next request it reads can call ksmbd_init_smb_server() and replace conn->ops, the table of protocol handlers. A short SMB1 request followed in the same TCP write by an SMB2 request can therefore make the worker process the SMB1 buffer with SMB2 handlers, which assume a larger header. The fix makes queue_ksmbd_work() wait until queued work has finished before reading another PDU, for as long as the connection is new or still negotiating:

+	bool wait_for_neg = ksmbd_conn_new(conn) || ksmbd_conn_need_negotiate(conn);
 ...
+	/* 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);

ZDI-CAN-33549: a length counter that wraps

For an SMB Direct read or write, the client sends a list of buffer descriptors. The server walks the list and clamps a descriptor that is longer than the remaining payload. In current mainline that loop is in smbdirect_connection_rdma_xmit():

143		if (desc_buf_len > buf_len) {
144			desc_buf_len = buf_len;
145			desc[i].length = cpu_to_le32(desc_buf_len);
146			buf_len = 0;
147		}
 ...
152		desc_buf += desc_buf_len;
153		buf_len -= desc_buf_len;	/* 0 - desc_buf_len: wraps */

After the clamp, buf_len is already zero, and line 153 subtracts the length again. The counter wraps to a huge value (a size_t on 7.1 and later; on the long-term branches an int that goes negative, with the same effect), the loop’s if (!buf_len) break; no longer stops it, and the following descriptors point past the end of the buffer. The RDMA transfers built from them then write beyond it. Up to 7.0, and on every long-term branch, the same loop is smb_direct_rdma_xmit() in fs/smb/server/transport_rdma.c.

The config gate

ksmbd is its own Kconfig option. The kernel SMB client (CONFIG_CIFS) never runs these code paths: on 7.1 and later it shares the smbdirect module with ksmbd, but only ksmbd issues these transfers. Samba runs in userspace and is not affected.

# ZDI-CAN-33774: the ksmbd server itself
CONFIG_SMB_SERVER=y            # or =m

# ZDI-CAN-33549: additionally SMB Direct, which needs InfiniBand/RDMA support
CONFIG_SMB_SERVER_SMBDIRECT=y
CONFIG_INFINIBAND=y            # =m only works with CONFIG_SMB_SERVER=m
CONFIG_INFINIBAND_ADDR_TRANS=y

If CONFIG_SMB_SERVER is not set, neither bug is reachable in your kernel. If it is set but CONFIG_SMB_SERVER_SMBDIRECT is not, only ZDI-CAN-33774 applies.

Where the fixes are

Neither fix is in mainline yet (checked against 2a08195e4db5, 22 October 2026, 18:23 UTC), and neither bug has a CVE: the kernel’s CVE team normally assigns one only once a fix is in a released kernel. Both fixes are already committed in the maintainers’ own trees:

The ZDI-CAN-33774 fix describes exactly the race in the report and carries a Fixes: tag pointing at dc8289f91238. The SMB Direct commit does not mention the report, but its author pointed the reporter at this branch on the mailing list as the likely fix. It reworks the transfer loop to handle one descriptor at a time and advances a byte iterator by what was actually transferred, so the clamp-then-subtract sequence no longer exists; the line-level match to ZDI-CAN-33549 is our own reading. It is a large rework aimed at 7.5, so the long-term branches will likely need a separate, smaller fix. When these fixes are merged into mainline, they may get new commit IDs.

What your tools will show, and when

Until a fix lands in a stable release, there is no CVE, so NVD, Dependency-Track and every CVE-based scanner see nothing. After that, the usual delay applies: the CVE is published, and NVD analysis with CVSS and version ranges can take days to weeks. The two reports are public now, so the gap between “anyone can read how to trigger it” and “your scanner flags it” is longer than usual.

30-second checklist

1. Is CONFIG_SMB_SERVER set in your kernel config? If not: not_affected for both bugs, justification code_not_present (on 7.1 and later with CONFIG_CIFS_SMB_DIRECT, the SMB Direct function is built but only ksmbd calls it: code_not_reachable). If it is set but CONFIG_SMB_SERVER_SMBDIRECT is not, ZDI-CAN-33549 is code_not_present too.
2. Does the product run ksmbd? Check whether ksmbd-tools are installed and ksmbd.mountd is started, or check for a listener on port 445 that is not Samba. If ksmbd is built but never started, the code is present but no attacker can reach it: not_affected, justification code_not_reachable.
3. Who can reach port 445? If ksmbd is running, ZDI-CAN-33774 is reachable by anyone on the network path to that port, before login. Firewall port 445 to trusted hosts now, or stop ksmbd until a fixed kernel is available. For ZDI-CAN-33549, also ask whether the server has an RDMA device (hardware, or the rxe/siw software drivers) and whether untrusted users, including guests, can write to a share.

Know before the CVE

The question “are we affected?” is answered by the kernel config, not by the score. Upload your .config to KernelScan and every kernel CVE is checked against the options your product actually builds, including the long-term branches and their backports. When these two fixes reach a stable release, they will show up as pre-CVE candidates on paid plans before the CVEs are published.