New Root Kernel Bug - Dirty Frag

General
1

Dirty Frag is the name and as of now, all distros are affected and to my knowledge a cve has not been posted.

2

For more context;

I dont see Arch listed there.

Which does not mean it is not affected but ..

The following modules are related (and the current mitigation is to blacklist them);

  • esp4
  • esp6
  • rxrpc

And, at least on my linux-cachyos-bore-lto kernel .. none of those exist.

So not affected and nothing to do. :+1:

3

  • The vulnerability (related reports call it “Dirty Frag” in recent coverage; the underlying issue is the Copy Fail-type kernel bug affecting algif_aead/AF_ALG and some XFRM/IPSec-related code) impacts kernels that include the 2017 in-place optimization and lack the upstream fix. Many mainstream kernels built since 2017 are affected, including kernels used by Arch and Arch-based distributions. Tom’s Hardware1

  • Arch typically ships very new mainline kernels, and upstream fixes have already been committed; however, a running system is only safe once you have an installed patched kernel package and have rebooted into it. Some reports show the PoC worked on updated Arch boxes before reboot/patch propagation. Tom’s Hardware2

Immediate mitigation (apply now):

  1. Check if the vulnerable module is present/loaded:

    • uname -a

    • lsmod | grep -E ‘algif_aead|esp4|esp6|rxrpc’

  2. Temporary module-block (persist across reboots):

    • To block algif_aead (recommended by CERT-EU for Copy Fail): create /etc/modprobe.d/disable-algif.conf containing:

      install algif_aead /bin/false

      then run: rmmod algif_aead 2>/dev/null || true

    • Some vendor write-ups also recommend disabling esp4, esp6, rxrpc as an additional mitigation for related exploits:

      printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.confrmmod esp4 esp6 rxrpc 2>/dev/null || true
4

What is that? Some LLM soup?

Those are specifically the modules needed for this “Dirty Frag” vuln.
Only these modules are detailed for its mitigation, ex;


This is for the related but different “Copy Fail” vuln.

And even with this blacklisted you would still be vulnerable to “Dirty Frag”.

5

Dirtyfrag is not copyfail. Or is it another variant of copyfail? Or is it completely new devastating exploit?

6

The kernel modules don’t have to be loaded into memory.

You can check if they are present on your system with

find /lib/modules/$(uname -r) -name "*.ko.zst" |grep -E "esp4|esp6|rxrpc"

On my system they are present:

/lib/modules/7.1.0-rc2-1-cachyos-rc/kernel/net/ipv4/esp4.ko.zst
/lib/modules/7.1.0-rc2-1-cachyos-rc/kernel/net/ipv4/esp4_offload.ko.zst
/lib/modules/7.1.0-rc2-1-cachyos-rc/kernel/net/ipv6/esp6.ko.zst
/lib/modules/7.1.0-rc2-1-cachyos-rc/kernel/net/ipv6/esp6_offload.ko.zst
/lib/modules/7.1.0-rc2-1-cachyos-rc/kernel/net/rxrpc/rxrpc.ko.zst

AFAIK only Alma Linux has patched kernels yet.

The bug affects multiuser systems with restricted accounts. So singleuser systems should be save. The attacker needs an account on the system to log in localy, via telnet, via ssh, etc. and then can elevate his rights to root with this exploit.

7

Even the mainline Linux kernel itself doesn’t appear to have any patches, as one colleague of mine reported a successful trigger of the exploit on a CachyOS machine running kernel 7.0.3-1-cachyos, and also on an updated Arch box

source: Devastating 'Dirty Frag' exploit leaks out, gives immediate root access on most Linux machines since 2017, no patches available, no warning given — Copy Fail-like vulnerability had its embargo broken | Tom's Hardware

8

same here, just not loaded atm

9

philm of the Manjaro team suggests this temporary mitigation over in their forum:

You can neutralize the attack surface by blacklisting the affected modules. None of esp4, esp6, or rxrpc are loaded on a typical workload that does not use IPsec transport mode or AFS, so on most systems this is safe to apply immediately:

sudo 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"

