A Linux Kernel Local-Root Bug Has Public Exploit Code and No Merged Fix, After Zero Day Initiative Reports Reached Public Mailing Lists

A report for ZDI-CAN-33367, a Linux kernel flaw that lets a local user write into a file they can read but not modify, has been in public mailing list archives since October 21, with C source code in it. No fix is in the networking or mainline trees we checked, no CVE has been assigned, and CloudLinux says it ran the public exploit to root on AlmaLinux 8, 9 and 10, Debian 12 and 13, and Ubuntu 24.04 and 26.04. The report came from Trend Micro’s Zero Day Initiative (ZDI). Its message went to the kernel’s private security address with the netdev and linux-kernel lists copied on the same message, so the whole text, more than 200,000 characters of it, went into public archives.

A two-line fix posted by Zizhen Liu on October 22 was reviewed the same day by Eric Dumazet, one of the networking maintainers. At 19:33 UTC on October 23 it had not been merged. The thread around it is as much a story as the bug: maintainers said the report arrived on public lists without a patch, and ZDI answered that it does not provide patches and will keep sending reports the way it always has. The interim advice we found is CloudLinux’s, which is to stop ordinary accounts from creating user namespaces, at the price of breaking rootless containers, and CloudLinux says it has not run the exploit against that mitigation.

What the public record shows

Times are UTC. Mail times come from message headers on Openwall’s mirror of the netdev and linux-kernel lists, converted from each sender’s offset, because lore.kernel.org answered scripted requests with a bot challenge.

How the flaw works, and what the fix changes

Network packets inside the kernel travel in buffers called skbs, and an skb can point at memory pages owned by something else, such as the cached pages of a file. The kernel marks those buffers with a flag, SKBFL_SHARED_FRAG, so that later code knows not to modify the data in place. IPsec’s ESP receive path reads that flag through skb_has_shared_frag() to decide whether it has to copy the data before decrypting. The check came from the May 2026 fix for CVE-2026-43284, which NVD describes as ESP that “decrypts in place over data that is not owned privately by the skb”, and which CloudLinux calls Dirty Frag.

The new report concerns a different helper, skb_zerocopy(), which moves page references from one skb into another. According to the commit message of the fix, the helper does not copy the flag across, so an skb it builds for nfnetlink_queue or for an Open vSwitch upcall looks private to ESP and is decrypted in place, “letting an unprivileged user write into the page cache of a root-owned read-only file”. The change is one statement in net/core/skbuff.c:

@@ -3942,6 +3942,8 @@ skb_zerocopy(struct sk_buff *to, struct sk_buff *from, int len, int hlen)
 	}
 	skb_shinfo(to)->nr_frags = j;

+	skb_shinfo(to)->flags |= skb_shinfo(from)->flags & SKBFL_SHARED_FRAG;
+
 	if (i > 0 && from->unreadable)
 		to->unreadable = 1;

The patch carries two Fixes tags. One names the January 2014 commit that, according to the patch’s own v2 note, introduced skb_zerocopy(); the other names the May 2026 ESP change that began relying on the flag. CloudLinux says that installing the CVE-2026-43284 fix does not protect against this bug. We are not describing the exploit chain, and we are not linking the original report, because it contains the exploit’s source code.

We have covered neighbouring parts of the kernel before: pedit COW in June, which concerned traffic-control handling, DirtyClone in July, which concerned socket-buffer fragments, and two days ago the Infinity Core bugs, where stable-kernel fixes had been public for weeks before exploit code appeared. This case runs in the opposite order: exploit text first, merged fix later.

What the maintainers said and what ZDI answered

The maintainers’ replies are short. Dumazet wrote “I had to cut this report. Way too long, I could not see a patch in it.” and added “We were fortunate to receive a report with a patch from another source one week ago. Patch will be available soon.” Greg Kroah-Hartman, writing as Greg KH, answered the vmwgfx report with “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.” His replies on the nvmet and ksmbd reports were “Again, no patch, and sent to a public list?” and “And again, no patch, and a public list?”, the first followed by “Please fix your submission process”. Willem de Bruijn pointed ZDI to the kernel’s reporting document: “For future reports: please review the documentation on how to share such findings”.

Willy Tarreau, who wrote in the first person about the kernel security team’s triage work, gave the maintainers’ case in practical terms. He said that “maintainers need a patch to start from”, that it is not possible to get anyone at ZDI, or the reporter, to test a patch, and that “just today we received more than 30 different reports”. Peter Zijlstra wrote that ZDI had been pointed to the document many times, and a later message called the ZDI reports very painful to handle.

