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

[Archie1]

@TheRaOct

@joekamprad

And i do not recommend to run the one-line-special mentioned.

• https://www.openwall.com/lists/oss-security/2026/05/07/8 ( @archisman already posted that ond)

Is this a typo, i.e. did you mean to say to run this command? If not, could you elaborate why not to run this command? (Or maybe I missed that part in the linked write-ups?)

Yeah I am confused too, Should we not put in the one-line-special mitigation? i.e.

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

[Archie1]

If the modules ESP4, ESP6 and RXRPC are not currently loaded and if the one-line-special vulnerability blockage is introduced then it does require a reboot of the system to take effect.

Please refer to https://github.com/V4bel/dirtyfrag/issues/1
From the discussion

Correct - i can confirm that, exploited hosts / tests the mitigation (removing/disabling esp4 esp6 and rxrpc) do need a reboot.

Just removing the kernel modules without rebooting does not affect already exploited machines (i’m guessing cause of how the exploit works, with overwriting the page-cache for /bin/su).

Sorry for the cross-post.

Still waiting on response from @joekamprad.

[cactux]

The latest stable 7.0.5.1-arch1-1 currently in testing comes with the

[joekamprad]

NOT! test the vulnerability, it could cause exactly what it says.

And i said not run the One-line special ! and best approach is to boot on LTS for the time till the fixed main kernel is reaching repos.

You can use the fix they offer there if you want to.
It is basically making the modules non loadable and unloading them right away. But this is mentione under Mitigation:

GitHub - V4bel/dirtyfrag

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; echo 3 > /proc/sys/vm/drop_caches; true"

/etc/modprobe.d/dirtyfrag.conf

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

If something tries to load one of the modules per example esp4 instead of doing so, it runs the /bin/false command instead of loading the driver/module

• /bin/false: A command that immediately exits with a “failure” status.
• Result: The kernel thinks the module failed to load and stops. The driver is never initialized in memory.

[vazicebon]

@joekamprad

If something tries to load one of the modules per example esp4 instead of doing so, it runs the /bin/false command instead of loading the driver/module

I wonder why they didn’t use the blacklist function, the file would contain :

blacklist esp4
blacklist esp6
blacklist rxrpc

[Archie1]

@vazicebon

@joekamprad

If something tries to load one of the modules per example esp4 instead of doing so, it runs the /bin/false command instead of loading the driver/module

I wonder why they didn’t use the blacklist function, the file would contain :

blacklist esp4
blacklist esp6
blacklist rxrpc

Yeah me wondering the same. blacklist also should have been used. Let us wait for some experts to chime in on this.

[joekamprad]

@vazicebon

blacklist esp4
blacklist esp6
blacklist rxrpc

blacklist prevents the module from loading automatically (e.g., during hardware detection), but it can still be loaded manually or by another module that needs it as a dependency.
like the exploit itself does.

[Archie1]

Will it be possible to add this vulnerability to the news section of pacman for EOS?

[joekamprad]

@Archie1

Will it be possible to add this vulnerability to the news section of pacman for EOS?

possible yes.. but it will be fixed any time soon anyway.

[Archie1]

The Arch forums have no mention about dirty-frag as on right now. Ditto for Cachy-OS. The Manjaro forum also has a pretty good initial post but not that much discussion on this.

The Debian news section has no mention of this. Nor is this being discussed on Debian Forums. Cant say about the Debian mailing list though.

All in all we are perhaps the most active community on this.

[joekamprad]

@Archie1

All in all we are perhaps the most active community on this.

seems correct, could be a cultural thing too

[Archie1]

wdym?

[TheRaOct]

Ah, I thought by One-line special you meant the one line fix/ workaround. Was wondering why I shouldn’t apply that. Thanks for clarifying!

[joekamprad]

i was to much into the format of the writeup on that github file i bet

I have referred directly to the headings to the individual parts, but they are both one-liners of course.

[eZepp]

So the fix is coming with the kernel 7.0.5 ? I’m on Linux 7.0.3-arch1-2, it would be with the next update?

[joekamprad]

the fixed main kernel is still hanging in testing..

[CarlLaFong]

Looks like 7.0.5 has been released finally, if that’s the fixed one

[swh]

7.0.5 is ready to update

The kernel 7.0.5 is the one with the fix for it, so update your systems…

[marteng69]

Already installed and rebooted …