ZDI Kernel Reports on Public LKML: ksmbd and skb_zerocopy Explained

On 21 October 2026, five unpatched Linux kernel vulnerability reports from Trend Micro's Zero Day Initiative (ZDI) landed on public kernel mailing lists instead of staying private. Two hit ksmbd, the in-kernel SMB server (CVSS 9.0 each), and one, in skb_zerocopy(), gives local root on mainstream distributions. Disable ksmbd if unused, restrict unprivileged user namespaces, and install distro kernels as they ship.

None of the five has a CVE yet, and as of 22 October none had a fix merged into the mainline kernel. Three of the reports carried full analysis and proof of concept code, according to a technical write-up by a commercial Linux support vendor that reproduced the skb_zerocopy bug to root on AlmaLinux, CloudLinux, Debian and Ubuntu. That bug also gets around the fix for Dirty Frag (CVE-2026-43284), the kernel privilege escalation patched in May, so a fleet that is fully patched for Dirty Frag is still exposed.

This post covers what was posted and when (to the minute, from the list archives), what each report says in plain language, which distributions and kernels are exposed, how to check every host, what to change today, what the maintainers said, and what is still unknown. There is no exploit detail here.

What happened

ZDI buys vulnerability research and coordinates disclosure with vendors. Its usual practice is to report privately and publish after a fix or after its 120 day deadline. On the evening of 21 October (UTC), ZDI sent five Linux kernel reports addressed to the kernel security team at security@kernel.org. The same emails also carried, in the Cc line, the subsystem maintainers and the public mailing lists for those subsystems: LKML, netdev, linux-cifs, dri-devel and linux-nvme. Public list traffic is archived and mirrored within minutes, so the reports, including proof of concept source for three of them, became public as soon as they were sent.

A sixth report, about ConnMan (a userspace network manager, not part of the kernel), reached the public ConnMan list a day earlier, on 20 October.

Phoronix reported the posting on the morning of 22 October and said it "seemingly was a mistake." The Linux support vendor's write-up also describes the public Cc as a mistake. ZDI has not described it that way in public. In its reply on netdev on 22 October, ZDI defended its report format and restated its disclosure policy, and did not address the public Cc. Cyber Security News wrote on 23 October that ZDI had not explained the routing and that it remained unclear whether it was an error. We describe it here as an unintended public disclosure, because that is how the maintainers and most reporting treated it, but we have no statement from ZDI that confirms it.

Greg Kroah-Hartman, the stable kernel maintainer, replied to the reports pointing out that they were now public and had arrived without patches. Eric Dumazet, a networking maintainer, said netdev already had the skb_zerocopy bug from another reporter, with a patch, a week earlier. A one line fix for that bug was posted to netdev on 22 October and reviewed the same day. The ksmbd maintainer, Namjae Jeon, said one of the two ksmbd bugs was already fixed in his tree.

Timeline

All times are UTC, converted from the time zones in the archived message headers. Where a source gave only a date, we say so.

Technical details

Everything in this section comes from the archived list messages or from the sources named in each row. Values we could not read in a fetched source are marked as unconfirmed.

The six reports

The CVSS numbers are ZDI's own scores. No CVE numbers, NVD scores or distribution scores exist yet for any of them.

ZDI-CAN-33367: the skb_zerocopy report header

From the netdev archive copy of the original message:

The Cc entries labelled "maintainer:" and "open list:" match the format of the kernel's get_maintainer.pl output, which lists both people and public lists for a file. That is an observation from the header, not a confirmed explanation. The kernel's reporting guide tells reporters to use that script to find maintainers, and separately says "Do not send it to a public list at this stage."

The fix for ZDI-CAN-33367

The patch makes skb_zerocopy() copy the SKBFL_SHARED_FRAG flag from the source buffer to the destination when it transfers fragment descriptors, which is what the other fragment transfer helpers already do. The commit message notes that v2 corrected the first Fixes tag to af2806f8f90a, because skb_zerocopy() did not exist yet when an earlier commit was merged. The vendor write-up dates af2806f8f90a to kernel 3.14, which is why CentOS 6 (kernel 2.6.32) is not affected.

