v12-security/pocs

They're not required. In fact, they are explicitly ignored: https://github.com/v12-security/pocs/blob/7b5fc577c3d9ad386cc109b1eb7b02623f48ca13/fragnesia/fragnesia.c#L1300

I successfully exploited on the same system when booted without `ipv6.disable=1`. That was the only difference. I don´t know C but I can see the ipv6-specific code in the source, for example: https://github.com/v12-security/pocs/blob/7b5fc577c3d9ad386cc109b1eb7b02623f48ca13/fragnesia/fragnesia.c#L738

Try it for yourself: `sudo grubby --update-kernel=ALL --args="ipv6.disable=1"`, reboot, then run `./exp` with or without arguments.

....

args are absolutely required.

XFRM_MSG_NEWSA creates IPsec Security Associations, ESP modules (esp4/esp6) are the transport layer for those SAs.

Check to see if you have those available:

# Method 1: Check if modules are currently loaded
lsmod | grep esp

# Method 2: Check if module files exist on disk
ls -la /lib/modules/$(uname -r)/kernel/net/ipv4/esp4.ko* 2>/dev/null
ls -la /lib/modules/$(uname -r)/kernel/net/xfrm/esp6.ko* 2>/dev/null

# Method 3: Try to load them (requires root)
sudo modprobe esp4 && echo "esp4: OK" || echo "esp4: BLOCKED/MISSING"
sudo modprobe esp6 && echo "esp6: OK" || echo "esp6: BLOCKED/MISSING"

# Method 4: Check modprobe blacklist
grep -r "esp4\|esp6" /etc/modprobe.d/

# Method 5: Check if modules can be found in module index
modinfo esp4
modinfo esp6

I don´t think they are necessary but anyway, it gives the same result:

```
user@f44:~/workspace/pocs/fragnesia$ ls -l /tmp/
total 0
-rw-r--r--. 1 root root 0 14 mei 17:48 frag

```

```
user@f44:~/workspace/pocs/fragnesia$ ./exp /tmp/frag 0 42434445
[*] uid=1000 euid=1000 gid=1000 egid=1000
[*] mode=xfrm_espintcp_pagecache_replace collateral=after

[*] target=/usr/bin/su size=57184
outer_write_open_denied=1 errno=13 (Permission denied)
userns_setup: outer_uid=1000 outer_gid=1000 ns_uid=0 ns_gid=0
netns_setup=1
loopback_up=1
namespace_gate_failed: XFRM_MSG_NEWSA ack errno=93 (Protocol not supported)
```

Did you test with the required arguments?

./exp /tmp/root-owned-copy 0 42434445

#2

I've tested the changed code in this PR on the same alma machine and am now dropped into a privileged root shell

To add onto the discussion, I tried this on an almalinux 9.7 machine on kernel 5.14.0-611.54.3
This machine had a mitigation for dirtyfrag until we patched it for that yesterday, the mitigation is no longer active.

It resulted in a weird bash shell that says it's root but is unable to perform root functions:



Is there something I am doing wrong or does it seem relatively harmless compared to the last 2 we've had?

Wellp, the fresh installed Debian 13 seems to be the patched kernel already...



I wish i had a rollback of the machine, since i cant reproduce it anymore xd

(any way to mitigate the mitigation?)

Since this is my WSL shit... sandbox i have NOT taken any mitigations, the modules were still active.

Thats why its strange.

I ran the "unload kernel modules" from dirtyfrag just to get the printout after rerunning it a second time, that now all modules are unloaded, as it should, when mitigated. First run was without a "is currently not loaded" run, so i guess they were still active. Now they are NOT anymore, so my shitbox debian is NOW status mitigated (without beeing wiped again).



For test reasons iam gonna install some random wsl distribution i can find and see if wsl is the killer, or the debian i played with dirtyfrag on already.

What mitigations did you take against Dirty Frag? Fragnesia & Dirty Frag attack the same module, so if you blacklisted and removed the modules as part of hardening against Dirty Frag, you'll have protected yourself against Fragnesia too.