1. Detect the build mode first

The mitigation that’s circulating widely —

echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif-aead.conf
rmmod algif_aead 2>/dev/null

— is fine on Debian/Ubuntu (module not loaded by default but autoloads when exploit code is called) but does nothing on RHEL-family hosts. Those kernels ship with CONFIG_CRYPTO_USER_API_AEAD=y rather than =m, so modprobe.d rules cannot block loading and rmmod cannot remove a built-in. The commands return success and leave the system unchanged. Any fleet rollout has to branch on the build mode of the running kernel.

grep -E '^CONFIG_CRYPTO_USER_API_AEAD=' /boot/config-$(uname -r)

• =m — module path (modprobe.d + rmmod work, with caveats below)
• =y — built-in path (needs initcall_blacklist + reboot, see §3)
• absent — already not compiled in, no action required

Runtime cross-check: lsmod | grep algif_aead only matches in the =m case.

2. Module case (Debian / Ubuntu / vanilla / cloud images)

Persistent block, active unload, initramfs regeneration so the rule survives early boot:

cat >/etc/modprobe.d/disable-algif-aead.conf <<'EOF'
install algif_aead /bin/false
install algif_skcipher /bin/false
install algif_hash /bin/false
install algif_rng /bin/false
EOF

update-initramfs -u            # Debian/Ubuntu
# dracut -f                    # Fedora-family module kernels

modprobe -r algif_aead 2>/dev/null

This is necessary but not sufficient. The next three subsections explain why, and what to add.

$ cat /etc/modprobe.d/test.conf
blacklist algif_aead
$ modprobe algif_aead          # succeeds despite the blacklist
$ lsmod | grep algif_aead
algif_aead             20480  0

# Bypasses /etc/modprobe.d/ completely:
insmod /lib/modules/$(uname -r)/kernel/crypto/algif_aead.ko.zst

#!/bin/bash
set -eu

KVER=$(uname -r)
KDIR=/lib/modules/$KVER/kernel/crypto

# Layer 1+2: chmod then delete (chmod first creates a clean audit trail
# for change-management reporting, then the artifact is removed).
for mod in algif_aead algif_skcipher algif_hash algif_rng; do
  for ext in ko ko.zst ko.xz ko.gz; do
    f="$KDIR/$mod.$ext"
    [ -f "$f" ] || continue
    chmod 000 "$f"
    # Layer 3: divert + rename so package upgrades don't restore it.
    dpkg-divert --add --rename \
      --divert "${f}.copyfail-disabled" "$f"
  done
done

# Rebuild dependency map so the loader doesn't see stale entries.
depmod -a "$KVER"

# Belt-and-suspenders: keep the modprobe.d install rule too,
# in case a fresh .ko is rebuilt and the divert hasn't been
# re-applied yet for that new kernel version.
cat >/etc/modprobe.d/disable-algif-aead.conf <<'EOF'
install algif_aead /bin/false
install algif_skcipher /bin/false
install algif_hash /bin/false
install algif_rng /bin/false
EOF
update-initramfs -u

3. Built-in case (RHEL / Alma / Rocky / CloudLinux / Oracle, some SUSE)

Module tooling is irrelevant. There is no .ko file to chmod, delete, or divert — the code is linked into vmlinuz. Suppress the initcall on next boot:

grubby --update-kernel=ALL --args="initcall_blacklist=algif_aead_init"
grubby --info=ALL | grep initcall_blacklist
# reboot required; the running kernel stays exposed until then

Until the reboot lands, the runtime control surface is seccomp/LSM rather than module management — block socket(AF_ALG, …) for any workload that doesn’t legitimately need it. §7 onwards covers this.

4. Fleet rollout fix (Ansible)

1. slurp /boot/config-$(uname -r), parse CONFIG_CRYPTO_USER_API_AEAD.
2. Module branch (=m): apply §2 — modprobe.d install, .ko chmod + delete + dpkg-divert, initramfs regen.
3. Built-in branch (=y): grubby edit, flag host for reboot batch.
4. Verify: assert no aead algorithms in /proc/crypto, no algif_* entries in lsmod, divert recorded in dpkg-divert --list | grep algif, or initcall_blacklist=algif_aead_init in /proc/cmdline after reboot.
5. Drift check until patched kernels are rolled.

