kpatch is in maintenance mode, and klp-build is replacing kpatch-build

The deprecation notice comes before the description

The first thing in the README is a notice, and it is unusually specific about what is stopping and what is not.

Starting with Linux 6.19, the kpatch project is deprecated and in maintenance mode, because kpatch-build functionality is being replaced by klp-build, which is now part of the upstream Linux kernel. The consequences are listed as four separate statements: kpatch is now in maintenance mode, no new features will be added, bug fixes for newer kernels or toolchains will not be provided, and existing functionality for older kernels continues to work and will be maintained minimally as needed.

That last clause is the operative one for anyone still running kpatch. You are not being cut off, you are being frozen. And the architecture support list for klp-build, the replacement, is the thing to plan around: x86-64 is supported on Linux 6.19 and newer, arm64 patches are in development on LKML, and ppc64le, s390 and loongarch are coming soon. If your fleet is on arm64, you are between two unfinished things.

The project points to issue 1498 for further information. The repository is not archived, and the last push was on 2026-09-15, with release v0.9.11 dated 2025-10-28 after v0.9.10 in January 2025. Recent commits against a deprecated project are typically maintenance rather than new capability, and the version numbering staying under 1.0 reflects that.

For reference, kpatch itself is Linux dynamic kernel patching infrastructure that patches a running kernel without rebooting or restarting processes, letting administrators apply critical security patches immediately rather than waiting for long-running tasks, user logoffs or a scheduled window.

Compile twice, diff the objects, emit a module

The mechanism is function-granular replacement: old functions are replaced with new ones. Three components carry that out.

kpatch-build is the collection of tools that convert a source diff into a patch module. Its approach is brute and effective, compiling the kernel both with and without your source patch and comparing the resulting binaries. kpatch-build is a script that drives a utility named create-diff-object to do the actual comparison.

The patch module is the output .ko file. It carries the replacement functions plus metadata about the originals, and on load it registers with the kernel's livepatch infrastructure, CONFIG_LIVEPATCH, which performs the patching.

The kpatch utility is the command-line tool a user runs to manage a collection of modules. One or more modules can be configured to load at boot time, so a system stays patched across a reboot into the same kernel version. That last capability is easy to overlook and it is what makes kpatch more than a one-shot emergency tool.

The kpatch-build pipeline in full, as the README lists it: build the unstripped vmlinux, patch the source tree, rebuild vmlinux while monitoring which objects get rebuilt as the changed objects, recompile each changed object with -ffunction-sections -fdata-sections for the patched version, unpatch the tree and recompile the same objects for the original version, then for every changed object run create-diff-object. That step analyses each pair for patchability, adds .kpatch.funcs and .rela.kpatch.funcs sections that the kpatch core module uses to determine which functions to redirect using ftrace, adds .kpatch.dynrelas and .rela.kpatch.dynrelas sections used to resolve references to non-included local and non-exported global symbols, and generates the output object. Finally all output objects are linked into a cumulative object and the module is produced.

A proc/meminfo patch, end to end

The README's worked example is deliberately trivial, patching one string literal in a proc file so a field prints in capital letters. It is worth reading end to end because the build output tells you what the tool actually did.

The input is an ordinary unified diff produced with diff, git or quilt against the kernel tree, changing one format string in src/fs/proc/meminfo.c so that VmallocChunk becomes VMALLOCCHUNK.

Building it produces a module named after the patch:

$ kpatch-build meminfo-string.patch
Using cache at /home/jpoimboe/.kpatch/3.13.10-200.fc20.x86_64/src
Testing patch file
checking file fs/proc/meminfo.c
Building original kernel
Building patched kernel
Detecting changed objects
Rebuilding changed objects
Extracting new and modified ELF sections
meminfo.o: changed function: meminfo_proc_show
Building patch module: livepatch-meminfo-string.ko
SUCCESS

Read the middle of that output as the pipeline executing. Building original kernel and Building patched kernel is the double compile, Detecting changed objects and Rebuilding changed objects is the rebuild-monitoring step, and Extracting new and modified ELF sections is create-diff-object running. The line naming the changed function is the only place the tool tells you which function will be redirected.

Note also that it built two kernels to change one string, and the cache directory shows the kernel version it was working against. That cost is the central objection to kpatch-build, and it is why klp-build exists.

Applying the result is a single privileged command:

$ sudo kpatch load kpatch-meminfo-string.ko
loading patch module: livepatch-meminfo-string.ko

and the effect is immediately observable through the patched interface:

$ grep -i chunk /proc/meminfo
VMALLOCCHUNK:   34359337092 kB

The README warns at the top of the file that kernel crashes, spontaneous reboots and data loss may occur, and it does not soften that warning.

The kpatch-build cost and the distribution caveat

Two constraints sit behind the deprecation decision, and both are visible in the documentation rather than inferred.

