CloudLinux Says an Exploit Hit a CloudLinux 8 Server on November 4 Through Linux Kernel Bug CVE-2026-98276, Fixed Upstream Since September, and Red Hat Still Lists Every Supported RHEL Kernel as Affected

CloudLinux says an exploit for CVE-2026-98276, a use-after-free in the Linux kernel’s UDP socket code, was used against a CloudLinux 8 server on November 4 and crashed it 12 times. The upstream fix is a change of 8 added lines and 1 removed line that has been in the mainline kernel since September 17, and the kernel team published the CVE record on October 6. When we checked on November 8, Red Hat’s CVE data still listed every supported Red Hat Enterprise Linux kernel as affected, with no update, 33 days after the record appeared (our arithmetic).

That headline has limits. The exploitation claim comes from one vendor’s post, last updated on November 7 at 22:30 UTC, which does not say who ran the exploit, whose server it was or whether the server had a fixed kernel, and which says “No exploit code is public.” CISA has not added the flaw to its Known Exploited Vulnerabilities (KEV) catalog (we read catalog 2026.11.06, the newest at our check), and a web search for the CVE ID found distribution trackers but no news report of an attack.

It is the fourth Linux kernel security story we have covered since October 21, after the Infinity Core batch of six bugs, the skb zerocopy local-root bug with public exploit text and the TCP flaw behind Anthropic’s remote-root claim. This one differs in who is exposed. Nothing arrives over the network: an attacker has to run a program on the machine, and on a shared host that is exactly what a customer account does.

What CloudLinux says happened

• The flaw. CloudLinux’s post says “Any user who can run a program on a server can use it to crash the kernel or become root,” and that “our engineers reproduced both.” It adds, “Our engineers have also turned the flaw into root access,” without saying how.
• The event. “On November 4, an exploit for it was used against a CloudLinux 8 server, and only crashes were seen there.” The post says the server “crashed 12 times” and was set to reboot whenever the kernel hits an error (kernel.panic_on_oops = 1), “so each crash was a full reboot.”
• The signature. “The exploit used on November 4 leaves the same crash in the kernel log each time.” CloudLinux publishes a log search for it, which we cover below.
• What the post leaves out. It does not say who ran the exploit (an attacker, a customer or CloudLinux’s own staff), what the server was used for, or whether it already had the fix. The CloudLinux 8 livepatch reached CloudLinux’s main feed at 08:50 UTC on November 6, two days after the event. The post also does not say whether the tool used on November 4 is the one its engineers used to reproduce root access, although it says no exploit code is public.

The bug, and a fix that took 8 added lines

The fix commit, dated September 15 and written by Eric Dumazet, credits Jungwoo Lee and Wongi Lee as the reporters and explains the mechanism. A socket’s flags live in one word of memory, and the kernel helper that sets a flag is not atomic. In the commit’s words, “sk->sk_flags must only be changed while holding the socket lock, because sock_set_flag() and sock_reset_flag() use non atomic operations (__set_bit() and __clear_bit()).” One path that broke that rule is the request that asks when a packet arrived on a socket, which runs through sock_gettstamp(). The commit says that when this runs at the same moment as bind() on the same UDP socket, the two updates can overwrite each other and cancel the SOCK_RCU_FREE bit, which tells the kernel to wait before freeing the socket. The socket is then freed while the UDP receive path can still be using it.

The change is in net/core/sock.c: 8 insertions and 1 deletion. sock_gettstamp() now takes the socket lock, but only when the timestamp flag is not yet set, so the common case stays lockless. The commit says so itself: “Only grab the socket lock when SOCK_TIMESTAMP has to be set, to keep the common case lockless.” The added code reads:

/* sk->sk_flags must only be changed under the socket lock,
 * because sock_set_flag() uses non atomic operations.
 */
if (!sock_flag(sk, SOCK_TIMESTAMP)) {
	lock_sock(sk);
	sock_enable_timestamp(sk, SOCK_TIMESTAMP);
	release_sock(sk);
}

Two details stand out. First, the commit’s Fixes tag points at 1da177e4c3f4, the Linux-2.6.12-rc2 import that starts git history, and the CVE record lists 2.6.12 as the first affected version, so the kernel team did not name a later commit as the origin. CloudLinux lists kernels as old as 3.10 as affected. We confirmed that net/core/sock.c in v6.1 calls sock_enable_timestamp(sk, SOCK_TIMESTAMP) unconditionally inside sock_gettstamp(), as the commit describes. Second, the commit says similar flag changes in sk_set_memalloc() and sk_clear_memalloc() also lack the lock, but that their callers (nbd, iscsi_tcp, nvme-tcp, sunrpc and wireguard) need a careful audit and “this will be addressed in a separate patch.” We have not looked for that follow-up.

The timeline

By our arithmetic, the Nov 4 event came 48 days after the mainline commit, 40 days after the first stable release with the fix and 29 days after the CVE record. CloudLinux’s fixed kernel for 7h and 8 was in staged rollout by its November 7 update, 32 days after the record, and the CloudLinux 8 livepatch reached its main feed on day 31. Ubuntu’s notices came 28 days after the record, and Red Hat had shipped nothing at day 33.

Where each distribution stands

Red Hat’s gap matters beyond RHEL itself. CloudLinux’s post lists an “AlmaLinux kernel” stream for CloudLinux 9 and 10, and says AlmaLinux “has published fixed kernels to its testing repository, ahead of Red Hat.” The same post says AlmaLinux “will move these kernels to its production repositories after community testing,” so installing a testing-repository kernel now is a decision about less field time against a known flaw (our reading). Ubuntu 24.04 LTS is also still marked pending.

One bug, three scores and four labels

The 7.8 versus 7.0 split is about whether winning the race is hard. The kernel team’s scoring note says “The attacker owns both sides of the race” and that the reporters reproduced it as an unprivileged user (UID 1000), and it scores the complexity as low. Red Hat’s statement says “winning the timing window between timestamp queries and address binding is difficult to achieve consistently” and that the local access and high complexity constrain the risk. CloudLinux’s report of 12 crashes on one server suggests only that the race can be run repeatedly (our reading), since the post gives no success rate. Oracle’s preliminary 3.3 is a different disagreement: it counts only a low availability impact and no loss of confidentiality or integrity. The labels still matter, because a team that sorts patches by vendor label would put a Moderate item behind an Important one (our reading).

Two other signals point toward the lower labels. NVD’s entry still showed the status Received when we checked, so it carries only the kernel team’s score and no NVD analysis. FIRST’s EPSS model, in its November 7 data, put the chance of exploitation activity in the next 30 days at 0.126 percent (the 2.3rd percentile). EPSS is a model estimate, not an observation, and that data most likely predates CloudLinux’s post (our reading).

One more tracker caution. The statement panel on TuxCare’s CVE tracker page for this CVE (TuxCare is the source of the ELS kernels and KernelCare livepatches in CloudLinux’s post) carries a “Resolution: Won’t Fix” text about a different issue: an OpenVPN fingerprinting bug that it says gets an inflated 9.8 score. It says the fix “is not available upstream and is unlikely ever to be provided,” which contradicts the fix list on the same page and CloudLinux’s post. It looks like a template error, but we cannot tell, so use CloudLinux’s post for fix status.

Who is exposed

CloudLinux’s case is about hosting: “Any hosting account that can run a program counts as a local user here, and so does an attacker who got in through one vulnerable site.” It says the flaw is reached through sockets an account opens for itself, “which touch nothing CageFS hides,” that a firewall does not see it because it is “a program’s own calls to the kernel, not network traffic,” and that an SELinux policy could block the calls but cPanel & WHM requires SELinux to be disabled. It says no sysctl or boot option turns the code path off.

The same logic applies to anything that runs other people’s code on one kernel, such as CI runners, build farms, shared developer machines and container hosts, where containers share the host kernel (our reading; we did not test any container runtime). The kernel team’s scoring note says the ioctl and an unprivileged bind have no capability check, so a sandbox that allows ordinary UDP sockets and that ioctl would not stop it (our reading).

What nobody has said yet

• Who ran the exploit on November 4, against whose server, and whether that server had a fixed kernel.
• Whether the exploit used then is one of CloudLinux’s own or someone else’s, given that the post says no exploit code is public and that its engineers reproduced root access.
• When Red Hat will ship fixes. Its bug has been NEW since October 6 and last changed on October 10, 29 days before our check (our arithmetic).
• Whether anyone besides CloudLinux has seen the flaw used. CISA has not listed it, and we found no other report.
• How reliable the race is. Red Hat and the kernel team disagree, and the only field data is one server that crashed 12 times.

