A third vulnerability has hit the kernel

Posted by NoDistrict1529@reddit | sysadmin | View on Reddit | 99 comments

This is part of the dirtyfrag family, but is different enough to warrant its own CVE.

https://www.bleepingcomputer.com/news/security/new-fragnesia-linux-flaw-lets-attackers-gain-root-privileges/

Known as Fragnasia and tracked as CVE-2026-46300, this security flaw stems from a logic bug in the Linux XFRM ESP-in-TCP subsystem that can enable unprivileged local attackers to gain root privileges by writing arbitrary bytes to the kernel page cache of read-only files.

Immediate patching if you cannot update:

rmmod esp4 esp6 rxrpc
printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.confrmmod esp4 esp6 rxrpc
printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf

[-]

ItsChileNotChili@reddit

If you blacklist and or remove the modules you are mitigated ( assuming you aren’t using IPSec ) for both dirty frag and fragnesia.

Errata is out for RHEL as of the 12th for dirty frag, but fragnesia has not hit repos yet.

[-]

ConstructionSafe2814@reddit

Sure, but we actually still use OpenAFS. So simply disabling the modules is not an option for us.

[-]

ConstructionSafe2814@reddit

Yes very much so. It's not much fun. Working hard to migrate away from it this year.

[-]

Tetha@reddit

After the second CVE in these IPSec modules, we went ahead and went through the kernel modules and blacklisted a whole lot of things, at least on the application servers.

Like, no, my java application server does not need IPSec, Kernel-Crypto-Offloading, Filesystem support from the early 90s, Support for IP via amateur radio (AX.25)....

It's probably not complete, but this is already mitigated on these systems.

[-]

HeKis4@reddit

As long as it works, it works right ?

[-]

reni-chan@reddit

but you need to be logged in as a non-root user first, right?

[-]

FortuneIIIPick@reddit

These aren't remote vulnerabilities, unlike the majority of Windows CVE's.

[-]

Hebrewhammer8d8@reddit

Later guys I'm going to the farm to milk the cows by hand.

[-]

f00l2020@reddit

Linux kernel is on fire. This will be the year of the CVEs. Glad I rolled out the latest kernel updates and disabled the 3 modules noted

[-]

This is going to accelerate moving forward thanks to AI just able to constantly crank through the kernel looking for vulnerabilities. It's actually a good thing they're all getting discovered, so they can be patched

[-]

ItsChileNotChili@reddit

I agree to a point. All of these were found by human researchers.

[-]

Turbulent_Fig_9354@reddit

Of the CopyFail vulnerability:

Theori’s AI-powered penetration testing platform, Xint, discovered the local privilege-escalation flaw in a Linux kernel module and reported it to the Linux kernel security team March 23. Major Linux distributions affected by the vulnerability had issued patches prior to Theori’s disclosure, which it published alongside a proof-of-concept exploit.

from this article: https://cyberscoop.com/copy-fail-linux-vulnerability-artificial-intelligence/

[-]

ItsChileNotChili@reddit

How We Found It

Taeyang Lee's earlier kernelCTF work had mapped out the AF_ALG attack surface. He realized that AF_ALG + splice creates a path where unprivileged userspace can feed page cache pages directly into the crypto subsystem and suspected that scatterlist page provenance may be an underexplored source of vulnerabilities.

Meanwhile, other Theori researchers were running Xint Code and finding critical vulnerabilities in kernel code, including Android drivers and XNU. We were looking to expand this work to Linux, and the crypto subsystem was a natural starting point given our existing knowledge of its internals.

Xint Code supports an "operator prompt" which (optionally) allows a human operator to provide additional context to guide the automated scan. In this case, the operator prompt was quite simple:

This is the linux crypto/ subsystem. Please examine all codepaths reachable from userspace syscalls. Note one key observation: splice() can deliver page-cache references of read-only files (including setuid binaries) to crypto TX scatterlists.”

From: https://xint.io/blog/copy-fail-linux-distributions

The researcher knew the bug, he just used AI to map the paths. And xint is trying to sell their tooling.

[-]

Turbulent_Fig_9354@reddit

I mean I suppose at some point it's just a matter of semantics how much you want to say "AI found this". Maybe it's inaccurate for me to describe it as "AI cranking through the code" but I think my main point still stands which is AI is without a doubt accelerating the pace as which these bugs are discovered and will continue to accelerate that pace into the future.

[-]

axonxorz@reddit

semantics

True, but you wouldn't say "ghidra found this exploit", you would say "I used ghidra to explore and assess this exploit"

Saying "AI did it" is a bit of a self-own imo.

[-]

Ssakaa@reddit

To be fair to them, the tool validated the finding, I suspect.

[-]

tenekev@reddit

I imagine all of them use AI to accelerate their work. It just frees a lot of time to focus on the problem at hand.

[-]

Trakeen@reddit

Security companies will sell ai powered remediation

We patched copyfail but i’ve not seen anything internal about these newer CVEs

[-]

ItsChileNotChili@reddit

Dirtyfrag patches went out the 12th for RHEL:

https://access.redhat.com/errata/RHSA-2026:16061

