Issue
How are the kernel versions displayed on patches.kernelcare.com and subsequently added 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" label in order to propagate KernelCare support for this new kernel. New kernel versions typically have no known security vulnerabilities, making it unnecessary to develop KC patches for them. Instead, it suffices to add them as stubs. This means that KernelCare on a server running the new kernel will recognize its version as supported, enabling further KC patch updates. For example:
# uname -r
3.10.0-1160.62.1.el7
# kcarectl --uname
3.10.0-1160.62.1.el7
Similarly, 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:
Comments
0 comments
Please sign in to leave a comment.