Linux Kernel Security Updates: When to Reboot and When Live Patching Is Enough

Installing a kernel update with apt upgrade or dnf update does not close the vulnerability right away. The new package lands in /boot, while the old, vulnerable kernel keeps running in memory until you reboot. That is how a server can look fully updated to the package manager while actually running a kernel that is 200 days old. You have two ways to fix this. A reboot is the only method that guarantees the new kernel runs with every fix included. Live patching, through tools such as kpatch, Canonical Livepatch and KernelCare, swaps vulnerable functions inside the running kernel without downtime. Live patching is excellent for closing critical holes between maintenance windows, but it does not cover every fix, it does not update libraries like glibc and OpenSSL, and it never fully replaces a reboot. The practical rule we recommend is live patching for urgent vulnerabilities, a fixed reboot window roughly every 30 days that lasts a few minutes, and a post reboot check confirming that the running kernel is the newest one and every service came back. This article covers the exact commands for each step, the limits of each tool, and what happens to services that do not start on their own.

Why a Kernel Hole Stays Open After the Update

The kernel is the one program you cannot restart like a normal process, because it manages every other process. At boot the kernel image is loaded from disk into memory once, and after that the kernel never looks at its files on disk again. The package manager places the new version next to the old one and updates GRUB to pick it on the next boot, and that is where its job ends.

Compare what the package manager says with what is actually running:

# Running kernel
uname -r

# Installed kernels on Ubuntu and Debian
ls /boot/vmlinuz-*

# Installed kernels on AlmaLinux and Rocky
rpm -q kernel --last | head -3

If uname -r shows something older than the newest installed kernel, every vulnerability fixed between those versions is still exploitable on your server right now. On Ubuntu you can simply check for /var/run/reboot-required, and on the RHEL family needs-restarting -r from dnf-utils gives you a direct yes or no.

The risk is not theoretical. Dirty COW, tracked as CVE-2016-5195, sat in the kernel for about 9 years before discovery, and Dirty Pipe, CVE-2022-0847, let any ordinary user overwrite read only files and reach root. In both cases updates shipped within days, yet servers that installed them without rebooting stayed exposed.

Live Patching: How It Works and Where It Stops

Live patching loads a small kernel module containing a corrected copy of the vulnerable function, then redirects every call from the old function to the new one while the system runs. It takes a fraction of a second and services notice nothing.

Tool	Distributions	Model	Status command
kpatch	RHEL and compatibles	Part of the distribution subscription	kpatch list
Canonical Livepatch	Ubuntu LTS	Through Ubuntu Pro, free on a limited number of machines for personal use	canonical-livepatch status
KernelCare	Most common distributions	Commercial, per server	kcarectl --info
Ksplice	Oracle Linux	Included with Oracle support	uptrack-show

The limits are what you need to understand before relying on any of them:

• Not every fix can be live patched. A fix that changes an internal kernel data structure, or touches code that runs constantly such as the CPU scheduler, is hard or impossible to apply live. Vendors pick the serious vulnerabilities and leave the rest for a reboot.
• Patches cover the kernel only. Libraries like glibc and OpenSSL live inside every process, and updating them does not reach running processes until they restart. needrestart on Ubuntu, or needs-restarting on the RHEL family, lists processes still using an old, deleted library.
• Support is tied to kernel age. Each tool supports a specific set of kernels for a limited period, so if you stay on a very old kernel the patches quietly stop arriving.
• Patches pile up. After months of live patching the gap between what runs and what is installed grows large, and any unplanned boot suddenly drops you onto a kernel that was never tested with your application.

A Reboot Window Every 30 Days With Minimal Impact

Rebooting a KVM cloud server usually takes from 30 to 90 seconds before services are back. That is a small number if you pick the right time and prepare the steps. For most company systems in Saudi Arabia we suggest early Saturday morning between 4:00 and 5:00 Riyadh time, when traffic on most internal systems is at its lowest.

1. 48 hours before: send users one clear message with the time and the expected duration, two minutes at most.
2. Right before the window: take a backup or snapshot, and save the output of uname -r plus the list of running services for later comparison.
3. Update: run a full package update, not just the kernel, so the reboot refreshes every library too.
4. Reboot: run systemctl reboot and watch the server come back with ping from another machine.
5. Post boot check: covered in the next section, and do not close the window until it is done.

To capture running services before the reboot and compare afterwards:

systemctl list-units --type=service --state=running --no-legend | awk '{print $1}' | sort > /root/services-before.txt
# after boot
systemctl list-units --type=service --state=running --no-legend | awk '{print $1}' | sort > /root/services-after.txt
diff /root/services-before.txt /root/services-after.txt

Any line in the diff starting with < is a service that ran before the reboot and is not running now, and that is the first thing to deal with.

Verification: Three Minutes That Prevent a Week of Surprises

After boot, run these in order:

uname -r
systemctl --failed
journalctl -b -p err --no-pager | tail -30
df -h
ss -tlnp

The first confirms the running kernel is the newest installed one. The second lists any service that failed at boot, and the target is zero. The third shows errors from this boot specifically, such as a disk that did not mount or a module that did not load. The fourth confirms every disk and partition is mounted with the right size. The fifth lists listening ports, so if your application normally listens on 443 or 3306 and does not appear, the service is down even if it is not marked as failed.

Services That Do Not Start on Their Own

The most common post reboot problem we see is not the kernel at all. It is a service someone started by hand months ago and never enabled at boot. The server is up and the site is down. The usual causes are:

• Service not enabled: check with systemctl is-enabled nginx, and if it says disabled, run systemctl enable --now nginx.
• A process running inside screen or tmux: a queue worker or Node.js script a developer launched in a terminal session. Move it into its own systemd unit with Restart=always.
• Docker containers without a restart policy: a container created without --restart unless-stopped will not come back after boot. Check with docker inspect -f '{{.HostConfig.RestartPolicy.Name}}' container_name.
• An fstab mount that fails: if an extra disk is unavailable at boot, the whole boot can stall. The nofail option on the fstab line prevents that, followed by a df -h check.
• Dependency order: an application starts before the database, fails to connect and exits. Add After=mysql.service and Requires=mysql.service to the application unit.

Your first planned reboot is the best test you will ever run, because it surfaces all of these problems at a quiet time you chose, instead of during a power cut or hardware fault in the middle of a working day.

The Practical Decision

If your system can tolerate two minutes of downtime every 30 days, which describes most internal company systems, scheduled reboots are enough on their own, combined with following your distribution's security advisories. Add live patching when the system is sensitive to downtime, or when a critical vulnerability appears between windows and you do not want to wait. In every case, make checking uname -r and systemctl --failed a fixed part of every maintenance session.

On a CLOUD cloud server you fully own your kernel and can reboot whenever you like from the control panel or the terminal, with servers in Riyadh at around 8ms latency. If you would rather not manage a kernel at all, managed cloud hosting starts at 2,900 SAR per year and we handle server updates and maintenance. The full comparison is on the pricing page.