For container fleets, the OVH-style privileged DaemonSet that lays down the modprobe.d file and unloads on each node is the host-side pattern, paired with a runtime-level seccomp profile change so unpatched nodes still refuse AF_ALG from workloads. The seccomp layer is the more durable control.

5. rmmod –force: what it actually does

rmmod -f sets the O_TRUNC flag on the delete_module(2) syscall, which the kernel routes through try_force_unload(). That bypasses three things the unforced path enforces:

• the usage-count check (module_refcount(mod) != 0 normally returns -EWOULDBLOCK),
• the requirement that the module be in MODULE_STATE_LIVE,
• waits for any pending grace periods, including RCU readers traversing the module’s text.

Two preconditions matter:

1. Kernel must be built with CONFIG_MODULE_FORCE_UNLOAD=y. Check via grep CONFIG_MODULE_FORCE_UNLOAD /boot/config-$(uname -r) or zgrep /proc/config.gz. Distribution kernels (RHEL, Ubuntu LTS, SUSE Enterprise) typically ship this off, in which case the syscall returns -EINVAL regardless of how loudly userspace asks. The userspace kmod accepts the flag and forwards it; success has to be confirmed with lsmod, not exit status.
2. The kernel taints itself (TAINT_FORCED_RMMOD, visible in /proc/sys/kernel/tainted), and any thread still executing inside the module’s .text or dereferencing into its data segment hits a use-after-free. For a crypto module this class is particularly nasty: outstanding tfm contexts, queued requests in workqueues, async completion callbacks, and in-flight scatterlists can all resume into freed pages.

6. Forensic posture — algif_aead loaded is itself an indicator

algif_aead is rarely present in normal operation on a typical server. Default-built kernels do not auto-load it at boot; it loads on-demand via the kernel’s request_module() path when something binds an AF_ALG socket to an AEAD algorithm. The well-known kernel crypto consumers — LUKS / dm-crypt, kTLS, IPsec / xfrm, OpenSSL / GnuTLS / NSS in default builds, OpenSSH — all use kernel-internal crypto APIs directly and never touch AF_ALG.

The legitimate consumers are narrow:

• libkcapi command-line tools (kcapi-enc, kcapi-dgst) used in specific embedded or testing contexts
• OpenSSL’s afalg engine, rarely enabled and historically unreliable
• Vendor-specific hardware crypto offload that exposes AF_ALG to userspace
• A handful of unusual strongSwan / IKE configurations

On a general-purpose server — web, database, app, k8s node, jump host, build agent — finding algif_aead loaded should be treated as suspicious. Because the module was the staging ground for Copy Fail, a loaded state that cannot be accounted for is consistent with either an in-progress exploitation attempt or a failed one that left the module attached. The kernel does not auto-unload modules when their refcount drops to zero, so a previously-exploited host can show the module loaded long after the attacker’s process has exited.

# Is any algif_* family member currently loaded?
lsmod | grep -E '^algif_(aead|skcipher|hash|rng)'

# Open AF_ALG sockets right now (newer iproute2):
ss -fa alg
# Older systems:
lsof 2>/dev/null | grep AF_ALG

# Module load history from the audit subsystem:
ausearch -m MODULE_LOAD -ts recent
# or:
grep -E 'init_module|finit_module' /var/log/audit/audit.log

# Kernel ring buffer (dyndbg-dependent, but worth checking):
dmesg -T | grep -iE 'algif|af_alg'

# Module-specific taint flags (forced load, unsigned, out-of-tree):
cat /sys/module/algif_aead/taint 2>/dev/null
cat /sys/module/algif_aead/refcnt 2>/dev/null
cat /proc/sys/kernel/tainted

