Kernel patching is a headache. Unless you’re using KernelCare, it requires rebooting your servers. This can take a while, and usually has to be done late on a Saturday night to minimize impact. While the servers are being rebooted, the websites they host will go down. And even after rebooting, it can take a while for performance to stabilize.
Because of this, SysAdmins tend to delay rebooting and kernel patching for as long as possible: weeks, if not months. They wait until patch releases have piled up to the point where they can’t be ignored anymore, and then they reboot. They tend to think that while this process is hardly perfect, it isn’t dangerous. But they’re wrong.
SysAdmins will usually rationalise their delays in kernel patching with the argument that most patches are minor, correcting small, unthreatening flaws. They will point out that most kernel vulnerabilities are no big deal, that they aren’t any sort of invitation to malicious hackers.
But here’s the point: Now and again, a kernel vulnerability comes along which is truly terrifying. There are hundreds of vulnerabilities found every year, and most aren’t too bad. But some are very bad indeed. Vulnerabilities like CVE-2017-18017 and CVE-2015-8812 can be incredibly destructive.
Why? Because vulnerabilities in the kernel are the worst kind of vulnerability an IT system can suffer. The kernel is the most important part of any Linux system, providing vital low-level functions to the entire system. Any security issues detected within it jeopardize the whole server. Once a hacker has exploited the kernel, they can get anywhere, and access everything, including customer data, for months or years. It’s like a thief getting into the safe-room. Once your kernel has been infiltrated, you’re exposed to the worst possible digital damage.
This is why immediate kernel patching is so important. Yes, serious vulnerabilities are relatively rare, but so are serious car crashes. This doesn’t mean you neglect car insurance.
And immediate patching is almost impossible if you have to reboot. Unless you’re using KernelCare, your kernel patching is without doubt happening slower than you could be. Meaning you are exposed to potentially serious kernel vulnerabilities.
Serious, damaging kernel vulnerabilities are rare, but proper security means protecting yourself from even relatively unlikely events –especially when those events have the potential to truly wreck an IT system. Live kernel patching isn’t a nice-to-have; it should be an integral part of any diligent Linux security posture.