This writes a modprobe config that prevents the three modules from loading, and unloads them if they happen to be loaded already (the rmmod is best-effort and silent if the module isn’t present). To revert, remove /etc/modprobe.d/dirtyfrag.conf.

The Dirty Frag exploit works by corrupting page-cache pages of sensitive files (such as /etc/passwd or /usr/bin/su). If you suspect the system may have already been targeted before you applied the mitigation, drop the page cache so any tampered pages are evicted and the next read comes fresh from disk:

sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'

This is safe to run on a live system — it only frees clean cache and dentry/inode entries — and pairs well with the blacklist above.

Thanks to philm of the Manjaro team

10

Seems to be fixed.

https://cdn.kernel.org/pub/linux/kernel/v7.x/ChangeLog-7.0.5

11

7.0.5 is only a partial fix, the rxrpc part is missing.

Edit: It looks like Peter patched 7.0.4 like Fedora did. I think the 7.0.4-2 should be fixing it completly.

12

Yeah I know, I dont know why the previous poster attempted to make some statement to the contrary - again I think its just because its some LLM slop so it only has a tenuous grasp on reality.

Thats just phil repeating what was already posted in one of the dozens of links already shared or linked from said links.

But as I mentioned above .. none of hose modules is present on my running kernel.

And for the record thats a slightly old variant that has not been restarted yet (7.0.3-1-cachyos-bore-lto).


To clarify once more .. I was not claiming anything special had been done for our kernels. Simply that the affected modules were not present.

With this we once more have nothing special happening. Just recent kernel changes merged. Nothing extra done by Cachy. But with those updates now if it were affected, then its also been patched against those problems.

13

he showed you the changelog for 7.0.5 which has alredy been shipped by Cachy.

Edit:

What I meant is, Cachy has already shipped 7.0.5-1.1, so I guess it’s going to be 7.0.5-2

14

This was an extremely fast reaction btw. Kudos to the upstream devs and CachyOS.

Does anyone here use one of the immutable distros? I wonder how long it will take to patch and update something like Bazzite

15

Yeah, I was surprised that they distributed 7.0.5 that other distributions refuse to push, because it’s only a partial fix (rxrpc still could be attacked). Fedora added all fixes to 7.0.4 to avoid the confusion that they use a partial fixed kernel, see kernel-7.0.4-200.fc44 - Fedora Packages . But on the other hand people that don’t read the release notes might think that they are still vunerable. In the end it’s only a number and IMHO there always should be an official statement that the problem is fixed in which kernel numbers.

17

In my years on any forum this is a big flaw in my view, here in partictular!

We need to do a better job on notifications for CVE’s

18

Definitely missing an official announcement here from cachy devs, especially from Peter Jung!
Like this one from Manjaro:

Now finally fixed?
https://www.phoronix.com/forums/forum/software/general-linux-open-source/1632339-dirty-frag-vulnerability-made-public-early-root-privilege-on-all-distributions?p=1632864#post1632864

https://cdn.kernel.org/pub/linux/kernel/v7.x/ChangeLog-7.0.6

19

Here is an assessment on both CopyFail and DirtyFrag by Michael Tunell (whom I personally find both knowledgeable and calm enough, compared to many of the overhyped ADHD YouTubers out there):

https://youtu.be/zRqYZ7iiU7o?t=706

20

Phoronix reports that DirtyFrag mitigations have been applied to Kernels 7.0.6 & 6.18.29 LTS

21

What happens to the compiled kernels in the repositories that may never receive an update?

cachyos/linux-cachyos 7.0.3-1 default kernel for v1 pcs is only 7.0.3
cachyos-znver4/linux-cachyos-gcc 7.0.2-2
cachyos-znver4/linux-cachyos-hardened 6.19.12-2
cachyos/linux-cachyos-bmq 6.19.6-1
cachyos/linux-cachyos-bore 7.0.3-1
cachyos/linux-cachyos-cacule 6.1.8-1
cachyos/linux-cachyos-deckify 7.0.3-1
cachyos/linux-cachyos-eevdf 7.0.3-1
cachyos/linux-cachyos-hardened 6.19.12-2 ?
…
and many more