CVE-2026-98276 Linux kernel UDP socket flaw: kernel update for CloudLinux

📋 TL;DR — last updated November 7, 2026, 22:30 UTC

CVE-2026-98276 (CVSS 7.0, Moderate per Red Hat) is a use-after-free vulnerability in the Linux kernel’s UDP socket code that lets any local user crash the server or become root. Our engineers reproduced both. On November 4, an exploit for it crashed a CloudLinux 8 server; only crashes were seen on that server. No exploit code is public.

• Affected: CloudLinux 7, 7h, 8, 8 LTS, 9, 9 LTS and 10. We’re still checking CloudLinux for Ubuntu 22.04. → Affected CloudLinux versions
• Mitigation: none. Limiting who can run programs on the server lowers the risk. → Is there a mitigation?
• Fix status: → Update instructions
• — CloudLinux 7h and 8 kernel: fixed kernel in staged rollout.
• — CloudLinux 7 kernel: fixed kernel in preparation.
• — AlmaLinux kernel (CloudLinux 9, 10): fixed kernel in the AlmaLinux testing repository; Red Hat hasn’t released its fix.
• — LTS kernels (CloudLinux 8 LTS, 9 LTS): fixed kernel in the stable channel.
• — KernelCare livepatch: on the main feed for CloudLinux 8 (not 8 LTS); in preparation for CloudLinux 9 and 10.
• Verify: kcarectl --patch-info | grep CVE-2026-98276, or uname -r against your stream’s version. A second command checks whether the exploit crashed a server. → How to verify you are patched
• Why it matters: one hosting account, or one hacked site, can take down every site on the server. → Why this matters on a shared host
• How the bug works: two calls on the same socket race each other, and the kernel frees the socket while it’s still in use. → Technical details of the bug

This advisory is also tracked on the CloudLinux status page; subscribe there for status updates.

CVE-2026-98276 is a use-after-free flaw in the Linux kernel’s UDP socket code. Any user who can run a program on a server can use it to crash the kernel or become root; our engineers reproduced both. On November 4, an exploit for it was used against a CloudLinux 8 server, and only crashes were seen there. No exploit code is public.

It affects CloudLinux 7, 7h, 8, 8 LTS, 9, 9 LTS and 10, and we’re still checking CloudLinux for Ubuntu 22.04. The fix is a kernel update or a KernelCare livepatch; the table below shows which is out for each version.

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.

💡 Fixes without a reboot

KernelCare is the alternative we recommend if emergency-patching and rebooting servers is not sustainable for you. It patches the running kernel in place. No reboot, no customer downtime. The livepatch for this issue is available for CloudLinux 8, and Stream 4 tracks the other versions.

Affected CloudLinux versions

† CloudLinux for Ubuntu 22.04 takes its kernel from Ubuntu (Canonical) via apt, not from a CloudLinux stream. We’ll add its status here once we’ve checked it.

Is there a mitigation?

No. Any user who can open a UDP socket reaches the vulnerable code, and no sysctl or boot option turns it off. A firewall doesn’t see the attack, because it is a program’s own calls to the kernel, not network traffic. An SELinux policy could block those calls, but cPanel & WHM requires SELinux to be disabled.

Until the fix is installed, restricting or suspending accounts you don’t trust lowers the risk: shell access, cron jobs, and customer applications that run their own programs. It doesn’t remove the risk.

Update instructions

The fix reaches CloudLinux servers through the four streams below, and CloudLinux for Ubuntu 22.04 gets it from Canonical. We’ll update each stream here when its state changes.

Stream 1: CloudLinux 7, 7h and 8 kernel

Status: November 7, 2026, 22:30 UTC.

A fixed kernel for CloudLinux 7 is in preparation. We’ll add its version here when it’s released.

CloudLinux has released a fixed kernel for CloudLinux 7h and 8: 4.18.0-553.184.1.lve.1. It is in a staged rollout to production servers, so a regular kernel update installs it only once the rollout reaches the server. To install it now, run:

yum update cloudlinux-release
yum update kernel --enablerepo=cloudlinux-rollout-10-bypass
reboot

The first command updates the package that defines the CloudLinux repositories, so the second one can reach the rollout repository. After the reboot, uname -r should report a version starting with 4.18.0-553.184.1.lve.1, or a later one. We’ll note here when the rollout is complete.

Stream 2: AlmaLinux kernel (CloudLinux 9 and 10)

Status: November 7, 2026, 22:30 UTC.

