Skip to main content

Documentation Index

Fetch the complete documentation index at: https://help.onetsolutions.net/llms.txt

Use this file to discover all available pages before exploring further.

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?
ProfileExposureAction
Single-tenant VPS, your code only, no third partiesLowWait for the kernel patch and schedule the upgrade
VPS hosting multiple customers, multiple shell accounts, or running unaudited code (shared CI, plugins, user runtimes)CriticalMitigate immediately, then patch
Kubernetes cluster orchestrating third-party pods or dynamic workloadsCriticalRoll out a mitigation DaemonSet across every node

​
Immediate mitigation

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.