V4bel/dirtyfrag

RedHat still offer security support for RHEL7 ("extended lifecycle support"). It is possible to compile the exploit on RHEL7.9. You need a newer GCC but it's not uncommon to have that available. Here using GCC 10.2.0.

Copy header from kernel sources:
```
mkdir -p include/linux
cp /usr/src/kernels/$(uname -r)/include/linux/rxrpc.h include/linux/
```

Patch the exploit code to make it compile:
```
diff --git a/exp.c b/exp.c
index d8d5711..25b5e1c 100644
--- a/exp.c
+++ b/exp.c
@@ -1,3 +1,5 @@
+typedef unsigned short u16;
+
#define _GNU_SOURCE
#include
#include
@@ -16,7 +18,7 @@
#include
#include
#include
-#include
+// #include
#include
#include
#include
```

Compile with
```
gcc --std=c99 -I./include -O0 -Wall -o exp exp.c -lutil
```

However, running the exploit fails. Tested on kernel `3.10.0-1160.147.1.el7.x86_64`.

But that doesn't mea...

You're running CentOS 7 so you're already screwed regardless of _this_ vulnerability.

They usually backport security fixes, not entire features. If it's not essential, it's not backported. I can't see why they would have backported that stuff unless it was breaking something else important and that bad code was part of the fix.

It's true that 3.10 was released in 2013 (with LTS thru 2017 I think).

That said, Red Hat does a lot of back porting into their EL kernels and 3.10.0-1160 was released in 2020 (still old) with end of maintenance in 2024 and of extended support ending in 2028.

It's the back porting that may make it vulnerable. 🤷

That kernel is way too old for that. The bug was introduced in a commit from 2017-01-17, your kernel is from 2013.

Android's SELinux setup blocks weird socket types. Additionally Android has no suid binaries.

It shouldn't be. I'm not aware that Android kernels have either loadable kernel modules nor XFRM/RXRPC support, and most definitely not accessible to regular user apps.

Android also doesn't really have SUID binaries, so while it potentially could be used to exploit something else to one's advantage, it ain't gonna give you a root shell on Android. The exploit relies on `su` being a SUID binary. The exploit only rewrites `su` to not check password and exploit its existing ability to become root by virtue of being a SUID binary.

[Comment thread on HN about it](https://news.ycombinator.com/item?id=48054201). The Linux kernel used by Android may be hardened to make it not possible (I don't know if Copy Fail was ever possible on Android). But time will tell I suppose.

> But it does not mean they are not affected, just that this specific code does not work for those targets

the particular exploit contains x86_64 binary code (see https://github.com/V4bel/dirtyfrag/blob/892d9a31d391b7f0fccb333855f6289507186748/exp.c#L43), so can't work verbatim on ARM

It does not on any of the devices I have tested. But it does not mean they are not affected, just that this specific code does not work for those targets. They might still be vulnerable.

> Can you try to drop the page cache after the exploit? This should work without a reboot.
>
> ```
> sudo echo 3 > /prox/sys/vm/drop_caches
> ```

That seems to work here. `su` asks for a password again after dropping the cache.

Well the exploit says Ubuntu 24, but i have tried both the latest HWE kernel (6.17.0-23) and non HWE kernel (6.8.0-111) and neither seems to be affected. On the oterh hand Ubuntu 26.04 running 7.0.0-15 is affected and the mitigation worked after a reboot.

Can you try to drop the page cache after the exploit? This should work without a reboot.
```
sudo echo 3 > /prox/sys/vm/drop_caches
```

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).



https://github.com/V4bel/dirtyfrag/blob/3099b8a3c79b8f0ad53e68ba9b2c9e89d38bc971/exp.c#L1640-L1659

Seems once a host as run the exploit, it won't stop until rebooted.

```
[tdockendorf@OMIT dirtyfrag]$ ./exp
dirtyfrag: failed (rc=1)
```

On mitigated host that hadn't been exploited yet.