On 29 April 2026, a high local privilege escalation vulnerability in the Linux kernel, tracked as CVE-2026-31431 and named “Copy Fail”, was publicly disclosed.
The vulnerability affects every mainstream Linux distributions shipping a kernel built since 2017. A public proof-of-concept exploit has been released.
According to what I know, it’s usable only locally, however any RCE could trigger a PoC for this issue.
I am aware:
-that patch will be delivered by Linux Foundation first, then from the Distro maintainers as updated kernel
-that CentOS 7 is out of support since July 2024
-that should be RedHat responsibility to deliver an eventual (and not expected in any way by me) 3.10 kernel backport of this patch
-that NethServer project is not responsible in any way for this vulnerability
but with more than 20k NethServer 7 I hope to raise awareness for this quite important security issue (7.8 current score) and hoping to trigger some… “nice pressure” to RedHat IBM to deliver some updated 3.10 kernel… backporting this and that.
According to Cert.EU
Temporary Mitigation
Disable the algif_aead kernel module persistently on all affected systems until a patched kernel is available:
This workaround does not affect dm-crypt/LUKS, kTLS, IPsec/XFRM, OpenSSL, GnuTLS, NSS, or SSH. It may affect applications explicitly configured to use the afalg engine or that bind aead/skcipher/hash sockets directly. Exposure can be assessed with lsof | grep AF_ALG.
I did not test this workaround and I’m not suggesting nor implying that might be suitable for CentOS7/NS7 in any way.
More sources of info
Take time to read informations, opinions and in any case, before taking any step, backup your current installation.
It seems (according to lsmod) the algif_aead kernel module is not loaded by default (stock) NS8, and not even present at all according to locate on the NS8 filesystem.
Unfortunately is pretty pointless delivering NS8 kernel version to community.
Being sort of distro agnostic, kernel version and release is delegated to the distro maintainer (Rocky Linux or Debian) therefore could be different among installations. I don’t remember which is the distro of your installation, but I’d guess Rocky Linux due to “el9” into the name. I reconnect it to RHEL9.
When it will be released a patched kernel from the distro mantainer, in few days will be marked to update the installation.
Things are different on NS7: there’s no installation that’s not CentOS7.
Hi, I don’t currently have a Rocky system available to test on, but on AlmaLinux 9 I believe the module is compiled directly into the kernel, so it does not show up in lsmod.
I can find it with something like:
It is a temporary fix and once a new kernel with the final fix is shipped and installed via a normal DNF update, the temporary mitigation can easily be undone. The temporary mitigation and undoing both require a reboot tho.
After applying the above mitigation, my system shows indeed the affected module is blocked. Use at your own risk, and read the articles carefully.
Nevertheless, the original question from@pikefor an ‘official answer from Nethesis’ remains.
Trying to adding more details… Apparently the commit that introduced vulnerability is dated 2017, but only on 4.14 version of kernel, or newer.
This mostly reverts commit 72548b093ee3 except for the copying of the associated data.
There is no benefit in operating in-place in algif_aead since the source and destination come from different mappings. Get rid of all the complexity added for in-place operation and just copy the AD directly.
The Linux kernel CVE team has assigned CVE-2026-31431 to this issue.
Affected and fixed versions
Issue introduced in 4.14 with commit
72548b093ee38a6d4f2a19e6ef1948ae05c181f7 and fixed in
6.18.22 with commit
fafe0fa2995a0f7073c1c358d7d3145bcc9aedd8
Issue introduced in 4.14 with commit
72548b093ee38a6d4f2a19e6ef1948ae05c181f7 and fixed in
6.19.12 with commit
ce42ee423e58dffa5ec03524054c9d8bfd4f6237
Issue introduced in 4.14 with commit
72548b093ee38a6d4f2a19e6ef1948ae05c181f7 and fixed in
7.0 with commit
a664bf3d603dc3bdcf9ae47cc21e0daec706d7a5
Probably the subscriptor-only page of RedHad could provide a bit more data.
but I am a peone, not a customer
Currently I don’t know if there’s a list of kernels affected and accept declaration from RH about not being affected.
For NS8, it’s a matter of time for distribution of a fixed kernel.
For NS7, according to RH.
Not affected (because) Vulnerable Code not Present
First, thank you all for sharing information and links about vulnerability CVE-2026-31431 (copy.fail). As explained in the posts above, only NS8 is affected and there are two possible ways to address it:
Update the kernel to a patched release and reboot the system. A patched kernel is currently available for the following distributions: Debian 12 and 13[1], AlmaLinux 9[2].
Apply the mitigation procedure and reboot. This is currently required on the following distributions: Rocky Linux 9 and CentOS Stream 9.
Older versions, NS7 and NS6, aren’t affected.
Mitigation procedure
Until Rocky Linux 9 releases a patched kernel, apply the official Rocky Linux mitigation procedure[3]:
It seems RH has created a fix that yet has to reach downstream Rocky and then Nethesis before a DNF update with the fix(es) are available to NS8. At the time of this writing the fix is not yet available to NS8.
It is true that NS8 remains affected; however, EDIT1 does not apply to NS8 because each rootless application runs under its own Unix user and uses separate image storage[1]. The author’s conclusion is still valid:
That said, I still think rootless containers raise the attack complexity well beyond a one-liner.
We must also consider application code that does not run inside containers, as well as rootful applications.
The attack surface is reduced, but the vulnerability remains.
unless it is later “optimized” to take advantage of the page cache ↩︎
The immediate concern for many is the impact on rootless containers (e.g., Podman). Rootless containers map container UID 0 to an unprivileged host UID using Linux User Namespaces. This inherently limits a container’s ability to escalate privileges to the host root. However, CVE-2026-31431 highlights a critical distinction: the exploit achieves root inside the container, but its actions are still bound by the host’s unprivileged user.
This does NOT mean rootless containers are safe. The critical issue is that rootless containers do not prevent page cache corruption. A malicious process within a rootless container can still corrupt the shared kernel page cache. This means the exploit can break container-to-container isolation on the same host. Imagine a compromised tenant in a multi-tenant Kubernetes cluster or a shared CI/CD runner. They could corrupt shared libraries or binaries in the page cache, potentially impacting other, legitimate containers.
Yes, that’s an important point for rootless containers in general. However, in NS8, rootless container images are not shared among different users or applications. A malicious process inside a rootless container can only corrupt the page cache of files accessible to it, limiting the attack surface to containers of the same application that use the same image layers.
For example, in the Mail app, Postfix and Dovecot share the same base Alpine image. However, that image layer is not shared with other applications using Alpine: they have separate copies with completely different inodes.
The lack of filesystem access optimization for container images generally leads to higher disk usage, but in this case it also provides stronger isolation.
Looking ahead, we may introduce optimizations to allow sharing of container images in order to improve space and I/O performance. However, based on this experience, we will carefully evaluate the impact of such optimizations on isolation requirements.
Hosting, container, virtualization.
Following that path, increase in memory, CPU and disk usage footprint. But also, usually isolation, and not always, security.
And control.
IMO this expecially applies to DBs and for IO throughput: you can’t actually manage memory, CPU or disk instant access for the containers, most of the times the sysadmin for NS8 needs to increase RAM, memory and CPU to keep the container overlord happy. You can manage the container (some of that) but the orchestrator cannot limit ram usage, swap usage, IO and ghz limit or reservation.
Type 1 virtualization also can stack vulnerabilities (software on top of OS, on top of Hypervisor, on top of Hypervisor OS, on top of metal) but if any guest becomes rogue, there is the “shut down option”.
Containers are not unsafe, but a virtualized OS usually is a bit safer.
Looking at the installed base of NS8 globally and the size of the clusters deployed (+90% 1 node clusters) I personally do not recognise the immediate need to implement such a risky change.I would say that IO shoud not be an issue by adding a reletively cheap fysical of virtual server to spread te load across the cluster, instead of opening possible disaster opportunities.
To me it would defy the containerized concept in general.