# When was the .ko file last accessed? (atime --- note relatime caveats)
stat /lib/modules/$(uname -r)/kernel/crypto/algif_aead.ko*

# Watch the module directory for tampering --- perm changes,
# deletions, new .ko drops:
auditctl -w /lib/modules -p wa -k module_changes

# Catch every load/unload at the syscall level, with PID/UID:
auditctl -a always,exit -F arch=b64 \
  -S init_module -S finit_module -S delete_module \
  -k module_lifecycle

# Persistent: drop the equivalents into /etc/audit/rules.d/
# and run augenrules --load.

Container runtime mitigations

Docker, Podman, Kubernetes — seccomp, admission policy, detection

The base ingredient is one seccomp profile that returns EAFNOSUPPORT for any socket(AF_ALG, …) call. The same JSON works in Docker, Podman, and Kubernetes (via Localhost profile). Below: the profile, then how each runtime references it, then enforcement at the cluster admission layer, then the detection counterpart.

7. The seccomp profile

AF_ALG is socket family 38. Returning EAFNOSUPPORT (97) rather than EPERM makes the runtime behavior indistinguishable from a kernel with CONFIG_CRYPTO_USER_API=n, so applications that probe AF_ALG fall back gracefully (OpenSSL’s afalg engine, libkcapi consumers) instead of bubbling up “permission denied” errors.

copy-fail-deny.json:

{
  "defaultAction": "SCMP_ACT_ALLOW",
  "syscalls": [
    {
      "names": ["socket", "socketpair"],
      "action": "SCMP_ACT_ERRNO",
      "errnoRet": 97,
      "args": [
        {
          "index": 0,
          "value": 38,
          "op": "SCMP_CMP_EQ"
        }
      ],
      "comment": "Block AF_ALG (CVE-2026-31431 Copy Fail)"
    }
  ]
}

This profile is additive only — defaultAction: SCMP_ACT_ALLOW lets everything else through. In production, merge this rule into Docker’s default seccomp profile (moby’s profiles/seccomp/default.json) rather than replace it. The merge is purely appending one entry to the syscalls array.

Correctness notes:

• The filter triggers on socket(2) and socketpair(2). On x86_64, ARM64, and every modern container target, glibc calls these directly. On x86_32 and a few legacy arches, glibc routes through socketcall(2) with the family hidden behind a userspace pointer that seccomp cannot dereference. For 32-bit workloads, complement this with a deny on socketcall.
• Privileged containers (--privileged in Docker, securityContext.privileged: true in K8s) bypass seccomp entirely. The profile gives no protection there; for those, the kernel-level mitigation is the only answer.

8. Docker

Per-container:

docker run \
  --security-opt seccomp=/etc/docker/seccomp/copy-fail-deny.json \
  myimage

Daemon-wide default in /etc/docker/daemon.json:

{
  "seccomp-profile": "/etc/docker/seccomp/copy-fail-deny.json"
}

then systemctl reload docker. Verify from inside any container:

python3 -c 'import socket; socket.socket(38, socket.SOCK_SEQPACKET, 0)'
# OSError: [Errno 97] Address family not supported by protocol

9. Podman

Same JSON, slightly different invocation:

podman run \
  --security-opt seccomp=/etc/containers/seccomp/copy-fail-deny.json \
  myimage

System default in /etc/containers/seccomp.json (Podman reads this path automatically when seccomp_profile is set in containers.conf).

10. Kubernetes — distribute the profile

The kubelet looks for Localhost profiles under <root-dir>/seccomp/, default /var/lib/kubelet/seccomp/. A privileged DaemonSet drops the file in place:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: install-copy-fail-seccomp
  namespace: kube-system