The second Fixes tag points at the Dirty Frag fix. Debian's tracker lists the upstream Dirty Frag commit as f4c50a4034e62ab75f1d5cdd191dd5f9c77fdff4, first in 7.1-rc3. In other words, the new patch closes a gap in the May fix rather than a brand new bug class.

Conditions for the skb_zerocopy proof of concept

The vendor lists the conditions the public proof of concept needs. We list them because they are the levers defenders can pull, not as instructions.

• Unprivileged user namespaces enabled.
• The ability to load, or auto-load, these modules: nfnetlink_queue, nft_queue, nlmon, cls_u32, act_pedit, act_mirred, esp4, plus crypto modules for a non-AEAD ESP cipher.
• No KASLR leak and no special capabilities.
• On Debian 12 (kernel 6.1), a different route is used to get file pages into a packet, so the bug is reachable there too.
• On Ubuntu 24.04 and later, the proof of concept got around Ubuntu's AppArmor restriction on unprivileged user namespaces by using a container launcher's AppArmor profile.

Distribution results for ZDI-CAN-33367 (vendor testing)

These are the Linux support vendor's own results. We have not reproduced them and no distribution had published its own assessment as of 22 October.

Not tested by the vendor: extended support kernels, FIPS kernels, Oracle UEK, cloud provider kernels and Ubuntu HWE kernels. Treat those as unknown, not safe.

The two ksmbd reports

Several outlets headline both ksmbd bugs as remote code execution. ZDI's titles describe them that way, but the public proof of concept code demonstrates memory disclosure and crashes, not code execution. That is still serious: a pre-authentication heap leak plus a crash on an internet facing file server is a bad combination. But the honest description today is "remote, unauthenticated, memory disclosure and denial of service, with a described write path."

ksmbd build status by distribution

Red Hat's statement dates from the 2022 ZDI ksmbd reports and was last updated in June 2024, so recheck it once Red Hat publishes anything for these reports. We did not find a SUSE statement for these reports and do not make a claim about SUSE kernels.

The ZDI-CAN numbers without detail

ZDI-CAN-34068 (vmwgfx, 8.8) matters to Linux guests running on VMware with the virtual GPU driver loaded. ZDI-CAN-34076 (nvmet, 8.6) matters to hosts acting as NVMe over Fabrics targets. Only titles are public, so there is nothing to act on beyond inventory and watching for fixes. Phoronix lists Greg Kroah-Hartman's replies on those threads with message IDs 2026102254-protector-seventy-6454@gregkh (dri-devel) and 2026102226-duly-imprison-a2c1@gregkh.

Dirty Frag, for reference

The vendor write-up says AlmaLinux 8 through 10 ship the Dirty Frag fix according to their changelogs and remain vulnerable to ZDI-CAN-33367. If your May response was "we patched Dirty Frag, we are done," that answer no longer holds.

Indicators of compromise

There are none. No source reports exploitation in the wild, and no advisory lists hashes, IP addresses or other indicators. The vendor write-up, SecurityOnline, Cyber Security News and Threat Landscape all say no exploitation had been reported as of 22 to 23 October.

How these bugs work, in plain language

Page cache writes, again

Linux keeps recently read file data in memory, in the page cache. When a program reads a file it cannot write to, such as a system binary, the bytes come from page cache pages that the kernel shares between everyone reading that file. Several modern network paths avoid copying data by passing references to those same pages around inside socket buffers (skbs). That is fast, and it is safe only as long as nothing writes into a page it does not own.

Dirty Frag showed that IPsec's ESP code could decrypt a packet in place, overwriting the bytes of a shared page. The May fix added a marker, SKBFL_SHARED_FRAG, so that code paths which splice file pages into packets tag them, and ESP makes a private copy before decrypting anything tagged.

ZDI-CAN-33367 is a path that loses the marker. skb_zerocopy() moves fragment references from one skb to another and takes a reference on each page, but did not copy the marker across. Downstream, ESP sees no marker and decrypts in place. The result, as the report and the vendor describe it, is that an unprivileged process can change the cached contents of a file it can read but cannot open for writing. The change lives in memory, not on disk, until the cache is dropped or the machine reboots, which is how the Dirty Frag family behaves too.

Why do unprivileged user namespaces matter? Setting up the networking pieces involved normally needs CAP_NET_ADMIN. Inside a new user namespace, an ordinary user gets that capability over a private network stack. That is the point of user namespaces, and it is why rootless containers and browser sandboxes work, but it also exposes a lot of kernel networking code to unprivileged users.

