CVE-2026-98276: CloudLinux UDP Socket UAF - Tenant Crash and Root, CL7 Still Open

CVE-2026-98276 is the Linux kernel CNA’s name for a use-after-free in UDP socket teardown. Upstream title: net: lock the socket in sock_gettstamp(). File: net/core/sock.c. NVD id CVE-2026-98276. vulnStatus Received. published 2026-10-06T09:18:17.360. lastModified 2026-10-19T10:18:28.973. Source identifier is the kernel CNA (416baaa9-dc9f-4396-8d5f-8c081fb06d67).[1][2]

Kernel CNA CVSS 3.1 is 7.8 High (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) as a Secondary metric. NVD has no Primary score. Ubuntu copies that 7.8 and sets Ubuntu priority Medium. Red Hat’s product score is 7.0 Moderate, vector AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H, status draft, CWE-413, Bugzilla 2546479, public_date 2026-10-06. It is not on CISA KEV. Catalog we used this morning still has 1,769 entries (same count as 2026.11.06).[1][3][4][5]

CloudLinux published the operator document on 7 November 2026, 22:30 UTC. Their engineers reproduced kernel crash and root. On 4 November an exploit against a CloudLinux 8 server crashed it 12 times (kernel.panic_on_oops = 1, so each oops was a reboot). They say only crashes were seen on that box, and no exploit code is public. That is CloudLinux’s report, not a CISA exploitation record.[6]

Yesterday’s post was the IPv4 TCP UAF (CVE-2026-98432, 9.8, unauth network). This ID is local. On a laptop that is “someone already on the box.” On a cPanel + CloudLinux shared host it is the everyday tenant model.

What it is

This is a kernel UDP socket bug, not a web-app RCE.[1][2]

sock_gettstamp() implements SIOCGSTAMP / SIOCGSTAMPNS (and SIOCGSTAMPNS_NEW): “when did a packet arrive on this socket?” The first time that runs, the kernel sets SOCK_TIMESTAMP on sk->sk_flags without taking the socket lock. sock_set_flag() uses non-atomic __set_bit(). bind() on the same UDP socket sets SOCK_RCU_FREE the same way. Two threads, one word, lost update. After the race, SOCK_RCU_FREE is gone while the socket is already visible to lockless UDP receive. sk_destruct() then frees immediately instead of waiting for an RCU grace period. The receive path still holds a pointer. The KASAN splat in the CNA write-up is ipv4_pktinfo_prepare from udp_queue_rcv_one_skb, task exploit, UID 1000, kernel 6.12.95+.[1][2]

Upstream fix: take the socket lock in sock_gettstamp() only when SOCK_TIMESTAMP has to be set, so the common path stays lockless. Stable floors named by the kernel CNA: 5.10.271, 5.15.222, 6.1.189, 6.6.158, 6.12.112, 6.18.54, 7.2.8, 7.3-rc4. Introduced in 2.6.12.[1][2]

We did not race bind() against SIOCGSTAMPNS_NEW. Treat “root” as CloudLinux’s lab result, not as a public PoC we ran.

How serious is it?

On paper: local, low privileges, high C/I/A. Kernel CNA 7.8 High. Red Hat Moderate because they want a precise race (AC:H) and local access. Ubuntu Medium.[1][3][4]

On a shared host: CloudLinux: any account that can run a program (shell, cron, a popped site) is a local user. CageFS does not help - the path is sockets the account opens for itself. No sysctl or boot option turns it off. A firewall never sees it. SELinux could, but cPanel & WHM requires SELinux off. They say there is no mitigation other than restricting untrusted accounts until the kernel or KernelCare patch is in.[6]

Vendors disagree on ease:

Red Hat: winning the timing window is difficult to achieve consistently; still admits crash / DoS / potentially privilege escalation.[3]
CloudLinux: engineers reproduced both crash and root; a CL8 production box was crashed 12 times on 4 Nov; no public exploit.[6]

Do not flatten those into “it’s only a DoS.” Also do not flatten them into “every $5 account is root this morning.” The published trigger still needs a local program that races timestamp ioctl vs bind() on a UDP socket.

Not KEV. Newest KEV rows this week remain SonicWall SSLVPN CVE-2026-19868 (6 Nov) and WordPress core CVE-2026-119977 (3 Nov) - the latter already shipped here as the 7.1.4 upgrade-window post.[5]

Who is affected

