KernelCare keeps the kernel patched without rebooting, and most hosts stop there. But the kernel is not where Heartbleed-class bugs live. A glibc or OpenSSL CVE sits in userspace, and yum update openssl does nothing for the copy of libssl that Exim, httpd, and MySQL already mapped into memory when they started. Those processes keep running the vulnerable code until you restart them — which is the maintenance window you bought KernelCare to avoid.
LibCare is the TuxCare add-on that closes that gap. It applies binary patches to the in-memory image of glibc and OpenSSL in live processes, so a long-running Exim daemon stops being exploitable without an exim -bV restart that drops every queued message. This guide covers finding the exposed processes, enabling LibCare through the KernelCare agent you already run, and verifying the patch actually landed.
Why a patched package is not a patched server
When a package manager replaces /usr/lib64/libssl.so.3, it writes a new file to disk. Every process that opened the old file keeps its pages mapped — the kernel just marks the old inode as deleted and hands it out until the last reference closes. On a cPanel box that means httpd, exim, dovecot, mysqld, and every PHP-FPM pool keep the pre-patch OpenSSL resident for days.
You can see exactly which processes are stuck on a deleted library:
lsof +c 0 2>/dev/null | grep -E 'libssl|libcrypto|libc-' | grep -i deleted
Any line that prints means that PID is still executing the old code. The textbook fix is systemctl restart on each service, but on a busy shared-hosting node restarting Exim or MySQL mid-day is a customer-facing event. That is the problem LibCare exists to solve.
Confirm LibCare is licensed
LibCare is not part of the base KernelCare kernel license — it's bundled with KernelCare Enterprise or sold as an add-on. Check the agent first:
kcarectl --lib-info
If you get Userspace patches are not supported by your license, the key needs the LibCare entitlement added. Sort that on the KernelCare license before going further — the rest of these commands no-op without it. LibCare is x86-64 only; there are no ARM userspace patches, so Graviton or Ampere nodes can't use it.
Enable userspace patching in the agent
LibCare rides on the same kcarectl agent that handles the kernel, so there's nothing new to install if KernelCare is already on the box. Tell the agent which userspace patch sets to apply by editing the config:
# /etc/sysconfig/kcare/kcare.conf
USERSPACE_PATCHES=libs
libs covers the glibc and OpenSSL patches that matter on a hosting node. (qemu is the other common value, relevant only on virtualisation hosts.) Then apply what's available right now:
kcarectl --lib-update
This downloads the current userspace patch level and applies it to every eligible running process. It does not restart anything — the patch is written into the live process image. On a node with a few hundred PHP-FPM workers this takes a few seconds.
The automatic cron that keeps userspace patches current is disabled by default, separate from the kernel cron. Turn it on once:
libcare-cron init
After that the agent picks up new glibc and OpenSSL patches on the same cadence as kernel patches.
Verify the patch landed
Two commands confirm the result. First, the per-process view:
kcarectl --lib-info
It lists each patched PID and the library it patched. Cross-check against the lsof output from earlier — the PIDs that showed a deleted libssl should now appear here as patched. For patch-level detail (which CVEs the applied set covers):
kcarectl --lib-patch-info
If you ever need to back out — say a patch is suspected in an application-level regression — unload userspace patches without touching the kernel:
kcarectl --lib-unload
The processes drop back to their original in-memory code immediately; the next --lib-update re-applies. This is the userspace mirror of the rollback behaviour described in the agent and ePortal upgrade guide.
Fleets and air-gapped nodes
If you distribute kernel patches through a local ePortal — which you should at any real scale — userspace patches flow through the same channel. The agents pull glibc and OpenSSL patches from ePortal instead of reaching out to the TuxCare CDN directly, so the air-gapped ePortal setup covers LibCare too without extra firewall rules. Stage userspace patches in a test feed first, exactly as you would kernel patches, before promoting them fleet-wide. The broader rollout mechanics are in the live-patching for hosting fleets playbook.
One caveat for EOL distributions: LibCare's glibc and OpenSSL coverage follows the operating system's lifecycle, including the extended phase. If you're keeping CentOS 7 alive on TuxCare Endless Lifecycle Support, the userspace patches keep coming for the same window as the ELS kernel patches — which is the entire reason to pair them.