CloudLinux Still Has No Kernel Patch for DirtyAH6 and Three Sibling LPEs

The Situation

On 18 September 2026, researcher manizada posted to oss-security after a linux-distros embargo: four independent local privilege-escalation bugs in the Linux kernel network stack, with public exploit code. The names and IDs:

DirtyAH6 - CVE-2026-80844 - xfrm AH6 routing-header handling (ipv6_rearrange_rthdr)
TUNderflow - CVE-2026-81000 - TUN receive-headroom underflow
PPPoEject - CVE-2026-68121 - PPPoE use-after-free across dev_hard_header()
DiagSpill - CVE-2026-74469 - SCTP peer transport_count wrap into sock_diag

The reporter's wording: all four PoCs give unprivileged local user → root on their targets. The first three need unprivileged user/network namespaces or specific CAP_NET_*. DiagSpill does not - it needs sctp and sctp_diag.

CloudLinux's own article (fetched 2026-10-02) is the operator document. Verbatim posture:

No fixed CloudLinux kernel and no KernelCare live patch exists for any of the four CVEs on the standard CloudLinux 7, CloudLinux 7 Hybrid, CloudLinux 8 or CloudLinux 9 kernels.

One exception: PPPoEject only, and only on CloudLinux 9 LTS and AlmaLinux 9.2 FIPS ESU (K20260915_0020 / K20260915_0019, stable since 18 September). Those kernels show a tuxcare suffix in uname -r. DirtyAH6, TUNderflow, and DiagSpill have no coverage on any CloudLinux stream. CloudLinux says remaining coverage is the regular KernelCare cycle, no out-of-band/emergency patch, no firm date.

Not in CISA KEV. Catalog 2026.10.01 (dateReleased 2026-10-01T19:54:04Z, 1,731 entries, fetched 2026-10-02) has none of the four IDs. Today's KEV add was Fortinet FortiMail (CVE-2026-104286), not this.

Scores - quote the CNA, do not invent the missing one

CVE	Name	CNA (kernel.org) CVSS 3.1	Vector
CVE-2026-80844	DirtyAH6	not published on the CVE record we fetched	-
CVE-2026-81000	TUNderflow	7.8 HIGH	`AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H`
CVE-2026-68121	PPPoEject	7.8 HIGH	`AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H`
CVE-2026-74469	DiagSpill	8.8 HIGH	`AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H`

DiagSpill's network vector is the CNA's scoring of the SCTP path, not "unauthenticated remote root." The researcher said remote crash/DoS is possible if ASCONF/ADD-IP plus SCTP-AUTH (or net.sctp.addip_noauth_enable=1) are on - all disabled by default - and something on the box still issues the sock_diag dump. They said they do not see a path to full remote root. DirtyAH6 remote-root was a lab result with on-target memory grooming; remote-only grooming to root was called extremely difficult. Treat those as researcher claims, not a mass-scan event.

Why this is a hosting-fleet problem

These are local bugs. On a laptop that is one user, they are "someone already on the box." On a cPanel + CloudLinux shared host they are the everyday tenant model: a $5 account, a popped WordPress, a jailbroken PHP script. If that uid can open the required modules and (for three of four) an unprivileged user namespace, the researcher says the PoC is local root.

CloudLinux's own split:

CloudLinux 8 and CloudLinux 7 Hybrid: unprivileged user namespaces allowed by default. DirtyAH6 / TUNderflow / PPPoEject path is in play unless you close it.
CloudLinux 9 and CloudLinux 7 (non-Hybrid): user.max_user_namespaces = 0 already (CL9 via lve-utils /etc/sysctl.d/90-cloudlinux.conf; CL7 unless user_namespace.enable=1 was added to the boot line).
DiagSpill: no namespace/cap requirement. sctp/sctp_diag load on demand on CloudLinux 7; blocked from autoloading in kernel-modules-extra on CloudLinux 8 and 9.

LVE and CageFS are not a substitute for those sysctls. CloudLinux is explicit: blocking user namespaces does not break LVE or CageFS. It does break rootless containers.

Upstream floors (not CloudLinux floors)

The researcher listed the first upstream stable releases that contain all four fixes:

5.10.270, 5.15.221, 6.1.188, 6.6.157, 6.12.109, 6.18.50, 7.2.4

CloudLinux 7 / 7h / 8 / 9 are 3.10 / 4.18 / 5.14 lines. Those numbers are not a yum update kernel target on a CloudLinux box. Do not reboot onto a random mainline kernel to "hit the floor." Wait for CloudLinux / KernelCare / TuxCare ELS packages, and until then apply the vendor mitigations.

Git commits named in the oss-security mail (for anyone matching vendor changelogs later):

DirtyAH6 - 7bad4bda74dc4713f398d3b7624ff05478e3a568
TUNderflow - 447c9303942c439a117d9b76ce6d6e2116b38ee7
PPPoEject - e9c238f6fe42fb1b4dba3a578277de32cb487937
DiagSpill - bd0e9289e2642f6a5c54faad304ce0f41e926d22

