CVE-2026-31431: AF_ALG Socket Creation by Non-Crypto Tooling (CVE-2026-31431 Copy Fail)

Vulnerability summary

CVE-2026-31431, known publicly as Copy Fail, is a Linux kernel local-privilege-escalation bug in the algif_aead crypto path. The kernel fix reverts most of an older in-place AEAD optimisation and moves the operation back out-of-place. That short phrase hides the operational risk: a low-privileged local process can abuse AF_ALG, authencesn and splice() to write four controlled bytes into the page cache of a readable file. Public analysis from the Copy Fail researchers shows the attack against setuid-root binaries such as /usr/bin/su, which can turn a shell user into root without changing the file on disk.

NVD records the kernel.org CVSS v3.1 score as 7.8 High with local attack vector, low complexity, low privileges required and no user interaction. CISA added the vulnerability to the Known Exploited Vulnerabilities catalogue on 2026-05-01, with a remediation date of 2026-05-15 for covered organisations. Microsoft also lists Azure Linux 3.0 kernel updates for the CVE. That mix matters for cloud teams: this is not remote access by itself, but it is a strong second step after web RCE, stolen SSH credentials, malicious CI code or a container escape primitive.

Attack-plane analysis

This CVE sits on ATT&CK T1068, Exploitation for Privilege Escalation. The affected code is in the Linux kernel, so the detection plane is endpoint telemetry from the host rather than cloud-control-plane audit logs. The rule reads Linux auditd events for the socket syscall and looks for address family 38, which is AF_ALG. That is the earliest reliable auditd-visible signal in the public exploit path. The later bind to an algif_aead transform and the splice() call carry the exploit detail, but default auditd records do not usually preserve the sockaddr_alg payload in a way a portable Sigma rule can match.

The choice is intentionally narrow. A generic privilege-escalation rule would be poor evidence for Copy Fail because many Linux LPEs never touch the kernel crypto API. Earlier CloudSigma output made that mistake by looking for ptrace and kernel module loading. The canonical rule avoids those branches and instead keys on the AF_ALG socket creation that starts this exploit family. It then filters known crypto users: cryptsetup, veritysetup, integritysetup, the libkcapi tools, strongSwan components and chronyd. That makes the rule useful for shared hosts, self-hosted CI runners, Kubernetes nodes and user-code sandboxes where AF_ALG use by an unknown process deserves review.

The rule

CloudSigma's canonical rule detects AF_ALG socket creation by non-crypto tooling. It is a behavioural rule, not proof that the page-cache overwrite has completed. Treat it as an early warning that a process is entering the kernel crypto API path used by Copy Fail. On hosts where legitimate AF_ALG consumers exist, tune by executable path and service account in the SIEM, not by broad host-level suppression.

title: AF_ALG Socket Creation by Non-Crypto Tooling (CVE-2026-31431 Copy Fail)
id: cd627699-056b-48e4-97c5-641fa7a2d832
status: stable
description: >
    Detects user-space creation of an AF_ALG socket by a process that
    is not part of the small set of legitimate kernel-crypto-API
    consumers (libkcapi, cryptsetup, strongSwan/charon, ipsec). AF_ALG
    sockets expose the kernel crypto subsystem to user space; the
    family is rarely used outside the listed tools, and the
    CVE-2026-31431 "Copy Fail" exploit chain begins with
    socket(AF_ALG, SOCK_SEQPACKET, 0) followed by bind() of an
    algif_aead transform such as authencesn(...) and a splice() that
    triggers the 4-byte arbitrary page-cache write against readable
    files (typically setuid binaries). Catching the unusual AF_ALG
    socket creation upstream of bind/splice gives the earliest
    auditd-visible signal of the exploit path. Pair this with
    `-a always,exit -F arch=b64 -S socket -F a0=38 -k af_alg` in
    audit.rules so SYSCALL records carry the AF_ALG family value.
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2026-31431
    - https://www.kernel.org/doc/html/latest/crypto/userspace-if.html
    - https://attack.mitre.org/techniques/T1068/
author: CloudSigma
date: 2026-05-03
tags:
    - attack.privilege-escalation
    - attack.t1068
logsource:
    product: linux
    service: auditd
detection:
    selection_af_alg_socket:
        type: SYSCALL
        syscall: socket
        a0: '38'
    filter_known_crypto_tools:
        exe|endswith:
            - /cryptsetup
            - /veritysetup
            - /integritysetup
            - /kcapi-enc
            - /kcapi-dgst
            - /kcapi-hasher
            - /kcapi-rng
            - /kcapi-rsa-test
            - /charon
            - /charon-systemd
            - /swanctl
            - /ipsec
            - /strongswan
            - /chronyd
    condition: selection_af_alg_socket and not filter_known_crypto_tools
falsepositives:
    - Bespoke applications that use the kernel crypto API directly via
      AF_ALG (rare). Baseline by exe path and parent process; if a new
      legitimate consumer appears, extend filter_known_crypto_tools.
    - Distribution-specific crypto helpers not present in the filter
      list. Verify the exe path matches the distro package and add it
      to the filter rather than suppressing the alert.
level: high

The selection_af_alg_socket block does the main work: type: SYSCALL, syscall: socket and a0: '38'. The filter is equally important because several legitimate tools use the kernel crypto API. The rule's false-positive section calls out disk encryption, IPsec and time-sync workflows, which match the allowlist in the detection body. If your audit policy does not record socket calls with a0=38, add the audit rule noted in the Sigma description before judging coverage.

Deployment notes

Patch first. The primary fix is a vendor kernel update that includes the upstream algif_aead change. For systems that cannot patch at once, the Copy Fail guidance describes temporarily blocking the vulnerable module path, for example by preventing algif_aead from loading and unloading it where safe. That mitigation can break real crypto workflows, so test it on the exact host class before using it on production fleets.

For runtime detection, deploy this rule at level: high on Linux servers where untrusted local code can run. Good first targets are self-hosted GitHub Actions and GitLab runners, Jenkins agents, shared build boxes, Kubernetes worker nodes, notebook platforms and sandbox hosts. A hit from a known encryption or VPN daemon should become a tuning item. A hit from a shell, Python process, build job, tenant container runtime or unfamiliar binary should be investigated as possible exploit staging.

Recommended actions

1. Inventory affected kernels against vendor advisories, not only upstream version numbers. Distribution backports can change the answer.
2. Prioritise hosts that run untrusted code: CI runners, developer jump boxes, Kubernetes nodes, notebook services and customer sandboxes.
3. Apply vendor kernel updates and schedule reboots where needed. A patched package sitting unused under /boot does not remove the running-kernel exposure.
4. Where patching is delayed, review whether algif_aead can be blocked without breaking disk encryption, IPsec, testing or compliance tooling.
5. Enable audit coverage for socket(AF_ALG) and deploy the Sigma rule with the allowlist intact.
6. Pair detection with patch-state reporting. The rule tells you that a process entered the risky kernel interface; asset data tells you whether that host was still vulnerable.