Executive Summary
Recently, two significant Local Privilege Escalation (LPE) vulnerabilities affecting the Linux kernel have been publicly disclosed: Copy Fail (CVE-2026-31431) and Dirty Frag (CVE-2026-43284, CVE-2026-43500). These vulnerabilities allow unprivileged users to gain root access on affected systems by exploiting kernel page cache mechanisms.
We have conducted a thorough internal review of our SERVERware platform. We can confirm to our customers that SERVERware is not vulnerable to either of these exploits. Our purpose-built architecture, custom Gentoo-based environment, and strict access controls provide overlapping layers of defense that inherently neutralize these threats.
Vulnerability Overview
- Copy Fail: CVE-2026-31431 | Exploits the Linux kernel’s cryptographic subsystem (algif_aead) to perform controlled writes into the page cache.
- Dirty Frag: CVE-2026-43284, CVE-2026-43500 | Abuses network and memory-fragment handling (esp4, esp6, rxrpc) to alter cached files.
To understand how our system responds to these exploits, we first need to understand what they are, what they try to achieve, and how they do it.
Local Privilege Escalation (LPE)
Both Copy Fail and Dirty Frag are LPE (Local Privilege Escalation) exploits. What this means is that a user, one who already has remote access to the system, is able to escalate their privileges from a standard unprivileged user to a privileged root user. Becoming a root user is a dangerous scenario. A malicious attacker can perform any kind of change on the filesystem that they desire.
Dirty Page Cache
Now that we’ve answered what these exploits are and what they try to achieve, it’s time to take a look at how they do it. In order to escalate the user privileges, both of these exploits rely on dirtying the filesystem page cache.
Now, what even is a filesystem page cache?
Whenever a file is read for the first time from the disk, the kernel caches (stores) the file contents in the system’s RAM. This is done to optimize performance, since these files usually occupy very small amounts of space. Reading from RAM is significantly faster than reading from the disk, making the system feel snappy. The same thing is performed the other way around. Whenever something is written to a file, the kernel first stores the change in RAM, and later on writes it to the disk in the background.
Although these two vulnerabilities use different kernel modules, they both try to achieve the same goal, which is to overwrite this cache in the memory. They open a specific binary (/usr/bin/su), and attempt to change the contents in the Page Cache from the actual /usr/bin/su code to their own custom script.
Now, why the /usr/bin/su binary?
Even if the attackers overwrite the source code, they are still going to execute this code as a normal user. The su binary is special since it has the setuid bit set. What this means is that the user executing the code of said binary has their privileges escalated to the owner of that file. Since the root user is the owner of all binaries in /usr/bin/, a regular user then starts executing their own source code, with the root user’s privileges. We can now see how this can be a big problem. Essentially, a regular user can perform whatever they want on a system.
Our Layers of Defense
Since both of these vulnerabilities exploit the system in a similar way, we will be looking at them together to see how our defenses stack up against them.
SERVERware relies on a highly customized, stripped-down operating system. The following architectural decisions ensure that our platform remains unaffected by Copy Fail and Dirty Frag.
1. Custom-built Linux Kernel
Unlike general-purpose distributions that compile all kernel modules for maximum hardware and protocol compatibility, the SERVERware kernel is custom-built. Modules strictly unnecessary for our virtualization workloads are entirely omitted from our build configuration, stripping away the vulnerable code paths required by these exploits at the source.
With that in mind, we need to address the following kernel modules, which are exploited by these two vulnerabilities:
Copy Fail (CVE-2026-31431)
The kernel module required to perform this exploit is the algif_aead, which allows userspace applications to utilize the kernel’s internal cryptographic hardware acceleration. Although this module is built with our custom kernel, it is never loaded for use. What this means is that although it exists as a tool, it is locked away, unable to be used. To load this module, the root user would have to do it manually. This defeats the entire purpose of the exploit, which tries to become a root user in the first place. We can determine that Copy Fail is already blocked here from exploiting our system.
Dirty Frag (CVE-2026-43284, CVE-2026-43500)
The kernel modules required to perform this exploit are esp4, esp6, and rxrpc. The esp4 and esp6 modules handle the Encapsulating Security Payload. They are used to perform a controlled 4-byte write. By manipulating the sequence, they are able to perform this write in a part of the memory region that they should not be allowed to.
For an unprivileged user to perform this, they need to be able to create a network namespace. Some distributions (like Ubuntu and Debian) use AppArmor to restrict these activities, which is where the rxrpc module comes in. Since SERVERware doesn’t use AppArmor, we can set aside the rxrpc module.
Going back to the esp4 and esp6 modules, these are once again built with our custom kernel but not loaded by default. However, there is a difference here. These modules are loaded by the kernel on demand. What this means is that a user doesn’t have to have privileges to manually load these modules in. Instead, whenever they call on their functionality, the kernel auto-loads them. This seems like a problem for SERVERware, but due to multiple lines of defense, the platform still isn’t vulnerable. This is addressed below.
2. Gentoo Filesystem and Immutable Properties
SERVERware is distributed as an ISO using the Gentoo Linux distribution. As previously mentioned, the first requirement for these exploits to work is the kernel modules. In our first line of defense, the custom kernel does protect us from the Copy Fail vulnerability, but it fails to protect us from the Dirty Frag exploit.
Our second line of defense is the Gentoo filesystem itself. After having the kernel modules loaded in, these exploits need to fulfill another requirement to perform their work. They need an executable binary on the system, which has the setuid bit set, and which can be read by unprivileged users.
Let’s break this down:
- The setuid bit: What this bit allows on an executable binary is to escalate the privileges of a regular user to the user who is the owner of said file. This is exactly what the exploit is trying to do. There are multiple such binaries on the filesystem required for normal Linux operations. The one attempting to be exploited by Copy Fail and Dirty Frag is the su binary. The su binary allows a user to run a program, or gain a shell, as a different user, with the requirement of knowing the different user’s password.
- The read permissions: This is pretty self-explanatory. Read permissions allow unprivileged (meaning non-root) users to read a file. This is another requirement for these exploits since they need to “open” (read) these files in order to manipulate them.
With all of this in mind, we can conclude that we need a binary which is:
- Executable
- Has the setuid bit been set
- Has read permissions set for other (non-root) users
Taking a look at the /usr/bin/su binary and other binaries in /usr/bin, we can conclude that no such file exists. Although there are multiple binaries with the setuid bit set, like su, passwd, mount, and others, none of them have read permissions enabled for “other” users.
There may exist some binaries in some non-standard paths that can have both the setuid bit set and read permissions for “other” users, but for the standard Gentoo filesystem, we can conclude that it protects our system from these exploits.
3. OpenZFS Storage Backend
If the algif_aead kernel module was somehow loaded ( Copy Fail), or if the esp4 and esp6 modules (Dirty Frag) were loaded on-demand by the kernel. And, if a binary was found by the attacker on our filesystem which has both the setuid bit set and read permissions for “others”, then the final line of defense would be encountered, which is OpenZFS.
SERVERware employs OpenZFS for its robust storage capabilities. OpenZFS implements its own ARC (Adaptive Replacement Cache) rather than relying exclusively on the standard Linux kernel page cache targeted by these specific vulnerabilities. This architectural divergence fundamentally breaks the exploitation chain required by both Copy Fail and Dirty Frag.
What this means is that although these exploits try to dirty the kernel’s page cache, which works for standard filesystems like ext4, it fails to work on OpenZFS since it uses its own cache. Essentially, instead of the kernel using its own cache, it offloads it to ZFS ARC, which is not exploitable in these scenarios.
4. Absence of Multi-User Linux Workloads
Local Privilege Escalation (LPE) inherently requires an unprivileged local user to execute the payload. SERVERware does not operate as a traditional multi-user environment. There are no unprivileged users on the system.
- The environment operates solely with the swadmin administrative user.
- The swadmin user inherently possesses credentials equivalent to root for system management.
- Because there is no unprivileged entry point, an LPE attack is conceptually impossible to initiate from within the host OS context.
Mitigations
Since SERVERware isn’t affected, there is currently no need for any kind of mitigation to be performed. As part of maintaining our ISO, the system will be updated and will be available in the next release.
The combination of our purpose-built kernel, tailored Gentoo filesystem, OpenZFS integration, and single-tenant administrative design ensures that SERVERware remains secure against both the Copy Fail and Dirty Frag vulnerabilities. No immediate action or patching is required by our customers to mitigate these specific threats.