What to do

Find out whether your kernel has the fix

If you run a distribution kernel, the version number alone will not tell you, because vendors backport fixes into version strings that look unchanged. Use the vendor pages in the table above. If you run an upstream kernel from kernel.org, compare it with the first fixed release on your line. This short script does that and answers UNKNOWN on purpose for anything that is not a plain upstream version string. We ran it on Windows against 31 version strings with expected answers and it matched all of them. Run without arguments on a Linux server, it checks the running kernel through platform.release(); we could not test that path on this machine.

# kcheck.py
"""Compare a kernel release string with the fixed releases in the CVE-2026-98276 record.

Only upstream (kernel.org) kernels can be judged by version number. Distribution kernels
carry backported fixes under version strings that do not change, so anything that is not
a plain x.y.z string is reported as UNKNOWN on purpose.

Usage: python3 kcheck.py [release ...]     (no arguments: check the running kernel)
"""
import platform
import re
import sys

# First release on each stable line that contains the fix (from the CVE record).
FIRST_FIXED = {(5, 10): 271, (5, 15): 222, (6, 1): 189, (6, 6): 158,
               (6, 12): 112, (6, 18): 54, (7, 2): 8}
# Mainline: the fix is in 7.3-rc4, so 7.3-rc4 and everything newer has it.
MAINLINE = (7, 3)
MAINLINE_RC = 4

PLAIN = re.compile(r"^(\d+)\.(\d+)(?:\.(\d+))?(?:-rc(\d+))?\+?$")


def check(release):
    m = PLAIN.match(release.strip())
    if not m:
        return "UNKNOWN: not a plain upstream version string, ask your vendor"
    major, minor = int(m[1]), int(m[2])
    patch = int(m[3]) if m[3] is not None else 0
    rc = int(m[4]) if m[4] is not None else None
    line = (major, minor)
    if line > MAINLINE:
        return "FIXED: newer than 7.3"
    if line == MAINLINE:
        if rc is not None and rc < MAINLINE_RC:
            return f"VULNERABLE: 7.3-rc{rc} is older than 7.3-rc{MAINLINE_RC}"
        return "FIXED: 7.3-rc4 and later have the patch"
    if line in FIRST_FIXED:
        if rc is not None:
            return "UNKNOWN: release candidate of a stable line"
        need = FIRST_FIXED[line]
        if patch >= need:
            return f"FIXED: {major}.{minor}.{need} was the first release with the patch"
        return f"VULNERABLE: update to {major}.{minor}.{need} or later"
    return "NO FIX LISTED: line is not in the CVE record, assume exposed"


if __name__ == "__main__":
    for release in sys.argv[1:] or [platform.release()]:
        print(f"{release:<26} {check(release)}")

Run on example strings: releases on either side of the fix, two 7.3 release candidates and newer, two lines the record does not list, and four strings that are not plain upstream versions (a custom build, an Ubuntu-style string, and the fixed CloudLinux 8 and CloudLinux 9 kernel versions named in CloudLinux’s post):

python3 kcheck.py 6.12.111 6.12.112 6.6.157 6.1.189 5.15.221 5.10.271 7.2.8 7.3.0-rc3 7.3.0-rc4 7.3.3 6.19.3 5.4.290 6.12.112-custom 5.15.0-202-generic 4.18.0-553.184.1.lve.1 5.14.0-687.66.2.el9_8

6.12.111                   VULNERABLE: update to 6.12.112 or later
6.12.112                   FIXED: 6.12.112 was the first release with the patch
6.6.157                    VULNERABLE: update to 6.6.158 or later
6.1.189                    FIXED: 6.1.189 was the first release with the patch
5.15.221                   VULNERABLE: update to 5.15.222 or later
5.10.271                   FIXED: 5.10.271 was the first release with the patch
7.2.8                      FIXED: 7.2.8 was the first release with the patch
7.3.0-rc3                  VULNERABLE: 7.3-rc3 is older than 7.3-rc4
7.3.0-rc4                  FIXED: 7.3-rc4 and later have the patch
7.3.3                      FIXED: 7.3-rc4 and later have the patch
6.19.3                     NO FIX LISTED: line is not in the CVE record, assume exposed
5.4.290                    NO FIX LISTED: line is not in the CVE record, assume exposed
6.12.112-custom            UNKNOWN: not a plain upstream version string, ask your vendor
5.15.0-202-generic         UNKNOWN: not a plain upstream version string, ask your vendor
4.18.0-553.184.1.lve.1     UNKNOWN: not a plain upstream version string, ask your vendor
5.14.0-687.66.2.el9_8      UNKNOWN: not a plain upstream version string, ask your vendor

