Vulnerabilities

Unpatched Linux ksmbd RCE flaws go public with no CVE or fix

Two CVSS 9.0 flaws in Linux’s in-kernel ksmbd SMB server are public with no released fix or CVE. Find it on NAS and appliances, disable it, block port 445.

Server illustration with the headline Linux ksmbd flaws public before any fix

Two remote code execution bugs in ksmbd, the SMB file server that ships inside the Linux kernel, are now public with no released fix and no CVE. Any organisation with a NAS box, single-board computer or appliance that serves files through ksmbd should check for it today and switch it off if it is not needed.

What happened

Between 21 and 22 October 2026, vulnerability reports from Trend Micro’s ZDI describing two critical flaws in ksmbd landed on public Linux kernel mailing lists, complete with technical detail, before any patch had shipped. Both are scored 9.0 on the CVSS scale by the reporter. One, tracked as ZDI-CAN-33774, can be reached over the network on TCP port 445 without logging in. The other, ZDI-CAN-33549, sits in the SMB Direct transport and needs RDMA networking to be in play.

As of 23 October, neither bug has a fix in the mainline kernel, and neither has a CVE identifier. The kernel project only assigns CVEs once a fix reaches a stable tree, so scanners and patch dashboards that key off CVE numbers will not flag these issues.

Three lower-risk kernel reports arrived alongside them: a local privilege escalation in skb_zerocopy networking code (CVSS 7.8), an out-of-bounds write in the vmwgfx VMware guest graphics driver and an information leak in the NVMe-over-fabrics target. None involves ksmbd.

The technical picture

Despite speaking the same protocol, ksmbd shares no code with Samba. Samsung originally wrote it as an SMB3 server living inside the kernel, with a small userspace helper package, ksmbd-tools. Its selling point is low overhead, which is why it tends to appear on low-power kit: home and small-office NAS devices, ARM boards and embedded appliances. It is disabled in the upstream default configuration, and Red Hat states that Red Hat Enterprise Linux does not ship it. Ordinary Samba installations are not affected by either flaw.

The first bug, ZDI-CAN-33774, is a timing flaw in the way ksmbd picks a protocol handler for each incoming request. The handler choice is fixed when work is queued, but the worker thread only reads it later. By mixing SMB1 and SMB2 traffic in the right way, a remote client can get SMB2 code processing a shorter SMB1 buffer, so the server reads beyond the end of it. According to the reports, a related out-of-bounds write exists in the parsing of security descriptors, the permission data a client supplies when changing file access. That write path needs access to a share; aggregator pwn.watch summarises the requirement as a guest-accessible share. Winning the race is hard, hence the high attack complexity rating, but no credentials are needed to try.

The second, ZDI-CAN-33549, lives in the SMB Direct code. Malformed RDMA buffer descriptors can make a size calculation wrap round to an enormous value, after which a memory copy overruns its destination. An attacker needs RDMA hardware (or the rxe software emulation), write access to a share and a session using SMB Direct, which is compiled in only when a non-default build option is chosen. In practice that makes it mostly a data centre concern.

On fixes, the picture is patchy. According to pwn.watch, ksmbd maintainer Namjae Jeon has said the race is already addressed in his own tree, and SMB Direct maintainer Stefan Metzmacher believes his branch aimed at Linux 7.5 probably resolves the underflow. Neither change is in a released kernel, and distribution backports will follow only after that. No exploitation has been reported.

Checklist of six actions to reduce exposure to the unpatched Linux ksmbd flaws, from finding ksmbd to tracking fixes manually

Why it matters for UK organisations

Large UK estates built on Red Hat or mainstream Samba are unlikely to be directly exposed. The risk sits in the long tail: the branch office NAS, the file share on a hobby-class board in a lab, the appliance a supplier installed years ago. Such devices drop out of asset registers, run vendor kernels months behind upstream and are sometimes exposed through a hasty port forward.

For small businesses working towards Cyber Essentials, any such device used for business data is in scope, and the scheme’s 14-day rule for high and critical fixes will start ticking once vendors publish updates. Until then, the controls that matter are secure configuration and firewalls, not patching.

The disclosure itself is context worth understanding. Stable kernel maintainer Greg Kroah-Hartman responded to several reports within minutes, telling the sender: “Please fix your submission process.” The reports credit TrendAI, Trend Micro’s AI scanner, and kernel security guidance revised in May 2026 treats AI-found bugs as effectively public and asks for them to go to subsystem lists, ideally with patches or a clear impact analysis. These came without patches. Whether the Zero Day Initiative was following that rule or simply made a mistake, Trend Micro had not explained publicly by 23 October. For defenders the outcome is the same: details are out, fixes are not.

Expert view

In my experience, in-kernel network services are where a parsing bug hurts most. A memory corruption flaw in a userspace daemon usually lands you as a service account; the same flaw in kernel space puts an attacker at the top of the box in one move. Complexity ratings also tend to fall once researchers have a full write-up, and here they already do.

When we test small-office networks, SMB on embedded storage is one of the most common findings, often with a guest share left enabled for convenience. Guest access plus a pre-authentication race is not a combination I would want on any network segment, internal or otherwise.

The missing CVE is the operational trap. Plenty of organisations run patch and vulnerability programmes entirely off CVE feeds. A bug with no number does not appear in the weekly report, so nobody is asked to act. Someone has to go and look.

What to do now

  1. Find ksmbd. On Linux hosts, check whether the module is loaded or the service is running (for example with lsmod or systemctl status ksmbd). For NAS devices and appliances, ask the vendor directly whether the product uses ksmbd or Samba; do not assume.
  2. Disable it where it is not needed. Stop the service, unload the module and blacklist it so it does not return after a reboot. This removes exposure to both flaws (Cyber Essentials: secure configuration).
  3. Block TCP 445 at the perimeter. SMB should never be reachable from the internet. Check router port forwards and cloud security groups as well as the main firewall (Cyber Essentials: firewalls).
  4. Remove guest shares. Require authentication on every share and restrict SMB to the internal segments that genuinely need it (Cyber Essentials: user access control).
  5. Leave SMB Direct off unless your storage network depends on RDMA.
  6. Track fixes manually. Watch your distribution’s security tracker and NAS vendors’ advisories rather than waiting for CVE-driven alerts, and patch within 14 days once updates appear (Cyber Essentials: security update management).

Bottom line

Most UK organisations will find they do not run ksmbd, but the ones that do are likely to be running it on the least-watched kit in the building. With working detail now public and no CVE to trigger the usual processes, the sensible response is a quick hunt, a firm switch-off where possible and a blocked port 445 everywhere else.

Sources

Related Posts