CVE-2026-68138, nicknamed RtabRace, is a race condition in the Linux kernel's traffic-control subsystem. An unprivileged local user who can open a user namespace can corrupt kernel memory with it. CVSS is 7.0, Red Hat rates it Moderate, and a working exploit is public.
That severity rating undersells what it means on shared hosting. The reliably reproduced outcome is a kernel panic — one compromised account running a published binary takes the whole machine, and every other customer on it, offline on demand. Root escalation is the harder case; the researcher demonstrated it on stock Ubuntu, and CloudLinux did not reproduce it on any of their versions. You do not need the root case for this to be your worst afternoon of the month.
The bug is in upstream Linux, not in anything CloudLinux ships. Every kernel carrying the 2019 traffic-control change is in scope, which puts RHEL, AlmaLinux, Rocky, and several Debian and Ubuntu releases in the same position.
Which CloudLinux versions need action
| Version | Status |
|---|---|
| CloudLinux 7 | Not affected — predates the vulnerable code |
| CloudLinux 7 Hybrid | Exposed — mitigate now, kernel patch in preparation |
| CloudLinux 8 | Exposed — mitigate now, kernel patch in preparation |
| CloudLinux 8 LTS | Code present, stock config blocks the exploit; patch via TuxCare ELS |
| CloudLinux 9 | Code present, stock config blocks the exploit; patch via AlmaLinux |
| CloudLinux 9 LTS | Code present, stock config blocks the exploit; patch via TuxCare ELS |
| CloudLinux 10 | Code present, stock config blocks the exploit; patch via AlmaLinux |
| CloudLinux for Ubuntu 22.04 | Code present, stock config blocks the exploit; patch via Canonical |
The split is entirely about one sysctl. CloudLinux 8 and 7 Hybrid ship with unprivileged user
namespaces enabled; everything newer ships with user.max_user_namespaces=0, which blocks
the published exploit in its stock configuration. If you have changed that sysctl on a 9, 10, or
LTS box — some container tooling asks you to — you have moved yourself back into the exposed
column.
Check your exposure
Two commands. Run them on every host before you decide anything.
sysctl user.max_user_namespaces
unshare -Urn true; echo "exit=$?"
You are exposed when all three of these are true: untrusted users have shell access,
user.max_user_namespaces is non-zero, and unshare exits 0. On a shared cPanel box with
jailed SSH handed out to customers, assume the first
condition is met.
The mitigation
One command, effective immediately, no reboot:
echo 'user.max_user_namespaces = 0' > /etc/sysctl.d/99-rtabrace.conf
sysctl -p /etc/sysctl.d/99-rtabrace.conf
If you genuinely need user namespaces
Two narrower options, both weaker than the sysctl:
Block the traffic-control modules the exploit path needs. This only works if they are not
already loaded, so verify with lsmod | grep -E 'cls_flower|act_police' first:
tee /etc/modprobe.d/99-rtabrace.conf > /dev/null <<'EOF'
install cls_flower /bin/true
install act_police /bin/true
EOF
Or drop CAP_NET_ADMIN from container workloads that don't need it — --cap-drop=NET_ADMIN on
Docker, securityContext.capabilities.drop on Kubernetes.
Why it races
A 2019 commit (470502de5bdb) removed RTNL mutex protection from the flower classifier so it
could run unlocked. That left qdisc_rtab_list — a process-global rate-table list guarded by a
plain non-atomic refcnt — reachable without serialisation. Concurrent RTM_NEWTFILTER
requests from separate network namespaces race the same rate-table object into a double free,
which corrupts the kernel heap. The upstream fix adds a dedicated spinlock.
Getting to a real fix
The sysctl is a stopgap. Four delivery streams are in flight, none with published target dates as of 18 August 2026:
- CloudLinux 8 and 7 Hybrid kernels — backport in preparation, ships through the normal kernel channel and needs a reboot.
- CloudLinux 9 and 10 kernels — waiting on AlmaLinux.
- CloudLinux 8 LTS and 9 LTS — waiting on TuxCare ELS.
- KernelCare livepatch — in preparation for all affected platforms.
If you run KernelCare, the livepatch closes this with no reboot and no maintenance window once it reaches the feeds. Confirm it landed with:
kcarectl --patch-info | grep CVE-2026-68138
That is the argument for live patching on a hosting fleet in one line: the alternative is coordinating a reboot window across every shared server you own while a public exploit sits in the wild. Add a KernelCare license to existing servers, or check the CloudLinux tiers if you're sizing both together.