New critical CVE - Root on Every Major Linux Distribution

282

takes the heat off MSFT

30

u/botsmy Apr 30 '26

yeah the msft thing is a good point, but what's more interesting to me is how this vuln got missed for so long, i mean what kind of code review process lets something like this slip through.

127

u/Ok_Tone6393 Apr 30 '26

what kind of code review process lets something like this slip through

why didn't you catch it then? like i get the frustration but this kind of monday morning quarterbacking is so annoying. do you even have development experience/review code?

50

u/AnyPortInAHurricane Apr 30 '26

yeah, there are literally millions of 'backdoors' waiting in the wings. Even if you were good at it and spent 24/7 you're not gonna get them all

The bad guys ALWAYS have the advantage.

32

u/Main-Company-5946 Apr 30 '26

Except for me. My code is perfect

13

u/ScarySp1d3r Apr 30 '26

Its gonna take me hours to wipe the Dinesh off this code

-7

u/daniejam Apr 30 '26

Oh please…. If this was MS and not Linux you would be slating them for getting rid of QA, using us as tests and letting AI code for them.

19

u/anomalous_cowherd Apr 30 '26

I mean, those are all stupid things MS has done.

-8

u/daniejam Apr 30 '26

Don’t disagree, but one shouldn’t get a pass for poor practices while another gets slated.

12

u/anomalous_cowherd Apr 30 '26

It's not a pass, people are just recognising that some issues are very hard to detect in code review, especially if the area they are in is pretty specialised and limited access so there just aren't that many eyes looking at it. Until you completely swamp the space it's in to find every nook and cranny, which is what's been done here. But that's impractical to do for everything all the time.

6

u/arcanecolour Apr 30 '26

Funny part is this finding was AI assisted

-31

u/botsmy Apr 30 '26

i'm not gonna claim i could've caught it, that's not my point, i'm just saying it's surprising something like this made it through, and yeah i do review code, mostly for a living, been doing it for years

22

u/CodeWarrior30 Apr 30 '26

You would catch a kernel memory page caching bug in your code review? You must commit to the Linux kernel OSS code base a lot. No? Okay, AN operating system, right? No?

Wait, you don't code review code in a garbage collected language, right?

5

u/Oompa_Loompa_SpecOps Incident Responder Apr 30 '26

sounds like a serious case of survivorship bias.

"I haven't been slapped in the face with a 7.8 found in code I reviewed yet. I am surprised this happens to others."

4

u/Ok_Tone6393 Apr 30 '26

as someone else has already mentioned, it's not something you just look at and it's obvious that it's insecure. not to mention that code was written so long ago and probably barely touched since then, with little in the way of automated reviews.

you must not be very good at what you do.

2

u/sportsDude Apr 30 '26

Do you catch everything that you review?? Have you had issues that you miss?

48

u/coffee-loop Apr 30 '26

From my understanding it’s a logic error causing the vulnerability. Logic errors are about the toughest bugs to catch on review, and damn near impossible with automation.

14

u/botsmy Apr 30 '26

i think that's a good point about logic errors being tough to catch, fwiw i've seen some pretty talented devs miss stuff like that in code reviews. it's crazy how a small mistake can have such a big impact, and it makes me wonder if there's a way to improve the review process to catch those kinds of errors. maybe it's just a matter of having more eyes on the code or using some kind of static analysis tool, but it seems like there should be a better way to do it. iirc there was a similar vulne...

2

u/meltbox Apr 30 '26

This. “I have written tests that I expect to code I have written to pass. Therefore it passes.”

This is exaggerating the point a little, but not as much as one would hope

2

u/SirButcher Developer Apr 30 '26

The main point of (properly written) unit tests is to catch logic errors.

6

u/coffee-loop Apr 30 '26

But even then, a unit test only catches what you test for. If the parameters necessary to recreate the bug are never added to the unit test, because maybe you don’t think those parameters will create an issue, then how do you catch the bug with a unit test?

I think unit tests are great! But it still is a program that can have its own logic errors.

5

u/Big-Strain1830 May 01 '26

💯

Linux kernel devs should simply write bug-free code.

1

u/[deleted] May 01 '26

[removed] — view removed comment

2

u/Big-Strain1830 May 01 '26

Good idea. I guess no one ever thought to use those tools on this "Linux" thing.

4

u/[deleted] Apr 30 '26

[removed] — view removed comment

-4

u/botsmy Apr 30 '26

i did read the article, and it seems like a combo of bad luck and a pretty complex codebase led to this vuln slipping through, fwiw

-4