I haven’t seen if Ubuntu has anything yet.

Fragnesia still has no patches.

[-]

Standard-Potential-6@reddit

Ubuntu still doesn’t have anything for either.

[-]

swiftb3@reddit

Yeah, AI if used by a subject matter expert is an incredible tool they would be idiots not to use.

[-]

HeKis4@reddit

Yes and no. For the kernel this is good as they have so many eyes on it ready to fix them, but with smaller projects, irresponsible disclosure like copyfail creates a lot of work on teams that are often already understaffed. Especially since, for every 10 vulnerabilities discovered by AI, 9 and a half are hallucinated or unexploitable and that adds to issue triage.

As always, LLMs are tools that need to be handled responsibly but go tell that to everyone and their dog that became a cybersecurity consultant overnight.

[-]

mrbiggbrain@reddit

Yea problems in daylight might cause panic. But problems in the dark of night cause crisis.

[-]

AverageCowboyCentaur@reddit

Palo alto used Mythic and released a shitload of patches for most of there fleet. They are actively breaking there stuff looking for faults before the bad actors do, pretty commendable and being open about it as well.

[-]

spin81@reddit

It's good that they're getting discovered, but not great that they leak before the patch comes out.

[-]

ozzie286@reddit

Yeah, these are vulnerabilities that we're just finding out about, but we'll never know how many people knew about them before now.

[-]

ocdtrekkie@reddit

Eh, I think the Linux kernel will be growing up a bit this year, but I don't see it as end of the world. Your primary folks at risk are people running cloud services where someone else is running untrusted code on their machines, so cloud providers need to be exceptionally on top of it.

The world still runs a significant amount of business in "organizations that just make every employee an admin account".

[-]

uzlonewolf@reddit

I'm just mad The Man himself absolutely refused a patch that would have allow admins to disable module auto-loading while still allowing them to be manually loaded. Would have been great for applications like servers where things like hot-plug aren't really needed.

[-]

Ziegelphilie@reddit

Not just Linux, everything else too. Firefox had 20x as much security fixes last month compared to the usual amount: https://hacks.mozilla.org/2026/05/behind-the-scenes-hardening-firefox/

[-]

Darkblitz9@reddit

It's because the hats are tasking AI with finding vulnerabilities.

It's both good and bad. We find more vulnerabilities but we can also fix them faster or before others are aware. Overall security should (hopefully) increase.

[-]

DNGRDINGO@reddit

Simply remove the kernal entirely, no issues then.

[-]

whamra@reddit

Remove all users and use single user mode. No more worries.

[-]

TaxHazyShade@reddit

from the article: "..gain root privileges by writing arbitrary bytes to the kernel page cache of read-only files."

so ... evidently "read-only files" are not ... read-only? If you can write bytes to them in cache? I'm new to this so probably missing something.

[-]

dasunt@reddit

The final form of distroless containers!

[-]

HeKis4@reddit

Why use kernel when stone tablet do trick

[-]

jbourne71@reddit

r/ShittySysadmin leaking

[-]

Cooleb09@reddit

Nah, those guys are actually self-aware.

This is more like /r/cybersecurity leaking.

[-]

Inquisitive_idiot@reddit

Ze mind Ken not operate withzout ze boot.xyz

[-]

alextbrown4@reddit

Ah I see you’re using the Anton model

[-]

Inquisitive_idiot@reddit

I told Linus to not get that damn standing desk. 😕

It was all downhill from there.

[-]

AGsec@reddit

I like my computer scientists old, cranky, hunched over, and preferably a smoker. These new computer scientists and their healthy habits...

[-]

SenTedStevens@reddit

I don't trust a Linux admin who isn't a morbidly obese chainsmoker with a huge beard.

[-]

Sure_Stranger_6466@reddit

If you are not vaping during the interview can you really call yourself a hiring manager?

[-]

throbbin___hood@reddit

😂😂😂

[-]

Techops837@reddit

