Patch the kernel on OCI Oracle Linux instances without rebooting: a Ksplice runbook

#Goal

A kernel CVE has landed, your security team wants it closed today, and the instance runs a production workload you can't reboot until the next window. On Oracle Linux instances in OCI, Ksplice patches the running kernel in memory. The patch takes effect straight away, and the instance keeps serving traffic.

Ksplice is installed by default on Oracle Linux platform images created after August 2017. On OCI it costs nothing extra and you don't need to register the instance with ULN.

Warning

Ksplice buys you time. It does not replace normal patching. Keep installing kernel packages with dnf, and reboot into them in your regular maintenance windows. Once the next reboot loads the new kernel, Ksplice starts from that kernel's baseline.

#1. Check the client and what's running

uname -r                          # kernel that was booted
rpm -q ksplice uptrack ksplice-tools 2>/dev/null
command -v ksplice uptrack-upgrade

There are two command sets. Both work against the same updates:

If neither package is installed (for example, on a custom image), install the online client:

sudo dnf install -y ksplice uptrack     # Oracle Linux 8/9
sudo yum install -y ksplice uptrack     # Oracle Linux 7

Package names vary by Oracle Linux version, so check what your repository offers with dnf list 'ksplice*' 'uptrack*'.

#2. See what's applied and what's available

sudo ksplice kernel show              # updates already applied in memory
sudo ksplice kernel show --available  # updates you can apply now
sudo ksplice kernel uname -r          # effective kernel version after Ksplice

The show output ends with a line such as Effective kernel version is 5.15.0-208.159.3.el9uek. Security scanners that read only uname -r will still report the booted version. Give the scanner team the effective version, or point the scanner at Ksplice-aware checks if it supports them.

To check whether a specific CVE is covered, search the available list:

sudo ksplice kernel show --available | grep -i CVE-2026-

On the Uptrack client:

sudo uptrack-show --available
uptrack-uname -r

#3. Apply updates

Dry run first to list what would change:

sudo ksplice -n kernel upgrade

Apply the kernel updates:

sudo ksplice -y kernel upgrade

Apply user-space updates (enhanced client only) and confirm afterwards:

sudo ksplice -y user upgrade
sudo ksplice all show

The Uptrack equivalent for the kernel:

sudo uptrack-upgrade -y

Tip

Applying a patch usually takes a few seconds. On busy hosts, run it outside peak load anyway and watch application latency while it runs. Start with one instance per tier before you touch the rest of the fleet.

#Which processes Ksplice can't patch

User-space patching has limits. Plan a restart (or the next reboot) for:

• PID 1 (systemd), which is never patched in place.
• Processes in chroots or containers that don't bind-mount /var/cache/ksplice.
• Programs that use setcontext/swapcontext.

#4. Verify and record

sudo ksplice kernel show | tail -5
sudo ksplice kernel show --available     # should list nothing for the CVE you targeted

Record the effective version in the change ticket. To check many instances without SSH, run the same show commands through OCI Run Command, or through your own configuration management, and collect the output.

#5. Make it automatic

Applied patches are cached in /var/cache/uptrack, and the client reapplies them early in boot. That way a reboot into the same kernel doesn't lose them. To have new updates installed as soon as they're published, edit /etc/uptrack/uptrack.conf:

autoinstall = yes

Leave the [Auth] accesskey that ships on OCI images alone. Then check that the setting is in place:

grep -E '^\s*autoinstall' /etc/uptrack/uptrack.conf

Caution

Auto-install changes the running kernel without a change window. For tightly controlled production, keep autoinstall = no on the first ring and apply manually. Turn it on for dev and test instances so problems show up there first.

To stop Ksplice reapplying updates at boot (for example, while you troubleshoot a suspected Ksplice issue), create /etc/uptrack/disable or add nouptrack to the kernel command line. Remove updates that are already applied:

sudo ksplice kernel remove --all

#Troubleshooting

#Network checks from a private subnet

curl -sS -o /dev/null -w '%{http_code}\n' https://ksplice.oracle.com/
env | grep -i _proxy

oci network route-table get --rt-id <route-table-ocid> \
  --query 'data."route-rules"[].{dest:destination,target:"network-entity-id"}' --output table

If the curl times out and the route table has no NAT gateway (or proxy) route for 0.0.0.0/0, the client can't reach the update server. The instance may still install RPMs through a service gateway to the regional yum mirror, but that doesn't prove Ksplice traffic follows the same path. Test the Ksplice endpoint itself.

For air-gapped hosts, Oracle provides an offline client (ksplice-offline, uptrack-offline) that installs updates from a local yum repository you mirror. That setup needs ULN access to build the mirror, so check the current Ksplice offline documentation before you plan it.

#Prevent it next time

• Add ksplice kernel show --available to your weekly patch report, so outstanding live patches are visible before a CVE becomes urgent.
• Turn on autoinstall = yes in dev and test, and keep production manual or on a later ring.
• Keep booted kernels current with OS Management Hub or dnf in maintenance windows. Ksplice coverage is best on supported, recent kernels.
• Make sure private subnets have a deliberate egress path (NAT gateway or proxy) for patch traffic, and document it in the network design.
• Give the security team the effective kernel version, so live-patched hosts aren't reported as vulnerable.