ksmbd

ksmbd is an SMB3 file server that runs inside the kernel, as an alternative to Samba, which runs in userspace. It is aimed at embedded and performance sensitive setups. It was merged in kernel 5.15 and has had several serious bugs since, including a ZDI batch disclosed in December 2022 that Red Hat also responded to. Running it means SMB parsing happens in kernel memory, so a parsing bug is a kernel bug.

ZDI-CAN-33774 is a race in how ksmbd decides which protocol handler processes an incoming request. Under the right timing, a worker can process data from one SMB dialect using the handler for another, and read past the end of a shorter buffer. Because SMB negotiation happens before login, no credentials are needed. ZDI-CAN-33549 sits in SMB Direct, the variant of SMB that runs over RDMA network hardware. A length value can wrap around to a very large number after a subtraction, and a later copy then overruns its buffer.

The important practical point: ksmbd is not Samba. If your file servers run Samba (smbd), these two reports do not apply to them. They apply only where the ksmbd module is loaded and the ksmbd service is running.

Who is affected

What to do now

The order matters. Mitigate the local root path first, because it is the one with working public code and the widest reach. Then deal with ksmbd. Then plan the kernel updates.

Step 1: list the kernels you actually run

Package lists tell you what is installed. You need what is running.

# Running kernel on one host
uname -r

# Installed kernels
rpm -q kernel kernel-core 2>/dev/null      # RHEL, AlmaLinux, CloudLinux, Rocky
dpkg -l 'linux-image-*' | awk '/^ii/{print $2, $3}'   # Debian, Ubuntu

# Is a reboot pending onto a newer kernel?
needs-restarting -r 2>/dev/null            # RHEL family (dnf-utils / yum-utils)
[ -f /var/run/reboot-required ] && cat /var/run/reboot-required   # Ubuntu

Across a fleet, collect the same with whatever you already run. For example, with Ansible:

ansible all -m command -a 'uname -r' -o | sort -k4 | uniq -c -f3

Group the results by distribution and kernel line, and match them against the table in the technical section. Anything not in that table (UEK, cloud kernels, HWE, custom builds) goes in the "unknown, treat as exposed" pile.

Step 2: check the user namespace setting on every host

# 0 means unprivileged user namespaces are off
sysctl user.max_user_namespaces

# Debian and some Debian derived kernels also have this switch
sysctl kernel.unprivileged_userns_clone 2>/dev/null

# Ubuntu 23.10 and later: AppArmor restriction on unprivileged userns
sysctl kernel.apparmor_restrict_unprivileged_userns 2>/dev/null

Do not treat Ubuntu's AppArmor restriction as a fix. The vendor's testing found the proof of concept got around it on 24.04 and 26.04 through a container launcher's profile.

Step 3: decide on user namespaces, host by host

The strongest mitigation the vendor offers is to turn unprivileged user namespaces off:

echo 'user.max_user_namespaces = 0' | sudo tee /etc/sysctl.d/99-zdi-33367.conf
sudo sysctl --system
sysctl user.max_user_namespaces   # expect 0

This breaks things. Rootless Podman and Docker, Flatpak, some browser sandboxes, and some CI tools that build images without root all depend on user namespaces. Sort hosts into two groups:

1. Servers that never need user namespaces (web servers, databases, most VMs that run system services): turn them off now.
2. Hosts that do (rootless container hosts, developer workstations, CI runners that build images): leave them on and apply Step 4, then prioritise these for the kernel update.

On Debian kernels you can set kernel.unprivileged_userns_clone = 0 instead, which blocks unprivileged creation while still allowing root to create namespaces. Test it on one host first.

Step 4: block the modules the public proof of concept needs

A lighter option, from the same write-up, is to stop two of the needed modules from loading. The vendor says this may not cover every path, so treat it as a layer, not a fix.

printf 'install nlmon /bin/false\ninstall act_pedit /bin/false\n' | \
  sudo tee /etc/modprobe.d/zdi-33367.conf

# Check they are not already loaded, and unload if they are
lsmod | grep -E '^(nlmon|act_pedit) '
sudo modprobe -r nlmon act_pedit 2>/dev/null