ZDI’s answer arrived at 18:51. “We’ve probably submitted nearly 1000 cases to kernel over the last ten years,” it wrote, and said its report format is essentially what it was ten years ago apart from changes the kernel team had asked for. It added that it may be mistaken but this was the first time it had seen a reference to the documentation, and that “we will send the cases to you as we always have.” On timing it wrote “We will release the findings at rejection, or 120 days. Whichever comes first.” On patches it was blunt: “we aren’t going to provide you with patches”, because “It’s not my call, and it’s overhead we cannot support.” It said it would “more than likely have to entertain other options”. The reply does not mention the public lists on the CC line; the recipient it questioned was Red Hat. The exchange was heated, and ZDI objected to the wording of one maintainer’s remark.

The kernel’s reporting document is more nuanced than either side’s summary. It says to send a report to the affected maintainers with the security team copied and “Do not send it to a public list at this stage, unless you have good reasons to consider the issue as being public or trivial to discover”. It places a proposed fix among the items it calls “highly desirable”, below the ones it calls “absolutely necessary”, and says “Proposing a tested fix will save maintainers a lot of time”. It also asks reporters not to “require triage engineers to scan multiple pages of text”, in a section about AI-assisted reports; nothing in the messages we read says ZDI’s report was AI-assisted.

Where ZDI’s own listing stands

ZDI’s upcoming-advisories page, which ZDI brands as the TrendAI Zero Day Initiative, opens by describing its list as vulnerabilities “that are yet to be publicly disclosed”. When we fetched it on October 23, ZDI-CAN-33367 was on it with a reported date of October 21 and a deadline of February 18, 2027, which is 120 days later. That matches ZDI’s disclosure policy, under which the vendor gets “four months (120 days)”. The other four October 21 reports carry the same deadline, and a ConnMan entry reported October 19 has a deadline of February 16.

For the kernel, that schedule no longer describes anything secret. The kernel’s rules say “Fixes for publicly known bugs are released immediately”, and allow an embargo of “up to 7 calendar days from the start of the release process, with an exceptional extension to 14 calendar days”, so the two timetables were far apart even before the CC line made the report public. The page lists 715 advisories pending in total and 30 under Linux. Two Linux entries, ZDI-CAN-31139 and ZDI-CAN-31417, show a deadline of October 23, the day we checked, and 11 listed Linux entries show deadlines that have already passed, so the column does not tell you when ZDI will publish.

Who is exposed, and what CloudLinux recommends

These are CloudLinux’s findings, and CloudLinux sells the KernelCare livepatch service named below. We did not run the exploit or the commands, and this site has no Linux test machine.

• What it tested. CloudLinux says its kernel team ran the published exploit to root on AlmaLinux 8, 9 and 10, on CloudLinux 9 and 10 (same kernels as AlmaLinux), on Debian 12 and 13 and on Ubuntu 24.04 and 26.04, and that CentOS 6 and 7 kernels are not affected. The kernels in that list include the 5.14 line (AlmaLinux 9) and the 6.12 line (AlmaLinux 10), and ZDI says it tested 7.3-rc1. CloudLinux had not run the exploit on its own CloudLinux 7 hybrid, 8 and 8 ELS kernels, but found on test machines that an ordinary account can create the private namespace the attack starts from, and treats those lines as exposed.
• The gate. The attack needs ordinary users to be able to create user namespaces. CloudLinux’s check is sysctl user.max_user_namespaces, and “A value of 0 means the path is shut for ordinary accounts.” The kernel’s sysctl documentation defines that setting as “The maximum number of user namespaces that any user in the current user namespace may create.” CloudLinux says it ships with 0 on CloudLinux 10 and on CloudLinux 8 and 9 servers installed since mid-2024, that older servers keep the open setting even after updates, and that “The version does not settle it, the command does.”
• Ubuntu has a second gate. Canonical’s 2023 post describes an AppArmor restriction on unprivileged user namespaces, controlled by kernel.apparmor_restrict_unprivileged_userns. CloudLinux does not say how its Ubuntu test machines were configured, so we cannot tell whether that setting was in play.
• The mitigation. CloudLinux’s commands, run as root, apply without a reboot and are undone by deleting the file and running sysctl --system again:

sysctl user.max_user_namespaces
echo 'user.max_user_namespaces = 0' > /etc/sysctl.d/99-zdi-33367.conf
sysctl --system

