ZDI-CAN-33367: Linux Kernel Local Root Zero-Day, Mitigation for CloudLinux

ZDI-CAN-33367 is a local privilege escalation in the Linux kernel networking stack, reported through Trend Micro’s Zero Day Initiative (ZDI). It has no CVE assigned and has a working exploit in public. An ordinary user with a shell on the machine can change the contents of any file they can read, including files they have no permission to write, and from there take control of the server.

We are calling it a zero-day: it became public with a working exploit, no CVE, and no fix. ZDI sent its reports to the kernel security team on 20 and 21 October and, by mistake, to public mailing lists as well (Phoronix covered it). We are not aware of any report of the flaw being used in the wild. It is the same class of flaw as Dirty Pipe, with one vector, and that vector is local. Nothing in it can be done to a server from the outside network.

“Local” does not mean an insider. On a shared server the attacker is a customer who bought an account, or an intruder who got into one site through a vulnerable plugin, and either one already stands where the exploit begins. The damage lands in the shared kernel, so success reaches every other tenant on the machine.

Affected CloudLinux versions

Version alone does not decide exposure. The exploit needs a set of networking kernel modules, and every affected kernel ships them. In practice one condition decides it: whether ordinary users on the server can create their own private namespaces, in which the user is treated as administrator of their own network. Where they can, treat the server as exposed today. Where they cannot, an ordinary account cannot start the sequence.

The check is read-only and takes a few seconds:

sysctl user.max_user_namespaces

A value of 0 means the path is shut for ordinary accounts. Any other number means it is open, and on an affected version the server should be treated as exposed. The number carries no meaning beyond being non-zero: it varies with the machine’s memory.

^† The kernel on this line comes from Canonical through apt, so there is no CloudLinux stream. It follows the Ubuntu security stream.

KernelCare livepatches apply without a reboot. One is released for CloudLinux 10, one is in review for CloudLinux 9, and one is in progress for CloudLinux 8. CloudLinux 8 ELS has no live-patching stream.

What we tested. Our kernel team ran the published exploit to completion, obtaining 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. On the older CentOS 6 and CentOS 7 kernels the chain does not work at all.

On CloudLinux 7 hybrid, 8, and 8 ELS, which run our own kernels, we have not run the exploit yet. On freshly installed machines of each line, on 22 and 23 October, we checked whether an ordinary account can take the first and decisive step: creating a private namespace in which the user is treated as administrator of their own network. On all three it could. Everything after that step is the code that gave root elsewhere, so we treat these lines as exposed. CloudLinux 7 and CloudLinux for Ubuntu 22.04 were measured the same way. CloudLinux 9 ELS was not tested separately and follows CloudLinux 9.

Install date, not updates, sets the default. On CloudLinux 8, 9, and 10 the value 0 is set by lve-utils only when it is first installed, on servers installed since mid-2024. Updating an older server, even to the latest lve-utils, does not apply it.

The version does not settle it, the command does. A server on a line listed as closed can still have had this setting changed locally, by an administrator or by container software. A process that already holds elevated network rights, such as the root user inside a container that was granted them, does not need the namespace step at all.

Is there a mitigation?

Yes, on servers that do not have a fixed kernel or livepatch yet. Disabling unprivileged user namespaces closes the path for ordinary accounts today, and it applies without a reboot. On CloudLinux 10, and on CloudLinux 8 and 9 servers installed since mid-2024, it is already the default.

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

What it costs. It stops ordinary users from creating their own namespaces, which is what the attack needs and also what rootless containers need. Rootless Podman and Docker, unprivileged LXC, Flatpak, and some browser sandboxes stop working for ordinary accounts. On a classic shared-hosting fleet that usually costs nothing. On a server where customers run their own containers it is disruptive, and those operators need to weigh it against leaving the path open until a fixed kernel or livepatch arrives.

To undo it later, delete the file and run sysctl --system again.

A second, narrower option. Blocking two less common kernel modules the exploit needs, nlmon and act_pedit, has low impact on most servers. Check first that nobody uses tc pedit or nlmon. It may not cover every path, so treat it as a fallback where namespaces cannot be disabled, not as a replacement.

printf 'install nlmon /bin/false\ninstall act_pedit /bin/false\n' > /etc/modprobe.d/zdi-33367.conf
lsmod | grep -E '^(nlmon|act_pedit) '   # must print nothing, else reboot

We have not run the exploit against either mitigation, and we have not verified that blocking the two modules stops every variant.

Does CageFS protect against this?

No, and we measured it. CageFS, the virtualized filesystem that gives each account its own restricted view of the server, does not sit in this path. The flaw does not travel through the filesystem: the damage is done inside the shared kernel’s own memory.

We tested it on an exposed line. Running the first step from a caged account through the shell appears to fail, but for a shallow reason: the small command-line tool that creates a namespace is not part of the cage’s file set, so the shell cannot find it. We then ran a small compiled program that asks the kernel for the same thing directly, which is how real exploit code works. Inside the cage it succeeded. With CageFS switched off and only LVE (Lightweight Virtualized Environment) limits left in place, it succeeded as well.