# Confirm the block is in effect (should print the /bin/false rule)
modprobe -n -v nlmon
modprobe -n -v act_pedit

If you blocked esp4 in May as a Dirty Frag mitigation and you do not use IPsec, keep that block. If you do use IPsec on a host, you cannot block esp4, and your options are the user namespace setting and the kernel update.

Check the change against anything that legitimately uses traffic control actions. act_pedit is used by some packet editing tc setups and by a few container network plugins. nlmon is a netlink monitoring device used for debugging. Most servers use neither.

Step 5: find and disable ksmbd where it is not needed

# Is the module available, loaded, and is the service running?
modinfo ksmbd >/dev/null 2>&1 && echo "ksmbd module available" || echo "ksmbd not built"
lsmod | grep -E '^ksmbd '
systemctl is-active ksmbd 2>/dev/null

# Kernel config, for the module and SMB Direct
grep -E 'CONFIG_SMB_SERVER(_SMBDIRECT)?=' /boot/config-$(uname -r)

# Userspace tools that start it
dpkg -l ksmbd-tools 2>/dev/null | awk '/^ii/'
rpm -q ksmbd-tools 2>/dev/null

# Who is listening on 445 (ksmbd shows no process name, Samba shows smbd)
sudo ss -ltnp 'sport = :445'

If ksmbd is running and nobody needs it:

sudo systemctl disable --now ksmbd
sudo modprobe -r ksmbd
printf 'blacklist ksmbd\ninstall ksmbd /bin/false\n' | sudo tee /etc/modprobe.d/disable-ksmbd.conf
# Rebuild the initramfs so the block applies early on boot
sudo update-initramfs -u        # Debian, Ubuntu
sudo dracut -f                  # RHEL family, SUSE

If ksmbd is needed, keep port 445 off untrusted networks and keep guest access off:

# nftables: allow SMB only from a trusted subnet (adjust table and chain names)
sudo nft add rule inet filter input ip saddr != 10.0.0.0/8 tcp dport 445 drop

# ufw
# ufw evaluates rules in order, so add the allow before the deny
sudo ufw allow from 10.0.0.0/8 to any port 445 proto tcp
sudo ufw deny 445/tcp

# firewalld
sudo firewall-cmd --permanent --remove-service=samba
sudo firewall-cmd --reload

Review /etc/ksmbd/ksmbd.conf for guest ok and writeable settings on every share, and turn off SMB Direct where you do not use RDMA. That removes the preconditions for ZDI-CAN-33549.

Step 6: install distribution kernels as they ship, then reboot

As of 22 October there was nothing to install for these reports. When fixes arrive, they will come as normal kernel updates:

# Debian, Ubuntu
sudo apt update && sudo apt full-upgrade

# RHEL, AlmaLinux, CloudLinux, Rocky
sudo dnf upgrade kernel kernel-core

# SUSE
sudo zypper patch

Then reboot, or apply a live patch if your vendor offers one, and confirm with uname -r. Installing a new kernel without rebooting changes nothing.

To check whether a given package contains the skb_zerocopy fix before the CVE exists, look for the patch subject in the changelog:

rpm -q --changelog kernel | grep -i 'skb_zerocopy'
apt changelog linux-image-$(uname -r) 2>/dev/null | grep -i 'skb_zerocopy'

Distribution changelogs do not always carry upstream subjects word for word, so a miss is not proof the fix is absent. The CVE, once assigned, will be the reliable key.

Step 7: write down what you changed and when to undo it

User namespace and module blocks are temporary. Record which hosts got which change, with a plan to remove them once the fixed kernel is running and verified. Mitigations that never come off become the reason a CI runner fails mysteriously a year later.

Detection: what you can look for

There are no indicators of compromise, and the skb_zerocopy bug changes cached file contents in memory without touching the disk, so file integrity tools that hash files on disk may not notice. A few things are still worth doing:

• Watch for unexpected module loads. nlmon, act_pedit, nft_queue and cls_u32 showing up on a web server is unusual. A simple daily check: lsmod | grep -E '^(nlmon|act_pedit|nft_queue|nfnetlink_queue|cls_u32|act_mirred|esp4) '. Audit rules on init_module and finit_module syscalls give you who and when.
• Watch user namespace creation by service accounts. An auditd rule on unshare and clone with namespace flags, or your EDR's equivalent, scoped to service accounts that never need namespaces, is a high signal alert.
• Watch for ksmbd crashes. A ksmbd host that oopses or reboots unexpectedly should be treated as possibly targeted. Look for ksmbd in journalctl -k and in your kernel crash collection.
• Compare in-memory binaries after a suspected event. Because the change lives in the page cache, dropping caches or rebooting clears it, which also clears your evidence. If you suspect something, capture memory or at least hash the suspicious file through a fresh read after a cache drop and compare it to the package checksum (rpm -V or debsums) before you reboot.

What changed since the first reports

• From "mistake" to an open question. Early coverage, starting with Phoronix, called the public posting a mistake. ZDI's 22 October reply did not use that word and focused on its policy. By 23 October, Cyber Security News wrote that the routing was still unexplained.
• The skb_zerocopy bug was already known. Eric Dumazet's reply showed netdev had the bug and a patch a week before ZDI's report. The v2 patch posted on 22 October is credited to Zizhen Liu, not to ZDI.
• A fix exists for the local root, just not shipped. Within about 13 hours of the report appearing, a two line patch with a Cc to stable was posted and reviewed by a maintainer.
• The ksmbd fixes are split. One is in the ksmbd maintainer tree, one is either in a 7.5 branch or still being confirmed, depending on the source.
• Distribution reach is clearer. The vendor's testing narrowed the ksmbd risk (not built on EL 9 and 10, opt-in on Debian and Ubuntu) and widened the local root risk (root on EL 8 to 10, Debian 12 and 13, Ubuntu 24.04 and 26.04).

The disclosure process argument

The thread on netdev turned into a public argument about how vulnerability brokers and kernel maintainers work together. It is worth understanding because it shapes how fast fixes arrive in your fleet.

The kernel's own reporting guide is short and specific. Send reports to the maintainers of the affected code, found with get_maintainer.pl, and Cc security@kernel.org if there are only one or two people. Do not use a public list at this stage. Include a version range, a reproducer that is not a binary, and ideally a tested patch. Embargoes are short, up to 7 calendar days from the start of the release process, and up to 14 in exceptional cases. The security team does not assign CVEs. And the guide now says bugs found with AI assistance should be treated as public; Threat Landscape dates that change to May 2026.

Maintainers on the thread were frank. Eric Dumazet cut the ZDI report as "Way too long, I could not see a patch in it." Willy Tarreau said ZDI acts as "an insulation layer between reporters and developers," because the person who found the bug cannot be reached to test a fix. He also said more than 30 reports had arrived in one day, a volume he linked to AI driven bug hunting, and asked that even half of ZDI's reports come with a tested patch.

ZDI's position, in its own reply, was that it has filed around 1,000 cases over ten years in much the same format, that writing patches is "overhead we cannot support," and that it publishes at rejection or after 120 days, whichever comes first.

For defenders, the takeaway is not who is right. It is that two different clocks run at once. The kernel works on days. ZDI works on 120 days. Distributions then add their own build, test and release time. When a report escapes early, defenders get the attacker's clock with none of the fix pipeline finished. Our post on AI found vulnerabilities after PHP2Shell and PwnEscape covers why that volume of reports is now normal, and why patch planning has to assume it.

Disputes and inconsistencies in the sources

• "Remote code execution." Phoronix, Slashdot and several others call both ksmbd bugs RCE, following ZDI's titles. The public proof of concept code shows a heap leak and crashes. Treat them as serious remote memory corruption, and do not repeat "RCE" as established.
• Was it a mistake? Phoronix said "seemingly"; the vendor write-up says "by mistake"; Cyber Security News says it is unclear; ZDI has not said.
• Dates. The ConnMan report was public on 20 October, the kernel reports on the evening of 21 October UTC, and some outlets date all of it to 22 October, when coverage began. SecurityOnline gives 22 October for the posting.
• ZDI-CAN-33549 fix. Phoronix says a patch is in a 7.5 branch; Threat Landscape says it was submitted by Stefan Metzmacher for the next cycle and not merged; the vendor says the maintainer only believes a 7.5 branch fix covers it.
• ConnMan score. The vendor lists 7.8; SecurityOnline says no score was given.
• Root results. All the "root verified" results come from one commercial vendor's testing. They are detailed and credible, but they are not a distribution statement.
• Port 445 advice. Blocking 445 from untrusted networks is sensible general advice that several outlets give. It did not come from the kernel maintainers.