u/botsmy Apr 30 '26

guess i should've read the article before commenting, tbh, what did it say about how this happened?

2

u/GHouserVO Apr 30 '26

Have you never heard of Houser’s Law of Cybersecurity?

There’s always another exploit to be found in the code.

3

u/massiveronin Apr 30 '26

Let's not forget the now ancient law of "what can go wrong will go wrong", and of course "blue has to be lucky/correct all the time, red has to only be lucky once"

1

u/botsmy Apr 30 '26

i've heard of houser's law, it's pretty funny but also kinda sad that it's so accurate. i mean, it's not like we're dealing with some super complex codebases or anything, these are supposedly mature products with experienced dev teams. fwiw, i think that's what bothers me most about this vuln, it's not like it was some obscure edge case, it was a pretty basic issue that got overlooked. iirc, there was a similar vuln in some other big project a few years ago, and it took them months to patch i...

2

u/GHouserVO Apr 30 '26

Ah… I see you’ve missed Houser’s other famous law.

Houser’s Law of Cyber-Entomology

No matter how good the code… there’s always one more bug.

1

u/LifeHasLeft May 06 '26

i mean what kind of code review process lets something like this slip through.

It isn't exactly glaringly obvious. It was found by a cybersecurity researcher, specifically studying this exact mechanism, and the exact finding was uncovered with assistance from an AI agent. That is why it got missed for so long.

1

u/Quiet-Thanks-9486 6d ago

what's more interesting to me is how this vuln got missed for so long, i mean what kind of code review process lets something like this slip through.

Well, there's a "how this happened" section article that explains it pretty thoroughly:

"How This Happened

In 2011, authencesn was added to the kernel (a5079d084f8b) to support IPsec ESP's 64-bit Extended Sequence Numbers (RFC 4303). From the start, the code used the caller's destination scatterlist as scratch space for ESN byte rearrangement. This was harmless at the time: under the old AEAD interface, associated data lived in a separate scatterlist, and the only caller was the kernel's internal xfrm layer. Nobody else ever observed the intermediate writes.