• What it costs. “Rootless Podman and Docker, unprivileged LXC, Flatpak, and some browser sandboxes stop working for ordinary accounts.” CloudLinux says that usually costs nothing on classic shared hosting and is disruptive where customers run their own containers.
• What is untested. CloudLinux also suggests blocking two modules, nlmon and act_pedit, as a narrower fallback. Then it adds: “We have not run the exploit against either mitigation, and we have not verified that blocking the two modules stops every variant.” The case for the sysctl rests on the namespace step being first, which CloudLinux did check on its test machines, and not on a test of the exploit with the setting at 0.
• CageFS does not help. CloudLinux says its per-account filesystem cage is not in the path and that it measured this by running the namespace step from a caged account.
• Livepatch. A KernelCare livepatch built from the upstream fix candidate is released for CloudLinux 10 and AlmaLinux 10, and CloudLinux says it verified that it stops the public exploit. The CloudLinux 9 livepatch is in review, the CloudLinux 8 one is in progress, and Debian and Ubuntu have not started. CloudLinux says no fixed kernel has shipped for any line.

CloudLinux’s argument for treating this as a whole-server problem on shared hosting is that the local user is a customer, or an intruder who got in through a vulnerable plugin, and that the damage lands in the shared kernel. The same reasoning covers any host with untrusted local users, such as CI runners and multi-tenant build machines. CloudLinux also writes: “We are not aware of any report of the flaw being used in the wild.”

The other reports in the same batch

CloudLinux’s assessment of the two ksmbd reports is that the public proofs of concept show a kernel memory leak and a crash, not code execution, and that ksmbd is not built into the AlmaLinux and CloudLinux 9 and 10 kernels. Debian and Ubuntu build it, it says, but it runs only after an administrator installs ksmbd-tools and starts the service, and CloudLinux’s check for whether it is running is systemctl is-active ksmbd. ZDI’s scores for both are 9.0.

What is still open

• When the fix lands. It was reviewed on October 22 and marked for the stable trees, but we found no commit in the trees we checked. The net tree did take three other fixes between 17:43 and 17:47 UTC on October 23 (sctp, tcp and ipmr), none of them this one. CloudLinux’s 14:59 UTC update says the upstream fix “has been reviewed by the netdev maintainer and is not merged yet.” The fix thread holds three messages: the patch, Dumazet’s review, and an automated reply from a kernel bot that says an LLM did the evaluation and asks how the bug was discovered and whether it was triggered. We cannot tell from the archive whether that request is holding up the merge.
• A CVE. The kernel’s CVE document says “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”. Until then, scanners that match on CVE identifiers will show nothing. Once the fix is merged it should be findable by its title, “net: skbuff: propagate shared-frag marker in skb_zerocopy()”, if the title survives the merge unchanged.
• Distribution kernels. CloudLinux reports none for its lines. We did not check each distribution’s tracker, because there is no CVE identifier to look up.
• Exploitation in the wild. None of the sources we read reports it, and the exploit has been public since October 21.
• ZDI’s process. ZDI said it would hold internal discussions and might “entertain other options”; its page still lists the five October 21 Linux reports with February 18, 2027 deadlines.

Sources and method

We read the maintainers’ replies to the ZDI reports and the fix thread on Openwall’s mirrors of the netdev and linux-kernel lists, opened the headers of the ZDI-CAN-33549, 33774 and 33367 messages, and measured the length of the 33367 message and checked that it contains C source, without running any of it. We also read Phoronix’s report, CloudLinux’s advisory as last updated at 14:59 UTC on October 23, ZDI’s upcoming-advisories and disclosure-policy pages, the kernel’s documents on security bugs, CVE assignment and the user sysctls, Canonical’s 2023 post and the NVD record for CVE-2026-43284. The commit dates come from GitHub’s API for the two Fixes commits. The fix-status check on October 23 at 19:33 UTC used the net and net-next atom feeds for net/core/skbuff.c on git.kernel.org, GitHub’s history of that file in Linus Torvalds’s tree and the list mirror’s index of replies; git.kernel.org commit pages and lore.kernel.org answered scripted requests with a bot challenge, so we did not use them. The CVE check searched NVD for “skb_zerocopy” among records published from October 15 and for “ZDI-CAN-33367”, and found nothing for either. Everything about which distributions the exploit works on, the mitigation and the livepatch is CloudLinux’s claim and not our test. Photo: Adelie penguins on an iceberg, by Jason Auch, CC BY 2.0, via Wikimedia Commons.