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: there is no CVE, no merged upstream fix, and the exploit is public. 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.

Version	Affected	Status
CloudLinux 7 (CL7) Kernel 3.10	✅ No The kernel never decrypts in place, so the flaw has nothing to act on, and ordinary accounts cannot create their own namespaces anyway. Measured on a stock install.	✅ Kernel patch: not needed ✅ Livepatch: not needed
CloudLinux 7 hybrid (CL7h) Kernel 4.18 (.lve.el7h)	❌ Yes, exposed as shipped An ordinary account creates its own namespace with no configuration change on your part, and every component the attack needs is present. Measured on a stock install, kernel 4.18.0-553.171.1.lve.el7h.	⏳ Kernel patch: waiting on the upstream fix ⏳ Livepatch: in preparation
CloudLinux 8 (CL8) Kernel 4.18 (.lve.el8)	⚠️ Conditional Servers installed since mid-2024 have unprivileged user namespaces disabled by default, so ordinary accounts cannot begin. Servers installed earlier keep them enabled and are exposed. Run the check above.	⏳ Kernel patch: waiting on the upstream fix ⏳ Livepatch: in progress
CloudLinux 8 ELS (CL8 ELS) Kernel 5.14 uplift (.tuxcare.*)	⚠️ Conditional Same as CloudLinux 8, kernel 5.14.0-284.1101.el8.tuxcare.11.els14. Closed by default on servers installed since mid-2024, exposed on older ones. Run the check above.	⏳ Kernel patch: pending on the extended-support channel ℹ️ Livepatch: none. This line has no live-patching stream, so a kernel upgrade and a reboot is the only route.
CloudLinux 9 (CL9) Kernel 5.14 (.el9_*)	⚠️ Conditional Same kernel as AlmaLinux 9 (5.14.0-687.59.1.el9_8), where root was confirmed in-house. Closed by default on servers installed since mid-2024, exposed on older ones. Run the check above.	⏳ Kernel patch: no fixed kernel yet ⏳ Livepatch: in review
CloudLinux 9 ELS (CL9 ELS) Kernel 5.14 (.tuxcare.*)	⚠️ Conditional Same as CloudLinux 9. Not tested separately. Run the check above.	⏳ Kernel patch: pending on the extended-support channel ⏳ Livepatch: in preparation
CloudLinux 10 (CL10) Kernel 6.12 (.el10_*)	⚠️ Closed by default Same kernel as AlmaLinux 10, where root was confirmed in-house. Unprivileged user namespaces are disabled by default, so ordinary accounts cannot begin as shipped.	⏳ Kernel patch: no fixed kernel yet ✅ Livepatch: released in the production feed
CloudLinux for Ubuntu 22.04 Kernel 5.15-generic	⚠️ Closed by default Ordinary accounts cannot begin, and the limit comes from CloudLinux’s own configuration rather than from Ubuntu. Measured on a stock install.	⏳ Kernel patch: via Canonical † ⏳ Livepatch: not started

^† 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 without a livepatch. 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 patched 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/falseninstall act_pedit /bin/falsen' > /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

No fixed kernel has shipped for any line yet. An upstream fix was posted for review on 22 October. The netdev maintainer has reviewed it, and it is not merged. The KernelCare livepatch for CloudLinux 10 is built from that fix candidate, and we verified that it stops the public exploit. On every other line, the mitigation above is the answer until a fixed kernel or livepatch ships. Install commands for each kernel stream will be added here when its fix is released.

Stream 1: CloudLinux kernel (CL7h, CL8)

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.

Once a fixed kernel ships, compare uname -r after the reboot with the version given in the stream’s latest update above.

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 builds a packet from memory pages that already exist instead of copying them. It lets a local user change the contents of a file they can only read, through the page cache, the kernel’s in-memory copy of file data. The upstream fix is titled “net: skbuff: propagate shared-frag marker in skb_zerocopy()”. The marker flags pages that other parts of the system also hold, so they are not modified in place. The 2026 fix for CVE-2026-43284 added that check elsewhere in the kernel. In this bug the marker is lost before the check happens, so the check never sees it.

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