spec:
  selector:
    matchLabels: { app: install-copy-fail-seccomp }
  template:
    metadata:
      labels: { app: install-copy-fail-seccomp }
    spec:
      tolerations:
      - operator: Exists
      containers:
      - name: installer
        image: busybox:1.36
        command: ["/bin/sh", "-c"]
        args:
        - |
          set -eu
          mkdir -p /host/seccomp/profiles
          cat > /host/seccomp/profiles/copy-fail-deny.json <<'EOF'
          {
            "defaultAction": "SCMP_ACT_ALLOW",
            "syscalls": [{
              "names": ["socket","socketpair"],
              "action": "SCMP_ACT_ERRNO",
              "errnoRet": 97,
              "args": [{"index":0,"value":38,"op":"SCMP_CMP_EQ"}]
            }]
          }
          EOF
          exec sleep infinity
        securityContext:
          privileged: true
          runAsUser: 0
        volumeMounts:
        - name: seccomp
          mountPath: /host/seccomp
      volumes:
      - name: seccomp
        hostPath:
          path: /var/lib/kubelet/seccomp
          type: DirectoryOrCreate

For production, prefer the Security Profiles Operator (SPO) — it owns this distribution problem properly via a SeccompProfile CRD and handles node churn.

Reference from pods

apiVersion: v1
kind: Pod
metadata:
  name: app
spec:
  securityContext:
    seccompProfile:
      type: Localhost
      localhostProfile: profiles/copy-fail-deny.json
  containers:
  - name: app
    image: myimage

The path is relative to the kubelet’s seccomp root, not absolute.

11. Enforce cluster-wide with Kyverno

Validation policy (rejects pods that don’t carry the profile):

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-copy-fail-seccomp
spec:
  validationFailureAction: Enforce
  background: false
  rules:
  - name: pod-must-have-copy-fail-seccomp
    match:
      any:
      - resources:
          kinds: [Pod]
    exclude:
      any:
      - resources:
          namespaces: [kube-system]
    validate:
      message: >
        Pods must set spec.securityContext.seccompProfile to
        Localhost:profiles/copy-fail-deny.json (CVE-2026-31431 mitigation).
      pattern:
        spec:
          securityContext:
            seccompProfile:
              type: Localhost
              localhostProfile: profiles/copy-fail-deny.json

Mutation variant (injects the profile rather than rejecting pods that lack it — friendlier rollout):

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: inject-copy-fail-seccomp
spec:
  rules:
  - name: add-seccomp-profile
    match:
      any:
      - resources:
          kinds: [Pod]
    mutate:
      patchStrategicMerge:
        spec:
          securityContext:
            +(seccompProfile):
              type: Localhost
              localhostProfile: profiles/copy-fail-deny.json

The +(seccompProfile) adds the field only when absent, so workloads that already declare RuntimeDefault or another Localhost profile aren’t clobbered.

12. OPA/Gatekeeper equivalent

apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
  name: k8srequiredseccomp
spec:
  crd:
    spec:
      names: { kind: K8sRequiredSeccomp }
      validation:
        openAPIV3Schema:
          type: object
          properties:
            requiredProfile: { type: string }
  targets:
  - target: admission.k8s.gatekeeper.sh
    rego: |
      package k8srequiredseccomp
      violation[{"msg": msg}] {
        input.review.kind.kind == "Pod"
        profile := input.review.object.spec.securityContext.seccompProfile
        not profile.type == "Localhost"
        msg := "Pod must set seccompProfile.type=Localhost"
      }
      violation[{"msg": msg}] {
        input.review.kind.kind == "Pod"
        profile := input.review.object.spec.securityContext.seccompProfile
        profile.localhostProfile != input.parameters.requiredProfile
        msg := sprintf("seccompProfile.localhostProfile must be %v",
                       [input.parameters.requiredProfile])
      }

Then the constraint:

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredSeccomp
metadata:
  name: require-copy-fail-seccomp
spec:
  match:
    kinds: [{ apiGroups: [""], kinds: ["Pod"] }]
    excludedNamespaces: ["kube-system"]
  parameters:
    requiredProfile: profiles/copy-fail-deny.json

13. Detection layer (Falco)

Pair prevention with telemetry on AF_ALG attempts so exploit attempts hitting the wall are visible:

- list: af_alg_legitimate_users
  items: [strongswan, charon, ipsec, kcapi-enc, kcapi-dgst]

