Exploit for CVE-2026-31431

## https://sploitus.com/exploit?id=C119AF33-63EE-58F0-913B-AB549837B701
# CVE-2026-31431-Copy-Fail---Vulnerability-Detection-Script
Detection Only.. working on an exploit PoC.
This script is for sysadmins trying to determine where they are vulnerable/still vulnerable after patching.

## What's this about?

On April 29th 2026, a vulnerability called **Copy Fail** (CVE-2026-31431) was publicly disclosed by the Xint Code Research Team. It's a logic bug that's been quietly sitting in the Linux kernel since roughly **2017** — nearly a decade — and it lets any unprivileged local user get root.

Not "get root under specific conditions with some luck and a good tailwind." Just... get root. Reliably. On essentially every major Linux distribution.

It affects Ubuntu, Amazon Linux, RHEL, SUSE, and anything else running a mainstream kernel from the last ~8 years. Same script, no recompilation, no per-distro tweaks required.

Yes, it's as bad as it sounds.


## The short version of how it works

The Linux kernel has a crypto subsystem that's accessible to unprivileged users via `AF_ALG` sockets. There's a mechanism called `splice()` that can feed file data directly into that subsystem without copying it — which means the kernel's in-memory cached copy of a file (the "page cache") ends up inside a cryptographic operation.

One specific algorithm — `authencesn`, used for IPsec Extended Sequence Numbers — has a quirk where it uses the output buffer as scratch space and writes 4 bytes slightly past where it's supposed to. Normally harmless. But when page cache pages from a setuid binary like `/usr/bin/su` end up chained into that output buffer (thanks to a 2017 "optimisation" in `algif_aead.c`), those 4 bytes land directly in the kernel's cached copy of the binary.

The operation fails with an error. The kernel never marks that page as dirty. The on-disk file is untouched. File integrity tools checking on-disk checksums see nothing wrong.

But the page cache is what gets executed. And `su` is setuid root.

The full technical writeup is over at [xint.io](https://xint.io/blog/copy-fail-linux-distributions) and is genuinely worth reading if you're into this sort of thing.


## What this script does

It checks your system for the conditions that make exploitation possible, and tells you *specifically* why you're vulnerable — not just "yes/no."

Seven checks:

| Check | What it's looking for |
|---|---|
| **Kernel version** | Is this kernel in the affected range (4.10–6.14)? |
| **Patch presence** | Is the fix commit actually in your running kernel? |
| **algif_aead module** | Is the vulnerable module loaded or loadable? |
| **AF_ALG socket** | Can an unprivileged user open one right now? |
| **Python os.splice** | Is the pure-Python exploit path available? |
| **Setuid binaries** | Are there readable setuid-root targets present? |
| **Mitigations** | AppArmor, SELinux, seccomp — what's in place? |

It won't fix anything. It won't exploit anything. It just tells you the truth about your system so you can act on it.


## Requirements

- Python 3.6+
- No external dependencies — stdlib only
- No root required (intentionally — we're checking what an unprivileged attacker can see)


## Usage

```bash
# Clone or download the script, then:
python3 cve_2026_31431_detect.py
```

That's it. It'll print a colour-coded report and a summary at the end.

### Example output

```
CVE-2026-31431 'Copy Fail' — Vulnerability Detection
authencesn page cache corruption / local privilege escalation
Running as uid=1001, euid=1001

=== Kernel Version ===
  [VULNERABLE] Kernel version
          Reason : Kernel is in the vulnerable range (4.10 – 6.14)
          Detail : Release: 6.12.0-124.45.1.el10_1 — patch status must be confirmed

=== algif_aead Module ===
  [VULNERABLE] algif_aead module
          Reason : Module is not loaded but will auto-load on AF_ALG bind() — no blacklist found

...

  SYSTEM IS LIKELY VULNERABLE TO CVE-2026-31431

  Recommended actions:
    1. Apply your distribution's kernel update for CVE-2026-31431
    2. Until patched, blacklist the module:
         echo 'install algif_aead /bin/false' > /etc/modprobe.d/disable-algif-aead.conf
         rmmod algif_aead 2>/dev/null
```

## Fixing it

**The real fix is patching your kernel.** Check your distribution's security advisories — they should all be shipping fixes now.

| Distribution | Where to look |
|---|---|
| Ubuntu | [ubuntu.com/security/CVE-2026-31431](https://ubuntu.com/security) |
| RHEL / Amazon Linux | `dnf update kernel` |
| SUSE | `zypper update kernel-default` |
| Debian | `apt update && apt upgrade` |

**While you're waiting for the patch** (or if you need an immediate stopgap), you can blacklist the vulnerable kernel module:

```bash
echo 'install algif_aead /bin/false' > /etc/modprobe.d/disable-algif-aead.conf
rmmod algif_aead 2>/dev/null
```

This prevents `algif_aead` from loading, which blocks the exploit path. It may affect IPsec if you're using it — worth checking before you deploy this fleet-wide.

**The upstream fix** is [this commit](https://github.com/torvalds/linux/commit/a664bf3d603dc3bdcf9ae47cc21e0daec706d7a5) — it reverts the 2017 in-place AEAD optimisation in `algif_aead.c`, separating the source and destination scatterlists so page cache pages can no longer end up in the writable destination.

## A note on scope

This script is for **detection only**. It doesn't attempt to exploit anything, doesn't modify your system (except reading `/proc` and a few other read-only interfaces), and produces no output beyond the report.

It's intended for internal security teams doing vulnerability assessments (benign check script, not malicious exploit code), not for anything else. You know who you are :P.

## Disclosure timeline

| Date | Event |
|---|---|
| 2026-03-23 | Reported to Linux kernel security team |
| 2026-03-24 | Acknowledged |
| 2026-03-25 | Patches proposed and reviewed |
| 2026-04-01 | Fix committed to mainline kernel |
| 2026-04-22 | CVE-2026-31431 assigned |
| 2026-04-29 | Public disclosure |

Credit to Taeyang Lee at Theori for the original research insight, and the Xint Code Research Team for the full disclosure writeup.

## Contributing

Found a false positive? A distribution this misses? A kernel config that should be checked? PRs welcome. The goal is accurate signal, not scary red text.


## Disclaimer

This tool is provided as-is for defensive security purposes. Point it at systems you're authorised to assess. Don't be weird about it.