Your scanner says zero criticals and the exploit gets root

On 21 October, Trend Micro's Zero Day Initiative sent five Linux kernel bug reports to the project's security team and, by mistake, to the public development lists. Three of them carried full proof-of-concept code. None has a CVE, and one has already been used to get root on AlmaLinux, Debian and Ubuntu running kernels that are in production right now. Ask your vulnerability scanner this week and it will tell you there is nothing critical. And it will be right, because there is no number to count.

What went out, and where

The sequence is short. On 20 October at 00:17 UTC a report went out about ConnMan, the connection manager that runs in user space. On 21 October five more followed, these ones about the kernel, addressed to the project's security team and — by mistake — with the public lists in copy, among them the main kernel list and the networking one. On 22 October Phoronix picked it up and Greg Kroah-Hartman, the kernel's second in command, replied to the reports pointing out what had just happened: they were public, and they had arrived without a patch.

The one that affects you is not the 9.0

Sort that table by score and you start with the two nines, which is the wrong place. Both nines are in ksmbd, a component you have to switch on by hand and that most people do not have. The one that actually moves your day is the 7.8.

skb_zerocopy() fails to carry forward a flag marking a data fragment as shared. Without that flag, ESP decryption ends up writing over data living in the page cache, so an unprivileged process modifies a file it can read but has no permission to open for writing. Same family as Dirty Pipe, and from there to root is a short step. In TuxCare's testing that step was taken on AlmaLinux 8, 9 and 10, CloudLinux 9 and 10, Debian 12 and 13, and Ubuntu 24.04 and 26.04. These are not lab branches: they are the kernels booting your servers. And it sidesteps May's Dirty Frag fix (CVE-2026-43284): AlmaLinux ships that fix in all three versions, and falls anyway.

Now the nuance that does not make headlines and that decides whether this costs you sleep: it is local. Someone must already be able to run unprivileged code on that machine. So the question is not the score, it is who has a shell on that server. A CI runner executing anyone's branches, shared hosting — CloudLinux appearing on the tested list is no accident — containers running third-party workloads, or a server with developer accounts: there this is urgent today. A machine two administrators log into with a key and nobody else is a different conversation. CVSS cannot know which of the two is yours. You can.

The number is not a warning: it is a receipt

The project's own assignment policy puts it plainly: "No CVEs will be automatically assigned for unfixed security issues in the Linux kernel; assignment will only automatically happen after a fix is available and applied to a stable kernel tree." And it adds another rule people trip over: "No CVEs will be assigned for any issue found in a version of the kernel that is not currently being actively supported by the Stable/LTS kernel team."

We think the policy is right and we defend it: padding the count with identifiers for bugs nobody can yet fix protects no one, and feeds the fiction that a number is a solution. But it has a consequence you feel on a Tuesday morning. For as long as the window lasts — from "this is public" to "this is in a stable tree" — there is no number, and your toolchain has nowhere to put this. The scanner compares installed versions against a CVE database. The monthly report counts CVEs. The patching service level is measured in days since CVE publication. The dashboard the committee sees says zero criticals, and it is telling the truth: there is no critical with an identifier.

Put the dates side by side and the window stops being a detail. ZDI's disclosure policy is 120 days, which puts the deadline for publishing the official advisories for the five kernel reports on 18 February 2027. The CVE will arrive when the fix reaches a stable tree, before or after that date, but always after the fix. What eventually shows up in your scanner is not an alert about something you need to do: it is confirmation of something that already happened. The number is not a warning. It is a receipt.

ksmbd is not Samba, and you probably do not even have it

ksmbd is the SMB3 server that runs inside the kernel. It is not Samba, which lives in user space and is what you will find in the vast majority of places where somebody shares a folder. It was written for performance, and its split is spelled out in the kernel documentation: performance-bound operations — open, read, write, close — go inside; DCE/RPC and account management stay outside because that is the part which, quoting directly, "has historically resulted into a number of buffer overflow issues and dangerous security bugs". That sentence has been there for years.

In the kernel configuration the option is called, literally, "SMB3 server support (EXPERIMENTAL)". Debian and Ubuntu ship the module, but inert: it does nothing until somebody installs ksmbd-tools, configures a share and starts the service. AlmaLinux and CloudLinux do not build it at all, and Red Hat neither builds nor ships it. To have this switched on you must have switched it on deliberately. So the likeliest outcome is that these two nines are not about you.

There is a detail in the first one worth looking at, because it contradicts what you would expect. The documentation says ksmbd implements dialects 2.1, 3.0 and 3.1.1, "intentionally excludes security vulnerable SMB1 dialect". And yet the described trigger is a burst of short SMB1 packets followed by an SMB2 packet in the same TCP write, which leaves a worker handling SMB1 data with an SMB2 handler and reading past the end of the shorter buffer. Both things are true: ksmbd does not discard SMB1, it partly implements it on purpose — it keeps an SMB1 operations table with its negotiate handler — because SMB1 multi-protocol negotiate is the legitimate route by which an old client upgrades to SMB2. The bug is not in the dialect you support nor in the one you reject, but in the instant you switch between them. Excluding a dialect from the feature list does not remove it from the code.

What to check, and the traps in checking it

On each Linux machine that shares files:

lsmod | grep ksmbd
modinfo ksmbd 2>/dev/null | head -2
systemctl is-enabled ksmbd 2>/dev/null
ss -Hltnp 'sport = :445'
grep -E 'CONFIG_SMB_SERVER(_SMBDIRECT)?=' /boot/config-$(uname -r) \
  || zcat /proc/config.gz | grep -E 'CONFIG_SMB_SERVER(_SMBDIRECT)?='

