Detecting and mitigating ZDI-CAN-33367 and five other Linux flaws

A working root exploit for a Linux kernel bug is now public, before it has a CVE or a merged fix. On October 20, 2026, Trend Micro’s Zero Day Initiative (ZDI) sent one report, a bug in the ConnMan network manager, to the public ConnMan mailing list. On October 21, ZDI sent five reports to the Linux kernel security team and copied public mailing lists on every one. The reports included reproduction details, showing that several had no patch attached and no fix in any released kernel. Two of the Linux flaws have been rated as CVSS 9.0.

None of the six bugs has been assigned a CVE ID yet, and no in-the-wild exploitation has been reported as of the publication of this blog. However, security teams should work to get detections and mitigations in place now. TuxCare has reproduced the public proof of concept (PoC) for ZDI-CAN-33367 from the ZDI report. Exploitation leads to root access on current Ubuntu, Debian, and AlmaLinux distributions.

The Sysdig Threat Research Team (TRT) reviewed the batch of Linux vulnerabilities and ranked the reports by how much each should affect what defenders do today. This report explores what was disclosed, who may be exposed, what runtime visibility can detect for each bug, and what defenders can do while patches are pending.

Timeline

Affected versions

Exposure risk varies greatly across the reports. One affects the mainstream distributions TuxCare tested, including Ubuntu, Debian, and AlmaLinux releases. Two affect only hosts running ksmbd, the in-kernel SMB server. Another affects only VMware guests.

Organizations should review their inventory before deciding how to prioritize these vulnerabilities.

ZDI-CAN-33367

Fix status

A small patch, “net: skbuff: propagate shared-frag marker in skb_zerocopy()”, is on netdev, reviewed by Eric Dumazet and tagged for stable. It has not been merged.

How the bug works: Dirty Frag again

Earlier this year, Dirty Frag (CVE-2026-43284) showed defenders how an unprivileged user could get the kernel's IPsec ESP code to decrypt in place over pages that belong to the page cache. Those pages back a file the user can only read, and decryption writes the attacker's bytes into the cached copy of that file. Targeting a setuid binary or /etc/passwd this way gives the attacker root without ever opening the file for writing.

The Dirty Frag fix marked those shared pages with a flag and taught ESP to copy before decrypting when it sees the flag. ZDI-CAN-33367 is a gap in that fix.

skb_zerocopy() moves the same pages into a new socket buffer but does not carry the flag across. ESP never sees the flag, decrypts in place, and the write lands in the page cache. According to and Safeguard, the code path dates to kernel 3.14.

Not the first gap

The Dirty Frag fix only works if every piece of networking code that moves those pages around carries the flag along. Since May, the kernel's CVE team has published six follow-up CVEs where some other path lost it:

• Frag-copy and shift helpers: CVE-2026-43503
• Coalescing: CVE-2026-46300
• IPTFS: CVE-2026-53363, CVE-2026-64566
• An error-handling helper: CVE-2026-80977
• Another error path inside skb_zerocopy() itself: CVE-2026-90049

CVE-2026-90049 is a different bug in the same function, so a kernel carrying its fix is not fixed for ZDI-CAN-33367.

Exploitation

The PoC needs unprivileged user namespaces and a handful of networking modules: nlmon, nft_queue, nfnetlink_queue, cls_u32, act_pedit, act_mirred, and esp4. It does not need a Kernel Address Space Layout Randomization (KASLR) leak, or any capability the user doesn't already get inside their own namespace.

Each step of exploitation is a system call that can be made by an ordinary user process:

• Unshare into new user and network namespaces, then write sysctls.
• Bring up an nlmon interface.
• Install XFRM state over netlink.
• Add an nftables NFQUEUE rule.
• Attach a tc pedit action with a redirect.
• splice() into a socket on 127.0.0.1, which triggers the in-place decryption over the page cache.

Impact

TuxCare reproduced a root shell on AlmaLinux 8–10, CloudLinux 9–10, Debian 12 and 13, and Ubuntu 24.04 and 26.04. AlmaLinux was rooted with the Dirty Frag fix installed. CentOS 6 and 7 kernels are not vulnerable. The vulnerability is a local privilege escalation (LPE), so an attacker needs code execution on the host first.

ZDI-CAN-33774 and ZDI-CAN-33549

Both CVSS 9.0 reports are in ksmbd, the in-kernel Server Message Block (SMB) server. Samba is not ksmbd.

If your file servers run smbd, neither report applies to you. To check whether ksmbd is running anywhere, look for the ksmbd kernel module, the ksmbd.mountd userspace daemon, and a kernel-owned listener on TCP 445.

ZDI-CAN-33774: The dispatch race

ksmbd decides per request whether it is handling SMB1 or SMB2. If an attacker packs a burst of short SMB1 packets and an SMB2 packet into the same TCP write, the worker threads can run an SMB2 handler over SMB1 data and read past the end of the shorter buffer. This works before authentication. The public PoC leaks 28 bytes of kernel heap per attempt and can crash the kernel. ZDI describes a write-past-buffer path that needs share access and labels the bug as remote code execution (RCE), but nothing public shows code execution as of this blog’s publication.

Maintainer Namjae Jeon says the bug is already fixed, and his tree bears that out. Commit 68f410faedaf ("ksmbd: wait for negotiation before receiving another PDU") was written on September 30, credited to a different reporter, and describes exactly this race. It is queued in ksmbd's ksmbd-for-next branch and has not reached a released kernel.

ZDI-CAN-33549: SMB Direct

An integer underflow in the Remote Direct Memory Access (RDMA) transport turns a crafted buffer descriptor into a heap overflow of up to eight KB. The bar is higher than for 33774. The host needs an RDMA-capable interface (hardware, or the rxe software driver), a client that negotiates SMB Direct, and a writable share. The public PoC crashes the kernel.

