Skip to main content
← Back to list
01Issue
BugShippedExtensionsPublic
Assigneesstack72

Relationships

↔ sibling #3776

#3814 @swamp/cve/dirtyfrag: scan flags suspicious XFRM SAs on every unprivileged Linux scan (greps 'error' in /proc/net/xfrm_stat counter names)

Opened by kagarmoe · 10/23/2026· Shipped 10/24/2026

Description

scan reports indicators.suspiciousXfrmSAs: true with "WARNING: XFRM Security Associations with sequential SPIs matching dirtyfrag pattern (0xDEADBE1x) detected" on any Linux host where it runs without root. No XFRM SAs exist. This is an indicator of compromise, so the false positive is alarming. It also contradicts the same scan's CLEAN verdict.

The cause is in models/dirtyfrag_detect.ts (v2026.10.22.2), around lines 522–527:

"(ip xfrm state list 2>/dev/null || cat /proc/net/xfrm_stat 2>/dev/null || echo '') | grep -ci 'deadbe1\\|error' || echo 0",
...
const suspiciousXfrm = parseInt(xfrmCheck.stdout) > 2;
  1. Without CAP_NET_ADMIN, ip xfrm state list fails ("RTNETLINK answers: Operation not permitted"), so the command falls back to /proc/net/xfrm_stat.
  2. /proc/net/xfrm_stat holds error counters, not SAs. Their names (XfrmInError, XfrmOutError, XfrmInHdrError, …) all contain "Error", so grep -ci 'deadbe1\|error' counts every one of them, even when every value is 0.
  3. That count is always over 2 (19 on kernel 6.18), so suspiciousXfrm is true.

Matching error against ip xfrm state output doesn't detect the SPI pattern either.

Steps to reproduce

On a Linux host, as a non-root user:

ip xfrm state list            # exits 1: Operation not permitted
(ip xfrm state list 2>/dev/null || cat /proc/net/xfrm_stat 2>/dev/null || echo '') | grep -ci 'deadbe1\|error' || echo 0
# -> 19
awk '$2 != 0' /proc/net/xfrm_stat   # -> nothing; every counter is 0
sudo ip xfrm state list | wc -l     # -> 0; there are no SAs

Then swamp behavior run <dirtyfrag-model> scan reports suspiciousXfrmSAs: true and "XFRM SAs" in the report's IOCs column.

Expected

  • Match only the SPI pattern (e.g. spi 0xdeadbe1[0-9a-f]) in ip xfrm state output.
  • Don't fall back to /proc/net/xfrm_stat for SA detection. If SA state can't be read unprivileged, report the indicator as unknown/not checked rather than true, or read it with sudo the way mitigate does.

Environment

  • @swamp/cve/dirtyfrag v2026.10.22.2
  • swamp 20261022.211048.0
  • WSL2 Ubuntu 26.04, kernel 6.18.54 (microsoft-standard-WSL2), scan run locally as a non-root user
02Bog Flow
✓OPEN✓TRIAGED✓IN PROGRESS✓SHIPPED+ 1 MOREASSIGNED+ 6 MOREREVIEW+ 9 MOREPR_LINKED+ 2 MORESESSION_SUMMARIZED

Shipped

10/24/2026, 1:41:05 AM

Click a lifecycle step above to view its details.

03Sludge Pulse
stack72 assigned stack7210/24/2026, 1:07:54 AM
stack72 linked sibling of #377610/24/2026, 1:08:48 AM
Editable. Press Enter to edit.

system commented 10/23/2026, 8:38:06 AM

Classified automatically when this issue was filed.

  • Source: Extensions

If you feel this classification is incorrect, add a ripple to tell us so.

stack72 commented 10/24/2026, 1:41:10 AM

Thanks @kagarmoe for reporting this! We shipped: Fix the false-positive XFRM IOC in the dirtyfrag scan: match only the 0xdeadbe1x SPI pattern in ip xfrm state output, drop the xfrm_stat fallback, and report the check as not checked when SA state is unreadable without root. Document that the check needs ip and sees only the scanning network namespace. Also switch the report and README to the swamp behavior command spelling (linked #3776). Version 2026.10.24.1.. The fix has been merged and a release is on its way. We appreciate your contribution to swamp.

Sign in to post a ripple.