Two 9.0 Rated Flaws Sit Unpatched In The Linux Kernel SMB Server: Who Is Actually Exposed

Posted on by
Contents show
A flat vector illustration of a closed grey metal server door with a small amber warning light above it and a thin teal key shape floating away from the keyhole, representing the unpatched KSMBD flaws in the Linux kernel

Two remote code execution flaws in the Linux kernel's built-in SMB server, KSMBD, were disclosed on public kernel mailing lists on 20 and 21 October 2026, both rated CVSS 9.0, neither with a merged mainline fix at disclosure time, and neither carrying a CVE identifier. One of them needs no authentication. The reports came from Trend Micro's Zero Day Initiative and, unusually, went out to public lists including LKML and netdev before any patch existed, with maintainers including Greg Kroah-Hartman publicly noting that the reports had arrived without fixes attached.

The disclosure mechanics are genuinely unusual and worth understanding, but the practical question for a server owner is narrower: are you running KSMBD, is port 445 reachable, and what should you do while the fix pipeline grinds through mainline, stable and distribution kernels? This article covers what each flaw is, who is and is not exposed, the patch status verified as of publication, and the concrete checks, which take about a minute per server. Everything comes from the ZDI reports as reflected in maintained kernel-security tracking and the kernel maintainers' own public replies.

What KSMBD is, and why most servers are safe

KSMBD is the SMB file server implemented inside the Linux kernel itself. It is not Samba. Samba is the userspace SMB server that most production Linux file servers run, and hosts sharing files through Samba alone are not exposed to these flaws at all. That distinction is the single most important fact in this story, and it is the one headline coverage has been worst at conveying.

Exposure requires three things to line up. The kernel must be built with KSMBD support, the ksmbd module must be loaded or the service started, and the SMB port must be reachable from networks you do not trust. Major distributions treat KSMBD as opt-in: on Debian and Ubuntu it only runs after an administrator installs ksmbd-tools and starts the service, and Red Hat family kernels historically have not enabled it by default. Some distributions, including recent AlmaLinux and CloudLinux releases, do not build KSMBD at all. An administrator who never deliberately turned it on is, in most cases, not running it. The verification commands later in this article settle that question per host rather than per headline, which matters because the gap between the headline population and the actually exposed population is the whole story of this disclosure.

The two flaws, in plain terms

ZDI-CAN-33774 is a race condition in protocol dispatch, and it needs no authentication. KSMBD selects protocol handlers for incoming traffic, and an attacker can send a burst of short SMB1 packets followed immediately by an SMB2 packet within the same TCP write. Worker threads can end up processing SMB1 data through an SMB2 handler, reading past the end of the shorter buffer. ZDI also identifies a write-past-buffer path available once an attacker has access to a share. Because the trigger needs no credentials, any server with KSMBD running and port 445 reachable is in scope for this one. It was tested against kernel 7.3-rc3.

ZDI-CAN-33549 is an integer underflow in the SMB Direct path, and it needs RDMA. The flaw lives in the RDMA transmit code. A client can supply buffer descriptors whose declared length exceeds the actual payload; after the code clamps the length, it subtracts the original, unclamped value from an unsigned variable, which wraps to a huge value, and a subsequent memory copy overruns the allocated buffer. Exploitation requires an RDMA-capable interface, a writable share, and SMB Direct negotiation, which is a rare combination outside high-performance storage environments. The finding is credited to HYEONTAE LEE working with ZDI and TrendAI, Trend Micro's AI scanner.

One caution that the tracking writeups handle honestly: ZDI classifies both as remote code execution, and the 9.0 scores follow that classification, but the public proof-of-concept material demonstrates memory disclosure and crashes rather than a working code-execution chain. That does not downgrade the risk; it describes the difference between what is published and what a motivated attacker may develop. The no-authentication trigger on the first flaw is what makes it the priority regardless.

Patch status, verified