AlmaLinux has published fixed kernels to its testing repository, ahead of Red Hat: kernel-5.14.0-687.66.2.el9_8 for CloudLinux 9 and kernel-6.12.0-211.74.2.el10_2 for CloudLinux 10. Red Hat lists its RHEL 9 and 10 kernels as affected and hasn’t released a fix. To install one now, enable the AlmaLinux testing repository by installing its release package from AlmaLinux directly, update the kernel, then disable the testing repository and reboot.

For CloudLinux 9:

rpm -Uvh --nodeps https://repo.almalinux.org/almalinux/9/extras/x86_64/os/Packages/almalinux-release-testing-9-2.el9.noarch.rpm
dnf update 'kernel*'
dnf config-manager --disable almalinux-testing
reboot

For CloudLinux 10:

dnf install -y https://repo.almalinux.org/almalinux/10/extras/x86_64/os/Packages/almalinux-release-testing-10-2.el10.x86_64.rpm
dnf update 'kernel*'
dnf config-manager --disable almalinux-testing
reboot

After the reboot, uname -r should report a version starting with 5.14.0-687.66.2 on CloudLinux 9 or 6.12.0-211.74.2 on CloudLinux 10. AlmaLinux will move these kernels to its production repositories after community testing. Once a fixed kernel reaches the CloudLinux repositories, a regular kernel update installs it, and we’ll note that here.

Stream 3: TuxCare ELS LTS kernel (CloudLinux 8 LTS and 9 LTS)

Status: November 7, 2026, 22:30 UTC.

The fix has been in the stable channel since November 2. The first fixed kernels are kernel-lts-5.14.0-284.1101.el8.tuxcare.11.els17 for CloudLinux 8 LTS and kernel-lts-5.14.0-284.1101.el9.tuxcare.11.els17 for CloudLinux 9 LTS, and every later build carries the fix too. If uname -r shows a build older than els17, run:

yum update 'kernel*'
reboot

After the reboot, uname -r should report els17 or a later build.

Stream 4: KernelCare livepatch

Status: November 7, 2026, 22:30 UTC.

The KernelCare livepatch for CloudLinux 8 has been on the main feed since 08:50 UTC on November 6. Subscribed servers take it on their next update cycle, or you can apply it now with no reboot:

kcarectl --update

Livepatches for CloudLinux 9 and 10 are in preparation, with no date yet. There is no livepatch for CloudLinux 7 and 7h yet; on CloudLinux 7h, install the fixed kernel from Stream 1. We’ll add each release here.

How to verify you are patched

After the reboot, run uname -r and compare it with the kernel version your stream lists. For KernelCare, run:

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

A patched server prints lines naming the CVE. Use --patch-info for this: kcarectl --info shows only the patch level and doesn’t list CVEs, so it makes a patched server look unpatched.

Did the exploit crash a server?

The exploit used on November 4 leaves the same crash in the kernel log each time. If a server has been crashing or rebooting with no obvious cause, check the log of the boot before the current one (this needs a persistent journal):

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

To check earlier boots, change -1 to -2, -3 and so on. A match isn’t proof of an attack on its own, but on a server without the fix it’s a reason to check which accounts were logged in and what they were running. A clean log doesn’t rule out an attack that didn’t crash the server.

Why this matters on a shared host

From a hosting account or a hacked site, the flaw crashes the kernel, and every site on the server goes down with it, as often as the attacker repeats it.

The server attacked on November 4 crashed 12 times. It was set to reboot whenever the kernel hits an error (kernel.panic_on_oops = 1), so each crash was a full reboot.

Our engineers have also turned the flaw into root access. Root gives an attacker every site, mailbox and database on the server, and a way to hide what they did.

CageFS limits what each account can see of the file system, but this flaw is reached through network sockets the account opens for itself, which touch nothing CageFS hides.

Technical details of the bug

The bug is in sock_gettstamp(), the kernel function behind the SIOCGSTAMP and SIOCGSTAMPNS requests, which ask when a packet arrived on a socket. The first time a program makes that request, the kernel sets a flag on the socket without taking the socket’s lock.

The socket’s flags share one word of memory, and that update isn’t atomic. If the same program calls bind() on the same UDP socket at that moment, the two updates can overwrite each other.

The flag that gets lost, SOCK_RCU_FREE, tells the kernel to wait until nothing is reading the socket before freeing it. Without it, closing the socket frees it straight away while the kernel’s UDP receive path may still be using it. That is the use-after-free.

The upstream fix takes the socket lock in sock_gettstamp(), only on the first call, when the flag has to be set.

References

• CVE-2026-98276 record
• Upstream fix commit
• Red Hat: CVE-2026-98276
• NVD: CVE-2026-98276 (CVSS 7.8, High, from the kernel CNA)
• CloudLinux status page incident for this advisory