Kernel Live Patching Is Not a Reboot Replacement: Why Your Deferred Patch Is Still Open

Kernel live patching is a bridge, not a destination: it buys you the right to choose when to reboot, and it does not remove the reboot. That distinction has become expensive to get wrong, because the Linux kernel flaws being exploited in the wild in 2026 are largely not the kind a function redirect can fix.

The practical version of this distinction is uncomfortable. A live patch that reports "applied, no reboot required" can leave part of the underlying vulnerability reachable if the fix also changed a kernel data structure. The system is not lying to you. It is doing exactly what live patching is designed to do, and the gap between that and the word "remediated" is what this article is about.

If you run a Linux fleet and you have ever pushed a reboot back because the maintenance window kept getting displaced, this is the mechanism behind the risk you are carrying. It is also the reason to stop treating "no reboot required" as a synonym for "fixed".

What Live Patching Actually Replaces

Live patching works by redirecting function calls at runtime. Rather than loading a new kernel image and rebooting, a live patch module supplies a corrected implementation of one or more functions, and the kernel redirects calls to that new code. The Linux kernel documentation states the motivation plainly: there are many situations in which users are reluctant to reboot, and live patching serves them by allowing function calls to be redirected, thus fixing critical functions without a system reboot.

The redirection is built on the kernel's dynamic ftrace framework, and that detail is what defines the technique's boundaries. Because ftrace inserts its hook at the very beginning of a function entry, a live patch must also redirect the call before the function's parameters or stack have been touched at all. On x86_64 this requires the kernel to have been compiled with the -fentry option. Architectures that do not work this way need special handling, and the kernel documentation names the PowerPC port as the exception that has to save the link register before it can call the handler.

The second mechanism is the consistency model, and it is the part that makes live patching safe rather than merely clever. A patched function is not swapped for every running task at once. The kernel switches each task over when that task is deemed safe to switch, most often by checking whether any affected function is on the task's stack. The documentation notes that the transition state usually completes in a few seconds, and that an interrupt handler inherits the patched state of the task it interrupts, as does a forked child from its parent.

So live patching is a real mechanism, not marketing, and for the class of fixes it covers it is excellent. The useful question is what falls outside that class.

The Limits Are Documented, Not Rumoured

The kernel's own live patching documentation lists its limitations without hedging. Each entry is a category of fix that a function redirect cannot deliver:

• Only functions that can be traced can be patched. Functions that implement ftrace or the live patch handler itself cannot be patched, because redirecting them would produce an infinite loop.
• Live patching works reliably only when the dynamic ftrace hook sits at the very beginning of the function. A fix that has to change behaviour after the stack or the parameters are already modified is outside the mechanism.
• Return probes conflict with patched functions, because both use a handler that rewrites the return address. The first user wins, so either the probe or the patch is rejected when the other already holds the handler.
• Probes placed inside the original function are simply ignored once the code is redirected to the new implementation. The kernel community treats this as a known gap, with work in progress to add warnings.

Read that list as an operator and the important item is the one that is missing. There is no entry describing support for changes to data structure layouts, because there is none. A function redirect replaces code. It does not resize a structure, relocate a field, or reorder an initialisation sequence that other functions depend on. When a security fix depends on a structural change, the live patch can carry only the portion of the fix that is expressible as function replacement.

That is the asymmetry worth internalising. The live patch loading successfully tells you the functions it contains are now running. It tells you nothing about the portions of the fix that were never expressible as functions in the first place.

What September 2026 Tested

On 18 September 2026, the United States Cybersecurity and Infrastructure Security Agency added three Linux kernel vulnerabilities to its Known Exploited Vulnerabilities catalog after confirming evidence of active exploitation. All three had working public exploits. The remediation deadline set for covered federal agencies was 21 September, a three-day window that the directive's risk matrix reserves for vulnerabilities that are publicly exploited, automatable, and capable of full system compromise.

Two details from that week matter here. The first is that the three flaws sit in unrelated subsystems, which means this was not one campaign with one root cause but three independent discoveries landing at once. The second is that the agency required covered organisations to perform forensic triage of affected assets, rather than treating successful patch deployment as closure. That instruction only makes sense if the agency assumed some systems had been exploited before the catalog entry existed.

Public sources disagree on the severity scoring of the first entry, and the disagreement is itself instructive. The Cloud Security Alliance research note on the catalog addition records the kernel TLS flaw at a CVSS base score of 9.8 and places it as the highest of the three. Contemporaneous news reporting records the same flaw at 7.1 on a local attack vector. Both descriptions can be true of the same defect, because a score depends on the assumed attack vector and the scoring version applied. If you make remediation decisions from a score in a headline rather than from the vendor advisory, you will race the wrong vulnerability.

Why Patch and Reboot Remained the Instruction

The kernel TLS flaw is the clearest illustration of why. It lives in the software implementation of TLS record processing on the receive side, used when an application hands TLS decryption to the kernel instead of a userspace library. That optimisation is common on high-throughput servers: content delivery nodes, reverse proxies and database servers enable it to accelerate TLS termination.

