CLN LoginThe patch was ready on Tuesday. The reboot was set for Saturday night, once the customer notice had gone out.
Anyone who keeps servers running for other people recognizes that sequence. The kernel fix for a root-escalation vulnerability, logged as a CVE (Common Vulnerabilities and Exposures) entry, lands in the repo soon after disclosure and installs in seconds.
The running kernel stays vulnerable until the server reboots, so the reboot gets a date, the date gets a notice, resellers forward the notice, and the night shift gets the work.
On an enterprise fleet, the same wait is made of sign-offs and a change board. Either way, the fix sits on disk while the exposure stays open.
Priced honestly, line by line, rebootless patching vs rebooting is not a close comparison, because the cost of a reboot is spread across everyone who has to plan around it.
Rebootless kernel patching removes the reboot for kernel security fixes, and with it most of the coordination, off-hours labor, and exposure window the reboot creates. For kernel security fixes, a scheduled reboot is not a patching strategy. It is the price of one.
Key takeaways
- A kernel reboot costs more than the minutes it's down: the notice, the night shift, and the days the CVE stays open.
- CloudLinux counted 13 named kernel exploits in about 110 days. If a third needs a reboot, a 40-server host loses 16 to 40 hours a year to reboots
- Rebootless kernel patching applies the fix to the running kernel.
- Security reboots keep jumping the schedule.
Why the reboot keeps jumping the schedule
Hosting providers publish their windows, so their notices show how the model behaves in practice.
TrueCore Hosting emails every customer on an affected server at least 48 hours before planned maintenance, and says a kernel update that requires a reboot takes 2 to 5 minutes from start to services restored. The same post names the exception: for emergency and zero-day patches, “security takes precedence over scheduling.”
The provider’s own policy treats the window as the default and the CVE as the override.
Exabytes ran the same play in 2016 when Dirty COW, a privilege-escalation flaw in the Linux kernel, hit its shared hosting servers. It booked a three-hour window and rebooted the servers one by one to load the patched kernel.
The window was on 29 October, about 10 days after the flaw became public.
The pattern has not changed. VirtFusion’s guidance for hypervisor operators states the constraint plainly: “A kernel update does not take effect until the host is running the new kernel, so the reboot is required.”
Even the tooling admits it. Ivanti’s documentation says that once updates have been deferred for about three days, “the agent overrides the maintenance window and starts the update process.”
Bryan Dam, an SCCM practitioner, wrote the sharpest version in 2020: “Maintenance windows can only decrease your patch compliance.” He is right, and that is the loop. The window exists to contain the reboot, but the reboot keeps escaping it.
The load on the model has changed as well.
CloudLinux counted 13 named kernel exploits between late April and its August 2026 Product Pulse webinar, roughly one every 10 days. A window sized for one kernel patch a quarter turns into a queue at that rate.
What one kernel reboot costs, line by line
A kernel reboot never appears as a budget line.
It shows up as hours on other people’s calendars, so the cost is spread thin and easy to miss. Put it on one line, in the units an operator counts in:
Rebootless patching vs. rebooting: the cost of one kernel CVE
| Cost line | Reboot-based model | Rebootless kernel patching |
|---|---|---|
| Approval chain | Operations sets the date and the notice period | No reboot to approve for covered kernel security fixes |
| Scheduling labor | Servers reboot one by one, so the implementation grows with the fleet | The agent checks every four hours and applies patches automatically; no reboot to schedule |
| Off-hours labor and on-call | Reboots run in the evening or overnight, with staff watching each server return | Patches apply while the system runs, during business hours, with nobody waiting on them |
| Exposure window (CVE disclosure to applied fix) | Bounded by the notice period and the next slot | Hours for a covered kernel, once the patch is released (typically within hours of disclosure) |
| Failure mode | A server that does not come back takes every account on it offline until it does | A patch that misbehaves is unloaded without a reboot |
| Audit evidence | Compliance scans of hosted servers show the open CVE until the reboot | Patch state is continuous; with a scanner that reads effective patch state, the gap a scan can find is hours wide |
| Customer-facing impact | A reboot notice, a reseller forwarding it to its own customers, and tickets from tenants who read neither; services are down for the reboot | No reboot notice to write and no customer-facing downtime |
| Cost shape | The same hours, multiplied by the notice, fan-out, and ticket work in every reboot round | A flat per-server license that does not rise with the CVE count |
The two timelines start at the same event. The left one spends weeks in the middle four boxes, none of which touch the patch itself.
You still must reboot for: storage and server firmware, hypervisor upgrades, a major OS version jump, a database engine upgrade, and any kernel change that is a feature rather than a security fix.
Those are quarterly or yearly events, and a window that only has to hold them can be booked a year ahead without anyone losing sleep.
What no longer needs a reboot is the thing that was filling it weekly. Kernel security fixes stop being a reason to assemble the approval chain, stop being a reason for patch night, and stop being the item the auditor finds open between scans.
Coordination relief, more than the vulnerability count, is the win.
For hosting providers: every reboot is a customer notice
On a shared server, an unpatched kernel is a shared exposure. One compromised account can use a kernel privilege-escalation bug to become root, and root reaches everything else on the machine:
- Customer files
- Databases
The reboot is what keeps that fix waiting, and the cost multiplies as the fleet grows.
Take an illustrative host with 40 servers. Every kernel CVE that needs a reboot means 40 reboots in sequence, a customer notice ahead of them, resellers forwarding it, and the tickets that follow.
Here’s a more detailed cost breakdown:
- Downtime per round — TrueCore says 2 to 5 minutes per reboot. 40 servers rebooted in sequence is 80 to 200 minutes of reboot time, and every account sees its own 2 to 5 minutes of outage.
- Rounds per year — CloudLinux counted 13 named kernel exploits in about 110 days, which is roughly 36 to 43 a year at that pace. Not every one needs a reboot; if a third do, that is about 12 to 14 rounds a year.
- At 12 rounds, that is 16-40 hours of reboot time a year across 40 servers (12×80 to 200 minutes), and each account sees 24-60 minutes of outage (12×2 to 5 minutes). That’s assuming sequential reboots, one server per account, and no overhead.
- Exposure, once a patch is released — Exabytes took about 10 days from disclosure to reboot, and TrueCore’s notice period alone is at least 48 hours. Against that, live patching closes at the next four-hour check.
Live patching takes the reboot out of that sequence. The agent checks every four hours and applies the kernel fix to the running kernel, so there is no reboot to plan and no reboot notice to send for kernel security fixes.
How rebootless kernel patching works
KernelCare is a live patcher for the Linux kernel. It applies security fixes to the running kernel in memory. A kernel module pauses processes for nanoseconds, redirects the vulnerable code path to a corrected version, and resumes.
The agent checks for new patches every four hours and applies them automatically. A patch can be unloaded without a reboot if anything looks wrong. Patches typically deploy within hours of CVE disclosure.
The mechanism is small, and the timing is the difference.
Under the reboot model, a kernel patch is a package that waits for a restart. Under live patching, a Linux kernel patch is a code change that takes effect at the next four-hour check.
Linux kernel updates stop being a calendar event and become a background process. This is what kernel patch protection between CVE disclosure and the next planned restart actually means: the fix is in place while the server keeps serving.
Linux kernel patching across a mixed fleet
Most fleets do not run one distribution, and the per-vendor live patchers stop at their own borders. KernelCare covers 60+ distribution versions from one agent, including CloudLinux, AlmaLinux, RHEL, Ubuntu, Debian, Rocky Linux, and Oracle Linux, with coverage verified per kernel build at patches.kernelcare.com. Ubuntu patch management is the usual example: Canonical Livepatch handles Ubuntu LTS kernels through Ubuntu Pro and nothing else on the rack.
| Live patcher | Covers | Stops at |
|---|---|---|
| kpatch | RHEL kernels | Red Hat subscription scope |
| Canonical Livepatch | Ubuntu LTS kernels, via Ubuntu Pro | Ubuntu only |
| Ksplice | Oracle Linux kernels | Oracle Linux only |
| KernelCare | 60+ distro versions, one agent | Per kernel build; check patches.kernelcare.com |
The per-vendor tools work, and this page does not argue with them. The argument for one agent across a mixed estate is made in full in our guide to how to patch a mixed RHEL, AlmaLinux, and Ubuntu fleet with one tool, so the kernel patch itself, not the vendor map, carries the rest of this comparison.
What rebootless patching does not remove
The comparison is lopsided, so the limits deserve their own section rather than a footnote.
Not every update is live-patchable. KernelCare patches the kernel, so a glibc or OpenSSL fix still means restarting the services that loaded the library, unless you run KernelCare+, which extends in-memory patching to those two libraries and is licensed separately.
A major OS version upgrade replaces the kernel, the libraries, and most of userland at once; that is a reboot, and no live patcher claims otherwise.
Vulnerability scanners that read package versions can flag a live-patched kernel as unpatched, because the package metadata still names the old kernel while the running code has been corrected.
Compliance teams raise this objection often, and it is fair. KernelCare integrates with Qualys, Nessus, OpenSCAP, and Rapid7 so the scanner reads the effective patch state. If your auditor uses a scanner not on that list, test it before you commit.
Coverage is per kernel build, not per distribution name. A newer or rarer kernel variant may lag. Check the exact kernel at patches.kernelcare.com before assuming a fleet is covered.
Patching end-of-life systems
Endless Lifecycle Support (ELS) backports security fixes for operating systems their vendors no longer patch, so you can stay on the version you run. It removes the migration deadline, not the reboot: a kernel fix that arrives as a package still takes effect at the next restart.
How to update the kernel in Linux: with and without a reboot
The package route still works. dnf update kernel or apt upgrade installs the new kernel in seconds, and it takes effect at the next reboot, which is why that route needs a reboot to plan.
To apply kernel security fixes without the reboot, install the KernelCare agent as root, register it with your key, and apply the current patches:
bash
curl -s -L https://kernelcare.com/installer | bash
kcarectl --register YOUR_KEY
kcarectl --updateFrom then on, the agent checks every four hours and applies new patches on its own.
To verify, run kcarectl –uname, which prints the effective kernel version, because uname -r still shows the kernel you booted. kcarectl –patch-info lists the loaded patches, and kcarectl –unload removes them without a reboot (commands per the KernelCare documentation).
Stay with the package route for a kernel feature you want, a major version jump, or a kernel that patches.kernelcare.com shows as not yet covered.
The patch that was ready on Tuesday
The patch that was ready on Tuesday goes onto the running kernel at the next four-hour check. The reboot set for Saturday night is gone for that fix, and so are the sign-offs and the notice that came with it.
The Saturday stays on the calendar for the storage firmware, which is what it was for.
To properly evaluate rebootless patching vs rebooting, start by checking whether your kernels are covered at patches.kernelcare.com, then run the 14-day free trial on the servers you least want to reboot.
Frequently Asked Questions
Common questions from hosting providers evaluating Endless Lifecycle Support
For covered kernels, usually no. KernelCare applies them to the running kernel with no reboot to plan. You still need one for firmware, major OS upgrades, hypervisor and database engine upgrades, and any kernel change that is a feature rather than a fix.
For a covered kernel, yes. A live patch corrects the same vulnerable code path as the vendor’s kernel package, in memory instead of at the next boot. The difference is timing. A reboot-based patch leaves the CVE open until the next reboot, while a live patch closes it at the next four-hour check.
A scanner that only reads package versions will not, because the package metadata still names the kernel you booted. KernelCare integrates with Qualys, Nessus, OpenSCAP, and Rapid7 to report the effective patch state. Confirm your scanner before an audit cycle, not during one.
kcarectl –unload removes the loaded patches from the running kernel without a reboot, and the server carries on with the kernel it booted. That unload is also how a team proves to a skeptical stakeholder that an incident had nothing to do with live patching.
Yes, from one agent. KernelCare covers 60+ distribution versions, including RHEL, AlmaLinux, Rocky Linux, Oracle Linux, CloudLinux, Ubuntu, and Debian, with coverage listed per kernel build at patches.kernelcare.com. The per-vendor tools (kpatch, Canonical Livepatch, Ksplice) each cover their own distribution only.
Comments