So the cage removed a convenience tool and nothing more. A report that a caged account “could not do it” from a shell test has measured the missing tool, not protection.

Update instructions

Fixed kernels are in beta for CloudLinux 7 hybrid and 8, and AlmaLinux has fixed kernels for the CloudLinux 9 and 10 line in its testing repository. The CloudLinux 10 livepatch is built from the upstream fix that was posted for review on 22 October, and we verified that it stops the public exploit. On lines without a fixed kernel or livepatch yet, the mitigation above is the answer.

Stream 1: CloudLinux kernel (CL7h, CL8)

To install the kernel from the beta channel now:

# CloudLinux 8
yum update 'kernel*' --enablerepo=cloudlinux-updates-testing
reboot

# CloudLinux 7 hybrid
yum update 'kernel*' --enablerepo=cl7h_beta
reboot

As the rollout reaches stable, a plain yum update kernel followed by a reboot installs the same kernel.

Stream 2: AlmaLinux kernel (CL9, CL10)

Stream 3: TuxCare ELS kernel (CL8 ELS, CL9 ELS)

Stream 4: KernelCare livepatch (all affected versions)

On CloudLinux 10, apply the livepatch from the production feed:

kcarectl --update

How to verify

Check exposure now. sysctl user.max_user_namespaces prints 0 when ordinary accounts cannot create their own namespaces.

After applying a KernelCare livepatch, confirm it landed with:

kcarectl --patch-info | grep -i 33367

Use --patch-info, not --info. The latter prints a summary and returns nothing for a specific issue even on a fully patched server, which is the usual reason someone concludes a server is unpatched when it is not.

After installing a fixed kernel, run uname -r after the reboot. It should show 4.18.0-553.177.1.lve.1.el7h on CloudLinux 7 hybrid or 4.18.0-553.177.1.lve.1.el8 on CloudLinux 8, or a later build.

Why this matters on a shared host

Shared hosting is close to the worst shape this flaw can take. The attacker’s starting position is an ordinary hosting account, which is exactly what every customer buys. No compromise of the provider’s own systems is needed, and no unusual server configuration. A tenant with a shell, or an intruder who got into one site through a vulnerable plugin, is already where the exploit begins.

From there the path is short: rewrite a file the system trusts, and the system runs the attacker’s version of it. Because the damage lands in the shared kernel rather than inside one account’s boundary, the result is the whole machine, with every other tenant’s files, databases, mail, and credentials on that server. For a hosting provider the question is not whether one customer loses a site. It is whether one account can take the entire box.

Closing the namespace path keeps a web-tier compromise where it started, as one site to clean up instead of a whole server to rebuild.

The other reports in the same leak

ZDI sent six reports in total. ZDI-CAN-33367 is the one with a public exploit that affects hosting servers. The others:

• ksmbd (ZDI-CAN-33774 and ZDI-CAN-33549). ZDI scores both 9.0 and calls them remote code execution. The public proofs of concept show a kernel memory leak and a crash, not code execution. ksmbd, the in-kernel SMB file server, is not built in the AlmaLinux and CloudLinux 9 and 10 kernels. Debian and Ubuntu build it, but it runs only after an administrator installs ksmbd-tools and starts the service. Servers that share files with Samba are not affected.
• vmwgfx and nvmet (ZDI-CAN-34068 and ZDI-CAN-34076). Only the titles are public. There is no technical detail to act on yet.
• ConnMan (ZDI-CAN-32005). A userspace network manager, not the kernel.

On a server that does run ksmbd, treat ZDI-CAN-33774 as a remote memory leak and crash before login, and stop the service if it is not needed. To check:

systemctl is-active ksmbd

Technical details of the bug

The flaw sits in skb_zerocopy(), a networking function that moves references to existing memory pages from one network buffer to another instead of copying the data. When those pages belong to a file, a local user can end up changing the file’s contents in the page cache, the kernel’s in-memory copy of file data. The earlier fix for CVE-2026-43284 added a marker, SKBFL_SHARED_FRAG, that tags pages shared with a file, and the IPsec ESP code checks it before decrypting: with the marker present, ESP works on a private copy. skb_zerocopy() passes the pages along without carrying the marker over, so ESP decrypts in place on pages that are still shared. The upstream fix, titled “net: skbuff: propagate shared-frag marker in skb_zerocopy()”, copies the marker across.

The exploit needs two things. The first is a private namespace in which the user is treated as administrator of their own network, which is what user.max_user_namespaces controls. The second is a set of kernel modules: nfnetlink_queue, nft_queue, nlmon, cls_u32, act_pedit, act_mirred, esp4, and xfrm_user. Every affected kernel ships them. With both in place, the published code runs to root, as our kernel team confirmed on the lines listed above.

References

• Phoronix: new Trend Micro kernel vulnerabilities posted to public lists
• ZDI-CAN-33367 original report on the kernel mailing list
• Upstream fix posted for review: net: skbuff: propagate shared-frag marker in skb_zerocopy()
• TuxCare: skb_zerocopy zero day analysis
• CloudLinux advisory for Dirty Frag, CVE-2026-43284
• CloudLinux status page