Open questions

• When will CVE numbers be assigned? Threat Landscape says the kernel CNA assigns CVEs once a fix reaches a stable tree, which means distributions' trackers will stay empty until then.
• Will the skb_zerocopy patch go to every stable branch back to 5.10 and 5.15? It carries a Cc to stable, but backports to old kernels sometimes need rework.
• Does the out of bounds write path in ZDI-CAN-33774 turn into code execution in practice? Nobody has shown it publicly.
• Does commit 68f410faedaf fully close ZDI-CAN-33774, and is ZDI-CAN-33549 actually covered by the 7.5 branch work?
• What are the vmwgfx and nvmet bugs? Only titles are public.
• Will ZDI change its routing, and will it start putting reporters in direct contact with maintainers, as Willy Tarreau asked?
• Are other distributions, including SUSE and Oracle UEK, exposed in the same way the vendor's tested kernels are?

What would have helped

Practices any team can use

• A runtime kernel inventory, not a package list. "Which hosts run which kernel, which modules are loaded, and is ksmbd running" is a five minute question if you collect it daily and a two day project if you do not. Our guide to using SBOMs and inventory in incident response applies to hosts as much as to applications.
• Default off kernel attack surface. Hardened baselines that set user.max_user_namespaces = 0 on servers that never need it, and blocklist rarely used modules (nlmon, act_pedit, ksmbd, unneeded esp4), would have made this a non-event for most of a fleet. Dirty Frag in May was the warning; this report is the second hit on the same surface.
• A triage path for "public proof of concept, no CVE, no patch." Many vulnerability programs key everything on a CVE ID. That would have left this invisible for days or weeks. A team needs a way to open an incident from a mailing list thread or a trusted write-up, assign an owner and roll out mitigations before any database entry exists.
• Separate who can run code locally. Local privilege escalation bugs matter most where untrusted users or workloads share a kernel: CI runners, shared hosting, build hosts. Ephemeral, single tenant runners and VMs per tenant reduce how much one kernel bug can reach.
• A reboot or live patch habit. Kernel fixes only help after a reboot or a live patch. Teams that already reboot monthly will absorb this fix calmly. Our PwnEscape post covers reboot and live migration planning for virtualization hosts.
• For disclosers: strip public lists from embargoed reports. If you copy the output of get_maintainer.pl into a private report, remove every "open list" entry first. A small pre-send check on the Cc line would have kept these reports private.

Where Safeguard fits

Be clear on the limits first. Safeguard does not patch or reboot host kernels, does not change sysctl settings or module blocklists on your servers, does not detect exploitation, and does not see a kernel running on a host unless that kernel is part of an image or SBOM you scan. The Linux kernel is not one of the package ecosystems Safeguard's vulnerability discovery covers. For this incident, the kernel fix comes from your distribution, and the mitigations are yours to roll out.

Where it helps:

• See what you build and ship. safeguard scan --image scans a container image, safeguard scan --sbom scans an SBOM file such as a VM or appliance SBOM from a vendor, and safeguard scan --dir . scans a repository, with JSON results under ./output. Container images share the host kernel, so an image scan will not show these bugs; it does tell you which base images and packages you ship, so the host work is not mixed up with image work.
• Answer "where is it" across projects. The platform shows which projects contain a given component and version. For appliance or VM image SBOMs that list kernel packages, that turns "which of our products ship a 6.12 kernel" into a query.
• Prioritise. Vulnerability matching against vulnerability databases, plus reachability analysis for application code, helps keep this week's kernel work from crowding out the dependency fixes that are reachable in your own code. Note that matching depends on a CVE existing, which for these reports it does not yet.
• Stop regressions. Policies and gates evaluated in the platform, and safeguard exec in CI, can stop an image or build that still carries a known vulnerable component from shipping.
• Do the change work with approval. The Safeguard CLI's assistant can edit files and run commands with your approval. You can ask it to write the sysctl and modprobe drop-in files above into your configuration management repository, update an Ansible role or a cloud-init template, or run the Step 5 ksmbd checks on the machine where the CLI runs, approving each step. Set /permissions to Ask or Strict for anything that touches servers. The desktop and phone apps can send that work to a computer running the CLI and let you approve each command. Our post on the security aware coding assistant explains the permission modes.

