KSMBD Vulnerabilities: Exposure, Patch Status and Checks

The October 2026 KSMBD reports concern Linux’s in-kernel SMB server, not every Linux host that shares files. ZDI lists ZDI-CAN-33774 and ZDI-CAN-33549 with scores of 9.0. ZDI’s advisory inventory. Before choosing a response, identify which implementation serves the share and whether it is reachable from an untrusted network.

This assessment was reviewed October 24, 2026. Public reporting and maintainer-tree changes are not a distributor’s fixed-package matrix. We do not assign an unannounced CVE number, claim a successful Penligent exploit, or infer that every kernel with a particular version string has the same backports.

Two reports, different prerequisites

TuxCare describes ZDI-CAN-33774 as a pre-authentication race with public memory-disclosure and crash demonstrations. ZDI-CAN-33549 concerns SMB Direct over RDMA and requires additional share-access conditions. TuxCare distinguishes those observations from demonstrated code execution and reports maintainer-tree work without establishing a shipped fixed kernel for every distribution. TuxCare’s KSMBD assessment.

Treat a severity score as an input to prioritization. Exposure and a working defensive control belong in the same ticket. A host with the component absent is different from a file server reachable across a broad VPN, even if an inventory scanner attaches the same Linux family name to both.

KSMBD and Samba are different server implementations

그리고 kernel KSMBD documentation describes performance-related file operations in kernel space and user-space management through ksmbd.mountd. It documents a listener on port 445 when the server starts. A port number identifies a service path to investigate; it does not tell you whether that path terminates at KSMBD, Samba or another appliance.

Build the service identity from local configuration and runtime observations. A business inventory entry reading “SMB server” is too broad for this report. Record the process or kernel component, the owner of the share, the device or host identity, and the network segment where clients connect. For appliances, ask the vendor to identify the implementation rather than attempting to infer it from a banner.

Explore Penligent for authorized security testing

Collect local evidence without sending malformed SMB traffic

These proposed commands are read-only inventory aids for a Linux host you administer. They do not scan the network, load a module or exercise a vulnerability. Some need administrative visibility, and some files or tools will be unavailable on a given distribution; preserve that result as a limitation.

uname -r
systemctl is-active ksmbd
lsmod | rg '^ksmbd\b'
ss -lntp 'sport = :445'
# If this distribution exposes its running-kernel configuration:
rg '^CONFIG_SMB_SERVER(=|_)' /boot/config-"$(uname -r)"

An inactive service result is useful, but not conclusive by itself. Another supervisor or an appliance-specific startup path can manage a service. A module listing also does not enumerate functionality built directly into a kernel. Combine the service state, kernel configuration, listener identity and deployment owner’s configuration record before concluding that the component is absent.

Do not make an empty output line mean “fixed.” It might mean the tool is missing, permissions are limited, the service is stopped, or the check does not fit the platform. Record the reason. The objective is a defensible service inventory, not a script that prints a reassuring status for every host.

Reachability includes internal low-trust networks

Once the implementation is identified, trace approved client paths through routing and access controls. Include branch networks, remote-user VPNs, vendor connections and guest segments. An internal address does not establish that every reachable client is trusted. Conversely, a public scan that finds no listener cannot describe paths available only from an internal network.

Prefer existing network policy and flow evidence before adding active tests. When an authorized connectivity check is necessary, use a normal benign service check from named test locations. Do not send crash-oriented protocol sequences to a production file server. File-service availability and kernel stability are assets the response is intended to preserve.

An offline triage example that preserves unknowns

We executed this model locally against synthetic records. It evaluates three inventory observations without contacting any machine. It is not a KSMBD detector, a CVE scanner or a proof of exploitability. Its useful property is that missing evidence does not silently become a clean result.

def triage(implementation, running, reachable):
    if implementation is None or running is None:
        return "REVIEW: service identity or state unknown"
    if implementation != "ksmbd":
        return "Different implementation: keep its own advisory review"
    if not running:
        return "Confirm no alternate startup path"
    if reachable is None:
        return "REVIEW: network path unknown"
    return "Prioritize containment" if reachable else "Verify restriction and fix status"

cases = [("ksmbd", True, True), ("ksmbd", True, False),
         ("samba", True, True), (None, None, None)]
for case in cases:
    print(triage(*case))

Prioritize containment
Verify restriction and fix status
Different implementation: keep its own advisory review
REVIEW: service identity or state unknown

Do not extend the model into a version comparison without a trustworthy package mapping. Distribution kernels can carry backports, and vendor appliances may use their own revision identifiers. Preserve the advisory and package provenance alongside any automated classification.

Contain the service you actually run

If the business does not require the KSMBD share, evaluate disabling it through the normal change process. Check dependencies first: applications, backups or user workflows may rely on that path. This is a proposed containment decision, not an action we executed and not a claim that disabling an unrelated Samba service changes KSMBD exposure.

If the share must remain available, restrict it to the smallest required source set and verify denied paths from approved test locations. Document any exception, owner and expiry. Restricting access buys time; it does not repair the kernel code or establish that an incident could not have occurred before containment.

Explore Penligent for authorized security testing

Recognize the difference between a fix reference and a fixed host

A useful patch record progresses through distinct states: a change exists, the distribution includes it, the correct package is installed, and the running kernel or supported livepatch state is verified. Skipping a state can leave an old kernel serving traffic while a dashboard reports a newer package on disk.

Request the distributor’s advisory or support statement for the exact report identifier if a CVE is not yet assigned. Keep the package revision, architecture and kernel flavor in the record. For a livepatch product, obtain its applicability and loaded-patch evidence rather than assuming that all fixes are delivered without reboot.

After the change, confirm normal read and write workflows with synthetic files in an approved test share. Review permissions and cleanup with the share owner. A successful file transfer proves that a supported workflow still functions; it is not a regression test of a memory-corruption flaw. Do not replace vendor fix evidence with a failed public PoC run.

When a server has already crashed

Preserve the kernel log, crash information, time and service context under the incident process. Correlate network observations with the host rather than labeling every SMB error an attack. Memory disclosure, a crash and arbitrary code execution require different evidence. If compromise is suspected, containment and forensic handling take priority over trying additional public exploit repositories.

Frequently asked questions

Is Samba affected by these KSMBD reports?

These reports concern KSMBD. Identify the implementation on your host and review separate advisories for other SMB servers.

Does port 445 prove that KSMBD is running?

No. It identifies a listener to investigate; combine it with service and kernel-component evidence.

Are all Linux distributions exposed by default?

Do not assume that. Build options, service activation and network reachability determine whether the relevant component is present and reachable.

Can I use a public crash PoC to verify a production share?

Use inventory and vendor fix evidence instead. Crashing a kernel is not an appropriate production availability check.

What closes the remediation record?

Distribution-specific fix evidence, the active kernel or supported livepatch state, verified access restrictions and normal functional checks, with exceptions recorded.

For an authorized assessment, define the permitted systems and evidence requirements before testing. Evaluate any automation by the observations it can actually preserve. This article does not claim a dedicated Penligent detector or a Penligent reproduction of the reported flaw.

The video below introduces a general AI-assisted pentesting workflow. It is not an exploit demonstration for the issues discussed here.