Patching a Kernel CVE Fast

When a critical Linux kernel CVE drops, the question isn't 'will the patch land' — it's 'what do you do in the meantime?' Here's how we mitigated Copy Fail across the fleet in hours, before the kernel patch shipped.

A critical Linux kernel vulnerability dropped recently — a memory safety bug in the kernel's userspace crypto interface (AF_ALG), nicknamed "Copy Fail". Local privilege escalation, working exploit chains, and worse: it sat in the kernel for years before disclosure.

The question every hosting company hits when a CVE like this lands is: what do you do between disclosure and the kernel patch shipping?

The answer most places give is "wait." We don't.

The shape of the bug

Copy Fail lives in the algif_ family of kernel modules. These are the modules exposing socket(AF_ALG, ...) to userspace, which lets unprivileged programs request kernel-side cryptographic operations through socket calls. Most production hosting workloads never touch them. But "most" isn't "none", and an attacker doesn't need your code to use the interface; they just need some* code on the box to be exploitable.

The mitigation path with kernel CVEs is usually:

Vendor backports the upstream patch
Distro builds new kernel packages
You install and reboot

That cycle is days at the fastest, sometimes weeks. We needed something for now.

Defense in depth before the patch

AF_ALG is a kernel-side feature exposed via loadable modules. If those modules aren't loaded, the address family doesn't exist as far as userspace is concerned — socket(AF_ALG, ...) returns EAFNOSUPPORT rather than touching any of the vulnerable code paths.

So we blocked the modules from loading. One file, three nodes:

# /etc/modprobe.d/disable-algif.conf
install algif_aead /bin/false
install algif_hash /bin/false
install algif_skcipher /bin/false
install algif_rng /bin/false
install af_alg /bin/false

The install ... /bin/false syntax tells modprobe "if anyone asks to load this module, run /bin/false instead." The module never loads. The vulnerable code is unreachable.

We deployed this file to all three fleet nodes, ran modprobe -r to unload anything already in memory, and verified socket(AF_ALG, ...) now returns EAFNOSUPPORT. End-to-end mitigation took under two hours. The kernel patch is still pending.

Why this works (and where it doesn't)

This pattern works whenever a vulnerability is gated behind a loadable module that nothing on your box actually needs. The kernel team makes a lot of features modular precisely so they can be excluded from minimal systems. When a CVE hits one of those modules and you don't use it, blacklisting is essentially zero-cost mitigation.

The pattern doesn't work for CVEs in core kernel paths — networking stack, VFS, scheduler, anything always-on. For those you really do have to wait for the patch.

It also doesn't help if you actually use AF_ALG. Some applications (typically older crypto libraries trying to offload work to a kernel hardware accelerator) genuinely need it. Disabling the module breaks them. We checked our entire stack first; nothing we run uses it. We disabled it confidently.

Defense in depth, not in lieu

This isn't a fix — it's a mitigation. We're going to install the proper kernel patch when Alpine ships it, and we'll unpin the kernel package at that point. Until then we run with the module blacklisted and a pinned kernel version, both, because the difference between "we mitigated it" and "we patched it" matters even if the practical result on our box is the same.

What we'd want from you, if you ran your own server

If you self-manage a Linux box, the principle generalises: when a kernel CVE drops in a module-loaded subsystem you don't use, blacklist it the same day. lsmod | grep <module> to check, /etc/modprobe.d/ to disable, modprobe -r to unload running copies. Don't wait for the distro fix if a one-line config file removes the attack surface entirely.

Our customers don't have to do this themselves — it's our job. We document what we do anyway, because the people who choose us tend to want to know.

Speed of response is one of the things you're paying for when you pick a hosting provider that operates its own infrastructure. The slower the patch cycle, the more it matters that someone is watching the kernel mailing lists in the meantime.