Look for crashes

CloudLinux says the exploit it saw leaves the same crash in the kernel log each time, and gives this search of the previous boot (it needs a persistent journal; use -b -2, -b -3 and so on for earlier boots):

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

We could not reproduce a crash, so we tested only the search pattern. This is a six-line file of made-up kernel log lines (our invention, not a real crash), two of which contain function names from the list:

Nov 04 03:12:01 host kernel: usb 1-1: new high-speed USB device number 4 using xhci_hcd
Nov 04 03:12:07 host kernel: Out of memory: Killed process 4121 (php-fpm) total-vm:812344kB
Nov 04 03:14:40 host kernel: RIP: 0010:inet_sock_destruct+0x1c3/0x2a0
Nov 04 03:14:40 host kernel: Call Trace: udp_destruct_common+0x2e/0x90
Nov 04 03:15:02 host kernel: EXT4-fs (sda1): re-mounted. Opts: (null)
Nov 04 03:15:09 host kernel: nf_conntrack: table full, dropping packet

Passing the same pattern to grep -E with that file as the input, in place of the journal, printed exactly the two lines that contain those names:

Nov 04 03:14:40 host kernel: RIP: 0010:inet_sock_destruct+0x1c3/0x2a0
Nov 04 03:14:40 host kernel: Call Trace: udp_destruct_common+0x2e/0x90

CloudLinux’s caution applies: “A match isn’t proof of an attack on its own,” and “A clean log doesn’t rule out an attack that didn’t crash the server.” On a server without the fix, a match is a reason to check which accounts were logged in and what they were running.

Until the fix is installed

CloudLinux’s advice is that “restricting or suspending accounts you don’t trust lowers the risk: shell access, cron jobs, and customer applications that run their own programs,” and it adds, “It doesn’t remove the risk.” For CloudLinux 8, the post says the livepatch can be checked with kcarectl --patch-info | grep CVE-2026-98276 (its command; we did not run it). Its steps for the staged-rollout and testing-repository kernels are in its post, and are worth reading in full before you use them on a production server.

What we checked

We read the CloudLinux post; the CVE.org record, including the kernel team’s scoring note, and NVD’s entry; the fix commit text through GitHub’s mirror of the kernel tree (git.kernel.org sits behind a bot check); the kernel.org ChangeLog files of the seven stable releases and the 7.3-rc4 tag; CISA’s KEV feed; FIRST’s EPSS data; and the CVE pages of Red Hat (JSON and Bugzilla), Ubuntu, Debian, SUSE, Amazon Linux, Oracle Linux and TuxCare. We also looked at net/core/sock.c in v6.1, and searched GitHub repository names for the CVE ID (no results, which proves little). We did not test any kernel, run or see an exploit, or contact CloudLinux, the reporters or any distribution, and this post adds no exploit detail beyond the public CVE and commit text. Distribution pages change often, so the status table is a snapshot from November 8. “Our reading” and “our arithmetic” mark inferences and counts that are ours.

• CloudLinux: CVE-2026-98276 Linux kernel UDP socket flaw: kernel update for CloudLinux
• Records: CVE.org, NVD, FIRST EPSS and CISA’s KEV feed
• Fix: mainline commit 9ed55f3dbef4, the 7.3-rc4 tag and the ChangeLog files for 6.12.112, 6.1.189 and 5.10.271
• Distribution pages: Red Hat and its bug, Ubuntu, Debian, SUSE, Amazon Linux, Oracle Linux and TuxCare
• Earlier on sxz.io: Infinity Core, the skb zerocopy bug, CVE-2026-98432 and Trail of Bits on stable-kernel backports