The defect is a corner case in the receive path. When the first record pulled from the receive queue is zero-length, the type-change detection logic can be bypassed, and in zero-copy mode the kernel ends up queueing the anchor socket buffer into a list where it must never be queued. That corrupts the anchor's reference count and produces a use-after-free when the socket is closed and the cleanup path walks memory that has already been freed. Reference counting is bookkeeping that lives in data structures. Red Hat shipped kernel updates for its enterprise Linux 9 and 10 streams. That is the shape of a fix that needs a real kernel and a real reboot, not a redirected function.

The ebtables flaw is a useful contrast because its interim control is not a patch at all. It is a missing writability check before a memory write, in the target that rewrites the source MAC address in bridged frames. When that target processes an ARP packet, a write can land directly in a backing page rather than in a private buffer, producing an out-of-bounds write. Triggering it requires local access plus the capability to configure the ebtables rule, not mere network adjacency, which is why it was rated lower than the TLS flaw. Kernel maintainers fixed it upstream and backported the fix to the 5.10.259, 6.1.176 and 6.12.94 stable branches. If you cannot patch immediately, the published compensating control is to disable ARP hardware-address rewriting in your ebtables SNAT rules, or remove SNAT rules that act on ARP traffic on bridge interfaces. That is a configuration change you can make in minutes and verify, and it belongs in your runbook either way.

The third flaw deserves more attention than its score suggests. It is a race condition in the cryptographic socket interface that had been present in the kernel for roughly fourteen years before discovery. Two concurrent writers can interleave payloads to the same socket and leave its internal state inconsistent, and the outcomes range from a system crash to silently corrupted cryptographic operations. A silent integrity failure is the worst of the available failure modes, because nothing announces it. A crash is loud and gets investigated. A cryptographic result that is wrong without looking wrong does not. The researchers credited with the discovery are at STAR Labs, a public proof-of-concept exploit is circulating, and the note recommends that operators of shared or multi-tenant hosts treat a delayed patch for this flaw as a potential isolation risk rather than a local denial of service.

The Number That Explains the Delay

The three-day federal window is worth measuring against how organisations actually perform, and the Verizon 2026 Data Breach Investigations Report supplies that measurement. The 19th edition of the report draws on more than 31,000 real-world incidents. Its headline finding is a shift in how breaches begin: exploitation of vulnerabilities has become the most common initial access vector, rising to 31% of breaches, while credential abuse, the previous leader, fell to 13%.

The remediation numbers are the ones to sit with. Only 26% of critical vulnerabilities, defined as those in the CISA catalog, were fully remediated by organisations in 2025, down from 38% the previous year. The median time to full resolution rose to 43 days from 32. In the median case, organisations had 50% more critical vulnerabilities to patch than they had the year before.

Forty-three days against a three-day window is the real gap, and it is not a gap that better dashboards close. It is a gap that only two things close: scheduling the reboot, and closing the exploit path by configuration in the meantime.

The Trap: A Deferred Patch Looks Like a Finished One

Here is the operational shape of the problem. A live patch reports the functions it redirected. It does not, and cannot, report the parts of a fix that a function redirect cannot express. If your remediation evidence is "the live patch applied and the module is loaded", then you hold evidence of a code redirect, and not evidence that the vulnerability is closed. The gap is invisible precisely where it matters, because a host that has been live patched and a host that has been rebooted into a fixed kernel can look identical on a compliance report.

The way out is to keep three states clearly separate, and to know which one each host is in.

A live-patched host that has never been rebooted is a host in the first row. Treating it as the second row is the mistake, and it is a mistake of labelling rather than of technology.

Rolling Reboots Without an Outage

The reason reboots get deferred is not laziness. It is that a rebooting host stops serving, and on a single node that is an outage. The sequence below is what turns the reboot back into a routine operation.

1. Inventory against the configuration the flaw requires, not against the kernel version alone. For the kernel TLS flaw that means every host that terminates TLS in the kernel. A fleet-wide kernel version report will overcount and will not tell you which hosts are actually reachable.
2. Apply the compensating control first if one exists. Closing the exploit path by configuration buys you the calendar time to schedule the reboot properly, and it is reversible.
3. Drain rather than stop. Remove the host from the load balancer or the standby set and let connections finish. A hard stop turns a patch into an incident.
4. Reboot one host, or one half of a pair, and confirm the booted kernel build before moving to the next. Verify the kernel that came up, not the patch module that was loaded before.
5. Re-run the inventory after the window. The hosts that fail to report back are the finding, and they are usually the ones nobody owned.

The failure modes repeat across teams, and they are worth naming in advance.

What to Evaluate Before You Buy

Everything above assumes two things about the platform under your application, and both are worth checking before you commit rather than after.