The first is the double compile. Building a kernel twice, once patched and once not, and then rebuilding every changed object in both states, is expensive in time and disk. That cost is why the cache path in the output matters, and why an emergency patch is not something you want to be doing under time pressure on a fleet you do not control. The project's own replacement, klp-build, lives in the kernel tree at scripts/livepatch/klp-build, which is a strong signal about where the maintainers think this should live.

The second is the tested-platform caveat, which the README states in a note attached to the quick start. kpatch is designed to work with any recent Linux kernel on any distribution, but kpatch-build has specifically been tested and confirmed to work on Fedora and RHEL, and has been known to work on Oracle Linux, Ubuntu, Debian and Gentoo. The distinction between tested and known to work is doing real work in that sentence, and for a tool that recompiles your kernel it is the difference between a supported configuration and an adventure.

Architecture support as listed covers x86-64, ppc64le, arm64 and loongarch64, plus s90 with a note about upstream prerequisites linked to a separate document, doc/s390-upstream-prerequisites.md. That last item is a reasonable model for how much detail this project attaches to platform caveats.

The patch author guide exists because the trivial example misleads. The README says plainly that live patching is not always as easy as the previous example and can have major pitfalls if you are not careful, and points to doc/patch-author-guide.md. Read that before writing anything real, because the failure mode of a function redirect that gets the wrong stack layout is a kernel panic on the machine you were trying to protect.

Building kpatch itself, and what the Makefile offers

Installation is delegated to a separate document, doc/INSTALL.md, rather than spelled out in the README. What the repository root does show you is the shape of the build.

The top-level Makefile includes Makefile.inc and builds five subdirectories in order: kpatch-build, kpatch, kmod, man and contrib. Each gets a matching build, install, uninstall and clean target generated from that list, so a top-level make install walks the same five directories rather than doing anything clever of its own.

The interesting targets are the test ones. There is a unit target that depends on the test/unit directory and on build-kpatch-build, so unit tests need the build tool before they run. There are three integration targets: integration-quick, integration-slow and plain integration, which defaults to the quick variant. Both build the three components before running, and the quick and slow split is how you keep a pre-merge run short.

There is a dependencies target, and it does something specific rather than the usual package-manager incantation:

dependencies: SHELL:=/bin/bash
dependencies:
	source test/integration/lib.sh && kpatch_dependencies

It sources a shell library and calls a function in it, which is how this project manages the long list of packages needed to build a kernel. The same lib.sh is used by vagrant-install, a target that checks whether you are root before proceeding and, if you are not, prints a warning that it is intended for freshly installed machines or VMs only, then makes you read lib.sh and confirm before continuing. That is an unusual and defensible guard rail for a target whose job is installing a hypervisor and destroying and recreating the current virtual machine.

Licence is GPL-2.0, with COPYING at the root.

Where this goes instead

The alternative is not another third-party project. It is the kernel's own livepatch tooling, and the relationship is stated directly in the README.

klp-build is now part of the upstream Linux kernel, living in the tree rather than outside it. That matters for three reasons. Patch authors get the tool from the same source as the kernel they are patching, so version skew becomes a non-issue. Distribution packagers already carry livepatch infrastructure, so a kpatch-built module and a klp-built module target the same CONFIG_LIVEPATCH machinery. And the architecture story is now the kernel's problem rather than kpatch's, with x86-64 already there and the others on the stated roadmap.

For teams that need live patching of a fleet, the decision is therefore between a deprecated external tool that works on older kernels and an upstream tool that works on new ones. The README's own guidance resolves it in one line: existing functionality for older kernels continues to work, and new work belongs with klp-build.

The other option, for completeness, is not patching at all. A container runtime or a userspace boundary can make a bug unreachable without touching the kernel at all, and for many classes of kernel issue that is the more durable fix. The README's pitch for kpatch is specifically about applying critical security patches immediately without waiting for a reboot window, which is a real operational need that no amount of userspace isolation addresses when the vulnerability is in the kernel itself.

What nobody should do is adopt kpatch today as a new dependency. The maintenance mode declaration exists precisely to prevent that, and the release history shows the project winding down rather than up.

Editorial conclusion

Adopt kpatch only if you are maintaining an existing deployment on an older kernel where the livepatch tooling is already in place, since existing functionality for older kernels continues to work and will be maintained minimally. Do not adopt it for anything new: the project states that starting with Linux 6.19 it is deprecated, that no new features will be added, and that bug fixes for newer kernels or toolchains will not be provided. Verify first which kernel your systems actually run and whether klp-build covers your architecture, because the README lists upstream support as x86-64 on Linux 6.19 and newer, arm64 in development on LKML, and ppc64le, s390 and loongarch as coming soon.

Frequently asked questions

Official sources

1. dynup/kpatch on GitHub
2. Issues
3. License: GPL-2.0
4. README
5. Releases