Dirty Frag: Local Privilege Escalation in Linux Kernel#
Source: CERT/CC VU#980487
What Changed#
A new local privilege escalation, nicknamed “Dirty Frag,” affects Linux kernel versions 4.10 and later. It exploits the IPv4/IPv6 fragmentation and reassembly subsystem by combining two prior flaws: xfrm-ESP Page-Cache Write and RxRPC Page-Cache Write. The vulnerability arises from improper handling of overlapping or malformed fragment offsets, allowing attackers to trigger memory corruption or kernel panic. Proof-of-concept exploits show controlled out-of-bounds writes can occur, potentially enabling local privilege escalation or container escape under certain conditions.
Why It Matters#
Systems processing crafted network packets are at risk. Depending on configuration, kernel hardening, and network exposure, Dirty Frag may lead to:
- Local or remote denial of service through kernel panic.
- Memory corruption in the networking stack.
- Container escapes in affected environments.
- Additional exploit primitives when chained with other vulnerabilities.
The flaw is notable because it leverages existing kernel mechanisms rather than introducing entirely new attack vectors, increasing potential exploit reliability where packet access is possible.
What to Check#
Immediate action focuses on patching and temporary mitigations:
- Patch: Update the kernel via your distribution’s standard channels once vendor updates are available.
- Module mitigation: If patching is delayed, disable affected modules with:
sh -c "printf 'install esp4 /bin/false
install esp6 /bin/false
install rxrpc /bin/false
’ > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; echo 3 > /proc/sys/vm/drop_caches; true"
- **Boot-time prevention:** For compiled-in modules, add `initcall_blacklist=esp4,esp6,rxrpc` to your boot parameters and reboot.
- **Containers:** Apply seccomp filters, AppArmor policies, or eBPF controls to block creation of AF_ALG and AF_RXRPC sockets.
Check `/sys/module/<module_name>/refcnt` to confirm module usage before disabling. Review container runtime security policies if applicable.
### What Not to Overclaim
- Dirty Frag is primarily a local exploit; remote exploitation requires crafted packet access.
- Kernel panic alone does not always lead to privilege escalation.
- The PoC shows memory corruption but real-world chaining to full root access depends on other factors, including containerization, kernel build options, and mitigation layers.
- Vendor statements are pending; rely on upstream patches rather than third-party forks for production systems.
This vulnerability highlights the importance of operationalizing security artifacts: timely patching, module control, and container-level mitigations remain the best defenses.
### References
- [Proof-of-concept write-up](https://github.com/V4bel/dirtyfrag/blob/master/assets/write-up.md)
- [NVD CVE-2026-43284](https://nvd.nist.gov/vuln/detail/CVE-2026-43284)
- [Tenable FAQ on Dirty Frag](https://www.tenable.com/blog/dirty-frag-cve-2026-43284-cve-2026-43500-frequently-asked-questions-linux-kernel-lpe)