ZDI Discloses Six Linux Kernel Zero-Days on Public Lists With Root Exploit, No CVEs Assigned

On October 20, 2026, Trend Micro's Zero Day Initiative disclosed six Linux kernel vulnerabilities on public mailing lists, three of them accompanied by full proof-of-concept code. None had a CVE assigned at the time of disclosure. One of them, ZDI-CAN-33367, enables escalation to root on enterprise distributions via a publicly downloadable exploit. The move exposed millions of systems to a window of risk, igniting tension between the kernel project's policy on AI-discovered bugs and the practice of coordinated disclosure.

The Mechanism: How skb_zerocopy Bypasses the Dirty Frag Protection

The technical core resides in skb_zerocopy(), a function in the Linux networking stack. According to TuxCare, the ZDI-CAN-33367 bug bypasses the Dirty Frag fix (CVE-2026-43284) applied in May 2026. The Dirty Frag fix introduced the SKBFL_SHARED_FRAG flag to mark socket buffers that share page fragments. When skb_zerocopy() copies a buffer, it does not propagate this flag to the new destination sk_buff.

The result is that the ESP (IPsec) subsystem decrypts in-place pages shared with the page cache of read-only files. A local attacker can overwrite the page cache, corrupting setuid binaries or system files such as /etc/passwd to gain root privileges. TuxCare has verified the reproduction internally.

Technical prerequisites include the ability to create user namespaces and establish ESP tunnels. This narrows the attack surface to systems with namespaces enabled and an accessible IPsec stack, a common configuration in shared hosting, CI runners, and multi-tenant university nodes.

The Six Vulnerabilities: From LPE to ksmbd RCE With Differing Impacts

The six ZDI reports cover five kernel vulnerabilities plus one in ConnMan. ZDI data assigns differentiated CVSS scores: 7.8 for ZDI-CAN-33367 (LPE with public root exploit), 9.0 for both ksmbd RCE flaws (ZDI-CAN-33774 and ZDI-CAN-33549). However, according to CloudLinux and Sysdig as cited by The Hacker News, "The public proof-of-concept code for the two KSMBD flaws shows a kernel memory leak and crashes, not code execution." The PoC for ZDI-CAN-33774 leaks 28 bytes of kernel heap memory per attempt; ZDI-CAN-33549 allows a heap overflow of up to 8 KB.

The gap between CVSS severity and public demonstration of code execution is significant: operators must calibrate their response on technical data, not theoretical scores. ZDI-CAN-34068 and ZDI-CAN-34076, the other two kernel reports, have not received the same level of technical attention in sources available as of October 26.

The Collision Between AI Policy and Coordinated Disclosure

The most disturbing element is the process. The kernel policy, updated in May 2026, defines bugs discovered by artificial intelligence as "already public." ZDI followed this logic in routing the reports, advancing the standard 120-day deadline. The source does not specify the exact reason for the advancement relative to the original date of February 18, 2027.

Greg Kroah-Hartman expressed this tension in two public responses reported by The Hacker News. On ZDI-CAN-34068: "For some reason you sent this to public lists, and did not include a patch, so there's not much we can do with this." On ZDI-CAN-34076, 17 seconds later: "Again, no patch, and sent to a public list? Please fix your submission process."

"For some reason you sent this to public lists, and did not include a patch, so there's not much we can do with this" — Greg Kroah-Hartman, stable-kernel maintainer, on ZDI-CAN-34068

The conflict remains open: the kernel policy classifies AI-discovered bugs as public, but maintainers receive no patches to review. Eric Dumazet reviewed the patch posted on October 22, demonstrating that the action is technically possible. Major distributions remain exposed during the interval.

Fragmented Response: Who Acted and Who Fell Behind

Some actors reacted with speed. AlmaLinux backported the fix for ZDI-CAN-33367 into its testing repository on October 23. KernelCare, TuxCare's live patching service, released an update for Enterprise Linux 10 on October 23. Sysdig proposed the mitigation user.max_user_namespaces=0 to block the public PoC.

However, TuxCare and CloudLinux have not independently validated the effectiveness of this mitigation. The upstream fix posted on October 22 had not yet been merged as of October 26. No in-the-wild exploitation had been reported as of the article date.

What to Do Now

For ZDI-CAN-33367, operators should monitor AlmaLinux testing repositories and KernelCare live patches for EL10, verifying availability for their distribution. The mitigation user.max_user_namespaces=0 blocks the public PoC, but has not been validated by independent vendors: it should be evaluated with caution on systems that rely on user namespaces for containers or sandboxes.

For the ksmbd vulnerabilities, the priority is network segmentation: limit exposure of the kernel SMB service to trusted interfaces, given that public PoCs demonstrate crashes and memory leaks but not confirmed code execution. Operators must also prepare alternative tracking processes to CVEs, since none of the six vulnerabilities had an identifier assigned as of October 26.

Dashboards and scanners that rely exclusively on CVEs remain blind to this class of bugs until formal assignment. Organizations must integrate direct feeds from kernel mailing lists and vendor advisories to compensate for this gap.

Editorial Closing

The ZDI-CAN-33367 incident and the five related reports expose a systemic fracture in kernel vulnerability governance. The Linux project's AI-discovered policy, ZDI's 120-day timeline, and distribution expectations do not mesh: the risk falls on operators, without standard tools to measure or mitigate it. Until CVEs, patches, and disclosure are synchronized, this window of blindness will remain a constant in the Linux threat landscape.