KernelCare and CloudLinux patches for CVE-2026-98276

Issue

• Is CloudLinux affected by CVE-2026-98276, and which KernelCare patch or kernel fixes it?

• kcarectl --update reports that no patches are available for the running kernel, and kcarectl --patch-info | grep CVE-2026-98276 returns nothing:

    [root@server ~]# kcarectl --update
    No patches are available for kernel 4.18.0-553.180.1.lve.1.el8.x86_64 (kernel ID <kernel_id>).
    [root@server ~]# kcarectl --patch-info | grep CVE-2026-98276

• Servers panic or reboot repeatedly with a NULL-pointer dereference in udp_destruct_common or __sk_mem_raise_allocated.
• Did the KernelCare update cause the kernel panics?
• Is CloudLinux 7 affected, and does exploitation need a local account?

Environment

• CloudLinux 7 / 8 / 9 / 10 (EL7/EL8/EL9/EL10)
• KernelCare (live patching)

Solution

Status as of 07/11/26. Check the patch status page linked under Useful Links for current availability.

CVE-2026-98276 is a use-after-free in the kernel's sock_gettstamp() (UDP socket handling). A local user can trigger it. It shows up as a NULL-pointer dereference in udp_destruct_common (socket close) or __sk_mem_raise_allocated (UDP receive) and panics the kernel. With kernel.panic_on_oops = 1, the server reboots on each hit. The crashes are caused by the vulnerability being exploited, not by the KernelCare patch. The patch is the fix.

The vulnerability was reproduced in-house and is treated as a local privilege escalation, not only a denial of service. Exploitation requires a local account or local code execution and cannot be triggered remotely over the network by an unauthenticated attacker. On a shared hosting server, any hosting account that can run code counts as local.

Current availability

Patch propagation through ePortal may lag behind the production feed.

Option 1. Apply the KernelCare live patch (CloudLinux 8, kernel 4.18.0-553.177.1.lve.1.el8)

1. Update the patches:

      kcarectl --update

2. Confirm that the patch is applied:

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

KernelCare does not patch kernel 4.18.0-553.180.1.lve.1.el8 yet. A newer kernel has to be onboarded into KernelCare before its patches are built, which is why kcarectl --update reports that no patches are available for it. Patches for the newer 4.18.0-553.18x.lve.1.el8 kernels are published after onboarding and after the kernel reaches the stable repository.

Option 2. Install the fixed CloudLinux 8 kernel (reboot required)

1. Install the fixed kernel from the rollout bypass repository:

      yum update "kernel*" --enablerepo=cloudlinux-rollout-10-bypass

   This also updates kernel-devel, kernel-headers, and kernel-tools to the same version. The package manager may remove the oldest installed kernel, because only a limited number of kernels are kept. This is expected.

2. Optional: confirm the fix in the changelog:

      rpm -q --changelog kernel-4.18.0-553.184.1.lve.1.el8 | head -3

   The first entry mentions net: lock the socket in sock_gettstamp() (CVE-2026-98276).

3. Reboot the server.

   This kernel does not have KernelCare patches yet. The server is protected from the CVE by the kernel itself. KernelCare patches for later vulnerabilities become available after the kernel is onboarded.

Option 3. Switch to the LTS kernel (CloudLinux 8 and 9, reboot required)

The LTS kernel already ships with this fix, so switching to it closes the CVE without waiting for a live patch:

• CloudLinux 8: kernel-lts-5.14.0-284.1101.el8.tuxcare.11.els17

• CloudLinux 9: kernel-lts-5.14.0-284.1101.el9.tuxcare.11.els17

  CloudLinux 9 on AlmaLinux testing kernels

  KernelCare does not patch AlmaLinux testing kernels (for example 5.14.0-687.61.2.el9_8). KernelCare works on CloudLinux 9, but only for stable kernels. To move to a stable kernel that KernelCare supports, install it with the testing repository disabled, then reboot:

  dnf update 'kernel*' --disablerepo=almalinux-testing

  At the time of writing, this installs 5.14.0-687.66.1.el9_8. It restores KernelCare coverage but has no fix for CVE-2026-98276 on CloudLinux 9.

  Mitigation while no patch is available

  No sysctl option or kernel parameter disables the affected code, and a firewall does not help against a local trigger. Restrict or suspend untrusted local users and hosting accounts until a fixed kernel or patch is applied.

Cause

Use-after-free in sock_gettstamp() (net/core/sock.c): the socket is not locked when the timestamp flag is set. The fix takes the socket lock. The vulnerability is locally exploitable for a kernel panic (denial of service) and for privilege escalation.

Useful Links

• Red Hat CVE page — https://access.redhat.com/security/cve/cve-2026-98276
• KernelCare patch status for CloudLinux 8 — https://patches.kernelcare.com/?cve=CVE-2026-98276&distro=cl8
• KernelCare patch status for CloudLinux 9 — https://patches.kernelcare.com/?cve=CVE-2026-98276&distro=cl9
• CloudLinux LTS kernel documentation — https://docs.cloudlinux.com/cloudlinuxos/cloudlinux_os_kernel/#lts-kernel
• Status incident — https://cloudlinux.statuspage.io/incidents/968jhv13bnlr