Published on May 1, 2026
CVE-2026-31431 — nicknamed “Copy Fail”. A local privilege escalation bug present in nearly every recent Linux kernel. If your server runs third-party code or grants shell access, treat the mitigation as a priority.
The bug in two sentences
The flaw lives in the Linux kernel’s cryptographic subsystem, exposed through the AF_ALG interface (algif_aead module). It lets locally-running code with limited rights write into kernel memory and walk back out with root privileges.
In practice, two exploitation paths stand out:
- User account → root on a regular server.
- Container escape to the host node on Docker or Kubernetes — pod isolation collapses entirely.
An attacker needs a local foothold first (a user account, a pod, code embedded in a dependency, etc.). Without one, the flaw is not remotely exploitable.
Sizing your exposure
Rather than a binary “critical / not critical”, the right question is: who can execute code on your systems?
| Profile | Exposure | Action |
|---|
| Single-tenant VPS, your code only, no third parties | Low | Wait for the kernel patch and schedule the upgrade |
| VPS hosting multiple customers, multiple shell accounts, or running unaudited code (shared CI, plugins, user runtimes) | Critical | Mitigate immediately, then patch |
| Kubernetes cluster orchestrating third-party pods or dynamic workloads | Critical | Roll out a mitigation DaemonSet across every node |
The real fix will be a kernel update. Until your distribution ships it, the workaround is to disable the offending module. The change is reversible and has no impact on the large majority of application workloads.
Debian, Ubuntu and derivatives
# Block the module from being reloaded on next boot
echo "install algif_aead /bin/false" | sudo tee /etc/modprobe.d/disable-algif.conf
# Unload the copy currently resident in memory
sudo rmmod algif_aead 2>/dev/null || true
RHEL, AlmaLinux, Rocky Linux, CentOS and Fedora
A slightly different path: the module is neutralised through GRUB at kernel init time.
sudo grubby --update-kernel=ALL --args=initcall_blacklist=algif_aead_init
sudo reboot
Kubernetes clusters
If you run Kubernetes on top of your VPS, propagate the mitigation across every node with a privileged DaemonSet. The trailing pause container keeps the DaemonSet alive after the initContainer finishes, so the system does not loop trying to restart it.
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: disable-algif-aead
namespace: kube-system
spec:
selector:
matchLabels:
app: disable-algif-aead
template:
metadata:
labels:
app: disable-algif-aead
spec:
hostPID: true
tolerations:
- operator: Exists
effect: NoSchedule
- operator: Exists
effect: NoExecute
initContainers:
- name: disable-algif-aead
image: alpine:3.23
securityContext:
privileged: true
command:
- /bin/sh
- -c
- |
echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif-aead.conf
rmmod algif_aead 2>/dev/null || true
volumeMounts:
- name: modprobe-d
mountPath: /etc/modprobe.d
containers:
- name: pause
image: registry.k8s.io/pause:3.10
resources:
limits:
cpu: 1m
memory: 8Mi
volumes:
- name: modprobe-d
hostPath:
path: /etc/modprobe.d
Verifying the mitigation is in effect
A quick check after applying:
# The module should no longer be listed
lsmod | grep algif_aead
# And any load attempt must fail
sudo modprobe algif_aead 2>&1
# expected: "install /bin/false algif_aead" followed by a failure
If lsmod returns nothing and modprobe fails, you are good.
Reverting
If a specific service relies on the kernel’s AF_ALG API (uncommon outside low-level cryptographic use cases), you can re-enable the module:
sudo rm /etc/modprobe.d/disable-algif.conf
sudo modprobe algif_aead
On RHEL and derivatives, also drop the kernel parameter:
sudo grubby --update-kernel=ALL --remove-args=initcall_blacklist=algif_aead_init
sudo reboot
What’s next
Track your distribution’s advisories — the kernel patch is the real destination, the module knockout is only a stopgap. For technical questions, open a ticket from your OnetSolutions client area.