On 29 April 2026 a local privilege escalation in the Linux kernel’s AF_ALG AEAD socket code (algif_aead) was disclosed: CVE-2026-31431, nicknamed Copy Fail. LWN’s stable kernel announcement the next day told all users to upgrade. If you run Linux hosts, VMs or Proxmox nodes where anyone or anything untrusted can run code, patch it.
What the bug is
algif_aead is the kernel module behind AEAD ciphers in the AF_ALG interface, which lets user space use the kernel’s crypto API through sockets. A 2017 change (commit 72548b093ee3) made it operate in place. Public analyses describe the result: by combining an AF_ALG operation with splice(), an unprivileged local user can write a few bytes into page-cache pages of files they can only read, for example a setuid binary, and get root. The fix, “crypto: algif_aead - Revert to operating out-of-place”, undoes that optimisation.
It’s a local bug: an attacker needs to run code on the machine. On a homelab that means shared machines, services that run untrusted code, and containers. Ubuntu notes it may also help container escapes, although no such exploit was published.
Am I affected?
Affected: kernels from 4.14 up to the fixed versions. Fixed upstream in:
| Kernel series | Fixed in |
|---|---|
| 5.10 | 5.10.254 |
| 5.15 | 5.15.204 |
| 6.1 | 6.1.170 |
| 6.6 | 6.6.137 |
| 6.12 | 6.12.85 |
| 6.18 | 6.18.22 |
| 6.19 | 6.19.12 |
| mainline | 7.0 |
Distribution kernels backport fixes under their own version numbers, so compare against your distro’s advisory, not just upstream numbers:
- Debian:
https://security-tracker.debian.org/tracker/CVE-2026-31431 - Ubuntu: fixes were released for 14.04 through 25.10. 26.04 is not affected, according to Ubuntu’s post.
- Fedora/RHEL:
dnf updateinfo list --securityand Red Hat’s CVE page
Check your running kernel and whether the module is loaded:
uname -r
grep -qE '^algif_aead ' /proc/modules && echo "algif_aead loaded" || echo "algif_aead not loaded"
A module that isn’t loaded can still be auto-loaded when a program opens an AF_ALG AEAD socket, so “not loaded” doesn’t mean “safe”.
Patch
# Debian / Ubuntu
sudo apt update && sudo apt full-upgrade
# Fedora / RHEL / Rocky / Alma
sudo dnf upgrade --refresh
# Arch
sudo pacman -Syu
Then reboot: a new kernel package does nothing until you boot into it. Afterwards, uname -r should show the new version.
Proxmox VE
Proxmox ships its own kernel packages (proxmox-kernel-* on current releases):
apt update && apt dist-upgrade
proxmox-boot-tool kernel list # newest installed kernel is the default unless one is pinned
Migrate or shut down guests before rebooting a node. In a cluster, do one node at a time and check pvecm status (and ha-manager status if you use HA) before moving on. If you once pinned a kernel with proxmox-boot-tool kernel pin, unpin it, or the node keeps booting the old one.
Mitigation until you can reboot
Ubuntu’s published mitigation blocks the module:
echo "install algif_aead /bin/false" | sudo tee /etc/modprobe.d/manual-disable-algif_aead.conf
sudo rmmod algif_aead 2>/dev/null
Caveats:
- It only works if
algif_aeadis a module. Check withgrep CONFIG_CRYPTO_USER_API_AEAD /boot/config-$(uname -r):=mis a module,=yis built-in and can’t be blocked this way. - Programs that use AF_ALG AEAD lose it. Ubuntu warns about performance loss where there’s no fallback, and running applications may need a restart.
- For individual systemd services,
RestrictAddressFamilies=~AF_ALGin the unit stops that service from opening AF_ALG sockets at all.
Remove the modprobe file once you’ve booted a fixed kernel, and patch as soon as you can.
What’s Next
- Proxmox VE Homelab Setup: Complete Installation and Configuration Guide (2026): Lock down your Proxmox environment beyond the defaults
- Linux Homelab Security Hardening: Complete Checklist (2026): Firewall, SSH and the rest of the host baseline this patch sits on top of
- Mitigating 400+ Linux Kernel CVEs in Your Homelab: Triage, scanning, and the reboot problem this CVE runs into
- Ansible for Homelabbers: Automate From One Playbook: Roll the same patch across every host instead of SSHing into each one
[discussion]
Comments are powered by Giscus — backed by GitHub Discussions. Sign in with GitHub to join the conversation.