CVE-2026-98276: UDP socket kernel flaw on CloudLinux servers

CVE-2026-98276 is a use-after-free in the Linux kernel's UDP socket code. Any local user who can open a UDP socket can trigger it, and on a shared hosting server that includes every cPanel account and anyone who has compromised a single WordPress site. The kernel CNA scores it 7.8 (High); Red Hat, SUSE, and Amazon rate it 7.0. CloudLinux published its advisory on 7 November 2026.

This is not a theoretical one. On 4 November a working exploit crashed a CloudLinux 8 production server 12 times. CloudLinux says its engineers also turned the bug into root; TuxCare's own analysis reproduced the crash but not the escalation. No exploit code is public. Treat it as a local root and patch on the same schedule as last week's IPv4 TCP flaw.

What the bug does

sock_gettstamp() handles the SIOCGSTAMP and SIOCGSTAMPNS ioctls. It sets a socket flag with the non-atomic __set_bit(), and if bind() runs on the same UDP socket at the same moment, that write can wipe the SOCK_RCU_FREE flag bind() just set. The socket is then freed without waiting for an RCU grace period while other code still holds it.

The upstream fix (commit 9ed55f3dbef4, by Eric Dumazet) takes the socket lock in sock_gettstamp() when the timestamp flag needs setting. It shipped in upstream stable 5.10.271, 5.15.222, 6.1.189, 6.6.158, 6.12.112, and later.

There is no mitigation. No sysctl or boot option disables the path, a firewall never sees it, and the SELinux policy that could block it is not an option on cPanel servers, which require SELinux off. The only fixes are a new kernel or a livepatch.

Which CloudLinux versions are affected

Unlike CVE-2026-98432, CloudLinux 7 is affected this time, and its fixed kernel is not out yet. That is one more reason to plan the move to CloudLinux OS 10.

Install the fixed kernel

CloudLinux 7 hybrid and 8

The kernel is in a staged rollout. Pull it now instead of waiting for it to reach your servers:

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

CloudLinux 9

Install from AlmaLinux testing, then disable the repo so nothing else comes from it:

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

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

CloudLinux 8 LTS and 9 LTS

The fix has been in the stable channel since 2 November. The first fixed builds are kernel-lts-5.14.0-284.1101.el8.tuxcare.11.els17 and kernel-lts-5.14.0-284.1101.el9.tuxcare.11.els17; anything newer also has it.

yum update 'kernel*'
reboot

After the reboot, uname -r should start with 4.18.0-553.184.1.lve.1 (7 hybrid and 8), 5.14.0-687.66.2 (9), or 6.12.0-211.74.2 (10), or show els17 or later on LTS.

KernelCare status

The CloudLinux 8 livepatch reached the main feed at 08:50 UTC on 6 November. Livepatches for 9 and 10 are in preparation with no date. None is coming for 7, 7 hybrid, or the LTS kernels, so those servers need the reboot.

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

Use --patch-info, not --info, which lists no CVEs and makes a patched server look unpatched. ePortal users need to sync the feed first. If you run Imunify360, check whether KernelCare is already included before buying it separately.

Check for past crashes

If a server has rebooted unexpectedly this month, look for the crash signatures in the previous boot's kernel log. 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'

Change -1 to -2, -3, and so on for earlier boots. A match is not proof of an attack, and a clean log does not rule one out. If you find one, find the account that ran it: LVE Manager statistics narrow it down, and the malware cleanup workflow covers the site.

Next steps

• Three kernel advisories in three weeks: read live patching for hosting fleets and add a KernelCare license to every node.
• Confirm you have also closed ZDI-CAN-33367 and CVE-2026-98432, which need different kernels.
• Adding servers before the reboot window? Order a CloudLinux license.