Copy Fail — 732 Bytes to Root any Linux distribution shipped since 2017
Posted by scottchiefbaker@reddit | linuxadmin | View on Reddit | 73 comments
Posted by scottchiefbaker@reddit | linuxadmin | View on Reddit | 73 comments
deeseearr@reddit
"CVE-2026-31431" if you're one of those people who would rather actual know what the problem is instead of seeing the fancy logo and press-release-friendly name. There are several detailed discussions of the exact flaw that was exploited and it was found by a human researcher who knew what they were looking for -- This isn't an AI doomsday bug.
The issue was fixed about a month ago. Patch your stuff.
rmullins_reddit@reddit
It might be fixed at that level but its not in vendor patches yet. both redhat and AWS Linux both show no fix yet as of this comment.
libertyprivate@reddit
Block the kmod and call it a day?
your_mind_aches@reddit
Do you have a pastable command?
libertyprivate@reddit
It was released as the workaround in the official release
rmullins_reddit@reddit
Note that this command doesn't work on redhat because its a builtin module.
Redhat has released a separate mitigation that requires a kernel bootline argument. Details are on their cve listing.
libertyprivate@reddit
You're right, thank you. It should work on aws tho
your_mind_aches@reddit
Wait so, it wouldn't work on Fedora either, right?
mlrhazi@reddit
hmmm I just did yum update on a RHEL8 server and the python script still works after that! so not fixed yet?
deeseearr@reddit
I usually check with the vendor instead. Saves a lot of time that way.
https://access.redhat.com/security/cve/cve-2026-31431
mlrhazi@reddit
so not fixed.
mlrhazi@reddit
to clarify, am saying that when you say:
> The issue was fixed about a month ago. Patch your stuff.
Well... not really! how do I fix my stuff? replace vendor provided kernel with my own?
RetroGrid_io@reddit
Sonny boy, I come from a time where this was normal and expected. Are you saying that you have never recompiled a kernel?!?
your_mind_aches@reddit
Yes, uphill in the snow, I know. But I don't know how to do that, so it's not really relevant.
dataexception@reddit
See above. Do you pay for the license, which includes security patches and maintenance? If not, RHEL 8 was EOL a few years ago.
If not, then... Why are you on RHEL 8? That's like still being on Windows Server 2012R2 (in MS server terms).
BirkirFreyr@reddit
This is just blatantly false.
RHEL 8 isn’t EOL until 2029 iirc, its still actively getting security patches without any special licensing. Its just out of its active feature update phase, so until its actually EOL it will only receive security update maintenance, albeit mostly only for stuff RH deems worthy enough to warrant one, but that kind of also applies for 9 or even 10 if we’re being honest with ourselves
dataexception@reddit
Sir, this is true only if you have a paid license, whether it's individual or enterprise. If you do not pay for entitlement support, you do not receive those updates.
mlrhazi@reddit
Why are you assuming anyone is not on a paid license?
dataexception@reddit
It's an assumption, you're right, and I don't mean anything negative by suggesting it. My personal account is just a developer license, and they're a pain in the ass.
I started using Red Hat in the 90s when Red Hat 2 had just been released. Not the much later version, but like original Linux where everything fit comfortably on a half empty CD, which even included all packages ,source code, and documentation.
I think IBM buying them was the worst thing for the open source community, which has only been a continuous trend with other companies like Broadcom/VMWare scooping up other OSS, community driven projects like Saltstack and monetizing them to corporate American thieves.
Fuck that. 🖕🏻
But, since I happen to work for a corporate entity, and have for a very long time, I am familiar with our contracts and the support options and limitations contained within them.
No judgement, but just saying that they will assume no legal liability unless they are receiving their protection dues.
kentrak@reddit
There's no reason for anyone to be running RHEL without a license. Multiple re-spins exist, some with binary compatibility (e.g. Alma linux).
That said, even if you weren't paying for a license, you can still get the source RPMs and build your own packages, so the support lifetime still matters for original RHEL, even if there's more steps to it.
The real answer to the question is that RHEL has not ported the patch from the newest kernel source to the kernels they are releasing for their products yet. Full stop, no need to get into how they charge for updates, or anything else, which is all just confusing the issue. This is easy to see if you check their errata page for this CVE at https://access.redhat.com/security/cve/cve-2026-31431.
dataexception@reddit
Thank you for clarifying the actual problem. I was trying to make one point, when I was an arm length away, and not quite grasping what the actual underlying issue was. Granted, a bit on the defensive from a few sophomoric greenies who feel that having a dual boot system qualifies them as an expert. When you children finish your Red Hat System Administration II (RH134) studies, maybe I'll answer your questions. Until then, you really might want to check yourselves.
And for fucks sake, close your profiles down a little bit. Fucking "n00bs". You don't seem to realize that we're the ones who wrote the commands you think you're so "31337" on. ;-*
BirkirFreyr@reddit
Last i checked (tbf i havent looked at licensing since the centos exodus) If you have RHEL as an enterprise, you have at least the barebones standard license.
If you are running on dev license, then you should already be on 10 anyway or go for 1 of the rhel derivatives, which are also still receiving said updates
dataexception@reddit
Exactly this. There's no reason to be on an earlier dev license, and again, nothing against that, when there are newer, supported releases available. The alternative options lack no functionality, like Alma <-- (my favorite), or Rocky. I think the CentOS Stream releases are maybe even still available, but I honestly haven't looked for some time.
The newest Linux kernels provide an amazing boost in performance compared to the older ones, so you're only depriving yourself by holding off on an upgrade.
mlrhazi@reddit
hmmm... the document you shared, from redhat, says only RHEL 6 and 7 are NOT affected. 8, 9 and 10 are affected, and there is not fix as of yet. No ?
deeseearr@reddit
Which is why blindly applying updates and hoping for the best isn't the best way to know that you're covered.
If your vendor hasn't gotten around to packaging the fixed kernel which was available to them last month that's their problem. It doesn't mean that a fix doesn't exist, and it also doesn't mean that you can't easily prevent exploitation by blacklisting the algif_aead module.
Typing "yum update" and praying won't tell you that. Reading the vendor statement, the CVE description and the references will.
dataexception@reddit
Considering I have shared no documents, I can't say that I know what you are referring to.
I'm just saying that RHEL 8 is generally out of support, and with an enterprise OS (now that IBM owns them), I wouldn't expect much if you only have a developer license like I do.
mlrhazi@reddit
hmm.. not sure what happened here. maybe you injected yourself in my reply to someone else? or I replied to you accidentally?
sorry either way. My understanding so far is that redhat did not fix this issue for any version at all. it does not matter whether you are paying them or not.
dataexception@reddit
No worries, man. Apparently I touched a nerve on a few others, though.
Just for the record, I am a Senior Operating Systems analyst with over 25 years of professional experience at Enterprise level. I can provide our organization's dedicated Red Hat team's sales representative contact information, if they want. I'm sure she'd be happy to incessantly call you back until you answered. 😆
Hotshot55@reddit
You sound like a twat.
Red Hat docs say it's not patched yet. You might want to check if your sales guy is just saying yes to anything you ask.
dataexception@reddit
I'm sorry that I come off that way. I haven't claimed anything saying that they have. I honestly don't know if they have or haven't. Most of our workload has been migrated to AL2023, but still have about 100 on-prem and legacy lift and shift migration projects that haven't been, so yeah, we still have a lot of licenses to maintain for the next 2-3 years.
I appreciate the feedback, and will try to hold back when someone starts spewing contrived bullshit in the future.
Friendly little sub you kids have here.
ult_avatar@reddit
you can apparently rmmod the offending module
egbur@reddit
that's not a fix, the module can be loaded again. And in RHEL-based distros it's likely builtin so the only way to disable it entirely is via kernel boot args
ult_avatar@reddit
you can write a .conf file into modprobe.d
for any module, that disables it completly
egbur@reddit
not if the module is builtin
dataexception@reddit
Isn't full RHEL 8 out of support since 2024? Do you currently pay the license fees for support entitlement? If so, then you should be covered until 2029, and get in touch with support.
FluffyIrritation@reddit
the Maintenance Support phase continues until May 31, 2029. The final minor release, RHEL 8.10, is supported with security patches and bug fixes until this 2029 date.
dataexception@reddit
Correct. That is the maintenance support (security /bugfix only)I was referring to for licensed subscriptions. Full support (app updates, kernel and feature enhancements etc) ended in 2024.
OZCriticalThinker@reddit
Wrong on almost everything.
"CVE-2026-31431". Congratulations. That's a huge help for people that can't read the same text in OP's picture, or bother to click the link.
The detailed discussion you linked is super helpful too. It saves people clicking OP's link and then clicking the same link you posted under "read the write-up". Massive time saver, and now they can bypass the summary that explains it quickly and easily. /s
But you're right, it was, 'fixed' according to your definition a month ago.
I'll just politely disagree on what constitutes 'fix'.
It was identified over a month ago in late March. It was promptly disclosed to Linux. A commit was made within days by Herbert Xu (Red Hat) to Linus' git, but that's not the same as rolling out that fix to all the Linux distro's.
It's now been publicly disclosed in past 24 hours more than a month later, and sys admins are only now scrambling to patch their systems. Only some distros with rolling kernel updates have been patched. Vast majority of systems have not been 'fixed' as you put it.
It was also discovered using AI by Taeyang Lee who was looking for an exploit. Like pretty much every use of AI, it was initiated by a human. Have not heard anyone called this AI doomsday bug or imply as much, so not sure you're point. What this does do is emphasis how powerful AI can be at finding exploits and how vulnerable Linux systems are (as with any OS).
Excellent advice though, patch your stuff. Anything else you want to add though?
You know, maybe acknowledge this is a massive backdoor into any system that any script kiddie can run in a few seconds with zero skill and gain root on almost every Linux server and desktop out there, had they known about it, or been following this exploit since March/April (you know, like hackers and intelligence agencies do).
But it's okay, you ran a quick patch to stop future exploitation of this vulnerability. I'm sure no-one got into your systems before then right? No need to audit anything? Just go on assuming everything's fine. You'd make a good sys admin.
deeseearr@reddit
That's nice, dear.
samamanjaro@reddit
lol typical dismissive and flippant comment
Wartz@reddit
Basically some "AI first security team" is trying to drum up marketing for themselves by memeing on an already fixed bug that doesn't necessarily cause much stir, as high level as it is.
Its fucking stupid. I hate the AI world.
Hotshot55@reddit
^Only ^Applies ^To ^Rolling ^Releases
glhaynes@reddit
Would’ve come in handy a few weeks ago when I locked myself out of root on one of my systems lol
dataexception@reddit
Glad I'm not the only one who has resorted to similar techniques when in a bind 😆
za72@reddit
mount the filesystem on another instance and edit the /etc/shadow
AtlanticPortal@reddit
Assuming you have physical control there are multiple ways to elevate privileges. Mount the disk on another OS, change the root password or add another user with id 0.
bobj33@reddit
I tried it on my update to date Fedora 43 systems and it didn't work. I tried it on an old Fedora 37 VM and it instantly gave me a root shell.
petra303@reddit
I tried it and it didn’t work on a rocky 9.x box.
egbur@reddit
because your python version is too old, but the demo code is just one of many ways to trigger the exploit
Hotshot55@reddit
Need python3.10 minimum.
scottchiefbaker@reddit (OP)
I tested it on a fully upgraded Rocky 10.x box and it worked.
GoodForTheTongue@reddit
Can someone be more specific than the news release's vague "every distro since 2017 is vulnerable"?? Does that mean, say, a RHEL 7 system installed in 2014, but then updated every year through 2020 (when updates stopped), would be vulnerable or not?
Basically, are we talking about the date of the base version of the kernel - or the latest version?
(in my example, RHEL 7.0 shipped with 3.10.0-123 but is now at 3.10.0-1160, if you've updated all the way to RHEL 7.9).
kai_ekael@reddit
Debian: only Trixie unless you run backported linux-image in prior:
https://security-tracker.debian.org/tracker/CVE-2026-31431
scottchiefbaker@reddit (OP)
"If your kernel was built between 2017 and [one month ago], you're in scope"
Bloodshot025@reddit
A mitigation is provided by openwall:
Essentially disables the module in question, which is normally automatically loaded in when a socket is requested.
throwaway234f32423df@reddit
you have to run
rmmod algif_aead(or reboot) after that because the module is probably already loaded, at least it was on my systemsBloodshot025@reddit
Yes; though it wasn't for me since I apparently don't have any service that uses it
FluffyIrritation@reddit
Be careful - If you are running a RHEL distro, you do use it. It's built in instead of a module.
If you run the PoC, it'll work.
You have to blacklist the module in grub to prevent it from being loaded. A modprobe.d file will not prevent it.
initcall_blacklist=algif_aead_init
Bloodshot025@reddit
Important note, yeah. Debian ships it as a module, in
linux-modules.zenfridge@reddit
I have gotten the impression this really requires a local user (e.g. shell), but realistically, couldn't this be leveraged remotely - e.g. leverage public website to read a remote script and run (e.g. php exec), apache (user) goes through the motions, now has root to do other things?
(yes, there might be additional security/mitigations in place to stop things like remote reads, uploads, etc., I'm just talking theoretically)
derprondo@reddit
For remote it would require a way to execute code, so combined with a remote exploit against a non-root user you could achieve root and presumably spawn a reverse shell.
hornetjockey@reddit
Yup, just tried it and it is scary how quick and easy that was.
geolaw@reddit
Rhel 14.3??? There's no such thing
qordita@reddit
I guess we're in the clear, we only have 9 and 10 in use.
geolaw@reddit
I was simply commenting about their "rhel 14.1" window in their example video - appears they have since fixed it to be RHEL 10.1 - I validated this this morning in a VM.
https://access.redhat.com/solutions/7141931
I updated to the latest RHEL 10 kernel :
and can confirm it still gets to root
Nelmers@reddit
Banks be like “told you suckers”
nethack47@reddit
Having a bit of finance experience. You’ll have some that will have to stop the CentOS6/7 upgrade program while they figure things out. And others will need an out of band patch panic this weekend.
This weekend will require a lot of pizza everywhere.
kai_ekael@reddit
"Major distributions" includes Ubuntu but not Debian, yet Ubuntu is based on Debian. That seem right to you?
-- Jubal Early
ThisIsProbablyFine1@reddit
This doesn’t work on any modernish kernels right
scottchiefbaker@reddit (OP)
"If your kernel was built between 2017 and [one month ago], you're in scope"
hijinks@reddit
it does.. it doesn't work on old kernels
DeviousFeline@reddit
Just saw this, uh oh lol
ipsirc@reddit
https://www.reactiongifs.com/r/2013/03/3.gif