DirtyFrag CVE-2026-43284 PoC Validation and auditd Detection

Scope: Linux Local Privilege Escalation (LPE) validation focused on the XFRM/ESP path associated with CVE-2026-43284.

This repository contains an English report and evidence artifacts from a controlled laboratory validation of the public DirtyFrag PoC. The focus is not on providing an exploitation guide, but on documenting what was visible in Linux audit logs and how those events can be transformed into practical SOC detection logic.

Full PDF report:

EN: reports/DirtyFrag_CVE-2026-43284_EN.pdf

PL: reports/DirtyFrag_CVE-2026-43284_PL.pdf

Purpose and scope

The test was performed to verify whether a normal local user could obtain a root shell in a vulnerable lab VM and to determine which events can be captured with auditd.

CVE-2026-43284 relates to improper handling of shared page fragments during ESP/IPsec operations. Under specific conditions, a local attacker can influence data in the page cache and escalate privileges. Ubuntu Security rates this vulnerability as CVSS 3.1: 7.8 High.

Technical references:

• Public DirtyFrag PoC repository: https://github.com/V4bel/dirtyfrag
• Ubuntu Security - CVE-2026-43284: https://ubuntu.com/security/CVE-2026-43284
• Ubuntu blog - Dirty Frag Linux vulnerability fixes available: https://ubuntu.com/blog/dirty-frag-linux-vulnerability-fixes-available

Test environment

Full system baseline: evidence/logs/system-info-table.md

Result

Before PoC execution, the test context was a normal user account. After running ./exp, a root shell was obtained and confirmed with whoami and id.

Evidence collection

After the test, auditd logs and summary outputs were exported to a local evidence directory and copied into this repository.

Repository structure

auditd detection logic

The most useful detection is not a single event. The strongest signal is the full chain observed in a short time window:

user namespace -> vmsplice/splice -> ESP/XFRM -> su -> root shell with AUID of a normal user

Relevant auditd keys

Reconstructed event chain

Example SIEM correlation

IF
  dirty_frag_unshare by auid>=1000
  AND count(dirty_frag_vmsplice + dirty_frag_splice by same exe or pid) >= 3 within 600s
  AND MAC_IPSEC_EVENT / XFRM activity within 1200s
  AND (dirty_frag_su_exec OR execve with euid=0 and auid>=1000) within 1200s
THEN
  alert = "Possible DirtyFrag CVE-2026-43284 Linux LPE"
  severity = high/critical

SOC recommendations

• Patch the kernel and enforce reboot into the patched kernel after updates.
• Collect syscall telemetry with auditd, Falco, eBPF-based tools or EDR.
• Do not alert on a single euid=0 event alone; this also catches legitimate sudo usage.
• Correlate unshare, vmsplice, splice, XFRM/ESP activity, su, and root process creation from a normal user session.
• Consider restricting kernel.unprivileged_userns_clone where application compatibility allows it.
• Review whether ESP/IPsec modules are required on a given host class and restrict unnecessary module loading where appropriate.
• Forward logs to a remote collector or SIEM; after LPE, local logs can be modified by the attacker.
• Monitor auditd quality: lost should remain 0 during testing and production monitoring.
• Maintain a Linux LPE triage playbook covering host isolation, audit log collection, running kernel verification and loaded module capture.

Notes

The collected auditd status showed lost=2555, which means some audit events may have been dropped. The key chain is still visible, but future tests should increase audit backlog and confirm lost=0 before running the PoC.

The report intentionally focuses on CVE-2026-43284 / XFRM/ESP to avoid mixing the SOC detection scope with other DirtyFrag-related paths.