Zero-Day Discovery and Gold

• Zero-Day Discovery looks for previously unknown flaws before a CVE exists, in an agentic mode and a deterministic scanner mode, and issues findings as SGZ advisories before they reach public CVE databases. It covers seven package ecosystems.
• Gold Open Source at gold.safeguard.sh is free with no login: CVE intelligence with CVSS, EPSS, KEV status, affected and fixed versions and a recommended safe version, plus a free read API and a CI gate GitHub Action. It keys on CVEs, so it will only have a record for these bugs once CVEs exist.
• Gold Registry at registry.safeguard.sh is the paid tier: hardened drop in components and container images held to zero exploitable critical or high CVEs, SLSA L3 or higher, Sigstore signed, with evidence pages. An artifact loses its badge if it regresses.

The habit they support is the same one this incident rewards on the host side: start from patched, signed components, and be able to rebuild and redeploy within hours. We are not claiming Gold has anything for these kernel reports, and a hardened container image does not fix a host kernel.

Common mistakes

• Assuming the Dirty Frag patch covers this. It does not. The vendor found EL 8 to 10 kernels with the Dirty Frag fix still exposed.
• Waiting for a CVE before acting. There is public proof of concept code today and no CVE. Vulnerability scanners and distribution trackers that key on CVEs will show nothing.
• Confusing ksmbd with Samba. A Samba server is not exposed to the two ksmbd reports. A host can, however, have both installed; check what is listening on 445.
• Rebuilding container images to fix a kernel bug. Containers share the host kernel. Patch and reboot the host.
• Relying on Ubuntu's AppArmor userns restriction. The vendor bypassed it on 24.04 and 26.04.
• Turning off user namespaces on a rootless container host without telling anyone. Builds and pods fail in confusing ways. Do it deliberately, host by host.
• Blocking modules and stopping there. The vendor says the module block may not cover every path. Keep the kernel update on the plan.
• Installing the fixed kernel and not rebooting. uname -r is the check that matters.
• Rebooting a host you suspect was attacked before capturing evidence. The page cache change disappears on reboot, and so does your evidence.

FAQ

What exactly was disclosed?

Five Linux kernel vulnerability reports from ZDI went to public kernel lists on the evening of 21 October 2026 (UTC): two in ksmbd (CVSS 9.0 each), one in skb_zerocopy() (7.8), one in vmwgfx (8.8) and one in nvmet (8.6). A sixth, about the ConnMan userspace network manager, went to the ConnMan list on 20 October. Three of the kernel reports included full analysis and proof of concept code.

Is any of this being exploited?

No source we read reports exploitation in the wild. The vendor write-up, SecurityOnline, Cyber Security News and Threat Landscape all say none had been reported as of 22 to 23 October. Public proof of concept code shortens the time to exploitation, so do not wait for reports of attacks.

Are there CVEs?

Not yet. The kernel security team does not assign CVEs, and Threat Landscape says the kernel CNA assigns them once a fix reaches a stable tree. Until then, track the ZDI-CAN numbers and the patch subjects.

Is my server vulnerable to the root exploit?

If it runs a recent Debian, Ubuntu, AlmaLinux or CloudLinux kernel, allows unprivileged user namespaces and can load the listed modules, assume yes. The vendor got root on AlmaLinux 8, 9 and 10, CloudLinux 9 and 10, Debian 12 and 13, and Ubuntu 24.04 and 26.04. CentOS 6 and 7 were not vulnerable. Other kernels were not tested.

I run Samba. Do the ksmbd bugs affect me?

Not through Samba. They affect hosts where the ksmbd kernel module is loaded and the ksmbd service is running. RHEL, AlmaLinux and CloudLinux 9 and 10 do not build ksmbd at all. On Debian and Ubuntu it is built but off unless ksmbd-tools is installed and the service started.

Are the ksmbd bugs remote code execution?

ZDI's titles say so, and much coverage repeats it. The public proof of concept code shows an unauthenticated kernel heap leak and crashes for ZDI-CAN-33774, and a crash for ZDI-CAN-33549. ZDI describes a write path for 33774 that is not shown publicly. Treat them as critical for exposed hosts, but RCE is not demonstrated in public.