The user-facing status question, still unpatched or not, has a dated answer. As of the latest tracking updates read for this article, neither flaw has a CVE identifier, because the kernel project assigns CVEs only after a stable-tree fix exists. For ZDI-CAN-33774, the KSMBD maintainer Namjae Jeon publicly replied that the issue was already fixed in his tree, pointing to commit 68f410faedaf, which has not yet reached mainline. For ZDI-CAN-33549, the SMB Direct maintainer Stefan Metzmacher submitted a fix for the next kernel development cycle, which had not landed in mainline or the integration tree at disclosure time. Fixes typically take weeks to reach stable branches after mainline acceptance, and longer to reach distribution kernels.

That pipeline, mainline acceptance, then stable backports, then vendor kernel releases, then your patch deployment, is the reason the practical guidance is exposure reduction rather than patching. There is nothing to deploy yet, and there will be a measurable window between a merged fix and a kernel your distribution ships. Treat this article's patch-status paragraph as having a shelf life: check your distribution's security feed, since the status will move.

The disclosure itself deserves its own note. The kernel's security reporting process asks researchers to send findings privately so fixes can be prepared before details are public. ZDI's own policy gives vendors 120 days. In this case the reports, several credited to an AI scanner, went to public lists without patches, and maintainers publicly flagged the deviation. Whatever the cause turns out to be, the effect is that the gap between public technical detail and an available fix is being crossed right now, which is exactly the gap coordinated disclosure exists to close.

Why KSMBD exists, and why its history matters

A fair question at this point is why the kernel ships a file server at all when Samba has done the job for decades. The answer is performance and footprint. An in-kernel server avoids context switches between kernel network code and a userspace daemon, which matters for high-throughput storage workloads, and it gives embedded systems and appliances an SMB option without pulling in Samba's considerable dependency tree. Those are legitimate engineering reasons, and they explain why the kernel community keeps maintaining KSMBD rather than removing it.

The trade-off is blast radius. A bug in a userspace file server crashes the file server; a bug in a kernel file server is a bug in kernel memory reachable from the network. KSMBD's short history reflects that: it has accumulated a series of high-severity findings since its introduction, including unauthenticated remote code execution issues that forced emergency patch cycles. The kernel community has responded with hardening and faster fixes each time, but the structural point stands: code that parses untrusted network traffic inside the kernel carries a permanently higher consequence per bug than the same code outside it.

That is why the standing advice from kernel developers and security trackers alike is to prefer Samba for production file sharing unless there is a specific, validated performance reason to use KSMBD. If a host runs KSMBD because an appliance vendor enabled it, that host inherits both the flaws of the moment and the next ones; if it runs KSMBD because someone chose it deliberately with a benchmark to justify the choice, the risk was at least priced in. Fleet owners who cannot say which category a host falls into should treat the inventory step below as urgent rather than optional.

The one-minute server check

Three commands answer most of the exposure question on any given host:

systemctl is-active ksmbd
lsmod | grep ksmbd
ss -tlnp | grep 445

An inactive service, no loaded module and nothing listening on port 445 means that host is not running the kernel SMB server, and these flaws do not apply to it. If the service is active and the share is not needed, stop it: systemctl disable --now ksmbd. If the module is loaded by something else on the host, check what started it before ruling exposure out. If the share is genuinely required, keep it off untrusted networks until fixed kernels arrive, and verify your firewall actually limits 445 the way you think it does, because the flaw that needs no authentication makes the firewall the only thing standing between an attacker and kernel memory on that host.

Two configuration notes from the tracking writeups matter for edge cases. AlmaLinux and CloudLinux 9 and 10 kernels do not build KSMBD, so those hosts are not affected regardless of configuration. And RDMA hardware is rare on general-purpose servers, which contains the second flaw's reach for most fleets; hosts that genuinely use SMB Direct for storage traffic are the exception and should treat that path as exposed now.

For organisations running fleets rather than single servers, run the same three commands through your existing automation, Ansible, Salt or plain SSH, and inventory the results. The output is a short list of hosts that need attention and a long list of hosts you can stop worrying about, which is a better artefact than any amount of headline reading.

The broader pattern: AI-found bugs and the disclosure clock