sudo rm -rf /*

that should do it!

[-]

brekfist@reddit

Intel agencies losing backdoor!

[-]

Cormacolinde@reddit

There’s this old joke that thr NSA designed IPSEC/IKE to be so complicated to implement and use in order to discourage usage or allow them to bresk it more easily due to misconfigurations or implementation mistakes.

Sometimes I actually believe it.

[-]

spin81@reddit

I don't know about IPSec or IKE, but it's known that the NSA designed a backdoor in DES by coming up with a specific constant in the implementation, so now if you have a constant in your algorithm that looks funny, you have to explain why you chose it or it won't be just the constant that looks funny to the cryptographic community.

https://en.wikipedia.org/wiki/Nothing-up-my-sleeve_number#Counterexamples

[-]

AuroraFireflash@reddit

but it's known that the NSA designed a backdoor in DES by coming up with a specific constant in the implementation

Straight from your link. NSA strengthened DES back in the day.

The Data Encryption Standard (DES) has constants that were given out by NSA. They turned out to be far from random, but instead made the algorithm resilient against differential cryptanalysis, a method not publicly known at the time.

[-]

spin81@reddit

Oh shit. I knew the NSA had put a backdoor in something and I didn't read it properly so thought it was DES. Thank you for calling me out!

[-]

AuroraFireflash@reddit

We think they did back when elliptical curves were becoming the next thing. From your same link, the next item below what I quoted.

Dual_EC_DRBG, a NIST-recommended cryptographic pseudo-random bit generator, came under criticism in 2007 because constants recommended for use in the algorithm could have been selected in a way that would permit their author to predict future outputs given a sample of past generated values

[-]

hak8or@reddit

That agency took the "trust us" angle for the constants by not properly explaining it. The crypto community took a "trust but verify", the nsa didn't give enough information to verify, so the crypto community rightfully so rejected it's adoption.

[-]

PJBthefirst@reddit

There's this great paper that covers how dire this problem is: https://eprint.iacr.org/2014/571

Basically, there's so many different combinations of "natural looking" constants + which curve to use for ECC, that it becomes very feasible to cover your tracks if you want to create a standard with a backdoor in it

[-]

Cormacolinde@reddit

And there is of course the DUAL EC DRBG pseudo-RNG the NSA pushed for inclusion in CPUs, routers and firewalls. Which they set the “magic constants” to values allowing them to predict the values it returned.

[-]

ciabattabing16@reddit

I'm sure they have some tools in the OS of every flavor, but they most definitely are in the hardware/chipsets and aren't subjected to loss of service from anything done at the OS or software level.

[-]

ipsirc@reddit

Finally, I can use all my computers, even the ones where I’ve forgotten my root passwords over the years. Congrats!

[-]

Awkward-Candle-4977@reddit

You just need to mount the storage in other Linux machine then edit the /etc/passwd

[-]

uzlonewolf@reddit

Wait, is your system from like 1992? Because passwords have been stored in /etc/shadow for decades now.

[-]

Awkward-Candle-4977@reddit

That's what I meant

[-]

theschizopost@reddit

I unironically did use this to reset a password in a rpi I had misplaced

Much more convient than refreshing/editing files on the SD card on another computer!

[-]

JoePatowski@reddit

gonna keep screaming this from the rooftops, but i’m not sure why you guys are not live patching your kernel. there is vendor support tools like ksplice and kpatch but kernelcare does it for all distros, which has helped us with our mix of ol7, al2, and c7 boxes. they had this patched yesterday. no reboots which has been wonderful

at this point if you’re still patching these cves manually, you deserve the headache.

[-]

badaccount99@reddit

We have a pipeline for upgrades to images using Packer and our CI process. Patching isn't the hard part. Going through the QA process is. We've got like 50 different homegrown apps/sites my team supports, many on different system images, and fast-tracking updates to all of them is a real PITA.

Live patching will absolutely not fly at a larger or even medium-sized org if you want to keep your job. Our stuff goes through two environments and tested by different people before it can go to prod.

[-]

Sinsilenc@reddit

Man i hate it when i get kernels stuck in my teeth...

[-]

Gullible-Surround486@reddit

We blacklisted the kmods last week and updated kernel, hopefully dirtyfrag mitigation overlaps this one too. this family is getting old fast.

[-]

Comfortable-Joke-970@reddit

I wonder how many serious buisnesses considering moving to bsd from linux these days

[-]

AuroraFireflash@reddit

Few, if any. Much smaller ecosystem. Linux is the known quantity.

[-]

Quantitation@reddit

Aside from OpenBSD, I doubt there is any serious advantage to be gained. The more eyes on any given project, the more vulnerabilities will be found. There are probably dozens of AI models scanning the Linux source tree at any given moment, I doubt that's the same for BSD.

[-]

segagamer@reddit

I knew once Linux got "mainstream" this would start picking up frequency lol

[-]

W3tTaint@reddit

This shit is getting real old

[-]

AuroraFireflash@reddit

Eh, tale as old as time. Defense in depth. Patch your shit.

[-]

antiduh@reddit

It's been this way for 30 years.

[-]

W3tTaint@reddit

I bet you were totally patching zero days in 1996 ...

[-]

Moontoya@reddit

Yup on unix systems and mainframes too

AS/400 , McDonnel Douglas PICC, StraTegGIX, , Novell SupportPak/NLM updates, DECCs, Solaris boxes etc.

oh dont forget SP1 & 2 for NT4 in 96

Grognards exist, go troll/shitpost elsewhere, I care little for those who hide their post history, it always indicates something TO hide.

[-]

antiduh@reddit

Not back then, I didn't really get into sysadmin till college in 2000.

But also, you can't patch a 0-day because by definition a 0-day is a vuln that has no patched released yet. "The software dev has had zero days to fix it since the bug was found."

[-]

Cyhawk@reddit

Yes, did you not subscribe to the kernel security (and similar) mailing lists? We were indeed patching zero days in 1996ish.

[-]

ozzie286@reddit

With floppy disks, a crt monitor, and a kvm switch with a big knob that went ker-thunk every time you switched inputs.

[-]

Irythros@reddit

Already old at not even a week.

Guess I'm just ancient bedrock at this point.

[-]