Patch Now, Reboot Later: Live Kernel Patching on Oracle Linux with Ksplice on OCI

Apply supported security updates to running Oracle Linux systems while keeping planned maintenance focused on changes that need it.

Security fixes shouldn’t wait weeks for a reboot window. Oracle Ksplice applies supported kernel fixes to a running Oracle Linux system. This post shows how to apply them, how to prove they took effect, and what it takes to make the process survive node replacement on Oracle Kubernetes Engine (OKE).

On OCI, Ksplice is available at no additional cost for Oracle Linux instances (Ten Years of Oracle Ksplice).

Why patches wait

The patch is available. The application owner wants it applied. The security team wants the vulnerability closed. What holds up the work is finding an acceptable time to restart the system.

For a virtual machine, that can mean coordinating application shutdown, checking dependencies, rebooting, and confirming that services recover. For an OKE worker node, the process can involve draining workloads, accommodating their resource requirements elsewhere, and waiting for replacement pods to become ready.

A resilient application makes this easier. It does not remove the work. In containerized environments, pod disruption budgets, limited spare capacity, long startup times, and stateful workloads can turn routine maintenance into a carefully scheduled operation.

Meanwhile, the vulnerability remains open.

This is where online patching has practical value. When a supported fix can be applied to a running system, teams can address it without waiting for the next reboot window. Oracle Ksplice provides that capability for supported Oracle Linux systems on OCI.

What matters is how long a known vulnerability stays open. Live patching shortens that window from “next maintenance cycle” to “now.”

What Ksplice does, and what it doesn’t

Ksplice applies supported fixes to a running Linux kernel without a reboot. Oracle’s documentation also describes live updates for selected user-space libraries such as glibc and OpenSSL, but this post covers the kernel only. (Oracle Ksplice)

The kernel is the layer every workload on a host depends on. On a VM, a kernel vulnerability affects everything running on it. On container platforms such as Kubernetes, the exposure is broader: every container on a node shares that node’s kernel, whatever is in its image. Rebuilding or redeploying an application image doesn’t change the kernel underneath it. Patching the host does, and that is the layer Ksplice updates.

Ksplice complements the rest of your patching process. It has limits worth knowing up front:

• It doesn’t update Kubernetes, the container runtime, or libraries inside your container images.
• It doesn’t install a newer bootable kernel. You still need regular on-disk kernel-uek updates (Updating an Instance).
• It doesn’t cover every fix. Check what is actually available for your kernel rather than assuming.
• It can confuse tooling. After live patching, uname -r still reports the booted kernel. Scanners that compare that string to a fixed version may flag a patched host as vulnerable. Check how yours handles Ksplice’s effective kernel version.