Patched kernels are available for all affected platforms:
- CloudLinux 7h / 8: kernel-4.18.0-553.139.3.lve.el7h / kernel-4.18.0-553.139.3.lve.el8 or newer, in the stable channel — yum update 'kernel*' and reboot; testing-channel steps are no longer needed - CloudLinux 9 / 10: in the AlmaLinux production repositories (kernel-5.14.0-687.23.1.el9_8, kernel-6.12.0-211.31.1.el10_2 or newer) — dnf update kernel and reboot - CloudLinux 8 LTS / 9 LTS: patched kernel-lts in the TuxCare ELS stable repository — yum update kernel-lts and reboot
KernelCare livepatches are on the main feed for CloudLinux 8, 9, 10, and CloudLinux for Ubuntu 22.04, and in the testing feed for CloudLinux 7h.
Posted Sep 03, 2026 - 20:02 UTC
Monitoring
The patched kernels are in the AlmaLinux production repositories: CL9 / AlmaLinux 9 kernel-5.14.0-687.23.1.el9_8 or newer. CL10 / AlmaLinux 10 kernel-6.12.0-211.31.1.el10_2 or newer. A plain dnf update kernel followed by a reboot is sufficient. The testing-repository steps below are no longer needed.
Posted Aug 25, 2026 - 22:19 UTC
Update
Patched kernel-lts package for CloudLinux 8 LTS and CloudLinux 9 LTS being prepared, installed from the TuxCare ELS repository, a pipeline separate from the stock CloudLinux 8 and 9 kernel rebuild. Install with yum update kernel-lts and reboot.
The KernelCare livepatch is available as a no-reboot alternative.
KernelCare livepatch for Januscape, by CloudLinux platform:
Fully rolled out on the main feed: CloudLinux 10 and CloudLinux for Ubuntu 22.04. On the main feed (staged rollout): CloudLinux 8. In the testing feed: CloudLinux 7h. Still in preparation: CloudLinux 9.
Posted Jul 11, 2026 - 03:15 UTC
Update
Patched CloudLinux CL7h/CL8 kernels are released to the beta/testing channel. Target versions: - CL7h kernel-4.18.0-553.139.3.lve.el7h or newer. - CL8 kernel-4.18.0-553.139.3.lve.el8 or newer.
Promotion to the stable channel follows after the testing period.
AlmaLinux 9/10 has published patched kernels to its testing repository. Target versions: - CL9 / AlmaLinux 9: kernel-5.14.0-687.20.3.el9_8 or newer. - CL10 / AlmaLinux 10: kernel-6.12.0-211.30.3.el10_2 or newer.
KernelCare is rolling out live patches for CVE-2026-53359 + CVE-2026-46113 (both required; tracked under the "CVE-2026-46113 and follow-up N-day kvm fixes" tickets).
Release state below is from the live release data In feed now (by release):
Not yet in any feed: el8, el9, ubuntu-noble, debian11, debian12, plain ubuntu-focal, uek6/uek7, ubuntu-bionic.
They are in active development (pushing to the release)
LibCare: out of scope (kernel-only).
How to update?
kcarectl --update --prefix test # from testing feed kcarectl --update # once promoted to main
Verify: kcarectl --info | grep kpatch-build-time # build dated 2026-07 or later kcarectl --patch-info | grep -E 'CVE-2026-53359|CVE-2026-46113' # both fixes needed for Januscape
How to mitigate until the patch will be available?
Hosts that do NOT run VMs but have KVM loaded by default — remove the attack surface entirely: # unload now (fails if a VM is running → that host isn't a candidate) sudo modprobe -r kvm_intel kvm # kvm_amd on AMD
# prevent load on boot ("install /bin/false" also blocks dependency/explicit loads, # which a plain "blacklist" line does not) printf 'install kvm_intel /bin/false\ninstall kvm_amd /bin/false\n' \ | sudo tee /etc/modprobe.d/disable-kvm.conf
Verify: lsmod | grep kvm is empty and ls /dev/kvm → No such file. Revert: remove /etc/modprobe.d/disable-kvm.conf and modprobe kvm_intel (or reboot).
Hosts that DO run VMs — cannot unload; they depend on the livepatch. Partial hardening for the unprivileged-local vector on RHEL-family (where /dev/kvm is 0666) only:
echo 'KERNEL=="kvm", GROUP="kvm", MODE="0660"' | sudo tee /etc/udev/rules.d/65-kvm.rules # then: sudo udevadm control --reload && sudo udevadm trigger (or reboot)
Perm-tightening does not stop a malicious VM guest — the guest→host escape still works via QEMU. Full coverage on a VM host = the livepatch.
Posted Jul 07, 2026 - 15:10 UTC
Investigating
Confirmed exploitable in our lab. Any KVM hypervisor host with the kvm_intel / kvm_amd modules loaded and /dev/kvm present is affected — i.e. the default posture on the KVM/enterprise fleet.
Impact ranges from host DoS (unprivileged, reliable) up to a full guest→host escape running as root . On RHEL-family, /dev/kvm is world-accessible (0666), so an unprivileged local user can trigger it directly.