Happy Thanksgiving – and Don’t Panic
Happy Thanksgiving, wherever you may be. May your day be entirely free from Vogon poetry!
Copy Fail was last month’s Linux media story that kept on giving – a seductively-named bug that enabled an elevation of privilege (EoP) attack that worked against many, perhaps even most, Linux distros by default.
Just to be clear: known EoP exploits are important to patch against or to block, because attackers who find a way to break in as a user with low privilege often use them to make a bad thing worse.
Ransomware criminals, for example, often use a remote code execution (RCE) exploit or a purloined password to start with, and then chain to an EoP to increase the amount of damage they can do.
But EoPs generally don’t help attackers with their initial intrusion, so they don’t usually get the high vulnerability scores that exploitable RCE holes do.
The Copy Fail bug was itself inspired by older vulnerabilities dubbed Dirty Cow and Dirty Pipe that exploited Linux kernel bugs in which readable files cached by the kernel could be corrupted while the kernel was processing them.
Indeed, Copy Fail might more reasonably have been named Dirty Crypt or Dirty Setuid, but that wouldn’t have allowed the publishers of the bug to register the domain copy.fail, and thereby to exploit the bug to promote their cybersecurity product.
So it goes, as Kurt Vonnegut might have said.
If you’re a LinkedIn user and you’re not yet following @SolCyber, do so now to keep up with the delightfully useful Amos The Armadillo’s Almanac series. SolCyber’s lovable mascot Amos provides regular, amusing, and easy-to-digest explanations of cybersecurity jargon, from MiTMs and IDSes to DDoSes and RCEs.
Even if you know all the jargon yourself, Amos will help you explain it to colleagues, friends, and family in an unpretentious, unintimidating way.
Bugs, especially bugs that open up exploitable security vulnerabilities, sometimes mirror that famous saying about buses – you don’t see one for a while, then three come along at once.
Well, the nature of Copy Fail, and its relationship to earlier kernel flaws of a similar sort, led (as we surmised when we wrote up the Copy Fail saga on this blog) to researchers looking for other ways to exploit similar vulnerabilities that weren’t yet patched.
These bugs are based around a special kernel system call known as splice() that aims to speed up memory-intensive operations by re-using kernel memory blocks as much as possible to reduce the number of times data gets copied around between buffers in RAM.
The new kid on the splice()-bug block is called Dirty Frag, which comprises two related vulnerabilities and a proof-of-concept program (PoC) that you can use to test whether your own Linux systems are vulnerable.
If you want to track these bugs, they’ve been given the IDs CVE‑2026‑43284 and CVE‑2026‑43500.
Unlike the Copy Fail PoC, the Dirty Frag PoC code will tell you in some detail what it’s doing.
This can be useful if the exploit code fails on your system, because you can then make an informed decision about whether the failure was due to a coding mistake in the exploit code itself (meaning that you might nevertheless be vulnerable), or due to your system configuration being invulnerable already (meaning that you can reassure your users and customers right away).
Unfortunately, just like the Copy Fail case, if the Dirty Frag PoC works, it doesn’t merely print a message to say, “I got root,” and then clean up after itself.
Instead, it boasts about its success by leaving you in a root shell, thus making the PoC into a ready-to-use attack tool, even for non-technical users.
It also leaves its malware-corrupted files behind in the kernel’s cache in memory, thus exposing your system to compromise or misbehavior until the cache eventually gets cleared.
Indeed, if either exploit works, any user (or any script or program) asking for root-level access for the next few minutes or hours will automatically acquire it, even if the workflow of that user or program is supposed to stop and ask for a password at that point.
So it goes, as Kurt Vonnegut might have said.
The first of these new vulnerabilities, CVE‑2026‑43284, is much like Copy Fail.
It tries to poison the su program in memory with a mini-program that uses its superuser privilege to switch to the root account and dump you into a root command prompt – with no password or authentication required.
(The program name su is short for set user ID and run, but it’s more generally known as the superuser program, because it switches by default to the superuser account, better known as root.)
Making your setuid-root programs readable by root only, as we suggested in our Copy Fail explainer, or even readable-by-nobody, blocks this exploit.
That’s because the vulnerability involves acquiring a readable file handle to the victim program, and a writable handle to a network socket that you set up yourself.
Then, while performing booby-trapped encryption or decryption operations to read from the input file and write to the output via the performance-boosting splice() system call mentioned above․․․
․․․four bytes of data wrongly get poked back into the input buffer each time.
This turns a read-only program (one that the system’s security settings are supposed to prevent you from modifying) into file that is writable inside the kernel’s cache.
If you can’t get read access to the setuid-root program you want to target, you can’t corral it into this exploit, so you can’t sneakily poison it with malware this way.
The second vulnerability, CVE‑2026‑43500, exploits a different bug in a kernel module called rxrpc, which provides a way for programs to call into each other via the network (RPC is short for remote procedure call).
This bug seems harder to exploit, because it relies on trying lots of different cryptographic keys for the RxRPC protocol’s packet verification system, hoping to finding one that produces just the right sort of corruption in its input buffer at runtime.
(I couldn’t get it to work on my test installation of Slackware Linux, because the concocted cryptographic keys it generated were rejected by the RxRPC subsystem; I assume, however, that with some effort the exploit could have been made to work.)
The idea behind this attack is to manipulate the cached contents of the passwd file, modifying it in memory to allow root logins with no password.
The passwd file serves as a publicly-visible list of usernames and user IDs on the system, so it is readable by everyone, despite its secret-sounding name, consisting of a series of lines like this:
root:x:0:0::/root:/bin/bash bin:x:1:1:bin:/bin:/bin/false daemon:x:2:2:daemon:/sbin:/bin/false . . . .
The fields on each line are separated by colons, and specify: username; password hash; user ID; group ID; full name or comment (often blank); home directory; and the command shell to use at login, if any.
But world-readable password hashes are a bad idea, because that means anyone can read them out and try cracking them offline, using as many computers as they like to speed up the cracking process until they find a user who has chosen badly.
As seen above, modern Linux systems therefore use a password hash of x to denote that the actual hash is stored in a separate, secure file called /etc/shadow, readable only by the root account:
If the password field is a lower-case
x, then the encrypted password is actually stored in theshadowfile instead; there must be a corresponding line in the/etc/shadowfile, or else the user account is invalid.
Unfortunately, as the documentation for the passwd file continues:
The [password hash] may be empty, in which case no password is required to authenticate as the specified login name.
Loosely speaking, this means that corrupting the cached version of the passwd file so it starts with the text root::0:0:․․․ (with the all-important x character missing) will temporarily switch the root account into “access at will” mode, with no password needed to acquire superuser powers.
That’s what the CVE‑2026‑43500 exploit attempts to do, using a buffer-leakage bug in the aforementioned rxrpc kernel code.
If the cached passwd file is successfully corrupted, not only the attacker who launched the exploit, but also any person, program or script that runs the su program before the cache expires will immediately land in a root command shell.
Even scripts that expect to halt and prompt for a password to prevent them running unexpectedly are likely to find themselves authorized to run automatically, with no user intervention, and no bail-out point.
Note, however, that most Linux distros use a system called PAM (pluggable authentication modules) to manage logins and other authentication-related security verification.
PAM can be configured to prevent logins with no password, thereby overriding automatic access for accounts where a blank password field has been set.
Unfortunately, most distros ship with an initial PAM configuration that permits instant logins with blank passwords (what PAM refers to as nullok), meaning that null passwords work by default.
For advice on how to change this setting, noting that you may have inherited programmatic workflows that depend on null logins, see below.
rxrpc module to fix Dirty Frag and perhaps other latent bugs.CVE‑2026‑43284 PoC code requires read access (though not write access) to a privileged system program to work correctly.rxrpc kernel module to prevent the second vulnerability being exploited. Some Linux distros don’t include this module at all, and are therefore safe by default, but many distros do. Add the line blacklist rxrpc to a file called /etc/modprobe.d/stoprxrpc.conf.system_auth and passwd_auth (usually in the directory /etc/pam.d) and remove references to the option nullok. Without this setting, null logins should be suppressed. Note that some programs, scripts and workflows you rely upon may need modifying to work in this stricter environment.Why not ask how SolCyber can help you do cybersecurity in the most human-friendly way? Don’t get stuck behind an ever-expanding convoy of security tools that leave you at the whim of policies and procedures that are dictated by the tools, even though they don’t suit your IT team, your colleagues, or your customers!
Paul Ducklin is a respected expert with more than 30 years of experience as a programmer, reverser, researcher and educator in the cybersecurity industry. Duck, as he is known, is also a globally respected writer, presenter and podcaster with an unmatched knack for explaining even the most complex technical issues in plain English. Read, learn, enjoy!
Happy Thanksgiving, wherever you may be. May your day be entirely free from Vogon poetry!
2021 was a tumultuous year for cybersecurity and, unfortunately, we saw the effects of successful cybersecurity attacks across major companies and industries. The trends we observed in 2020 largely continued in 2021. Ransomware attacks continued to increase and a few major hacks dominated news media around the world. The Colonial Pipeline attack showed how devastating these ransomware attacks could be, and the immediate impact to supply chains and municipal infrastructures. The aftermath of 2020’s SolarWinds hack was also at the […]
Work ahead for vendors, but not the end of Wi-Fi for the rest of us.
By subscribing you agree to our Privacy Policy and provide consent to receive updates from our company.
