Dirty Frag: local privilege escalation in the Linux kernel (esp4, esp6, rxrpc)
CVE-2026-43284 (IPsec ESP: esp4 / esp6) CVE-2026-43500 (RxRPC: rxrpc) related follow-up: CVE-2026-46300 "Fragnesia"
Dirty Frag lets an ordinary, unprivileged local user become root on an unpatched Linux machine. It was publicly disclosed on May 7, 2026, and it is really two kernel bugs that can be chained together. It needs local access first (an SSH login, a web shell, a container, a shared account), so it is not a "remote hack from nowhere", but on any machine where more than one person or process can run code it matters a lot. This sheet covers what it is, which kernel modules are involved, how to check your exposure, how to block the modules by hand, and which Ubuntu and Red Hat kernel versions contain the fix.
Versions and advisories below were checked against the Ubuntu and Red Hat pages on 2026-09-29. A kernel NEWER than the one listed also contains the fix. Always confirm with your own package manager (see "Is my kernel patched?").
Defensive notes only: no exploit code here. Only run the mitigation on machines you own or administer.
What it is, in plain English
Linux keeps recently read files in memory (the "page cache"). When the network code processes data, it can end up working directly on memory pages that also belong to a cached file. In the IPsec ESP code (esp4/esp6) and the RxRPC code (rxrpc), the kernel does encryption work "in place" on data it should have copied first. A local user can abuse that to change the in-memory copy of a file they are only allowed to read, such as a setuid program or a system file, and then use it to become root. The file on disk is not modified, which is why it is sneaky. Because the flaw is in the kernel, a container shares it with the host: a vulnerable host kernel means a container can be a way in too.
The ESP flaw has been in the upstream kernel since about 2017, the RxRPC flaw since about 2023, so almost every distribution released in the last nine years was affected until patched. A public proof of concept appeared right after disclosure. Microsoft reported limited in-the-wild use (SSH access, then a privilege escalation involving su) in its May 8, 2026 write-up. Severity: CVSS 8.8 (CVE-2026-43284, kernel.org rating) and 7.8 (CVE-2026-43500); Red Hat rates it Important, Ubuntu rates it High.
Who is affected
Ubuntu: 18.04, 20.04, 22.04, 24.04, 25.10 and 26.04 (14.04 and 16.04 are not affected)
Red Hat family: RHEL 8, 9 and 10 and products on its kernel (OpenShift 4, OpenStack, Virtualization). RHEL 6 and 7 are NOT affected
Others: Fedora, CentOS Stream, AlmaLinux and other distributions were reported vulnerable too. Follow their own advisories.
Lower risk: machines where nobody untrusted can run code. Still patch them.
The kernel modules involved
Module What it is CVE Affects
esp4 IPsec ESP (encrypted packets), IPv4 CVE-2026-43284 Ubuntu, RHEL
esp6 IPsec ESP, IPv6 CVE-2026-43284 Ubuntu, RHEL
rxrpc RxRPC protocol, used by AFS filesystem CVE-2026-43500 Ubuntu (Red Hat: not affected by this CVE)
esp4/esp6 are what IPsec VPNs use (strongSwan, Libreswan). rxrpc is only used by AFS.
Blocking esp4/esp6 breaks IPsec VPN tunnels. It does NOT affect OpenVPN or WireGuard, which do not use those modules. Blocking rxrpc only matters if you use AFS (kernel "kafs"), which is rare.
Related: Fragnesia (CVE-2026-46300) is a variant in the same ESP code (the ESP-in-TCP path), disclosed May 13, 2026. It is another reason to install the newest kernel, not just the first fixed one.
Also related: Copy Fail (CVE-2026-31431) is a separate bug with a similar effect, in the algif_aead module. Blocking esp4/esp6 does NOT protect against it (and blocking algif_aead does not protect against Dirty Frag), so see the Copy Fail sheet on this tab too. Patching the kernel covers both.
Check your exposure first
uname -r # the kernel you are running RIGHT NOW (compare with the tables below)
lsmod | grep -E '^(esp4|esp6|rxrpc|kafs)' # is any of the modules loaded at this moment?
modinfo -n esp4 esp6 rxrpc # each should print a .ko path (it exists as a loadable module)
grep -E 'CONFIG_INET_ESP=|CONFIG_INET6_ESP=|CONFIG_AF_RXRPC=' /boot/config-$(uname -r)
# =m means a module (can be blocked); =y means built in (CANNOT be blocked, you must patch)
ip xfrm state # anything listed = IPsec is in use here: do NOT block esp4/esp6
systemctl list-units --type=service | grep -Ei 'strongswan|libreswan|ipsec|openswan' # is an IPsec VPN service running?
Manual mitigation: Ubuntu (as published by Ubuntu)
Do this only if you cannot patch and reboot yet, and only on hosts that do not use IPsec or AFS.
1. Block the modules from loading (install rules make modprobe run /bin/false instead of loading the module):
sudo sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirty-frag.conf"
cat /etc/modprobe.d/dirty-frag.conf # should show exactly three "install ... /bin/false" lines
2. Rebuild the initramfs so the block also applies during early boot:
sudo update-initramfs -u -k all
3. Unload them if they are already loaded (errors are hidden if they are not):
sudo rmmod esp4 esp6 rxrpc 2>/dev/null
4. Verify (prints a message saying whether any of them is still loaded):
grep -qE '^(esp4|esp6|rxrpc) ' /proc/modules && echo "Affected modules are loaded" || echo "Affected modules are NOT loaded"
modprobe -n -v esp4 # should print: install /bin/false
If rmmod says a module is "in use", something is using it (usually IPsec). A reboot will enforce the block, but it will break whatever was using the module.
Undo it later (after you have installed the patched kernel):
sudo rm /etc/modprobe.d/dirty-frag.conf
sudo update-initramfs -u -k all
Manual mitigation: Red Hat / RHEL family (as published by Red Hat in RHSB-2026-003)
Option A: block IPsec (broad, simple, breaks IPsec VPNs). Red Hat's procedure only lists esp4 and esp6 because the rxrpc CVE does not affect RHEL:
sudo sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf"
sudo rmmod esp4 esp6 2>/dev/null; true
modprobe -n -v esp4 # should print: install /bin/false
Undo: sudo rm /etc/modprobe.d/dirtyfrag.conf
Option B: keep IPsec working by turning off unprivileged user namespaces instead (the attacker needs them to reach the vulnerable code):
sysctl user.max_user_namespaces # WRITE DOWN the current value first, so you can restore it
sudo sh -c 'echo "user.max_user_namespaces=0" > /etc/sysctl.d/dirtyfrag.conf'
sudo sysctl --system
Side effects (Red Hat's own warning): rootless containers (podman), sandboxed browsers and Flatpak can stop working.
Undo: sudo rm /etc/sysctl.d/dirtyfrag.conf, then reboot or set the old value with: sudo sysctl -w user.max_user_namespaces=<old value>
The same two ideas work on any distribution. Ubuntu's own advisory only documents the module block.
If you think a machine may already have been targeted: the corrupted copy lives in memory only, so after mitigating or patching, drop the page cache (Microsoft's and Tenable's advice) or simply reboot:
echo 3 | sudo tee /proc/sys/vm/drop_caches
Then look for signs of trouble: unexpected new root shells, su or other setuid programs behaving oddly after a login, and unknown users or SSH keys. Microsoft also suggests hunting for processes that load modules named algif-skcipher, net-pf-38 or crypto-seqiv(rfc4106(gcm(aes))).
The real fix: install the patched kernel and REBOOT
Ubuntu:
sudo apt update && sudo apt upgrade
sudo reboot
Red Hat / RHEL:
sudo dnf upgrade --refresh 'kernel*'
sudo reboot
A kernel update does nothing until you boot into it. Run uname -r afterwards and compare with the tables below.
Live patching: Red Hat also published kpatch live patches for some RHEL streams, but a normal update plus reboot is the sure route.
Patched kernels: Ubuntu (first fixed versions; anything newer is also fixed)
Release Kernel line Fixed in
18.04 LTS Bionic Linux 4.15 4.15.0-251.263
18.04 LTS Bionic Linux 5.4 (HWE) 5.4.0-231.251~18.04.1
20.04 LTS Focal Linux 5.4 5.4.0-231.251
20.04 LTS Focal Linux 5.15 (HWE) 5.15.0-181.191~20.04.1
22.04 LTS Jammy Linux 5.15 5.15.0-181.191
22.04 LTS Jammy Linux 6.8 (HWE) 6.8.0-124.124~22.04.1
24.04 LTS Noble Linux 6.8 6.8.0-124.124
24.04 LTS Noble Linux 6.17 (HWE) 6.17.0-35.35~24.04.1
24.04 LTS Noble Linux 7.0 (HWE) 7.0.0-28.28~24.04.1
25.10 Questing linux 6.17.0-35.35
26.04 LTS Resolute linux 7.0.0-22.22
Cloud kernels have their own numbers. Examples from Ubuntu's tracker:
linux-aws 22.04: 5.15.0-1109.116 24.04: 6.8.0-1057.60 26.04: 7.0.0-1006.6
linux-azure 22.04: 5.15.0-1114.123 24.04: 6.8.0-1058.64 26.04: 7.0.0-1007.7
linux-gcp 22.04: 5.15.0-1109.118 24.04: 6.8.0-1060.63 26.04: 7.0.0-1005.5
Other flavours (oracle, raspi, lowlatency and so on): look them up on https://ubuntu.com/security/CVE-2026-43284
18.04 and 20.04 are past standard support: their fixes come through Ubuntu Pro. 18.04 is not affected by the rxrpc CVE (only by the ESP one). 20.04 and 18.04 are not affected by Fragnesia. 14.04 and 16.04 are not affected at all.
Patched kernels: Red Hat Enterprise Linux (kernel package; "or newer" applies)
RHEL 10.2 6.12.0-211.16.1.el10_2 (RHSA-2026:19569, May 20 2026: also fixes Fragnesia)
earlier fix: 6.12.0-211.7.3.el10_2 (RHSA-2026:19074, May 19 2026)
RHEL 10.1 6.12.0-124.56.1.el10_1 (RHSA-2026:16062, May 11 2026)
RHEL 9.8 5.14.0-687.10.1.el9_8 (RHSA-2026:19568, May 20 2026: also fixes Fragnesia)
earlier fix: 5.14.0-687.5.3.el9_8 (RHSA-2026:19225, May 19 2026)
RHEL 9.7 5.14.0-611.55.1.el9_7 (RHSA-2026:16206, May 12 2026)
RHEL 8.10 4.18.0-553.125.1.el8_10 (RHSA-2026:19666, May 20 2026: also fixes Fragnesia)
earlier fix: 4.18.0-553.124.1.el8_10 (RHSA-2026:16196, May 12 2026)
RHEL 7 and RHEL 6: not affected.
Extended-support streams (EUS, AUS, TUS, SAP) each have their own fixed kernel:
10.0 EUS 6.12.0-55.73.1.el10_0 9.6 EUS 5.14.0-570.113.1.el9_6 9.4 EUS 5.14.0-427.125.1.el9_4
9.2 5.14.0-284.170.1.el9_2 9.0 5.14.0-70.179.1.el9_0 8.8 4.18.0-477.140.1.el8_8
8.6 4.18.0-372.192.1.el8_6 8.4 4.18.0-305.191.1.el8_4
OpenShift Container Platform 4.12 to 4.21 is fixed through updated RHCOS images; see the Red Hat CVE page below for the exact build per version.
Rebuilds (AlmaLinux, Rocky Linux, CentOS Stream, Oracle Linux) use their own package numbers: follow their advisories, not this table.
Note on the two Red Hat dates: the first fixes (May 11 to 13) cover Dirty Frag; the May 20 kernels are the ones that also cover Fragnesia, so aim for those or anything newer.
Is my kernel patched?
Ubuntu:
uname -r # compare with the Ubuntu table above
apt changelog linux-image-$(uname -r) | grep -E 'CVE-2026-(43284|43500|46300)' # the changelog should mention the CVE
pro fix CVE-2026-43284 --dry-run # Ubuntu Pro client: says whether this machine is fixed
Red Hat / RHEL:
uname -r # compare with the RHEL table above
rpm -q --changelog kernel-$(uname -r) | grep -E 'CVE-2026-(43284|46300)' # the changelog should mention the CVE
sudo dnf updateinfo list --cve CVE-2026-43284 # shows which advisory fixes it and whether it is installed
sudo needs-restarting -r # says whether a reboot is still needed
Careful: rpm -q kernel lists INSTALLED kernels, including old ones you are not running. Only uname -r tells you what is actually running.
Common problems
"rmmod: ERROR: Module esp4 is in use": IPsec is active on this host. Check ip xfrm state. Either stop the VPN service, use the user-namespace option instead, or (best) patch and reboot rather than blocking.
The VPN stopped working after the mitigation: that is the expected side effect of blocking esp4/esp6. Undo the block and patch instead, or use the user-namespace option, which leaves IPsec alone.
The modules still load after I blocked them: check modprobe -n -v esp4 (it must print install /bin/false). Ubuntu needs the update-initramfs step. If the config shows CONFIG_INET_ESP=y the code is built into the kernel, cannot be blocked this way, and only a patched kernel helps.
I updated but uname -r shows the old kernel: you have not rebooted yet. The patch only counts once the new kernel is running.
podman, Flatpak or the browser sandbox broke after the sysctl change: that is the side effect of user.max_user_namespaces=0. Restore the old value (you wrote it down) or remove /etc/sysctl.d/dirtyfrag.conf and reboot.
Ubuntu 18.04 or 20.04 shows no update: those releases need Ubuntu Pro for kernel security fixes. Check pro status.
A cloud image shows a kernel name like 6.8.0-1057-aws: cloud kernels have their own fixed numbers (see the examples in the Ubuntu section), do not compare them with the generic 6.8.0-124 line.
Tips
Patch and reboot beats blocking modules every time. Treat the module block as a temporary bandage for hosts you cannot reboot yet, then install the kernel, then remove the bandage.
Prioritise by who can run code: shared servers, container hosts, CI runners, jump boxes, hosting machines and anything with many SSH users come first. A single-user laptop is lower risk, but still patch it.
Containers do not have their own kernel. Patching the host fixes the containers on it, and updating the image inside the container changes nothing.
Do not forget virtual machines, cloud instances and Kubernetes nodes: every one of them has its own kernel to update.
Blocking modules and patching are not exclusive: the mitigation files are harmless once patched, but remove them so a later IPsec setup does not fail mysteriously at 2 a.m.
Ask your future self a kindness: put the date and reason in a comment inside the modprobe file. "Why does IPsec not work on this box?" is a bad mystery.
There are two kinds of sysadmins: those who reboot after a kernel update, and those who are still vulnerable.
Sources (checked 2026-09-29)
Ubuntu advisory and fixed versions: https://ubuntu.com/blog/dirty-frag-linux-vulnerability-fixes-available
Ubuntu CVE tracker: https://ubuntu.com/security/CVE-2026-43284 https://ubuntu.com/security/CVE-2026-43500 https://ubuntu.com/security/CVE-2026-46300
Red Hat security bulletin (mitigation): https://access.redhat.com/security/vulnerabilities/RHSB-2026-003
Red Hat CVE page: https://access.redhat.com/security/cve/cve-2026-43284
Microsoft write-up (in-the-wild use): https://www.microsoft.com/en-us/security/blog/2026/05/08/active-attack-dirty-frag-linux-vulnerability-expands-post-compromise-risk/
Tenable FAQ: https://www.tenable.com/blog/dirty-frag-cve-2026-43284-cve-2026-43500-frequently-asked-questions-linux-kernel-lpe