SMB Direct maintainer Stefan Metzmacher believes a fix already in his branch for Linux 7.5 covers it. As of this writing, that hasn't been confirmed. Ubuntu builds SMB Direct support; Debian does not.

ZDI-CAN-34068

ZDI-CAN-34068 is an out-of-bounds write in vmwgfx, the kernel driver for VMware's virtual GPU, rated as LPE (CVSS 8.8). Only the title is public. Kroah-Hartman's reply on dri-devel points to the dirty-tracking code. There is no patch.

The exposure is narrow. vmwgfx only binds to VMware's SVGA virtual display adapter, so the bug only matters on VMware guests: vSphere and Workstation VMs, and VMware-based virtual desktop infrastructure (VDI). In Sysdig TRT testing, it does not reproduce on Lima or EC2 instances, which don't present that device.

ZDI-CAN-34076 and ZDI-CAN-32005

ZDI-CAN-34076 (nvmet) is an uninitialized-memory information leak in the Non-Volatile Memory Express (NVMe) target's Get Log Page handling. Only the title is public, and the kernel team has said nothing can be done until details arrive.

ZDI-CAN-32005 (ConnMan) is a stack overflow in the ConnMan network manager's DNS proxy. It is a userspace bug, not a kernel bug, and is outside the scope of this post.

Detection

The four bugs that are the most impactful right now differ in what a syscall-level runtime sensor can observe:

• ZDI-CAN-33367. The sequence of the exploitation is distinctive. The process unshares into new user and network namespaces, writes sysctls, brings up an nlmon interface, installs XFRM state over netlink, adds an nftables NFQUEUE rule, attaches a tc pedit action with a redirect, and then splice()s into a socket on 127.0.0.1. Nothing legitimate does all of that from a single unprivileged process. Of the four, this is the easiest one to detect.
• ksmbd (33774 and 33549). A sensor can see that ksmbd is exposed: the module loads, ksmbd.mountd starts, and 445 is listening. It can see what an attacker does after code execution, once something spawns a process or touches files. It cannot see the race or the overflow itself. Runtime detection is the backstop.
• ZDI-CAN-34068. The trigger is DRM ioctl() calls on the vmwgfx device node, made by a local process. That narrows where to look, but GPU ioctls are noisy on any desktop or VDI guest, so treat them as context for an investigation, not as a signal on their own.

Sysdig Secure customers are covered by a new runtime rule in the Sysdig Runtime Behavioral Analytics policy, Page Cache Poisoning via Spliced File Pages to Loopback, which matches the syscall patterns as seen for ZDI-CAN-33367. Work on exploits for the other flaws in this disclosure continues, and the Sysdig TRT is writing detection rules for them as the techniques become clear.

Independently of the entry point, customers also keep post-exploitation coverage, which detects the effects of a successful exploit rather than the route in.

Recommendations

ZDI-CAN-33367

• Patch as soon as your distribution ships the skb_zerocopy() fix. A kernel carrying only the CVE-2026-90049 fix is not covered.
• Restrict unprivileged user namespaces. Setting user.max_user_namespaces=0 (or kernel.unprivileged_userns_clone=0 on Debian) should block the public PoC, though TuxCare notes it has not yet validated this against the PoC. The cost is real: rootless containers, some browser sandboxes and some build tooling depend on user namespaces, so scope it to hosts that don't need them.
• Avoid relying on Ubuntu's AppArmor user-namespace restriction. The PoC got past it through the AppArmor profile of a container launcher package.
• Block the nlmon and act_pedit modules where you can. Denying them breaks this PoC, although TuxCare cautions it may not close every path to the bug.
• Enforce seccomp RuntimeDefault on Kubernetes pods. The exploit starts by creating a user namespace, so containers that can call unshare(CLONE_NEWUSER) are in play. Docker's default seccomp profile blocks that call, but Kubernetes pods run Unconfined unless you set RuntimeDefault per pod or cluster-wide using the kubelet --seccomp-default option. This is a good week to make it the cluster default.

ZDI-CAN-33774 and ZDI-CAN-33549

• Inventory where ksmbd runs. Samba users are unaffected.
• Unload ksmbd and block the module on hosts that don't need it.
• Restrict TCP 445 to trusted networks where ksmbd must stay.
• Disable SMB Direct unless your storage network depends on RDMA.

ZDI-CAN-34068

• Inventory Linux guests running on VMware, and watch for the vmwgfx patch.
• Disable 3D acceleration, or keep the vmwgfx module from loading, on guests that have no use for it.

Across all Linux flaws

• Track the reports by ZDI ID and component name until CVEs are assigned.

Conclusion

ZDI's decision to copy public lists put reproduction details for six bugs in front of attackers before several of them had fixes. As defenders know, a lack of an assigned CVE ID does not mean a lack of exposure. Only one of the six, ZDI-CAN-33367, combines a public root exploit, broad distribution exposure, and a fix that hasn't yet merged. It is the seventh path found to drop the Dirty Frag flag, reopening a bug class whose protection has already leaked six times since May 2026. The two ksmbd reports carry the highest scores, but they only matter where ksmbd — not Samba — is running.

For defenders, the practical takeaway is that this week's work is about exposure, not scanners. It’s also important to note that the bugs differ in what defenders should actually watch. The ZDI-CAN-33367 exploit runs as an ordinary user process through a distinctive sequence of systems calls, so teams can catch it in motion. The ksmbd bugs run inside the kernel worker threads with no attacker process on the host, so controlling exposure is key.

Affected organizations should immediately restrict unprivileged user namespaces and enforce RuntimeDefault seccomp where they can, find out whether ksmbd is running anywhere in their estate, and patch ZDI-CAN-33367 the day their distribution ships the fix.