• Can you tell which kernel your instance is running, and when it last booted? If the answer requires a ticket to the provider, you cannot run this process yourself.
• Does the provider patch the host layer on its own schedule without restarting your instance, and does that claim cover the layer you are worried about? A hypervisor patched in place does not patch your guest kernel. Those are two different layers and the distinction is routinely blurred in marketing copy.
• What headroom do you actually have? Rolling reboots require a second node that can absorb the load. That is a cost decision made at purchase time, not at incident time.
• When a hot-patch capability is advertised, ask which subsystems it covers. Redirection is not universal, and a provider that cannot answer that question has not implemented it at the guest layer.

These are not exotic requirements. They are the four questions that decide whether the reboot you deferred is something you can still schedule, or something that has become an unfunded liability.

Where This Stops Being Something You Patch Yourself

The sequence in the previous section assumes a second node to stand on, and a moment when draining the first one does not cost more than the reboot saves. Up to a certain size that is a shell script and a documented window. Past it, the reboot scheduling, the inventory discipline and the headroom stop being tasks and become an infrastructure commitment, and at that point the honest question is whether you should be buying the reboot at all.

The Hong Kong node from SurferCloud is the case where that trade usually gets decided, because it is typically the node sitting in front of users you cannot move, which makes its maintenance window the hardest one to find. The page publishes two tiers. The lightweight hosting tier carries the numbers you can plan against: an entry plan at $6.75 per month with 1 vCPU, 2 GB of memory, a 40 GB disk, one IPv4 address and 1 TB of outbound traffic on a 30 Mbps port; a Starter at $7.6 and a Standard at $10.4; then a Plus at 4 vCPU and 4 GB with a 100 GB disk at $19.5; and an Ultimate at 4 vCPU and 8 GB with a 120 GB disk and 4 TB of outbound traffic at $24 per month. The campaign headline is up to 25% off, and every one of those five plans carries a renewal label that matters more to a maintenance budget than the discount does: the renewal price is the same as the first-term price, so the number you plan with is the number you keep paying.

The page also makes one claim that belongs directly in this article's argument, and it needs to be read precisely. It lists kernel hot patch technology among the platform features, and elsewhere on the same page describes platform upgrades applied online. Read that as a statement about the provider's own layer: the platform can be upgraded without restarting your instance. It does not mean your guest kernel patches itself, and an article arguing that live patching cannot replace reboots would be self-contradictory if it implied otherwise. A live-patched guest is still a guest that eventually needs a reboot.

What the platform does remove is the portion of the problem you cannot fix from inside the instance: provider-forced restart windows, and the uptime cost of someone else's maintenance schedule. The page's stated commitments sit in the same area, listing 99.95% availability, 17 or more availability zones across four continents on Tier 3 data centres, and a complete pricing, region and service list in the console rather than on the page, which is what the page's own FAQ directs you to after signing up. It also states that deployment can be anonymous and that payment is accepted by card, PayPal and cryptocurrency, which is a genuine consideration for operators who cannot complete a conventional identity process before standing up a node.

The infrastructure tier is quoted on consultation rather than published, so if you need more than the lightweight tier's four cores and eight gigabytes, that conversation has to happen before you can cost the headroom that rolling reboots require.

Frequently Asked Questions

Does live patching mean I never need to reboot?
No. It defers the reboot for the class of fixes that can be expressed as a function redirect. Fixes that change a data structure layout, or that alter what a function means to the rest of the kernel, sit outside that class and need a real kernel.

How do I tell whether a specific catalog entry can be live patched?
Read the vendor advisory for the change, not the catalog description. If the fix changes a structure or spans multiple functions that must switch together, plan the reboot and use the interim control until then.

Is a three-day remediation window realistic?
Only for hosts where an interim control closes the exploit path. The catalog addition in September 2026 gave covered agencies 72 hours; the median time to full remediation in the same period was 43 days. The gap is closed by configuration first and reboots second.

What is the fastest interim step for the ebtables flaw?
Disable ARP hardware-address rewriting in your ebtables SNAT rules, or remove SNAT rules that act on ARP traffic on bridge interfaces. That closes the specific path without a kernel update.

Why does the article keep insisting the reboot is the point?
Because the only state that counts as full remediation is a host running the fixed kernel. A loaded patch module and a documented rule change are positions you hold until you boot into it, and positions have to be maintained.

Where to Go From Here

If the reboot you keep deferring is the one you cannot schedule because there is no second node to stand on, then the headroom is the thing to price, not the patch. The Hong Kong node terms, including the entry plan and the renewal commitment, are published on the Hong Kong node pricing page, and the configuration and region list are visible in the console once you have an account, which is the right place to confirm capacity for a specific availability zone before you commit.

Start the evaluation with the reboot in it. Run a rolling restart of a node you already have, time how long the drain takes, and see whether the surviving node holds. If it does, the patching process is a runbook you own. If it does not, the same Hong Kong VPS plans will show you what a second node costs against the cost of the window you cannot find.