Podman Rootless and the Copy Fail Exploit: What to Know

Copy Fail (CVE-2026-31431) is a Linux kernel bug in the algif_aead crypto socket module, disclosed on 29 April 2026. It lets an unprivileged local process write into page-cache pages of files it can only read, for example /usr/bin/su, and become root. The kernel side (affected versions, patching, the module mitigation) is covered in the AEAD socket flaw guide.

This article is about what it means for rootless Podman. Containers share the host kernel, so a process inside a container can use a kernel bug like any other process. The question is how far it gets.

What happens inside a rootless container

Andrea Veri ran the exploit in a rootless Podman container on Fedora 43 with a vulnerable 6.17 kernel. The exploit worked: it corrupted /usr/bin/su in the page cache and got root inside the container. But rootless Podman runs the container in a user namespace, where container UID 0 maps to the unprivileged host user who started it. The escalation stopped there: no host root, no escape.

Compare a rootful container, where container root is host root: the same exploit is far more dangerous there.

The remaining risk: the shared page cache

The page cache belongs to the host, not the container. The same write-up points out that containers using the same base image layers share the same cached pages. A compromised container could therefore tamper with the cached copy of a binary that other containers then run, breaking container-to-container isolation without ever touching the host.

What to do

1. Patch the kernel and reboot. That’s the fix. Updating Podman does nothing for this bug. See the AEAD guide.
2. Keep containers rootless. Check with podman info --format '{{.Host.Security.Rootless}}', which should print true.
3. Harden containers so container root is worth less. These are standard podman run options (and their Compose and Quadlet equivalents):

podman run -d \
  --user 1000:1000 \
  --cap-drop=all \
  --security-opt=no-new-privileges \
  --read-only \
  docker.io/library/nginx:latest

--security-opt=no-new-privileges stops processes from gaining privileges through setuid binaries, which is the route the public exploit uses after corrupting su. Running as a non-root --user and dropping all capabilities limits what a compromised process can do. Many images need some writable paths: add --tmpfs or volumes for those when using --read-only.

4. Until you’ve rebooted, Ubuntu’s module block (install algif_aead /bin/false in /etc/modprobe.d/) removes the attack path entirely, with the caveats described in the AEAD guide.

Image hygiene still matters

Copy Fail needs code execution inside the container, and the usual way that happens is an untrusted image or an internet-facing service. Pull from sources you trust, and pin images by digest for services you care about:

podman image inspect --format '{{.Digest}}' docker.io/library/nginx:latest

image: docker.io/library/nginx@sha256:<digest>

Signature verification in Podman is configured through /etc/containers/policy.json (see containers-policy.json(5)), not through a pull flag.

The takeaway

Rootless Podman did its job here: a kernel privilege escalation inside the container ended as an unprivileged host user. Patch the kernel, keep containers rootless and hardened, and remember that the shared page cache makes containers built from the same image less isolated from each other than they look.

What’s Next

• Your Container Is Not a Sandbox: Use MicroVMs Instead: Where the container security boundary actually ends, rootless included
• Self-Hosting Forgejo on Your Homelab: A GitHub-Free Git Server Setup: Run your own registry to eliminate dependency on Docker Hub and control image provenance
• Docker Compose for Homelab: What It Is and How to Use It: The Compose side of the comparison, and what Podman has to stay compatible with