Copy Fail — 732 Bytes to Root any Linux distribution shipped since 2017

[-]

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

how do I fix my stuff? replace vendor provided kernel with my own?

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

install <module_name> /bin/true

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

The issue was fixed about a month ago. Patch your stuff.

^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:

echo "install algif_aead /bin/false" | sudo tee /etc/modprobe.d/disable-algif.conf

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 systems

[-]

Bloodshot025@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.

[glaw@localhost ~]$ chmod +x exp
[glaw@localhost ~]$ ./exp
[   79.121757] alg: No test for authencesn(hmac(sha256),cbc(aes)) (authencesn(hmac(sha256-avx2),cbc-aes-aesni))
[   79.134426] process 'su' launched '/bin/sh' with NULL argv: empty string added
[root@localhost glaw]# uname -a
Linux localhost.localdomain 6.12.0-55.9.1.el10_0.x86_64 #1 SMP PREEMPT_DYNAMIC Tue Mar 25 09:14:09 EDT 2025 x86_64 GNU/Linux
[root@localhost glaw]#

https://access.redhat.com/solutions/7141931

I updated to the latest RHEL 10 kernel :

Linux localhost.localdomain 6.12.0-124.52.1.el10_1.x86_64 #1 SMP PREEMPT_DYNAMIC Sat Apr 11 20:17:08 EDT 2026 x86_64 GNU/Linux

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"

[-]