TL;DR: There are two new Linux kernel bugs. This script tells you if you're vulnerable. Patch your stuff.
On May 7th 2026, a vulnerability class called Dirty Frag was publicly disclosed by security researcher Hyunwoo Kim (@v4bel) — ahead of schedule, after an embargo break forced his hand before patches were ready.
It lets any unprivileged local user get root. No race condition. No timing window. Highly reliable.
Two subsystems are affected:
| CVE | Subsystem | Modules | Introduced | Fixed (upstream) |
|---|---|---|---|---|
| CVE-2026-43284 | IPsec ESP | esp4, esp6 |
Jan 2017 (cac2661c53f3) |
May 7 2026 (f4c50a4034e6) |
| CVE-2026-43500 | RxRPC | rxrpc |
Jun 2023 (2dc334f1a63a) |
May 10 2026 (aa54b1d27fe0) |
Neither bug alone is fully reliable — the ESP path requires the ability to create a user namespace (which Ubuntu's AppArmor blocks), and the RxRPC path needs rxrpc.ko loaded (which most distros don't do by default). Together they cover each other's blind spots, making the chain work on essentially every major distribution.
A public proof-of-concept is available. Assume it's already in active use.
It checks your system for the conditions that make exploitation possible, and tells you specifically why you're exposed — not just a yes or no.
| Check | What it's looking for |
|---|---|
| Kernel version | Is this kernel in either affected range? |
| Patch — CVE-2026-43284 | Is the esp4/esp6 fix (f4c50a4034e6) in your kernel package? |
| Patch — CVE-2026-43500 | Has your distro backported the rxrpc fix (aa54b1d27fe0)? |
esp4 module |
Loaded, loadable, or blacklisted? |
esp6 module |
Loaded, loadable, or blacklisted? |
rxrpc module |
Loaded, loadable, or blacklisted? |
| XFRM netlink socket | Can an unprivileged user open one right now? |
| AF_RXRPC socket | Can an unprivileged user open one right now? |
| Mitigations | AppArmor, SELinux, unprivileged user namespaces, blacklist file |
It won't fix anything. It won't exploit anything. It just tells you the truth about your system.
- Python 3.6+
- No external dependencies — stdlib only
- No root required (intentionally — we check what an unprivileged attacker can see)
python3 dirty_frag_detect.pyThat's it. Colour-coded output, specific reasons for each finding, and a remediation summary at the end.
[
]
The real fix is patching your kernel. Check your distribution's security advisories:
| Distribution | Where to look |
|---|---|
| Ubuntu / Debian | sudo apt-get update && sudo apt-get dist-upgrade |
| RHEL / AlmaLinux / Rocky | sudo dnf update kernel |
| Arch | sudo pacman -Syu linux |
| CloudLinux | CloudLinux advisory |
While you're waiting (or if patches aren't yet available for your distro), blacklist the vulnerable modules:
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; \
echo 3 > /proc/sys/vm/drop_caches"
⚠️ Before you do that:
- Blacklisting
esp4/esp6will break IPsec tunnels (strongSwan, Libreswan, WireGuard is unaffected). Don't apply this on VPN gateways.- Blacklisting
rxrpcwill break AFS distributed filesystem clients. Almost nobody uses this — but check first.
Important: if your system may have been targeted before the mitigation was applied, the exploit can modify binaries in the page cache without touching disk. File integrity tools (Tripwire, AIDE) checking on-disk checksums won't see anything wrong. Rebooting clears the page cache and restores the on-disk state.
Both bugs live in the kernel's in-place decryption fast paths. When a socket buffer carries paged fragments that aren't privately owned by the kernel — for example, pipe pages attached via splice() or sendfile() — the ESP and RxRPC receive paths decrypt directly over those externally-backed pages instead of copying first.
An attacker can steer a page from the cache of /usr/bin/su (or any other readable file) into one of these decryption paths, using their own key so the "decrypted output" is whatever bytes they choose. The kernel writes those bytes straight into the in-memory cached copy of su. The on-disk file is untouched. The kernel never marks the page dirty.
From that point, every process that executes su runs the attacker's version — until drop_caches or a reboot.
The ESP variant (cac2661c53f3) and the RxRPC variant (2dc334f1a63a) share the same sink but have different prerequisites that cancel out, making the chain reliable across all major configurations.
For the full technical writeup, see V4bel/dirtyfrag.
| Date | Event |
|---|---|
| 2026-04-30 | Reported to Linux kernel security team |
| 2026-05-07 | Embargo broken by third party; Hyunwoo Kim publishes ahead of schedule |
| 2026-05-07 | Public PoC released; CVE-2026-43284 assigned |
| 2026-05-07 | CVE-2026-43284 fix (f4c50a4034e6) merged to netdev/net.git |
| 2026-05-08 | CVE-2026-43500 reserved; distros begin shipping patched kernels for CVE-2026-43284 |
| 2026-05-10 | CVE-2026-43500 fix (aa54b1d27fe0) merged to mainline |
| 2026-05-11 | Distro backports for CVE-2026-43500 in progress |
Credit: Hyunwoo Kim (@v4bel) for the original research, disclosure, and PoC.
Detection only. Point it at systems you're authorised to assess.