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.