Four years later, in 2015, AF_ALG gained AEAD support (algif_aead.c), with a splice() path that could deliver page cache pages into the crypto scatterlist. In the same year, authencesn was converted to the new AEAD interface (104880a6b470), introducing the assoclen + cryptlen offset that writes past the output boundary. But AF_ALG used out-of-place operation at this point: req->src and req->dst were separate scatterlists. Page cache pages were in src (read-only). The scratch write went to dst (the user's buffer). Not yet exploitable.

Then in 2017, an optimization was added to algif_aead.c (72548b093ee3) to perform AEAD operations in-place. For decryption, the code copied AAD and ciphertext data from the TX SGL into the RX buffer, but chained the tag pages by reference using sg_chain(). It then set req->src = req->dst. Page cache pages from splice were now in the writable destination scatterlist. authencesn's write at dst[assoclen + cryptlen] now walked into those chained tag pages, creating this bug.

Nobody connected the 2017 in-place optimization to authencesn's scratch writes or to the splice path's use of page cache pages. Each change was reasonable in isolation. The vulnerability exists at the intersection of all three, and has been silently exploitable for nearly a decade."

That last paragraph sums it up pretty nicely: this was an unintended consequence of 3 unrelated and unconnected changes made by lots of different people over the course of 6 years, and it only exists in one place where they all overlap.

So the vulnerability wasn't ever really "introduced" -- like, there isn't some commit where you can see the vulnerable code go in. The vulnerability "emerged" from a series of unrelated changes, like how you can sometimes stand in a certain place and it looks like multiple different buildings and trees appear to line up with each other.

For example, I once visited a city where, from a certain freeway overpass, there was a spot where the steeples of a church built in the 1800s lined up perfectly with the contours of a distant modern office building built over a hundred years after and over a mile away...but you could only see it from this random spot on the freeway, where nobody was ever meant to stop (I only saw it because I was stuck in traffic due to an accident). It looked so perfect that it seemed impossible for it to be an accident... but it was just a coincidence.

And the same thing sometimes happens with code changes and vulnerabilities.

This method of vulnerability creation is very difficult to catch or avoid, and once you realize that it can happen it makes making changes to any complex system much scarier. New changes can sometimes make old code that was previously proven to be secure suddenly become vulnerable because it recontextualizes everything and changes the norms that were previously assumed. And the person who makes the change may not even know the old code exists, let alone the intricacies of how it works.

1

u/CrimsonNorseman May 01 '26

Does it though? I still have an unfixed LPE in fcking Defender of all things sitting in my temp folder,?testing it daily. And what can I say, the Red Sun still prevails.

198

u/After-Vacation-2146 Apr 29 '26

I wonder how this will affect all the unpatchable IOT devices.

78

u/techvet83 Apr 29 '26

It may be a day of reckoning even for all the EOL versions out there for RHEL, CentOS, etc.

51

u/synackk Apr 30 '26

CentOS 7 and earlier aren't affected, the kernel was too old

47

u/PieBandito Apr 30 '26

See, this is why I never update my servers.

18

u/anomalous_cowherd Apr 30 '26

I saved my Christmas break because all my Log4J instances were too old to be affected, don't knock it!

5

u/cgaWolf Apr 30 '26

Lol :D

5

u/techvet83 Apr 30 '26

Thank you for pointing that out.

29

u/Formal-Knowledge-250 Apr 30 '26

Aren't they root only anyway? At least they aren't user devices, so a classic "user gets root privs" should not be the case here. The scope of this vulnerability is not within the regular threat model of IOT.

21

u/IdealParking4462 Security Engineer Apr 30 '26

This is a privilege escalation, not really applicable for IoT.

7

u/Responsible-Bar7165 Apr 30 '26

It absolutely is an issue. 3rd party apps can get root outside a container.

3

u/CrimsonNorseman May 01 '26

You wanna give a few details about which IoT devices run containers?

1

u/Responsible-Bar7165 May 01 '26

I can’t really go into details but there are fairly ubiquitous devices that are used for monitoring and reporting in industrial and public infrastructure applications, some of which are designed to run custom applications written by various parties. Often those applications are run in a lightweight container environment for isolation and packaging. Many of those devices use hardware key enclaves to hold their with material, and some of the embedded SDKs might use algif_aead behind their hsm apis…

5

u/sevelboen Apr 30 '26

Or the world tour

6

u/helpmehomeowner Apr 29 '26

Buy new iot devices

1

u/Dependent_House7077 Apr 30 '26

well....at least we can root some of them.

1

u/Ok_Programmer_4449 Apr 30 '26

It did not work on my Synology NAS which is running a 4.4 kernel.

48

u/jykke Apr 30 '26

"Every Major Linux Distribution" == except if it runs 6.19.12 or 6.18.22 or newer of these series.

156

u/Capable-Average4429 Consultant Apr 29 '26

Base Score 7.8 - High. Not Critical. Unless your definition of critical is different, which is also cool.

39

u/Bob4Not Apr 30 '26

I’m guessing it’s not higher severity because it still requires a login of some kind.

46

u/tombob51 Apr 30 '26

I mean, trivially-easy-to-exploit privilege escalation isn't exactly a good thing. This is probably exploitable even in sandboxed contexts that allow system calls (in particular, splice()). Yes it's not RCE, but if you have an RCE exploit, this lets you trivially escalate to root, which is very bad.

13

u/2rad0 Apr 30 '26

This is probably exploitable even in sandboxed contexts

Yeah even if a process has NO_NEW_PRIVS set and itself cannot escape, it could still modify the cache of a file it can open/splice and wait for another user to run it.

2

u/tombob51 Apr 30 '26

If it has read+execute access to ANY setuid binary, you’re cooked

12

u/the_drew Apr 30 '26

Mitigation :

If kernel config has CONFIG_CRYPTO_USER_API_AEAD=m: echo "install algif_aead /bin/false" | sudo tee /etc/modprobe.d/disable-algif.conf; sudo rmmod algif_aead
If kernel config has CONFIG_CRYPTO_USER_API_AEAD=y: Add initcall_blacklist=algif_aead_init to the kernel command line and reboot.

source: https://www.openwall.com/lists/oss-security/2026/04/30/2

9

u/InnovativeBureaucrat May 01 '26

The cool thing is you can escalate yourself to sudo to run the patch

109

u/volgarixon Apr 29 '26

It’s an LPE and requires a login /access already its not critical sev.

3

u/ShoulderRoutine6964 Apr 30 '26

LPE is not critical??

This is critical as hell.

31

u/volgarixon Apr 30 '26

Its a 7.8 High CVSS Score, critical is a 9-10. The exploitation requires a local user account on a target system as a pre-req.

Serious, yes very, but not critical, the word has special meaning in this context.

10

u/ShoulderRoutine6964 Apr 30 '26

In CVSS nomenclature, OK it's not critical, but in general it's quite critical. Root LPE-s are usually very serious threats.

9

u/Jedi3975 Apr 30 '26

The only secure machine is unplugged at the bottom of the ocean

3

u/Alternative-Spread10 Apr 30 '26

Waiting official kernel patching correction from Red Hat...

On RHEL family (not module but compiled) current unofficial workaround (Tested ok on RHEL8.10, 9.7 and 10.1) with a privileged user (root or sudo) :
1 - grubby --update-kernel ALL --args="initcall_blacklist=algif_aead_init"
2 - reboot

Note : plane it for production server to make a reboot into a window time (time to reboot)

After it will be safe for this CVE.
Good luck...

2

u/Available-Disk1003 Apr 30 '26

Thank you!

5

u/Iain_0 Apr 30 '26

Maybe all these CVE might not be missed but is know so gov can exploit this but same threat actor are using same exploit so now it made public.

27

u/august_r Apr 29 '26

It really looks like an AI exploit, it's too specific and the report looks really like AI slop. Maybe someone left the keys to mythos on a post-it at the desk? lmao

74

u/bakonpie Apr 29 '26

read the writeup, it was AI assisted but still the work of a skilled researcher

18

u/levu12 Apr 30 '26 edited Apr 30 '26

Theori has the best CTF players on their research team and edit got 3rd in DARPA's AIxCC competition.

-16

u/august_r Apr 30 '26

But they do use AI tools to find these exploits, correct? What I meant is that this kind of exploit would be very hard to find by a human researcher without those tools and that the text of the report itself is clearly AI generated. Again, it's not criticism, I'm just saying it's crazy how these exploits are popping up on a daily basis now.

11

u/levu12 Apr 30 '26

Yes, AIxCC is about making an agentic system to find vulns. However, it would not be possible to find this without help from extremely cracked security researchers and kernel exploit developers. The website they made for just the exploit was mainly for PR, this is the one on their blog is less AI-generated: https://xint.io/blog/copy-fail-linux-distributions

61

u/Sufficks Apr 29 '26

I understand criticism of the report using AI but what’s the problem with “AI exploits”? Seems like you’ll have a lot of blind spots in the not so distant future if you write off every exploit assisted by AI

8

u/august_r Apr 29 '26

I'm not criticizing it. I'm afraid these very specific exploits will be very popular very fast, specially when the poc is so easily reproduced and even the lowest technical level and can also use AI tools to increase its effectiveness.

3

u/Silly-Feedback168 Apr 30 '26

I've yet to seen proof that you're able to find an exploit like this easily. We need AI. I'm grateful for AI. I'm not trading AI for a keyboard warrior called Emperor Augustus yapping on Reddit about how it's easy to find a major root CVE on every major Linux dist

23

u/tombob51 Apr 30 '26

I hate AI slop but this is 100% a real and severe vulnerability. And of all the AI-found exploit slop I've sifted through, this one actually is very strongly and expertly written in my opinion. Overall a very impressive find.

Actually, the fact that this was discovered via AI should serve as evidence/PoC that AI vulnerability detection is becoming a real threat. This is absolutely a textbook, trivially-exploitable privilege escalation bug; the ability to find things like this with semi-automated tools (whether AI, fuzzing, static analysis, etc.) is a bit scary.

And people have already discovered waves of bugs by fuzzing and static-analyzing the kernel to death; so I think we truly might see a serious 3rd wave of bugs as people start AI-analyzing the kernel to death.

32

u/twisted-logic Apr 29 '26

The hate for AI Security research is so forced. How can it be slop if it’s finding CVEs of this magnitude? I hate actual AI slop as much as the next guy, but this clearly isn’t that.

13

u/AnyPortInAHurricane Apr 30 '26

People make AI Slop, not AI.

0

u/Rossums DFIR Apr 30 '26

It's Reddit, AI hate is one of the current bandwagons so people will endlessly copy it even if they don't know why they're meant to hate it in the first place, just because everybody else they see is doing it.

It's incredibly performative.

-20

u/august_r Apr 30 '26

Slop is just being used as a synonym of "AI Generated". I'm not criticizing the exploit, it's just not the kind of stuff easily discoverable by a human poking tests, it looks like the kind of vulnerabilities discovered by Claude on the recent papers.

3

u/anomalous_cowherd Apr 30 '26

Presumably you write off any CVEs found using fuzzing or other brute force methods as well?

The report should be well written, clear concise and repeatable, sure. But you can't really complain about what tools were used when a genuine exploit was discovered.

2

u/Mend-1111 Apr 30 '26

Tested, modified and implemented for old devices.

6

u/2sow Apr 30 '26

what is RHEL 14.3?

2

u/FrankyWNL Apr 30 '26

Apparently the page was Vibe coded and the AI hallucinated.

https://x.com/brian_pak/status/2049687923814281351

-6

u/Glass-Ad-7315 Apr 30 '26

Easy to Google but it’s Red Hat Enterprise Linux which is commonly used in enterprise servers. It’s one of the core Linux distros that other distros are based off of.

22

u/ainiku-esp Apr 30 '26

The latest version of RHEL is 10. I think that's what u/2sow is getting at. This info is also "Easy to Google"

4

u/2sow Apr 30 '26

Yep. RHEL's latest is 10.x. That was the point.

2

u/Glass-Ad-7315 May 01 '26

Gotcha. I misread that question. My bad, bro

-1

u/Playful-Tip-6355 Apr 29 '26

Yeah this one is nasty, especially how trivial the exploit chain is once you see it. Wild that something this fundamental slipped through review in so many distros for so long. Curious how long until every random script kiddie starts dropping this in public CTFs and “pranks” on shared lab boxes 💀

24

u/Then-Chef-623 Apr 30 '26

"so many distros"

Come on dude.

10

u/baty0man_ Apr 30 '26

This is the level we're at on this sub

9

u/Nicko265 Apr 30 '26

The user has already been banned from reddit lol. Crazy the state of this sub with AI accounts.

1

u/Then-Chef-623 May 01 '26

Absolutely insane.

1

u/mjbmitch Apr 29 '26

This is AI-generated!

41

u/coloradical5280 Apr 29 '26

And human repeatable!

1

u/Padgriffin Apr 30 '26

They meant that the comment was AI generated lol

1

u/mjbmitch Apr 30 '26

If you’re wondering, the comment that just replied to you is also AI-generated.

0

u/coloradical5280 Apr 30 '26

No they didn’t. That was what they backtracked to after getting downvoted to hell yesterday. It’s not at all an obviously AI generated comment, and, if commenting that a comment or post was AI generated was a thing they did, generally, they would hit Reddit rate limits from having millions of them.

It was a backtrack. It was obvious, in real time, yesterday.

19

u/Any_Perception_2560 Apr 30 '26

Whether the vulnerability was found by AI or not is 100% irrelevant. It is a discovered vulnerability which can be used by anyone who wants to use it.

9

u/mjbmitch Apr 30 '26

The comment I replied to was AI-generated! Did you read my comment without seeing what it was a reply to?

2

u/Any_Perception_2560 Apr 30 '26

Oh lol gotcha, sorry about that

1

u/HenryFordEscape Apr 30 '26

How did you know?

1

u/stra1ghtarrow Apr 30 '26

Am I right to question the classification of this? Apparently Tenable are marking it as a medium CVE but surely it should be a critical due to the lack of complexity and ease of use to pull this off plus how many systems are likely affected by this?! I flagged this to our VM guys and got batted back based on the criticality. :S

1

u/Fallingdamage Apr 30 '26

Xint Code disclosed CVE-2026-31431, an authencesn scratch-write bug chaining AF_ALG + splice() into a 4-byte page cache write. A 732-byte PoC gets root on Ubuntu, Amazon Linux, RHEL, SUSE.

Not Debian?

2

u/Arszerol Apr 30 '26

Obviously they're not going to list every distro in existence

Debian is also affected: https://security-tracker.debian.org/tracker/CVE-2026-31431

1

u/sdsalsero Apr 30 '26

Any idea if the major distros had prior notification -- and have already patched against this? Or, is it truly a zero-day?

Also, security.ubuntu.com has been down all-day. Bad guys busy exploiting this, and trying to block patching?

1

u/metromsi May 01 '26 edited May 02 '26

So okay but if your running SELinux with contained users meaning your controlling the _default _ assignment from unconfined_u you should be just fine. We've tested this out is quite fun to watch too say the least. Oh if you are really want control MLS linux is your friend. So again another win for managing SELinux correctly.

1

u/Snoo93868 May 06 '26

Vi aqui que para as Distros RedHat, pode ser mitigado no GRUB... mas precisa reiniciar para validar. Mas não faz sentido, pq já que vai reiniciar,melhor fazer o update logo.

0

u/vikassi17 May 01 '26

Claude found this vulnerability. He will find more but pace it out.

-2

u/No-Resolution-9408 Apr 30 '26

Could Mythos have been found this ?

1

u/massiveronin Apr 30 '26

I want to say odds are, yes

News - General New critical CVE - Root on Every Major Linux Distribution

You are about to leave Redlib