Whonix Documentation Advanced Documentation Previous page: Whonix Index page: Documentation Next page: Advanced Documentation copy.fail security vulnerability (CVE-2026-31431)

CVE-2026-31431 is a Linux kernel local privilege escalation vulnerability. The main action for most users is to install kernel security updates and reboot into the updated kernel. Advanced users may also review temporary mitigation options and their possible compatibility risks.

Introduction

copy.fail documents CVE-2026-31431, a Linux kernel security vulnerability related to algif_aead and AF_ALG.

In simple terms, this vulnerability can allow code that is already running as a normal local user to become root. It is therefore most important for shared systems, container hosts, CI runners, servers that execute untrusted code, and systems where an attacker might already have limited local code execution.

What it is: CVE-2026-31431 is a Linux kernel local privilege escalation vulnerability.
Main risk: Code that is already running as a normal local user may be able to gain root privileges.
Most important action: Install kernel security updates and reboot into the updated kernel.
Debian stable status: A fixed Linux kernel package is now available for Debian stable trixie through trixie-security. See: Debian Security Tracker: CVE-2026-31431
Higher risk systems: Shared servers, container hosts, CI runners, build systems, and systems that run untrusted code need special attention.
Temporary mitigation caution: Disabling algif_aead may reduce exposure before patching, but it can affect software that uses AF_ALG AEAD functionality.
Relation to Kicksecure: This issue is unspecific to Kicksecure. Kicksecure inherits it because Kicksecure is based on Debian.
Affected Linux distributions: Most mainstream Linux distributions.

If your kernel was built between 2017 and the patch — which covers essentially every mainstream Linux distribution — you're in scope.Copy Fail: official disclosure and mitigation

Help wanted: Yes. See Help Wanted - Contribute.

What users should do

Regular desktop users: Install normal operating system security updates and reboot into the updated kernel.
Debian stable users: A fixed Linux kernel package is now available for Debian stable trixie through trixie-security. Install security updates and reboot after installing the fixed kernel. See: Debian Security Tracker: CVE-2026-31431
Server administrators: Prioritize systems where untrusted users, containers, build jobs, or web services can run code.
Container and CI operators: Treat this as higher risk because containers and CI jobs share the host kernel.
Do not test exploit code casually: Only test proof-of-concept code on systems you own or are authorized to test.

Mitigation

The preferred mitigation is to install a fixed kernel and reboot.

A temporary mitigation has been suggested upstream, but it may affect software that uses AF_ALG AEAD functionality. Users who are unsure should prefer distribution kernel updates over manual kernel feature changes.

Careful with the following:

Patch first. Update your distribution's kernel package to one that includes mainline commit a664bf3d603d - it reverts the 2017 algif_aead in-place optimization, so page-cache pages can no longer end up in the writable destination scatterlist. Most major distributions are shipping the fix now.
Before you can patch: disable the algif_aead module.
# echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf # rmmod algif_aead 2>/dev/null
What does this break? For the vast majority of systems - nothing measurable.

Will not affect: dm-crypt / LUKS, kTLS, IPsec/XFRM, in-kernel TLS, OpenSSL/GnuTLS/NSS default builds, SSH, kernel keyring crypto. These all use the in-kernel crypto API directly - they don't go through AF_ALG.

May affect: userspace specifically configured to use AF_ALG - e.g. OpenSSL with the afalg engine explicitly enabled, some embedded crypto offload paths, or applications that bind aead/skcipher/hash sockets directly. Check with lsof | grep AF_ALG or ss -xa if in doubt.

Performance: AF_ALG is a userspace front door to the kernel crypto API. Disabling it does not slow anything that wasn't already calling it; for the things that were, performance falls back to a normal userspace crypto library, which is what almost everything else already does.
For untrusted workloads (containers, sandboxes, CI), block AF_ALG socket creation via seccomp regardless of patch state.Copy Fail - Mitigation

The following caution explains why the temporary mitigation should not be treated as risk-free:

I'd like to also point out that the copy.fail website may underplay the impact this mitigation has on userspace. It's not the easiest thing in the world to find out everywhere where an AF_ALG socket is opened and then set up in AEAD mode in Debian, but so far I've found that at least bluez, cryptsetup, iwd, and stress-ng contain code that does this, as does a particular test in some Rust code in rustc, firefox-esr, and thunderbird. libkcapi is also a thing, anything that does AEAD with it will be affected. Simply nuking this part of the kernel API from orbit is not a universally safe operation.

