Another Vulunerabilty found in Kernel: "Fragnesia" a variant of Dirty Frag vulnerability in the ESP/XFRM

[ajgringo619]

(From the Manjaro forums)

[ALERT] CopyFail 3.0 - Fragnesia - Unpatched vulnerability

[r0ckhopper]

bad things come in threes - Wiktionary, the free dictionary

[Archie1]

Thanks to @dirn to point this out.

“Fragnesia” is a variant of Dirty Frag vulnerability in the ESP/XFRM. CVE-2026-46300 is the id used to track this. How this functions is

It writes a small position-independent ELF stub (setresuid/setresgid/execve /bin/sh) over the first 192 bytes of /usr/bin/su in the page cache, then calls execve(“/usr/bin/su”) to obtain a root shell. The page cache modification is not backed to disk; the on-disk binary is untouched.

So it takes /usr/bin/su in RAM, Modifies its first 192 bytes, executes it and gets privilege escalation. Since the file, /usr/bin/su, on the disk is not modified, all of this happens in RAM, an Host based file system monitoring solution will not catch the exploit. This exploit uses page-cache corruption vulnerability.

It does not require user interaction, so without user doing anything this can be triggered from a service or from a timer or from any thing else.

[Archie1]

The mitigation for this remains the same as that for dirty-frag. Stop the loading of ESP4, ESP6 and XFRM modules. Put the following in the directory /etc/modprobe.d/ inside a .conf file.

install esp4 /bin/false
install esp6 /bin/false
install rxrpc /bin/false

blacklist esp4
blacklist esp6
blacklist rxrpc

I wonder if this has been patched or not.

[Archie1]

From the OSS-mailing list,

This vulnerability is a path that was accidentally activated after the introduction of f4c50a4034e6 (2026-05-05), the patch for CVE-2026-43284 in the Dirty Frag chain.

Does this mean that Fragnesia was accidentally activated because of the fix for the Dirty-Frag, i.e. CVE-2026-43284? Or am I misunderstanding this?

Continuing in the same email-chain

Exploitation requires the attacker to have permission to create user namespaces, unless chained with a separate vulnerability.

So disabling username space will mitigate the attack vector? It is time for a bottom up re-write of namespaces in Linux Kernel. And it is also time for Firefox and other apps to stop using namespaces.

From the same email-chain

At least for the time being, I recommend keeping the Dirty Frag mitigation in place:

So despite dirty-frag being fixed should the mitigation remain in place. The folks at VPN Service providers are not going to be happy.

Some kernel developers are getting annoyed

I understand that the realistic utility of embargoes is currently shrinking dramatically, but this “drop it while it’s hot” approach to seemingly promote yet another AI vulnerability discovery service is a trend I can’t abide.

[SCORPION2000]

Wow Microsoft(and others I’m sure) is pushing hard in Linux smear campaign

This and all does DoS attacks .

[Archie1]

Well the question still stands. Has this been patched? Does the dirty-frag vulnerability fix also patch this up?

Or do we have to wait for another Linux Kernel update?

[MyNameIsRichard]

It looks like it hasn’t been patched yet, because they’re not following responsible disclosure of waiting 90 days. They must really be desperate.

[Bink]

The mitigation for Fragnesia appears to be the same as that for Dirty Frag.

Another vulnerability that gives root access: dirty-frag (FIXED with Linux kernel 7.0.5 Update)

This is the mitigation being shared by most sources: Mitigation Because the responsible disclosure schedule and the embargo have been broken, no patch exists for any distribution. Use the following command to remove the modules in which the vulnerabilities occur. sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true" Once each distribution backports a patch, update accordingly. …

If you’re not needing IPSec (sorry @Archie1 ), or using the Andrew File System (AFS), I suspect you could simply leave these modules disabled…

[Archie1]

but this “drop it while it’s hot” approach to seemingly promote yet another AI vulnerability discovery service is a trend I can’t abide.

Oh I dont envy being in Linux Kernel developer shoes. Windows and Mac OSX gets a pass since they have closed source code. So no one is aware of the vulnerabilities that are there inside Windows.

[ExDebianuser]

I just added this to my blacklist.conf…

[Scotty_Trees]

I’ll just wait for a new kernel update just like the last couple times this happened.

[autofire]

New kernel 7.0.7 just dropped; might be a Fragnesia fix, but it broke my laptop’s internal bluetooth.

[drunkenvicar]

these bug names lately have been hot and sexy.

Just sayin.

[rich52]

Just installed 7.0.7 kernel. . . . I’ll have to check and see if my bluethooth is still working. . .

Rich

[Scotty_Trees]

@autofire @rich52 Just booted up 7.0.7 and bluetooth is still working on my Acer laptop.

[rich52]

I’ve gone through the bluetooth help in the ‘Welcome’ app. I’ve gotten my ‘Smokin Buds’ to work a few times in the past but more often than not they disconnect or can’t be found again during pairing. Right now I have conflicts with the bluetooth being ‘enabled’ and ‘not enabled’ in several different place locations in the KDE plasma software. This is particularly strange in my opinion. In some area’s it is enabled and others not enabled. . . . It’s pretty much screwed up. When these earphones worked in the past they were great and worked like a charm . . . .now they don’t work once again. I’m currently running kernel 7.0.7 - 2-1 arch.

Rich

[autofire]

Who made your laptop’s bluetooth module? Mine is from Mediatek, and I did see that 7.0.7 touched Mediatek bluetooth driver code…

[HBR]

7.0.8.arch1-1 / 7.0.8-zen1-1-zen fixes this for Mediatek BT.

Arch mainterners picked a pending patch from upstream.

[Archie1]

Why is a fix for Fragnesia and dirty-frag updating code of Bluetooth? Or did the Bluetooth code just hop a ride with this fix.