RtabRace CVE-2026-68138: CloudLinux & KernelCare coverage

Issue

A public proof of concept for RtabRace (CVE-2026-68138), released August 12, 2026, targets a race condition in the Linux kernel's traffic-control (TC) subsystem.

Environment

• CloudLinux 8 and CloudLinux 7 Hybrid (kernel 4.18) - vulnerable in stock configuration (unprivileged user namespaces enabled by default). Immediate mitigation recommended.
• CloudLinux 9, CloudLinux 10, CloudLinux 8 LTS, CloudLinux 9 LTS - vulnerable code present, but stock configuration blocks the public exploit (user.max_user_namespaces=0).
• CloudLinux for Ubuntu 22.04 - vulnerable code present; protected by the CloudLinux sysctl overlay (/etc/sysctl.d/90-cloudlinux.conf sets user.max_user_namespaces=0). 
  Exposed only if that overlay was manually removed. A durable kernel fix comes from Canonical via apt.
• CloudLinux 7 (kernel 3.10) - not affected; predates the vulnerable code.
• KernelCare - a livepatch is in preparation.

Solution

1. Check exposure per server

# 1) Are unprivileged user namespaces enabled?
sysctl user.max_user_namespaces        # RHEL-family: 0 = safe, non-zero = exposed
sysctl kernel.unprivileged_userns_clone  # Debian/Ubuntu: 0 = safe, 1 = exposed

# 2) Can an unprivileged shell actually create one?
unshare -Urn true; echo "exit=$?"      # 0 = exposed, non-zero = safe

A server is exposed to the published exploit only when all three are true: untrusted local users have shell access, the sysctl in check 1 is non-zero, and check 2 exits 0.

2. Mitigation and fix status

We keep the following blog post up to date with the mitigation steps and the most recent news about this vulnerability. Please refer to it for the current status:

RtabRace (CVE-2026-68138): mitigation and kernel update

Cause

The kernel keeps a process-global list of traffic-control rate tables (qdisc_rtab_list) managed by qdisc_get_rtab()/qdisc_put_rtab() with a plain non-atomic reference count and no lock of its own; serialization was incidental via the global RTNL mutex. A 2019 change (commit 470502de5bdb, Linux 5.1, "net: sched: unlock rules update API") let the flower classifier run without RTNL held. Two concurrent requests installing a flower filter with a police action and naming the same rate table race the list walk against the insert and the refcount decrement against an increment, producing a use-after-free or double-free of struct qdisc_rate_table on the kernel heap.

Because the list is global rather than per-network-namespace, requests from separate network namespaces race the same object. A user namespace grants CAP_NET_ADMIN inside a private network namespace, which is all the attack needs; the capability is never required on the host itself. The upstream fix (f43ee0c0730d, mainline 7.2-rc5, backported to stable 7.1.6 as fb29e1b41052) adds a dedicated spinlock across the list walk and refcount update.

Useful Links

https://blog.cloudlinux.com/rtabrace-cve-2026-68138-mitigation-and-kernel-update/

https://cloudlinux.statuspage.io/incidents/kspns5x27g0g

https://github.com/aramosf/CVE-2026-68138