Overview
Not every privilege escalation vulnerability stems from a simple coding mistake. In some cases, root access can be achieved by combining legitimate kernel features in unintended ways.
Like its predecessors, Dirty Pipe and Copy Fail, Dirty Frag exploits the Linux kernel’s page cache—the in-memory representation of files maintained for performance. This technique abuses the kernel’s network cryptography code to write attacker-controlled data directly into these cached file pages.
Once modified, the changes persist in memory until a reboot or cache flush. Any subsequent reads of the affected file return the tampered content, effectively altering system behavior without modifying the file on disk.
Similar to Copy Fail, this approach appears reliable across multiple kernel versions and distributions, making it more practical than many traditional kernel exploits.
The original research notes that Dirty Frag was inspired by Copy Fail, highlighting how recent discoveries continue to influence new exploitation techniques.
For a deeper technical breakdown and proof-of-concept details, refer to the original research write-up.
Exploit Availability
A proof of concept is already publicly available and can be executed with a single command. At the time of writing, no confirmed real-world exploitation has been reported.
However, the barrier to entry is notably low. The exploit is deterministic, works across a broad range of kernel versions, and does not require kernel-specific adjustments.
Affected Systems
According to the original research, the following systems are vulnerable to Dirty Frag:
- Ubuntu 24.04.4 — 6.17.0-23-generic
- RHEL 10.1 — 6.12.0-124.49.1.el10_1.x86_64
- openSUSE Tumbleweed — 7.0.2-1-default
- CentOS Stream 10 — 6.12.0-224.el10.x86_64
- AlmaLinux 10 — 6.12.0-124.52.3.el10_1.x86_64
- Fedora 44 — 6.19.14-300.fc44.x86_64
Detection for Dirty Frag with Guardsix SIEM
Required Log Sources
- Unix Default Logs
- Kernel Logs
- Auditd
- Unix Sysmon
Not all of these are strictly required to detect this vulnerability. However, combining them significantly improves visibility and helps correlate different stages of the exploit.
Stay tuned for updates on configuring relevant auditd rules and detecting them.
Detection Using Default Unix Logs
Similar to Copy Fail, detection relies on identifying specific kernel-level behaviors and anomalies.
Detect XFRM Initialization
Dirty Frag leverages the kernel’s network cryptography subsystem (XFRM/IPsec) as part of its exploitation path. To detect this, use:
norm_id=Unix "process"=Kernel
"Initializing XFRM netlink socket"
Detect Splice Syscall Usage
Dirty Frag relies on splice for page cache manipulation and data movement. To detect this, use:
norm_id=Unix
event_type="SYSCALL" system_call=splice
Detect Suspicious Privileged Shell Spawn
Similar to Copy Fail, DirtyFrag exploitation results in abnormal root shell execution, often triggered through malformed or unusual process arguments. One observable artifact is the kernel logging a process launching a shell with a NULL argument vector, which is not typical in normal system behavior.
norm_id=Unix "process"=Kernel
"process 'su' launched '/bin/sh' with NULL argv: empty string added"
To generalize detection across different shell binaries, you can use the following query:
norm_id=Unix "process"Kernel"
| process regex("kernel: process '(?P<proc>[^']+)'
launched '(?P<cmd>[^']+)' with NULL argv: empty string added", msg, "filter=true")
Detection with Auditd
DirtyFrag may result in the execution of targeted SUID binaries as part of the final privilege escalation stage.
To detect the final shell spawned via auditd, you can refer to the process spawning shell with root privileges, within the time frame of the other above-mentioned events.
norm_id=Unix system_call=execve status_code=0 -user=root
effective_user=root command IN ["*su *", "*sudo*", "*passwd*",
"*chsh*", "*mount*", "*umount*","*pkexec*", "*newgrp*", "*crontab*"]
Note: A legitimate sudoer will trigger FPS so analysts needs to filter out known sudo users.
Detection with UnixSysmon
Successful invocation executes su with - (su -) argument as mentioned in the payload, which can be detected using the following query
norm_id=UnixSysmon event_id=1 command="su -"| chart count() by parent_process, parent_command, "process",command
For auditd-based customers, use the following query:
norm_id=Unix event_type=Execve command="su -"
| chart count() by parent_process, parent_command, "process",command
Mitigation
- Apply patches immediately or upgrade to a fixed kernel version when available.
- As suggested by the proof-of-concept author, you can reduce exposure by disabling affected modules and clearing the page cache:
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 command:
- Prevents vulnerable modules from loading
- Unloads them if currently active
- Clears the page cache to remove any injected data from memory