(Note that I've not yet made any of these applications misbehave by applying the mitigation, I tried some experiments with cryptsetup and the results were inconclusive. So this might be safe enough for most people.)@arraybolt3 quote Aaron Rainbolt on oss-security

Technical background

This section is intended for advanced users, administrators, developers, and contributors.

Kernel feature involved: The vulnerability involves Linux kernel crypto functionality exposed through AF_ALG.
Relevant module: The temporary mitigation focuses on algif_aead.
Exploit class: This is a local privilege escalation issue, not a normal remote attack by itself.
Container relevance: Containers share the host kernel, so a kernel local privilege escalation can be especially serious on container hosts.
Patch direction: The upstream kernel fix reverts the affected algif_aead in-place behavior so affected page-cache pages can no longer end up in the writable destination scatterlist.

Help Wanted - Contribute

SUID binaries are a long-known security issue.

Ideally, there should be no SUID binaries reachable from the user account, as otherwise significant extra attack surface inside the VM is exposed (dynamic linker, libc startup, portions of Linux kernel including ELF loader, etc.)Quote security researcher Solar Designer

Kicksecure has been working towards making SUID unreachable for non-root user accounts by implementing SUID Disabler and Permission Hardener, which is part of security-misc . However, Kicksecure has not been able to disable all SUID for non-root users yet due to the massive development effort required and converting SUID binaries to Linux capabilities not being a high priority for the wider security community. (Scattered Attention)

Configuration folder security-misc | /usr/lib/permission-hardener.d | raw contains documented whitelists of SUID binaries such as:

fusermount: disabling would break AppImages / Docker
- security-misc | /usr/lib/permission-hardener.d/25_default_whitelist_fuse.conf%23security-misc-shared | raw
pam-tmpdir-helper: disabling would break libpam-tmpdir, which is a security feature.
- security-misc | /usr/lib/permission-hardener.d/25_default_whitelist_pam.conf%23security-misc-shared | raw
Qubes specific: qfile-unpacker
- security-misc | /usr/lib/permission-hardener.d/25_default_whitelist_qubes.conf%23security-misc-shared | raw

To see a list of SUIDs reachable for account user, refer to Search for SUID SGID. At the time of writing, the list of SUID binaries is greatly reduced compared to most other Linux distributions, but unfortunately not zero. Current list:

/usr/libexec/pam-tmpdir/pam-tmpdir-helper /usr/lib/qubes/qfile-unpacker /usr/lib/dbus-1.0/dbus-daemon-launch-helper /usr/bin/qfile-unpacker /usr/bin/fusermount3

What volunteer developers can do:

Work upstream: Contact the upstream projects that ship remaining SUID binaries and propose safer designs.
Convert where possible: Replace SUID use with Linux capabilities where that is technically sufficient and accepted upstream.
Reduce privilege: Where Linux capabilities are not enough, help upstream investigate other privilege separation designs.
Test compatibility: Verify whether removing SUID breaks existing software, and document the exact reason if it does.
Submit patches: Send changes directly to the relevant upstream projects rather than only to Kicksecure.

This work is unspecific to Kicksecure. Therefore, coordination with Kicksecure is appreciated, but not required.

If you do not work on this, probably nobody else will either and SUID will remain a security issue in the future. Converting SUID binaries to safer alternatives will require many more years, if not decades. (Security Mindset of Open Source Software Ecosystem)

Resources

Whonix Documentation Advanced Documentation Previous page: Whonix Index page: Documentation Next page: Advanced Documentation

Kicksecure

A secure by default operating system with the latest security research in place.

Dark mode

Supported by Power Up Privacy

Kicksecure is proudly supported until 2026 by Power Up Privacy, a privacy advocacy group that seeks to supercharge privacy projects with resources so they can complete their mission of making our world a better place. (Strictly subject to our sponsorship policy.)

At Kicksecure we value freedom and trust, supporting Open Source and Freedom Software

By using this website, you acknowledge you have read, understood, and agree to be bound by these agreements: Terms of Service, Privacy Policy, Cookie Policy, E-Sign Consent, DMCA, Imprint

2012- 2026 ENCRYPTED SUPPORT LLC

Your support makes
all the difference!

We believe security software like Kicksecure needs to remain Open Source and independent. Would you help sustain and grow the project? Learn more about our 14 year success story and maybe DONATE!

copy.fail security vulnerability (CVE-2026-31431)

Contents