The traps, in order of how likely they are to bite. An empty lsmod does not settle it: if the kernel was built with CONFIG_SMB_SERVER=y the server is compiled in and never shows up as a module. modinfo answers better than the config does: =m tells you how the kernel was built, not which file is installed — on Ubuntu the module lives in a separate extra-modules package, and without it modprobe fails. And in ss, use the port filter rather than grep ':445', which also matches 4450 and 4455; besides, for ksmbd the process column comes back empty, because the listener is the kernel and there is no process to point at. If you expect a name there and see none, that does not mean nobody is listening.

The second bug additionally needs an RDMA-capable card and CONFIG_SMB_SERVER_SMBDIRECT. An empty ls /sys/class/infiniband points to no, with the caveat that the directory may not exist at all if the RDMA core is not loaded, and that software RoCE can be created later with no hardware whatsoever.

If the answer is yes and you do not need it, what holds is not unloading the module: modprobe -r ksmbd fails while it is in use and nothing stops it loading again at the next boot. What holds is masking the service and moving the share to Samba. Not because user space is magic — Samba has its own history of bugs — but because an overflow inside the kernel runs with kernel privilege and one in a daemon runs with the daemon's. If you cannot switch it off today, the mitigation is a network one: port 445 should not be reachable from the internet, nor from the guest VLAN, nor from the whole office out of habit. That is fixed with a rule, not with a maintenance window.

And the honest limit of the method: these lines answer about that machine. The question that matters is about all of them. The jump from one machine to the whole estate is where you find out whether you have an inventory that answers or a spreadsheet somebody updated in March.

A carbon-copy field opened the window

This week's exposure was not opened by an attacker or by a kernel design flaw. It was opened by a carbon-copy field in an email. A coordinated disclosure procedure, which exists precisely so that details do not go out ahead of the fix, bypassed itself through one recipient too many.

Something similar shows up in the reference study on why large services fail: in two of the three services analysed, operator error is the leading cause of failure, and more than half of those errors — in one case nearly all — were configuration errors. Nothing has fallen over here, but the shape is identical. Processes are run by people, and a person can get the recipient field wrong.

What you can design is what comes next. It starts with an inventory that answers: not an asset list, but a source of truth that knows which kernel each node boots and which services listen on which port. We run NetBox for that and Zabbix with SmokePing for telemetry; the tool is not the point, the point is that "how many machines have this?" is answered by querying something rather than by asking somebody. It continues with exposure, the only control that does not depend on a patch existing: a port that cannot be reached does not force you to run, and deciding who reaches what is the work of cybersecurity and Zero Trust — nobody reaches a service for being inside the office, but because it is theirs to reach.

And it ends in the one of the three that cannot be automated: somebody reading your distribution's channel when the fix appears, deciding whether tonight is the night, and writing down why. That is what we sell as 24x7 IT support, and we sell it with the limit stated up front: there is no scanner that sees what has no number, and we do not have one either. What can be sustained is the rota, and having somebody at two in the morning who can tell apart what can wait until Tuesday and what cannot.

The uncomfortable question

It is not "do I have ksmbd?". That one is answered in thirty seconds and quite probably with a no. The uncomfortable question is how long your organisation took to answer it without a CVE to paste into a search box. If the answer is "I do not know yet", the gap is not in SMB: it is that your ability to say anything about your own estate depends on somebody outside issuing a number.

We ran into the same gap when we wrote that the fixed versions in an advisory match no branch a Proxmox node actually boots: the advisory tells you the bug exists, not whether the binary you boot carries it. And when the fix arrives, it will arrive with its own cost, because we already saw that patching the kernel means rebooting, and rebooting erases the evidence. This time there is not even an advisory: there are six emails that went out through the side door.

If you want us to look with you at what is listening on port 445 in your network today, who has a shell on the servers that matter and how long you take to answer the next question of this kind, let us talk. The deliverable is a list, not a project.

Sources. The timeline (ConnMan report on 20 October 2026 at 00:17 UTC; five kernel reports on 21 October to the security team and, by mistake, to public lists; coverage and Greg Kroah-Hartman's reply on 22 October), the six ZDI-CAN identifiers with their scores and fix status, Namjae Jeon's reply about commit 68f410faedaf, Stefan Metzmacher's working branch for the 7.5 cycle, the 18 February 2027 disclosure deadline and the exploitation results with skb_zerocopy — root verified on AlmaLinux 8, 9 and 10, CloudLinux 9 and 10, Debian 12 and 13 and Ubuntu 24.04 and 26.04, bypassing the Dirty Frag fix (CVE-2026-43284) — come from Phoronix, TuxCare and Security Online. TuxCare sells rebootless kernel patching: its commercial interest is declared, as is ours. The CVE assignment policy and both quotations come from the kernel documentation; the description of ksmbd, the split between kernel and user space, the "SMB3 server support (EXPERIMENTAL)" option and the supported dialects, from the ksmbd documentation. That Red Hat neither builds nor ships ksmbd is published in its knowledge base. The existence of an SMB1 operations table with its negotiate handler in ksmbd is verifiable in the kernel source itself (fs/smb/server/smb_common.c). The study on failure causes is Oppenheimer, Ganapathi and Patterson, "Why Do Internet Services Fail, and What Can Be Done About It?" (USENIX USITS, 2003). The reading that a local bug matters according to who has a shell, the warnings about the traps in each check command, the thesis that the number is a receipt rather than a warning, and the reading of the operations-table switch are our own judgement, not claims made by the sources cited. everyWAN provides managed support and security services: the conflict of interest is declared. Cover photo: "Front of server racks at NERSC", by Derrick Coetzee, Wikimedia Commons, CC0 1.0.