V4bel/dirtyfrag

Amazon Linux doesn't seem to ship with rxrpc.ko so that entire path is not available.

I think 6.12.80-106.156.amzn2023.x86_64 is a patched kernel version so not going to have any luck there.

For the 6.1.168-203.330.amzn2023.aarch64 system, that should be patched from copyfail but not dirtyfrag, you can try my arm64 port: [https://github.com/linnemanlabs/dirtyfrag-arm64/](https://github.com/linnemanlabs/dirtyfrag-arm64/) and use --force-esp since rxrpc wont be available.

Tracked at https://bugs.launchpad.net/ubuntu/+source/kmod/+bug/2151831

as pointed out by @ChrisTX, if you can corrupt the page cache of any file you have `READ` permission, then it would be fairly easy to build an escape by identifying a privileged container on the node and messing with it's container image content. I've described 2 such exploits over here https://github.com/clementnuss/copyfail-cve-exploits

I'm currently trying to see if `dirtyfrag` can do the same but I expect it to be the case. I'll update this post in a few hours!

Tested on `PVE 5.15.143-1 (2024-02-08T18:12Z) x86_64 Linux` seems not vulnerable.It is too old. :>

Oh sorry 😅

```
./exp-x86_64
dirtyfrag: failed (rc=1)
/var/www/html $ DIRTYFRAG_VERBOSE=true ./exp-x86_64
[su] installed 48 xfrm SAs
[su] do_one_write #0 at off=0x0 failed
[su] corruption stage failed (status=0x200)

=== rxrpc/rxkad LPE EXPLOIT (uid=1000 → root) ===
[*] uid=82 euid=82 gid=82
[!] socket(AF_RXRPC): Address family not supported by protocol — module not loadable?

=== rxrpc/rxkad LPE EXPLOIT (uid=1000 → root) ===
[*] uid=82 euid=82 gid=82
[!] socket(AF_RXRPC): Address family not supported by protocol — module not loadable?

=== rxrpc/rxkad LPE EXPLOIT (uid=1000 → root) ===
[*] uid=82 euid=82 gid=82
[!] socket(AF_RXRPC): Address family not supported by protocol — module not loadable?

=== rxrpc/rxkad LPE EXPLOIT (uid=1000 → root) ===
[*] uid=82 euid=82 gid=82
[!] socket(AF_RXRPC): Address family not supported by protocol — module not loadable?
dirtyfrag: failed (rc=1)
/var/www/html $ uname -r
6.12.80-106.156.amzn2023.x86_64
```

> ```
> [ec2-user@al2023 dirtyfrag]$ gcc -O0 -Wall -o exp exp.c -lutil
> [ec2-user@al2023 dirtyfrag]$ ./exp
> dirtyfrag: failed (rc=1)
> [ec2-user@al2023 dirtyfrag]$ uname -a
> Linux al2023 6.1.168-203.330.amzn2023.aarch64 #1 SMP Fri May 1 14:08:03 UTC 2026 aarch64 aarch64 aarch64 GNU/Linux
> ```

The payload is x86, your instance is aarch64/arm. #2

```
[ec2-user@al2023 dirtyfrag]$ gcc -O0 -Wall -o exp exp.c -lutil
[ec2-user@al2023 dirtyfrag]$ ./exp
dirtyfrag: failed (rc=1)
[ec2-user@al2023 dirtyfrag]$ uname -a
Linux al2023 6.1.168-203.330.amzn2023.aarch64 #1 SMP Fri May 1 14:08:03 UTC 2026 aarch64 aarch64 aarch64 GNU/Linux
```

Mixed on Gentoo. So far I've had one exploit work and two attempts on other machines failed. Various kernels and emerge states. Mitigation worked on the exploited machine. All are Gentoo Base System release 2.18

> Worse, at least on my Gentoo system, the ESP parts were configured as built-in, not modules

You may try the ebpf way to mitigate, it's faster and does **not** require a full rebuild of your kernel.

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

I don't think so. [According to the README, the RXRPC part is only required to circumvent an AppArmor policy in Ubuntu](https://github.com/V4bel/dirtyfrag#why-did-you-chain-two-vulnerabilities), which I understand as Gentoo systems without RXRPC are vulnerable as long as they don't come with a similar extra layer via AppArmor or the likes.
Worse, at least on my Gentoo system, the ESP parts were configured as built-in, not modules, making the workaround via modprobe impossible. Thus, I had to re-configure, build, and install my kernel and reboot to mitigate. I did not check if this was a default configuration or something I specificially did.

On rootless containers like "unprivileged LXC" if the rootfs of the container is isolated, it cannot escape.

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

I have tested it on GKE and ACK clusters. All failed.

On ACK default node image:
user.max_user_namespaces is set 0, so unprivileged user can't use CLONE_NEWUSER unshare.
On GKE default node image (COS):
user.max_user_namespaces is 15426, but kubelet enables --seccomp-default, the default seccomp policy disable unshare syscall.

after some research i think its related to this it must be loaded and activated for the exploit to work :

```
$ grep CONFIG_AF_RXRPC /boot/config-$(uname -r)
# CONFIG_AF_RXRPC is not set
```

it must be :

```
$ grep CONFIG_AF_RXRPC /boot/config-$(uname -r)
CONFIG_AF_RXRPC=m
CONFIG_AF_RXRPC_IPV6=y
```