DEV Community

jeffrey
jeffrey

Posted on

CVE-2026-80521: An AF_UNIX Use-After-Free That Crosses the Container Boundary

#linuxkernel #afunix #containerescape #cve202680521

CVE-2026-80521: An AF_UNIX Use-After-Free That Crosses the Container Boundary

Opening

A container is supposed to be a boundary. CVE-2026-80521 is a Linux kernel use-after-free in the AF_UNIX subsystem that lets an unprivileged process inside a container reach the host, and the reason it matters is not the exploit technique. It is that the control the whole model leans on, the seccomp filter, allows the syscall this bug needs.
DepthFirst published a working exploit for Ubuntu 26.04 on 2026-09-22. Distribution kernels, including the ones cloud providers ship, were still without a fix at that point.

Technical context

AF_UNIX sockets are the local inter-process transport on Linux. They are used by systemd, by container runtimes, by databases, by logging daemons and by almost everything that needs to talk to something else on the same machine. Blocking socket(AF_UNIX) outright breaks most of userspace, which is why the default seccomp profiles in Docker and Kubernetes permit it.
The defect is in the edge-tracking code that maintains the socket's connection graph. The upstream fix references af_unix: Unlink scc_entry in unix_del_edge(), which describes an entry left linked after the edge that owned it was removed. A freed structure remains reachable, and the shape of the allocation is such that a process which can trigger the sequence controls what is read back.
That control is what turns a memory-corruption bug into a boundary crossing. The kernel structures involved sit outside the namespaces a container defines, so the escape does not depend on a misconfigured volume mount or a privileged flag. It depends on being able to run code and to open a socket.
The vulnerability is rated 7.8. The upstream fix landed on 2026-08-06 and is present in 7.2 and 7.1.10. Ubuntu 22.04, 24.04 and 26.04 LTS kernels, including the variants built for AWS, Azure and GCP, did not have a distribution patch when the exploit became public.

Explanation or walkthrough

The exploit path runs in three parts. A process inside the container triggers the edge removal sequence through AF_UNIX socket operations, repeatedly, to shape the heap. The dangling reference is then used to read and write memory that belongs to the kernel rather than to the container's namespace. Because the allocator state is predictable after the shaping step, the write lands on a structure the process can use to escalate to root on the host.
None of the three parts requires a capability a normal container is denied. The seccomp profile that ships with Docker and Kubernetes permits socket creation for AF_UNIX, so the first step is available to any process that can execute code. That includes a compromised application, a malicious dependency, a build job and a scheduled task.
This is the part worth sitting with. Container isolation has three layers in common use: namespaces, cgroups and seccomp. Namespaces and cgroups partition and limit resources, and a kernel memory bug is not confined by either, because the resource being reached is kernel memory rather than a namespaced object. Seccomp is the layer that constrains which kernel interfaces are reachable at all, and it is the one that had to allow the syscall family in question for ordinary software to function. When those two facts meet, the isolation guarantee for a kernel bug of this class is thinner than the deployment diagram suggests.
Severity ratings across vendors differ because they weigh the escape against the local-access requirement. A 7.8 is a fair reading if you assume the container is already running untrusted code under an account that cannot do much. That assumption is exactly what multi-tenant build systems, notebook platforms and function-as-a-service runtimes make, and it is what makes the rating look low for those environments.

Defensive implications

Patch the kernel. There is no user-space change that removes the underlying bug, and the upstream fix is the only complete answer. Track the distribution advisory rather than the upstream commit, because the affected cloud kernels are the ones that matter in practice.
Where the patch has not arrived, close the syscall path. A custom seccomp profile that denies socket(AF_UNIX) removes the trigger, at the cost of breaking workloads that need local IPC. That is a real trade, and it is why this mitigation belongs on the highest-risk workloads rather than fleet-wide. Denying AF_UNIX in a workload that does not use it costs nothing.
For workloads that must keep AF_UNIX and cannot wait, the answer is a different isolation boundary. Firecracker and Kata Containers put a hypervisor between the workload and the host kernel, which means a kernel memory bug in the host does not hand over the host. That migration is a larger project than a seccomp profile, and for a multi-tenant platform running untrusted code it is the durable fix rather than the emergency one.
Assume compromise for anything that ran untrusted code before the patch. A kernel escape leaves limited traces by design, so the practical response is credential rotation and a rebuild from known state rather than a hunt for a specific artifact.
Two habits pay off independently of this bug. Audit what the default seccomp profile actually permits instead of assuming it is restrictive, and keep a current inventory of which kernel version each node is running. The first tells you which syscalls your threat model has to cover. The second is the only way to know when the gap closes.

References

Top comments (0)