How the kernel versions are appearing on patches.kernelcare.com and adding as supported by KernelCare?

Issue

How the kernel versions are appearing on patches.kernelcare.com and adding as supported by KernelCare?

Environment

• KernelCare

Solution

Once the new stable kernel version of some supported distro is released, our KernelCare developers add the "stub" in order to propagate KernelCare support for this new kernel. Any new kernel version has no known security vulnerabilities so there is no sense to develop KC patches for it and it's enough to add it only as a stub. It means that KernelCare that's installed on the server with the new running kernel will detect its version as supported and further KC patch updates will be allowed. For example:

# uname -r
3.10.0-1160.62.1.el7
# kcarectl --uname
3.10.0-1160.62.1.el7

 
In another case, if KC support for some new version of kernel is postponed for some reason (i.e. you don't see the new kernel version on patches.kernelcare.com) - KernelCare that's installed on the server with this new running kernel will detect it as 'Unknown' kernel until it gets KC support during the upcoming KC update.
 
The second case, is when the kernel version is added to patches.kernelcare.com with patched CVEs. I.e. KC developers release the patches to fix a vulnerability. And only in this case, after applying KernelCare updates (getting a patchset with corresponding CVEs applied) the kernel effective version is raised.

In our example - the kernel-3.10.0-1160.62.1.el7 is added as a stub, i.e. with no real new patchset with patched CVEs, and that's why KC effective version can't be raised. 
 
To avoid such possible misunderstandings, our KC added patchset ID for ePortal patches ('ePortal' tab) on patches.kernelcare.com – on the screenshot you can see one and same patches ID for both kernels, the old kernel and the new one: