CVE-2026-53361 AF_Unix GC vs. MSG_PEEK use-after-free container escape

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 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()" 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 | | 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 | - 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%.