cfDr - Copy Fail Doctor

Copy Fail Detection and Remediation

An Ansible role and playbook suite for detecting and remediating CVE-2026-31431 (Copy Fail), a critical local privilege escalation vulnerability in the Linux kernel's algif_aead module.

Repository

🔗 GitHub: https://github.com/parmstro/cfDr

The name cfDr is a play on "Copy Fail Doctor" - your trusted remedy for CVE-2026-31431.

---

Table of Contents

1. Understanding CVE-2026-31431
2. Available Remediations
3. Detection Methodology
4. How cfDr Works
5. Impact on System Cryptography
6. Recommended Workflow
7. Additional Resources
8. Monitoring for Patches
9. Quick Start
10. Advanced Configuration

---

Understanding CVE-2026-31431

What is Copy Fail?

CVE-2026-31431 (CVSS 7.8) is a logic flaw in the Linux kernel's AEAD socket interface (AF_ALG) discovered in 2026. The vulnerability allows any unprivileged local user to escalate privileges to root in seconds.

Technical Details

• Affected Component: algif_aead kernel module (AF_ALG crypto interface)
• Vulnerability Type: Logic flaw in copy operation handling
• Attack Vector: Local
• Privileges Required: None (unprivileged user)
• User Interaction: None
• Impact: Complete system compromise (root access)

Affected Systems

Kernel Versions: Linux kernel >= 4.10 (released 2017)

Distributions Affected:

• Red Hat Enterprise Linux 7, 8, 9
• CentOS 7, 8, 9 (and Stream)
• Fedora (all currently supported versions)
• Ubuntu 17.04 and later
• Debian 9 (Stretch) and later
• SUSE Linux Enterprise 12, 15

Note: Any Linux distribution with kernel 4.10 or newer is potentially vulnerable.

Why This Matters

This vulnerability is particularly dangerous because:

1. No privileges required - Any user account can exploit it
2. Instant escalation - Root access in seconds
3. Widespread impact - Affects 7+ years of kernel releases
4. Local execution - No remote access needed, but attackers who gain initial foothold can immediately escalate
5. Active exploitation - Public exploits are available

Real-World Impact

Once an attacker has any form of local access (SSH, web shell, container escape, etc.), they can:

• Gain complete control of the system
• Install persistent backdoors
• Access sensitive data
• Pivot to other systems on the network
• Deploy ransomware or cryptominers

---

Available Remediations

While waiting for vendor-supplied kernel patches, several mitigation strategies are available. cfDr implements all of them, with intelligent recommendations based on your system configuration.

Understanding Protection Levels

Not all remediations are equal. Here's what you need to know:

Method	Can Root Bypass?	Coverage	Enterprise Linux Support
Module Blacklist	✅ Yes (via insmod)	Prevents modprobe loading	All versions
SELinux Policy	❌ NO (LSM layer)	Configured domains only	All versions (default)
systemd seccomp	❌ NO (syscall filter)	Configured services only	All versions
eBPF LSM	❌ NO (LSM layer)	System-wide (if configured)	RHEL 9+, Fedora 34+

Recommended Approach: Defense-in-Depth

cfDr's default recommendation: Flag 3 (Module Blacklist + SELinux)

This provides two independent protection layers:

┌─────────────────────────────────────────────────┐
│  Layer 1: Module Blacklist                      │
│  • Prevents modprobe algif_aead                 │
│  • Persists across reboots                      │
│  • CAN be bypassed by malicious root (insmod)   │
├─────────────────────────────────────────────────┤
│  Layer 2: SELinux Policy                        │
│  • Blocks AF_ALG socket() at syscall level      │
│  • Works even if module is loaded               │
│  • CANNOT be bypassed from userspace            │
│  • Covers user_t, unconfined_t (majority cases) │
└─────────────────────────────────────────────────┘

Result: If either layer fails, the other still protects

Why Module Blacklist Alone Is Not Enough

A determined attacker with root access can bypass module blacklisting:

# Module blacklist DOES NOT prevent:
insmod /lib/modules/$(uname -r)/kernel/crypto/algif_aead.ko.xz

However, this is acceptable because:

1. The vulnerability targets privilege escalation (unprivileged → root)
2. If an attacker already has root, they can exploit directly without loading the module
3. Module blacklist protects against the primary attack vector

Complete Protection Strategy

For complete, non-bypassable protection, you need:

Module Blacklist + at least one of:

• SELinux policy (recommended for Enterprise Linux)
• systemd seccomp filters (per-service protection)
• eBPF LSM program (RHEL 9+ only, system-wide)

Mitigation Flag Reference

cfDr uses bitwise flags to enable multiple mitigations:

Flag Value	Mitigations Enabled	Use Case
1	Module Blacklist only	Minimal protection, systems without SELinux
2	SELinux only	SELinux-only environments
3	Module Blacklist + SELinux	RECOMMENDED default
5	Module Blacklist + seccomp	Non-SELinux with service hardening
7	Module Blacklist + SELinux + seccomp	Enhanced protection
15	All mitigations	Maximum protection (RHEL 9+ only)

Calculate flags: 1 (blacklist) + 2 (SELinux) + 4 (seccomp) + 8 (eBPF) = sum

Coverage Gaps to Be Aware Of

SELinux Protection:

• Only covers domains specified in the policy: user_t, unconfined_t, httpd_t, postgresql_t, mysqld_t
• Processes running in other SELinux domains may not be protected
• In practice, user_t and unconfined_t cover the vast majority of attack scenarios

systemd seccomp Protection:

• Only protects services explicitly configured
• Default configuration covers: httpd, nginx, postgresql, mariadb, redis, memcached
• Processes outside these services are not protected

eBPF LSM Protection:

• Requires kernel 5.7+ (RHEL 9, Fedora 34+)
• Complexity requires expertise to implement correctly
• Can provide comprehensive system-wide protection if configured properly

---

Detection Methodology

How cfDr Detects Vulnerability

cfDr performs comprehensive assessment across multiple dimensions:

1. Kernel Version Check

uname -r

• Determines if kernel version >= 4.10 (vulnerable range)
• Identifies kernel release and distribution

2. Module Availability Check

modinfo algif_aead

• Verifies if algif_aead module exists in the kernel
• Checks module location and metadata

3. Module Load Status

lsmod | grep algif_aead

• Determines if module is currently loaded
• Critical: Loaded module = actively exploitable

4. Active Socket Detection

lsof -U | grep AF_ALG

• Identifies active AF_ALG sockets
• Indicates potential active exploitation

5. Existing Mitigation Detection

Module Blacklist:

grep -E "blacklist algif_aead|install algif_aead" /etc/modprobe.d/*.conf

SELinux Policy:

semodule -l | grep cve_2026_31431_af_alg_deny

systemd seccomp:

systemctl show <service> | grep RestrictAddressFamilies

6. Categorical Status Determination

cfDr categorizes each host into one of these states: