Skip to main content
Sign in

TuxCare Knowledge Base

  1. TuxCare
  2. KernelCare
  3. Articles

CVE-2026-74580 missing from kcarectl --patch-info on RHEL 8 although effective version is newer than the fixed kernel

Karina Aparicio
  • Updated

Issue

  • Red Hat lists CVE-2026-74580 (vhost: reset the vring metadata cache on vring reconfiguration) as fixed in RHEL 8 kernel 4.18.0-553.156.1.el8_10 under RHSA-2026:55764, but the CVE doesn't appear in the KernelCare patch information on a server that runs an older kernel with KernelCare patches applied:

      # uname -r
  4.18.0-553.132.1.el8_10.x86_64

  # kcarectl --uname
  4.18.0-553.171.1.el8_10

  # kcarectl --patch-info | grep CVE-2026-74580
  #
  • Is CloudLinux affected by CVE-2026-74580, and which kernel contains the fix?
  • There's no announcement or dedicated post for CVE-2026-74580.

Environment

  • RHEL 8.10
  • CloudLinux 7 Hybrid, 8, 9, 10
  • AlmaLinux 9
  • KernelCare

Solution

Red Hat fixed CVE-2026-74580 in RHEL 8.10 kernel 4.18.0-553.156.1.el8_10 (RHSA-2026:55764, released 2026-08-17), but didn't link the CVE to that advisory until 2026-10-14. The advisory's "Fixes" tab and older checks therefore showed RHEL 8 as "Affected". The current Red Hat CVE page shows it as fixed.

The kernel changelog entry has no CVE tag, so kcarectl --patch-info | grep CVE-2026-74580 returns nothing: patch-info only lists patches that are tagged with a CVE. To check whether a kernel has the fix, grep for the commit subject, not the CVE ID:

rpm -q --changelog kernel-core-$(uname -r) | grep 'vring metadata cache'

If the kernel has the fix, the command prints the vhost: reset the vring metadata cache on vring reconfiguration line.

The first kernels that contain the fix:

  • RHEL 8.10: 4.18.0-553.156.1.el8_10
  • CloudLinux 8: 4.18.0-553.157.1.lve.el8 (stable since 2026-08-24)
  • CloudLinux 7 Hybrid: 4.18.0-553.157.1.lve.el7h (stable since 2026-08-24)
  • AlmaLinux 9 / CloudLinux 9: 5.14.0-687.41.1.el9_8 (stable since 2026-08-21)
  • CloudLinux 10: 6.12.0-211.49.1.el10_2 (stable since 2026-08-21)

Any later kernel in the same stream includes the fix. CloudLinux shipped it in regular kernel updates, which is why there was no separate announcement. To confirm, search the changelog at https://changelog.cloudlinux.com/kernel for "vhost: reset the vring metadata cache on vring reconfiguration". A server that runs one of these kernels (or a later one) doesn't need a mitigation.

For a server that boots an older kernel, either update and reboot into a fixed kernel, or check the exposure of the vhost devices:

ls -l /dev/vhost-*
lsmod | grep vhost
  • On EL8 (RHEL 8 and CloudLinux 8), /dev/vhost-vsock is 0600 root:root by default, so unprivileged users can't reach the bug, and the public exploit doesn't work on a default install.
  • On EL9 (CloudLinux 9), the vhost device nodes are world-accessible by default (crw-rw-rw- root kvm), so a local unprivileged user can reach the bug on an unfixed kernel.
  • If the vhost modules aren't loaded and the server doesn't run virtual machines, there's nothing to unload. vhost is used only by KVM hosts, so don't unload it on a virtualization host without checking first. On a server that doesn't host virtual machines, modprobe -r vhost_vsock vhost_net vhost unloads the modules.

KernelCare doesn't have a live patch for this CVE on EL8 yet. A server that boots a kernel older than 4.18.0-553.156.1 stays exposed until it reboots into a fixed kernel or the KernelCare patch is released.

Cause

Red Hat's advisory RHSA-2026:55764 was released on 2026-08-17 with 10 CVEs. Red Hat added CVE-2026-74580 to it only on 2026-10-14. KernelCare processed the advisory in August based on the CVEs listed at that time, so the patch set for EL8 carries no CVE-2026-74580 tag, and kcarectl --patch-info doesn't list it.

Useful Links

Comments

0 comments

Article is closed for comments.