- rule: AF_ALG socket creation
  desc: >
    socket(AF_ALG,...) is the first step of CVE-2026-31431 Copy Fail.
    Outside known IPsec/libkcapi binaries it is suspicious.
  condition: >
    evt.type = socket and evt.dir = > and
    evt.arg.domain = AF_ALG and
    not proc.name in (af_alg_legitimate_users)
  output: >
    AF_ALG socket created (proc=%proc.name pid=%proc.pid
    cmdline=%proc.cmdline container=%container.id image=%container.image.repository)
  priority: WARNING
  tags: [linux, container, mitre_privilege_escalation, cve-2026-31431]

Tetragon equivalents work too if that’s the stack — same observable, different sensor.

14. Verification

End-to-end test from a pod or container:

# Should now fail with Errno 97
python3 -c 'import socket; socket.socket(38, socket.SOCK_SEQPACKET, 0)'

# C version, useful in scratch images
cat > t.c <<'EOF'
#include <sys/socket.h>
#include <stdio.h>
#include <errno.h>
int main(void){
    int s = socket(38, SOCK_SEQPACKET, 0);
    printf("rc=%d errno=%d\n", s, errno);
    return 0;
}
EOF
gcc t.c -o t && ./t  # expect rc=-1 errno=97

If the test instead returns errno=13 (EACCES) or the socket succeeds, the profile isn’t being applied — most likely the pod is privileged, the runtime is kata / gvisor with its own filter chain, or the kubelet path is different from /var/lib/kubelet/seccomp/. Check crictl inspect <container> for the seccomp path the runtime actually loaded.

Exploit portability

The §6 forensic guidance assumes the published PoC is what’s hitting your fleet. That assumption holds for hosts that match the PoC’s development environment, and it breaks for everything else. A target that the public exploit walks past untouched is not a target that’s safe from algif_aead corruption — the kernel bug doesn’t care which userspace binary the attacker chose to poison. This section walks through where the off-the-shelf script needs porting work, where it fails outright, and what that means for both the patch-priority calculus and the detection rules from §6.

15. Where the public PoC fits and where it doesn’t

The published PoC for Copy Fail is a 732-byte Python script. It opens the page-cache mapping for /usr/bin/su, drives algif_aead through the in-place AEAD path until the kernel’s copy step writes attacker-supplied bytes into the cached page, then runs su. The kernel uses the poisoned page on the next exec because mmap returns whatever the page cache holds; the on-disk file is unchanged. That description fits a glibc Debian or Ubuntu host on x86_64 with 4 KiB pages — the development environment the PoC author wrote against.

Three things in that description are assumptions, and each one breaks on a class of system worth thinking through.

        mov     x0, #0
        mov     x8, #146           // __NR_setuid
        svc     #0
        adr     x0, sh             // "/bin/sh\0"
        mov     x1, #0
        mov     x2, #0
        mov     x8, #221           // __NR_execve
        svc     #0
sh:     .ascii  "/bin/sh\0"

uname -m && getconf PAGESIZE

find / -perm -4000 -type f 2>/dev/null

16. Portability quick reference

The rows that say “Runs” or “Runs after re-derivation” are the urgent patch-now group for the public exploit. The rows that say “rewrite needed” are not safe — they’re vulnerable to a custom build, and that build is a few days of work for a competent operator. Patch all of them.

17. Patch precedence stays the same

Nothing in §15 or §16 changes the patch-precedence calculus from §1–§5: apply the kernel update from your distribution and reboot. The interim controls in §2 (module case) and §3 (built-in case) hold across all the targets in the §16 table, because they remove or suppress algif_aead itself rather than blocking any specific exploit shape. The seccomp profile from §7–§12 likewise applies regardless of arch or distro, because it intercepts the AF_ALG socket creation step that every variant of the exploit has to make first.

The portability discussion in this section is for triage and detection tuning, not for re-prioritising patches. A host the public PoC can’t touch today is a host a custom build can touch tomorrow.