CVE-2026-53361 — an unprivileged, container-escapable use-after-free in the AF_UNIX socket garbage collector. This is the single-vector (MSG_PEEK only) version.
The Bug
The AF_UNIX GC reclaims "in-flight" sockets that form unreachable reference
cycles. A concurrent MSG_PEEK on an in-flight fd takes a reference the GC's
census never counts, so the collector can free a socket that is still alive and
leave a dangling sk_buff. The peek is supposed to back off while a collection
runs, but the gc_in_progress flag it checks can read false mid-run, so the
peek slips through and the race is open.
Same interaction, fixed three times:
- CVE-2021-0920 —
cbcf01128d0a"af_unix: fix garbage collect vs MSG_PEEK" - CVE-2026-23394 —
e5b31d988a41"af_unix: Give up GC if MSG_PEEK intervened" - CVE-2026-53361 —
d82ba05263c6"af_unix: Set gc_in_progress to true in unix_gc()"
Targets
Vulnerable = affected by the bug. Targeted = covered by this exploit (single MSG_PEEK vector). The 7.x kernels and the Ubuntu 6.8 GA kernel are vulnerable but out of scope here.
| Target | Kernel | Vulnerable | Patched | Targeted |
|---|---|---|---|---|
| Stable 6.12 | 6.12 |
Y | 6.12.95 |
up to 6.12.94 |
| Ubuntu 24.04 HWE | 6.17 |
Y | N | up to 6.17.0-41 |
| Ubuntu 24.04 GA | 6.8 |
Y | N | N (non-PEEK vector) |
| RHEL 10 | 6.12 |
Y | N | Y |
| Debian trixie | 6.12 |
Y | DSA-6381-1 | up to 6.12.94+deb13-cloud-amd64 |
A Few Kernels Tested
| Line | Latest tested kernel | Build date |
|---|---|---|
| Debian 13 (trixie) | 6.12.94+deb13-cloud-amd64 |
Jun 20, 2026 |
| Ubuntu 24.04 (6.17) | 6.17.0-41-generic |
Jun 30, 2026 |
| Ubuntu 24.04 (6.14) | 6.14.0-37-generic |
Nov 20, 2025 (old HWE) |
| CentOS Stream 10 | 6.12.0-257.el10 |
Aug 6, 2026 13:25 GMT |
| RHEL 10.2 / AlmaLinux | 6.12.0-211.43.1.el10_2 |
Aug 6, 2026 17:19 GMT |
Notes
- CPU count — designed for fewer than 8 CPUs (2–7). A choice, not a reliability quirk: the clean order-N strategy is left out on purpose, not worth exposing it for a -1 day bug.
- SLUB Cache Armoring — most cache-armoring/shadowing code was stripped from the
PoC. The SID-leak phase can occasionally collide with a spurious low-order
kmalloc()or a specific per-cache PCP reuse (anon_vma,kmalloc-64, and friends); the higher buckets are safe, the dedicated caches and lower buckets are not. Add your own armoring to push it toward ~100%.