In scope until you hit a vendor floor: kernels from 2.6.12 through the stable tags above. CloudLinux lists 7, 7h, 8, 8 LTS, 9, 9 LTS, 10. CloudLinux for Ubuntu 22.04 was still being checked as of their 7 Nov 22:30 UTC article (that kernel comes from Canonical via apt).[1][6]

Floors we actually pulled this morning:

Distro / product	Status this morning	Floor / note
CloudLinux 7 (3.10)	Affected	Kernel in preparation. No KernelCare livepatch yet.[6]
CloudLinux 7h (4.18)	Affected; kernel in staged rollout	`4.18.0-553.184.1.lve.1` via `cloudlinux-rollout-10-bypass`. No livepatch yet.[6]
CloudLinux 8 (4.18)	Affected; kernel in staged rollout	Same NVR. KernelCare livepatch on main feed since 08:50 UTC 6 Nov.[6]
CloudLinux 8 LTS / 9 LTS	Affected; kernel in stable	`kernel-lts` els17 or newer since 2 Nov. No livepatch; reboot.[6]
CloudLinux 9	Affected	AlmaLinux testing `5.14.0-687.66.2.el9_8`. KernelCare in preparation.[6]
CloudLinux 10	Affected	AlmaLinux testing `6.12.0-211.74.2.el10_2`. KernelCare in preparation.[6]
RHEL 8 / 9 / 10	Affected (hydra JSON)	No RHSA in the CVE record we fetched. Red Hat has not released a fix; CloudLinux says Alma published testing kernels ahead of Red Hat.[3][6]
RHEL 6	Out of support scope	-
RHEL 7	Affected	ELS kernel. Still EOL for anyone not on paid ELS.[3]
Debian bookworm (security)	Fixed	`linux` 6.1.190-1
Debian trixie (security)	Fixed	`linux` 6.12.116-1
Debian forky / sid	Fixed	7.2.15-1 / 7.3.3-1
Ubuntu 22.04 (`linux`)	Released	`5.15.0-202.212` - notices USN-8961-1 (3 Nov) include this ID
Ubuntu 24.04 (`linux`)	Pending	`6.8.0-148.148` on the tracker. USN-8959-1 lists noble but the generic `linux` row is still pending. Do not treat that USN as a 24.04 generic floor.
Ubuntu 20.04 (`linux`)	Needed	HWE 5.15 is released on esm-infra as `5.15.0-202.212~20.04.1`
Ubuntu 26.10 / resolute (`linux`)	Released	`7.0.0-42.42`

AlmaLinux / Rocky follow the RHEL NVR once it is in their repos. CloudLinux 9/10 testing kernels are Alma testing, not CloudLinux production. Do not assume the NVR is already on the mirror you actually use.

What to do now

Read the running kernel, not the last yum log.

uname -r
# EL / CloudLinux:
rpm -q kernel
# KernelCare:
kcarectl --patch-info | grep CVE-2026-98276
# Debian/Ubuntu:
dpkg -l 'linux-image-*' | awk '/^ii/{print $2,$3}'

kcarectl --info does not list CVEs. CloudLinux is explicit: use --patch-info. Empty grep means not patched.[6]

CloudLinux 8 with KernelCare (no reboot):

kcarectl --update
kcarectl --patch-info | grep CVE-2026-98276

Livepatch is CL8 only as of 7 Nov 22:30 UTC. CL9/10 “in preparation, no date.” CL7/7h: none. CL8 LTS: none - reboot into els17.[6]

CloudLinux 7h / 8 stock kernel (staged rollout). A normal yum update kernel waits for the rollout. To pull it now:

yum update cloudlinux-release
yum update kernel --enablerepo=cloudlinux-rollout-10-bypass
reboot
uname -r   # expect 4.18.0-553.184.1.lve.1 or later

CloudLinux 8 LTS / 9 LTS:

yum update 'kernel*'
reboot
uname -r   # els17 or later

CloudLinux 9 / 10: CloudLinux’s own commands enable AlmaLinux testing, update kernel*, then disable testing and reboot. That is a testing kernel. Recheck their article before you put it on a production node. Prefer waiting for the CloudLinux production repo, or KernelCare when it exists for that stream.[6]
Ubuntu 22.04 generic: apt update && apt install --only-upgrade linux-image-generic (or the meta you actually boot) then reboot. Confirm uname -r is at least the 5.15.0-202 line. Ubuntu 24.04 generic is still pending on the tracker we fetched.
Debian bookworm/trixie: install from security, not the unfixed suite version (bookworm 6.1.176-1 and trixie 6.12.107-1 are still marked vulnerable).
Until the fix is running: CloudLinux says restrict shell, cron, and untrusted apps. That lowers risk. It does not close it. We are not publishing exploit steps.
If a CL box has been rebooting for no reason, CloudLinux’s journal grep for the 4 Nov crash class (needs a persistent journal):

