> ## 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.

# Copy Fail (CVE-2026-31431): Linux Kernel Local Privilege Escalation

> A critical Linux kernel cryptographic-subsystem flaw lets a local user become root. Analysis, scope, and mitigation.

*Published on May 1, 2026*

<Warning>
  **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.
</Warning>

## 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  |

## 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

```bash theme={null}
# 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.

```bash theme={null}
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.

```yaml theme={null}
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:

```bash theme={null}
# 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:

```bash theme={null}
sudo rm /etc/modprobe.d/disable-algif.conf
sudo modprobe algif_aead
```

On RHEL and derivatives, also drop the kernel parameter:

```bash theme={null}
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](https://onetsolutions.net).