VU#980487: Local privilege escalation in Linux Kernel (Dirty Frag)

Overview

A privilege escalation vulnerability, nicknamed “Dirty Frag,” has been discovered in the Linux kernel versions 4.10 and later. This vulnerability is a result of chaining together two previously discovered vulnerabilities, xfrm-ESP Page-Cache Write CVE-2026-43284 and the RxRPC Page-Cache Write CVE-2026-43500. This vulnerability was publicly disclosed on May 07, 2026.

Description

Dirty Frag is a Linux kernel vulnerability affecting the IPv4/IPv6 fragmentation and reassembly subsystem. The issue stems from improper handling of overlapping or malformed fragment offsets during the reassembly process. An attacker capable of sending crafted network packets to a vulnerable host can exploit the flaw to trigger memory corruption conditions.

The publicly documented proof of concept demonstrates that fragmentation logic can be manipulated such that the kernel processes inconsistent fragment states, enabling a controlled write out-of-bounds scenario. When successfully exploited, this can result in local or remote denial of service (kernel panic) and, depending on configuration and kernel build options, may create a primitive for more advanced memory manipulation.

The vulnerability arises from insufficient validation of fragment metadata during reassembly, specifically around:

• Incorrect or incomplete enforcement of fragment boundary checks
• Acceptance of overlapping fragments in unsafe sequences
• Inadequate cleanup when transitions occur between valid and invalid fragment states

The fragment queue logic in affected kernels does not fully verify that fragment offsets, sizes, and overlap conditions remain consistent throughout reassembly. This allows malformed sequences to be processed without proper rejection.

Impact

The primary security concern is potential privilege escalation, similar in nature to the previously disclosed VU#260001 (“Copy Fail”) vulnerability.

Depending on system configuration, kernel hardening features, and network exposure, successful exploitation may result in:

• Local or remote denial of service through kernel panic
• Memory corruption within the Linux networking stack
• Privilege escalation
• Container escape in certain containerized environments
• Additional exploit primitives when chained with other vulnerabilities

Solution

Update your distribution’s kernel package as soon as vendor patches become available. Most major Linux distributions are expected to release fixes through their standard update channels.

Workarounds (if patching is not immediately possible):

1) Disable at-risk modules (if loaded and loadable):
Use the following command to remove the modules in which the vulnerabilities occur and clear the page cache.
sh -c "printf 'install esp4 /bin/falseninstall esp6 /bin/falseninstall rxrpc /bin/falsen' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; echo 3 > /proc/sys/vm/drop_caches; true"

Note: you can verify if a module is currently being used using lsmod and the Used field or reviewing refcnt data in /sys/module/<module_name>/refcnt for e.g., cat /sys/module/esp4/refcnt

2) If affected modules esp4, esp6, rxrpc are compiled into the kernel (not a dynamic module), the following parameter can be added to grub, systemd-boot, or grubby, depending on your boot configuration:
initcall_blacklist=esp4,esp6,rxrpc
This prevents the module from initializing at boot time. A system reboot is required for this change to take effect.

Mitigation for Containers

For containerized environments, where this vulnerability may be leveraged for container escape, consider applying one or more of the following mitigations:

• Secure computing (seccomp) filtering: Restrict or deny system calls that create sockets using the AF_ALG address family (protocol 38) and AF_RXRPC (protocol 33) .
• AppArmor policies: Use AppArmor to block creation of AF_ALG sockets and AF_RXRPC via the network alg rule.
• eBPF-based enforcement: Deploy BPF-based controls to deny socket creation with address family AF_ALG (38) and AF_RXRPC (33).

Acknowledgements

This vulnerability was disclosed by Hyunwoo Kim. This document was written by Bob Kemerer.