journalctl -k -b -1 | grep -E 'inet_sock_destruct|udp_destruct_common|__sk_mem_raise_allocated|__udp_enqueue_schedule_skb'

A match is not proof of this CVE. A clean log does not rule out a non-crashing root. Snapshot before you conclude.[6]

Versions with no floor

CloudLinux 7 standard 3.10: kernel still in preparation, no livepatch. This is the open hole this morning.
RHEL 8/9/10: hydra still Affected. No RHSA in the record we fetched.
Ubuntu 24.04 generic linux: pending.
Ubuntu 20.04 generic linux: needed unless you are on the HWE 5.15 ESM build.
EOL Ubuntu 16.04 / 18.04: tracker needed / ignored. Upgrade the OS.
Custom / panel / appliance kernels with no errata: isolate or replace.

Compromise signs

None of these prove CVE-2026-98276. Together they are enough to snapshot and rotate.

uname -r below the floor and untrusted local code can run (shared hosting default).
Repeated oops / reboot with the journal strings CloudLinux named, especially on CL8 around 4 Nov.
New root SSH keys, new SUID binaries, unexpected kernel modules - general host compromise, not a published IoC for this ID.

CISA did not list this CVE. There is no BOD due date.

FAQ

Is this on CISA KEV? No. 1,769 entries this morning. Not this ID.[5]

Is it remote? No. Kernel CNA and Red Hat score AV:L. CloudLinux: not network traffic, not a firewall event. A tenant who can run a binary is local.[1][3][6]

Does CageFS / LVE stop it? CloudLinux: no. Sockets the account opens itself.[6]

Is livepatch enough? Only if kcarectl --patch-info names this ID. CL8 main feed yes (as of 6 Nov). Other streams: no, or not yet.[6]

Same bug as CVE-2026-98432? No. 98432 is IPv4 TCP handshake, unauth network, 9.8. This is UDP sock_gettstamp() vs bind(), local, 7.8 / 7.0. Different file, different trigger, different floors.

Can I nftables it away? No published network mitigation. The path is local syscalls.

Honesty

We did not exploit this. No ioctl/bind PoC was run.
CVSS 7.8 is kernel CNA Secondary and Ubuntu’s copy. Red Hat is 7.0 Moderate draft. NVD is Received with no Primary score.[1][3][4]
“Root” and the 12 crashes on 4 Nov are CloudLinux’s 7 Nov 22:30 UTC article, not CISA, not a public exploit archive. They say no exploit code is public.
Not KEV. No public IoCs.
CloudLinux KernelCare / rollout / Alma-testing sentences are from that 7 Nov article. Recheck before you reboot a KC host into a testing kernel.
Ubuntu 24.04: linux row pending on the CVE JSON fetched 9 Nov 2026. USN-8959-1 listing noble is not treated here as a generic-24.04 floor.
RHEL 8/9/10: Affected on hydra JSON this morning. We do not invent an RHSA.
CWE: Red Hat CWE-413. NVD has no CWE in the record we fetched. We do not invent CWE-416.

Sources

NVD CVE-2026-98276 - Received; kernel CNA 7.8 Secondary AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H; published 2026-10-06T09:18:17.360; lastModified 2026-10-19T10:18:28.973
linux-cve-announce, 6 Oct 2026 - Greg Kroah-Hartman; stable floors 5.10.271 … 7.3-rc4; introduced 2.6.12
Red Hat CVE-2026-98276 - Moderate 7.0 AV:L/AC:H/...; CWE-413; Bugzilla 2546479; RHEL 8/9/10 Affected; hydra JSON pulled 2026-11-09
Ubuntu CVE-2026-98276 JSON - priority Medium; linux jammy released 5.15.0-202.212; noble pending 6.8.0-148.148; updated_at 2026-11-03T18:48:36Z; USN-8961-1 / USN-8959-1 / USN-8963-1 / USN-8960-1
CISA KEV JSON - 1,769 entries this morning; CVE-2026-98276 absent
CloudLinux, 7 Nov 2026 22:30 UTC - crash+root reproduced; CL8 crashed 12× on 4 Nov; stream floors and KernelCare status
Debian tracker CVE-2026-98276 - bookworm security 6.1.190-1; trixie security 6.12.116-1
CVE Record