These two reports did not arrive alone. ZDI posted six reports to the kernel security team and, accidentally, to public lists across 20 and 21 October, including a serious local privilege escalation in the networking helper skb_zerocopy with public exploit code, a flaw in the VMware virtual GPU driver, an NVMe target issue and a ConnMan bug. Several are credited to TrendAI, Trend Micro's AI scanner. Kernel guidance updated in May 2026 treats bugs found by AI tools as public by definition, on the reasoning that widely available tools surface the same issues simultaneously, and directs such reports to subsystem lists rather than the private security queue.

That policy collision is now playing out in public: AI scanners finding bugs faster than humans can fix them, reporters treating AI-found bugs as pre-public, maintainers insisting the process exists for a reason, and disclosure windows shrinking from both directions at once. For server owners, the operational consequence is concrete: the assumption that public detail means a patch is available no longer holds, and exposure reduction, the boring work of not running services you do not need and not exposing ports you do not use, has quietly become the first control again rather than the fallback. The LiteLLM supply chain incident, covered in the LiteLLM supply chain attack article, made the same point from the package registry side: a poisoned version sat on PyPI for under two hours, and the defence that mattered was not a scanner but knowing what you had installed and what it should never do. It is the same conclusion this site keeps arriving at from different directions, whether the subject is agent-driven intrusion campaigns or the CERT-In advisory on AI agents: the faster the attacker's tooling gets, the more your defence rests on the few things that were true yesterday and stay true tomorrow, like a service that is simply not running.

Where the numbers stop

  • The CVSS 9.0 scores are ZDI's, and no CVE identifiers have been assigned as of this writing, which means vulnerability dashboards keyed to CVEs will not show these flaws yet. Manual checks are the only reliable inventory method until IDs exist.
  • The public proof-of-concept material demonstrates kernel memory disclosure and host crashes, not a working remote code execution chain. ZDI's classification and score describe the flaws' assessed potential, not published exploit results, and the published results may understate what is developable.
  • The write-past-buffer path in ZDI-CAN-33774 requires share access, per ZDI's report; only the race-trigger path is unauthenticated. The two conditions should not be merged in risk statements.
  • Patch status in this article is dated to the tracking sources read on publication day. A fix may merge to mainline at any time, and distribution backports will follow on their own schedules. Verify current status before acting on this paragraph.
  • No exploitation in the wild has been reported in the sources available as of publication. Absence of reporting is not evidence of absence.

FAQ

Do these KSMBD flaws affect my Linux server?

Only if the kernel's built-in SMB server is actually running and reachable. Most production Linux file servers use Samba, which is a separate, userspace program and is not affected. Run systemctl is-active ksmbd and lsmod | grep ksmbd; if the service is inactive and the module is not loaded, the flaws do not apply to that host. Many distribution kernels, including recent AlmaLinux and CloudLinux releases, do not build KSMBD at all.

Is there a patch available yet?

Not in a form you can deploy, as of this writing. The KSMBD maintainer has fixed one flaw in his development tree, the SMB Direct maintainer has submitted a fix for the next development cycle, but neither has reached mainline, and distribution kernels lag mainline by weeks. No CVE identifiers exist yet either, so scanners and patch dashboards will not track these until IDs are assigned. Check your distribution's security feed for the current status.

What should I do if I do run KSMBD?

Reduce exposure now rather than waiting for patches. If the share is not needed, stop and disable the service. If it is needed, restrict port 445 to trusted networks with firewall rules and verify the rules with an external scan, and treat the SMB Direct path as exposed if you use RDMA. Keep the affected hosts first in line when distribution kernels with the fixes ship, and confirm the running kernel version rather than assuming the package manager handled it.

The short version

Two CVSS 9.0 remote code execution flaws in the Linux kernel's KSMBD server were disclosed on public mailing lists before any fix was available, one reachable without authentication on any host with port 445 open, the other requiring the rare combination of RDMA and a writable share. Neither has a CVE or a merged mainline fix as of publication, fixes are moving through the maintainers' trees, and distribution kernels will lag further. The exposure test takes a minute per server, and most servers, running Samba or nothing at all, will fail the premises entirely. For the rest, the answer is the oldest one in the book: stop the service if you do not need it, wall it off if you do, and let the disclosure drama unfold without you.

Sources
Subscription Form