We have a fleet of VMs running CentOS. When I run my script, I can see different versions of CentOS running on these servers by catting /etc/centos-release. I see anything from CentOS 7.2 up to 7.9.

I also found that all the CentOS 7 servers I queried all have the same kernel version (3.10.0-693) by running uname -a. These servers are all running CentOS 7 but the dot version varies from 7.2 to 7.9.

$ uname -a
Linux myhostname 3.10.0-693.el7.x86_64 #1 SMP Tue Aug 22 21:09:27 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

How does kernel version correlate with the release version of CentOS in this case? Perhaps I'm not understanding something basic here but I'm expecting the kernel version to change with each dot release of CentOS 7.

I found a link that shows the different Linux OS distributions with their respective kernel versions and the kernel version does change (e.g. CentOS 7.2 has 3.10.0-327, CentOS 7.3 has 3.10.0-514, etc.) https://knowledge.broadcom.com/external/article/150469/list-of-linux-distributions-and-kernels.html

Hopefully someone can shed some light on my confusion or slap me if it's something super simple and basic.

  • The administrator can well choose to upgrade the kernel but not the rest of the system, or vice versa.
    – muru
    Aug 4, 2021 at 2:01

1 Answer 1


CentOS 7 is a community-supported clone of RHEL 7, and RHEL's kernel policy has long since been to freeze the kernel version at each major release (see https://access.redhat.com/articles/3078).

CentOS is built from the same sources as RHEL (only replacing logos, trademarks and similar copyrighted assets), so it reflects the same policy. Both the kernel's and the distribution's version numbering scheme has varied slightly through the years, but the principle is the same:

  • RHEL 2.1 (GA and all Update levels 1-7) had kernel version 2.4.9
  • RHEL 3 (GA and each Update level 1-9) had kernel version 2.4.21
  • RHEL 4 (GA and each Update level 1-9) had kernel version 2.6.9
  • RHEL 5.x (RHEL version numbering style change) had kernel version 2.6.18
  • RHEL 6.x had kernel version 2.6.32
  • RHEL 7.x has kernel version 3.10 (Linus changed the kernel release scheme: major releases are now x.y[.0], minor releases x.y.z)
  • RHEL 8.x has kernel version 4.18

Wikipedia has a list of CentOS release dates and kernel versions: https://en.wikipedia.org/wiki/CentOS#CentOS_releases

In RHEL/CentOS, the kernel version number consists of two parts:

  • the part before the dash is the upstream version number, referring to which kernel release this RHEL kernel is based on.
  • the part after the dash is the patch level, indicating the various backported bug fixes and hardware support patches added by Red Hat

By freezing the upstream version, Red Hat makes it easier for third-party driver developers to keep supporting a specific major release of Red Hat through its lifecycle, as major changes to internal kernel workings are avoided as much as possible. (Of course the fixing of a discovered security vulnerability may require major changes, as happened with the Spectre/Meltdown family of vulnerabilities in and after January 2018.)

3.10.0-693 would be the kernel version for CentOS 7.4 (released 2017-09-13), indicating that the CentOS 7.2 and 7.3 servers you see it in have had their kernels updated to the 7.4 level, although they may otherwise been frozen to a lower release level. That suggests the freezing of the release level might be for application support reasons (i.e. some third party application has an expensive support agreement that is valid only on particular release levels), and the kernel update may have been enforced by the virtualization framework requirements or mitigation of a serious security vulnerability.

The fact that CentOS versions 7.5 and higher also show the kernel version of 7.4 might be simply because those systems have not been rebooted after update, so those systems might have one or more updated kernel versions waiting to take effect at next reboot.

Since CentOS 7.4 and its kernel version 3.10.0-693 pre-dates the Spectre/Meltdown vulnerabilities which required fairly major kernel changes to mitigate, the kernel version indicates your systems are currently vulnerable to an entire class of Spectre/Meltdown-based attacks.

Note: I've had bitter experiences trying to use pre-Spectre/Meltdown versions of third-party drivers with post-Spectre/Meltdown kernels. So if you use third-party drivers, make sure they are updated appropriately too.

If your virtualization framework requires you to use a kernel provided by the virtualization host, contact the host administrators to find out what you need to do to get your VMs running a kernel that has the Spectre/Meltdown fixes.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.