What to do now

1. Confirm you are actually on CloudLinux, and which stream

cat /etc/os-release
uname -r
# ELS / TuxCare kernels carry a tuxcare suffix

2. Ask KernelCare the only question it can answer today

kcarectl --patch-info | grep -E 'CVE-2026-(80844|81000|68121|74469)'

Empty on stock CL7 / CL7h / CL8 / CL9 is what CloudLinux documented. A hit on CVE-2026-68121 only is the ELS exception, not coverage for the other three.

3. Exposure checks (vendor commands, verbatim intent)

# 0 is the safe value
sysctl user.max_user_namespaces

# exit=0 means an ordinary user can create a user namespace
runuser -u nobody -- unshare -Urn true; echo "exit=$?"
# "No space left on device" here is expected and is not a disk problem

lsmod | grep -E '^(sctp|sctp_diag|ah6|pppoe|tun)'
modinfo -n sctp   # "not found" means the module is not on disk

4. Interim mitigations CloudLinux called optional - still do them on CL8 / 7h

CloudLinux: root is not reachable by default on vendor kernels with the published exploits (stock config blocks the path, or the exploit's KASLR bypass does not work reliably). They still publish hardening that closes the class, not just these four IDs, and is safe to leave in place after patches ship:

# CloudLinux 8 and 7 Hybrid: close the user-namespace path
echo 'user.max_user_namespaces = 0' > /etc/sysctl.d/90-lpe-mitigation.conf
sysctl --system

# If SCTP is not in use
printf 'install sctp /bin/false\ninstall sctp_diag /bin/false\n' > /etc/modprobe.d/no-sctp.conf

Same install /bin/false pattern is safe for ah6 and pppoe on a hosting server. Only add it for tun if no VPN or container tooling on that box needs it.

5. cPanel caveat before you flip the sysctl

CloudLinux: cPanel, EasyApache, PHP Selector, CageFS, and LVE do not use user namespaces or the affected modules. Exception: cPanel containerized packages (ea-podman).

/usr/local/cpanel/scripts/ea-podman containers

Empty → user.max_user_namespaces = 0 is safe. If ea-tomcat, ea-redis, or ea-nodejs are deployed, that sysctl will break them.

6. After you harden, record the evidence

sysctl user.max_user_namespaces
lsmod | grep -E 'sctp|sctp_diag|ah6|pppoe|tun' || true
kcarectl --patch-info | grep -E 'CVE-2026-(80844|81000|68121|74469)' || true
date -u; uname -r

Keep that output with the change ticket. When KernelCare actually ships, kcarectl --update (or the kernel RPM + reboot) is the close-out, not this sysctl.

What we don't know

CloudLinux's "root is not reachable by default" is a vendor lab statement, not a CISA exploitation status. They reproduced the four bugs on EL6-10, Debian, and Ubuntu, then said stock vendor kernels either block the path or the published exploit's CPU-specific KASLR bypass does not work reliably. We did not re-run those PoCs.
No CVSS on CVE-2026-80844 in the kernel.org CNA record we fetched. Do not copy a 7.8 from the siblings onto DirtyAH6.
Not in CISA KEV as of catalog 2026.10.01 / fetch 2026-10-02. That can change. Re-check the JSON before you tell a customer the urgency dropped.
No public claim of in-the-wild mass exploitation for these four IDs in the sources cited here. The researcher published PoCs. CloudLinux did not claim they are being used against shared hosts.
Container escape was described as theoretically possible (host kernel corruption from a container). The researcher did not pursue that with the PoCs.
Remote DirtyAH6 root was a lab result with on-target grooming. Do not brief it as "unauth internet RCE."
We are not publishing exploit steps, IOCs, or PoC links. Patch and mitigate from the vendor article and the oss-security summary. Do not paste a random "DirtyAH6 detector" from a forum into production.
This is not last week's CISA kernel KEV trio, not LiteSpeed 6.3.7, not WHMCS CVE-2026-67399. Different products, different commands.

Sources

CloudLinux - KernelCare coverage and mitigations for four LPE CVEs (fetched 2026-10-02)
oss-security - A quartet of Linux local root vulns: DirtyAH6, PPPoEject, TUNderflow, and DiagSpill (manizada, 18 September 2026 06:15 UTC)
CVE JSON - CVE-2026-80844 (CNA kernel.org; no CVSS in the record fetched 2026-10-02)
CVE JSON - CVE-2026-81000 (CVSS 3.1 7.8 HIGH)
CVE JSON - CVE-2026-68121 (CVSS 3.1 7.8 HIGH)
CVE JSON - CVE-2026-74469 (CVSS 3.1 8.8 HIGH)
CISA KEV JSON - https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json (catalogVersion 2026.10.01, 1,731 entries; none of the four IDs)