What is the safest mitigation for the root bug?

Setting user.max_user_namespaces = 0, per the vendor. It breaks rootless containers, Flatpak and some browser sandboxes, so apply it to servers that do not need user namespaces and use module blocks plus fast kernel updates on the hosts that do.

Do I need to rebuild my container images?

No, not for these bugs. They are in the host kernel. What protects containers is patching the host and limiting which workloads can create user namespaces.

When will distributions ship fixes?

No distribution had shipped a fix as of 22 October. The skb_zerocopy patch is reviewed with a Cc to stable, which is the path to stable kernels and then to distribution kernels. Watch your distribution's security announcements, and check changelogs for the patch subject until CVEs exist.

What should I do about the vmwgfx and nvmet reports?

Inventory where those drivers are loaded (lsmod | grep -E '^(vmwgfx|nvmet)') and watch for fixes. Only titles are public, so there is nothing more specific to do yet.

Fix it without waiting for upstream

This incident is a kernel bug, so the fix itself has to come from your distribution. The section below covers the open source dependencies and container images you build on top of that kernel, where the same two gaps, waiting for a fix and waiting to ship it, cost teams the most time.

In incidents like this one, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would have helped

These are real product sessions on other examples. None of them shows these kernel reports.

The CLI demo shows the assistant fixing a lodash CVE in a repository: it reads the finding and advisory, asks before each command, edits package.json, runs install and tests with your approval, and pushes nothing. For these reports, the same approval flow applies to your configuration repository: ask it to add the 99-zdi-33367.conf sysctl file and the modprobe blocks to the Ansible role for servers that never need user namespaces, then review and approve each edit before anything is committed.

Click through it at your own pace, or open it full screen.

The desktop app demo shows a real session: the CLI session appears in the conversation list, you ask for work on your computer, pick the folder, and Approve or Deny each command and file edit, ending with the upgrade done and tests passing. Here you would pick the folder that holds your host baseline, ask for the ksmbd checks from Step 5 and the matching blocklist file, and approve each command one at a time.

Click through it at your own pace, or open it full screen.

The mobile demo shows a real Android session that sends work to a computer running the CLI and approves a command on the phone with Allow once, Allow for turn or Deny. Kernel reboots usually land in an evening window; this is how an on call engineer can approve a uname -r check or a reboot of a patched runner from a phone without giving the assistant open permission.

Click through it at your own pace, or open it full screen.

To try it on your own systems, download Safeguard and read the CLI documentation. For the wider month, see our October 2026 incident roundup.

Quick check

Sources

• netdev archive: ZDI-CAN-33367: New Vulnerability Report (21 Oct 2026, 21:46 UTC)
• netdev archive: Eric Dumazet reply to ZDI-CAN-33367 (22 Oct 2026)
• netdev archive: PATCH v2 net, propagate shared-frag marker in skb_zerocopy()
• netdev archive: Eric Dumazet Reviewed-by on the skb_zerocopy patch
• netdev archive: Willem de Bruijn reply on reporting process
• netdev archive: Willy Tarreau reply on ZDI report efficiency
• netdev archive: ZDI reply on format, patches and the 120 day policy
• netdev archive: Willy Tarreau follow up on tested patches
• netdev archive index, 22 Oct 2026
• Linux kernel documentation: Security bugs
• Debian security tracker: CVE-2026-43284
• Red Hat CVE data: CVE-2026-43284
• Ubuntu security: CVE-2026-43284
• Red Hat: response to Zero Day Initiative ksmbd vulnerabilities
• Commercial Linux support vendor's technical write-up on the ZDI ksmbd and skb_zerocopy reports (22 Oct 2026)
• Phoronix: Linux kernel vulnerability reports posted to the public mailing list
• Slashdot: Several Linux kernel vulnerabilities accidentally posted to public kernel mailing list
• SecurityOnline: Linux kernel ksmbd vulnerabilities made public
• Cyber Security News: Linux kernel flaws accidentally disclosed
• Threat Landscape: ksmbd ZDI-CAN-33774 and ZDI-CAN-33549, unpatched

Last reviewed: 23 October 2026. This is a developing story; check the linked advisories for the latest status.