← Back to Feed CACHED · 2026-09-23 15:02:35 · CACHE_KEY CVE-2026-80521
CVE-2026-80521 · CWE-416 · Disclosed 2026-08-26

In the Linux kernel

ASSESSED — NOISGATE
Vendor
Reassessed
Verdict:
Do you agree?
01 · The Real Story

Someone left the prison door unlocked and published the blueprints on the internet yesterday

CVE-2026-80521 is a use-after-free in the Linux kernel's AF_UNIX socket garbage collector, introduced when the GC was rewritten to use a Strongly Connected Component (SCC) graph model in kernel 6.10 (later backported to 6.1.x and 6.6.x stable branches). When unix_del_edge() frees a vertex, it fails to call list_del_init(&vertex->scc_entry), leaving a dangling pointer in the cached SCC list. The next GC pass follows that pointer into freed memory. An unprivileged process inside a default Docker or Kubernetes container can win this race deterministically, reclaim the freed slab with controlled data, forge a fake vertex with a skb destructor pointing to call_umh_work, and land an interactive root shell on the host. Affected kernels span 6.1.x, 6.6.x, and 6.10 through 7.1.9; the fix landed upstream on August 6, 2026 in 7.1.10 and 7.2.

The vendor CVSS of 7.8 HIGH undervalues this bug dramatically. The vector AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H treats it as a standard local privilege escalation, but it ignores the container-escape dimension entirely — S:U (Scope: Unchanged) is wrong when the exploit crosses namespace, cgroup, and seccomp boundaries from an unprivileged container to host root. DepthFirst published a working exploit on September 22, 2026 — yesterday — and no Ubuntu LTS release has shipped a patch for any of its supported kernels, including AWS, Azure, and GCP variants. This is a zero-day gap for the most popular server Linux distribution.

"Public container-escape exploit with no distro patches — upgrade to CRITICAL immediately"
02 · The Attack Path

5 steps from start to impact.

STEP 01

Gain code execution inside a container

The attacker needs an execution context inside a Docker or Kubernetes container. This can come from a compromised application (RCE in a web service), a supply-chain poisoned image, a malicious tenant in a multi-tenant cluster, or a CI/CD job. No special privileges or capabilities beyond the container's default are required.
Conditions required:
  • Code execution inside a Linux container or local shell on a host running a vulnerable kernel (6.1.x/6.6.x/6.10–7.1.9)
Where this breaks in practice:
  • Requires initial access — not remotely exploitable from the network without a prior foothold
Detection/coverage: Application-layer IDS, image scanning (Trivy, Snyk Container), admission controllers (OPA/Gatekeeper, Kyverno) for known-bad images
STEP 02

Build cyclic AF_UNIX socket topology

The exploit creates cyclic AF_UNIX socket pairs and passes file descriptors via SCM_RIGHTS to force the GC into the SCC fast-walk cached path. This involves creating ~252+ file descriptors per sendmsg() call. All syscalls used are permitted by Docker's default seccomp profile and Kubernetes' RuntimeDefault profile.
Conditions required:
  • AF_UNIX sockets available (default in all container runtimes)
  • SCM_RIGHTS descriptor passing available (default)
Where this breaks in practice:
  • None — these are core IPC primitives that cannot be disabled without breaking systemd, D-Bus, and container runtimes
Detection/coverage: Anomaly detection on rapid AF_UNIX socket creation and large SCM_RIGHTS batches (252+ descriptors) from containerized processes; Falco rules can flag this pattern
STEP 03

Win the GC race condition

The exploit uses calibrated jitter and a pipe marker to synchronize with the garbage collector's timing window. When unix_add_edges() publishes a new edge before the skb is queued, and socket closure triggers GC, the partially freed SCC vertex remains linked via its scc_entry pointer. DepthFirst describes the race as deterministic after calibration, not probabilistic.
Conditions required:
  • Timing control over GC scheduling (achieved via calibration, no special privileges)
Where this breaks in practice:
  • Race-condition exploits can be flaky across kernel versions and CPU architectures, but DepthFirst's published exploit handles this
Detection/coverage: Kernel oops in unix_scc_dead() or soft-lockup warnings in dmesg; SIEM rules on kernel panic/oops patterns
STEP 04

Reclaim freed memory via AF_PACKET RX rings

The exploit drains kmalloc-96 slabs and reclaims the freed vertex with attacker-controlled data using AF_PACKET TPACKET_V1 RX ring allocations. It uses /proc/kpagecount as a physical page oracle to bypass KASLR and slab randomization. This step requires CAP_NET_RAW, which Docker grants by default but Kubernetes Pod Security Standards Restricted policy drops.
Conditions required:
  • CAP_NET_RAW capability (Docker default, K8s Baseline allows it, only Restricted drops it)
  • Access to /proc/kpagecount (available in default container mounts)
Where this breaks in practice:
  • Dropping CAP_NET_RAW blocks this specific reclamation primitive
  • Restricting /proc/kpagecount access degrades the KASLR bypass oracle
  • Kubernetes Restricted PSS would block this step
Detection/coverage: AF_PACKET RX-ring allocations from containerized processes; /proc/kpagecount reads from non-root namespaces
STEP 05

Forge fake vertex and execute host root shell

The attacker forges a fake vertex structure in the reclaimed slab, setting the skb destructor to point to call_umh_work. When the GC follows the dangling scc_entry pointer and processes the forged vertex, it triggers controlled kernel code execution, spawning a usermode helper process as root on the host — outside all container isolation boundaries.
Conditions required:
  • Successful memory reclamation from step 4
  • KASLR bypass from /proc/kpagecount oracle
Where this breaks in practice:
  • If the slab reclamation fails or the KASLR bypass is blocked, the exploit degrades to a kernel panic (DoS) rather than code execution
Detection/coverage: Unexpected usermode helper invocations; container-escape detection in Falco/Tetragon (process spawned outside expected namespace hierarchy)
03 · Intelligence Metadata

The supporting signals.

In-the-Wild ExploitationNo confirmed attacks as of 2026-09-23. Not listed in CISA KEV. However, a public weaponized exploit was released by DepthFirst on September 22, 2026 — exploitation is imminent, not theoretical.
Proof-of-ConceptPublic exploit available. DepthFirst published a working container-escape exploit targeting Ubuntu 26.04 on 2026-09-22. The exploit achieves deterministic host root shell from an unprivileged default Docker container. DepthFirst won a Google kernelCTF slot on 2026-07-24.
EPSS Score0.00128 (low percentile) — EPSS has not yet caught up to the public exploit release. Expect a significant jump in the next EPSS update.
CISA KEV StatusNot listed as of 2026-09-23. Given the public exploit and unpatched distro status, KEV listing is likely if in-the-wild exploitation is confirmed.
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H (7.8 HIGH). The S:U (Scope Unchanged) designation is arguably incorrect — the exploit crosses container isolation boundaries (namespaces, cgroups, seccomp) to reach the host kernel, which constitutes a scope change.
Affected VersionsIntroduced in kernel 6.10 (commit 4090fa37), backported to 6.1.x and 6.6.x stable branches. Affects Ubuntu 22.04 LTS, 24.04 LTS, and 26.04 LTS including AWS, Azure, GCP, NVIDIA, OEM, and Realtime kernel variants.
Fixed VersionsMainline 7.2 (commit 594d9051), stable 7.1.10 (commit e3702470). No Ubuntu, Debian, or RHEL patches have shipped as of 2026-09-23. Ubuntu tracker shows all affected releases as *work in progress*.
Scanning / ExposureNot remotely scannable — requires local/container access. However, any Linux host running kernels 6.1.x/6.6.x/6.10–7.1.9 with containers is exposed. This encompasses a vast majority of Ubuntu cloud instances on AWS, Azure, and GCP.
Disclosure Timeline2026-07-24: DepthFirst wins kernelCTF slot. 2026-08-05: Reported to kernel security. 2026-08-06: Upstream fix merged (7.1.10, 7.2). 2026-08-26: CVE published. 2026-09-22: DepthFirst publishes exploit. 2026-09-23: No distro patches shipped.
ResearchersKyle Zeng (independent kernel researcher, credited in upstream commit), DepthFirst (AI-assisted discovery using dfs-large1 model), OpenAI (independent report). Discovery partially AI-accelerated.
04 · The Call

Final Verdict
UPGRADED to CRITICAL (9.0/10)

Why this verdict

  • Public weaponized exploit released yesterday: DepthFirst published a working container-escape exploit on 2026-09-22 targeting Ubuntu 26.04. The exploit is described as deterministic after calibration, not probabilistic. This eliminates the 'theoretical only' friction that normally tempers kernel race conditions.
  • Zero distro patches available: Ubuntu 22.04, 24.04, and 26.04 — including all cloud kernel variants (AWS, Azure, GCP) — remain unpatched as of 2026-09-23. The upstream fix has been available since August 6, making this a 48-day patch gap with no relief in sight.
  • Default container configurations are fully exposed: The exploit uses only AF_UNIX sockets, SCM_RIGHTS, and standard syscalls — all permitted by Docker's default seccomp profile, Kubernetes RuntimeDefault, and even Pod Security Standards Baseline. No --privileged, no CAP_SYS_ADMIN, no kernel module loading. The only partial friction point is CAP_NET_RAW for the AF_PACKET oracle, which Docker grants by default.
  • Role multiplier: The affected component is the Linux kernel itself — 100% of Linux installs run it by definition. Container hosts (Kubernetes workers, Docker hosts, CI/CD runners) represent a substantial and growing fraction of enterprise Linux deployments (conservatively >30%). On a Kubernetes worker node, container escape to host root means: (1) access to all pod secrets and service account tokens on that node, (2) ability to pivot to the kubelet credential and impersonate the node to the API server, (3) potential to compromise the entire cluster. On CI/CD runner hosts, container escape means supply-chain pivot. On database hosts running containerized databases, it means mass data exfiltration. The blast radius is fleet-scale to supply-chain-scale, and the affected component is canonically high-value — verdict floor is CRITICAL.
  • Scope undercount in vendor CVSS: The vendor vector uses S:U (Scope Unchanged), but the demonstrated attack crosses from an unprivileged container namespace to host root, definitively changing the security scope. A corrected vector with S:C would push the base score above 9.0.

Why not higher?

A score of 9.0 rather than 9.8+ reflects that the attack still requires initial code execution inside a container — it is not remotely exploitable from the network without a prior foothold. The CAP_NET_RAW requirement for the full exploit chain (while default in Docker) is droppable, and Kubernetes Restricted PSS does drop it, providing a partial population reduction. The exploit targets a specific slab allocator path that may need re-tuning across kernel minor versions and architectures.

Why not lower?

A public, deterministic exploit exists as of yesterday, no distribution patches are available, and the default configurations of Docker and Kubernetes are fully exposed. The affected component is the Linux kernel — every Linux server runs it — and container hosts are a canonical high-value deployment role representing well over 10% of the installed base. The demonstrated blast radius (container escape → host root → node takeover → cluster compromise) is fleet-scale. Downgrading below CRITICAL would require evidence that container hosts are a niche deployment pattern (they are not) or that the exploit is unreliable (DepthFirst says it is deterministic).

05 · Compensating Control

What to do — in priority order.

  1. Drop CAP_NET_RAW from all containers immediately — The DepthFirst exploit requires CAP_NET_RAW for the AF_PACKET TPACKET_V1 physical page oracle that enables reliable slab reclamation and KASLR bypass. Dropping this capability degrades the exploit from deterministic code execution to a probabilistic kernel panic (DoS). In Docker: --cap-drop=NET_RAW. In Kubernetes: set securityContext.capabilities.drop: ["NET_RAW"] or enforce Pod Security Standards Restricted. Deploy within 3 days per noisgate mitigation SLA for CRITICAL.
  2. Restrict /proc/kpagecount and /proc/kpageflags access from containers — The exploit uses /proc/kpagecount as a physical page oracle to bypass KASLR and slab randomization. Mask or block these proc interfaces from container mount namespaces using AppArmor/SELinux profiles or OCI runtime configuration. Deploy within 3 days.
  3. Enforce Kubernetes Pod Security Standards Restricted on all namespaces — PSS Restricted drops CAP_NET_RAW and applies additional constraints that degrade the exploit chain. For clusters not yet using PSS, this is the single most impactful policy change. Apply namespace-level enforcement via pod-security.kubernetes.io/enforce: restricted labels. Deploy within 3 days.
  4. Deploy Falco or Tetragon runtime detection rules — Add rules to detect: (1) rapid AF_UNIX socket creation (>100/sec from a single container), (2) large SCM_RIGHTS batches (252+ descriptors), (3) AF_PACKET RX-ring allocations from containers, (4) /proc/kpagecount reads from non-init namespaces, (5) unexpected process spawns outside container namespace hierarchy. These provide detection-in-depth while patches are unavailable. Deploy within 3 days.
  5. Migrate untrusted and multi-tenant workloads to microVM isolation — Firecracker, Kata Containers, or gVisor provide a hardware-level isolation boundary that kernel-level container escapes cannot cross. This is the only complete mitigation until kernel patches ship. Prioritize CI/CD runners, multi-tenant SaaS workloads, and any container running third-party or user-supplied code. Begin migration within 3 days; complete within 30 days.
  6. Apply upstream kernel 7.1.10 or 7.2 manually where distro patches are unavailable — The upstream fix (commit 594d9051) is a one-line list_del_init() addition. For organizations with kernel build capability, cherry-picking or upgrading to 7.1.10/7.2 eliminates the vulnerability entirely. Test thoroughly before deploying to production — this is a kernel update. Target within 3 days for critical container hosts; deploy fleet-wide within noisgate remediation SLA of 90 days.
What doesn't work
  • Default Docker seccomp profile — does not block AF_UNIX sockets or SCM_RIGHTS, which are the core primitives the exploit uses. The default profile was never designed to prevent kernel exploitation via standard IPC.
  • Kubernetes Pod Security Standards Baseline — allows CAP_NET_RAW, which the exploit requires for reliable slab reclamation. Only the Restricted level drops it.
  • Network policies and firewalls — this is a local kernel exploit reachable via local IPC, not a network attack. Network segmentation provides zero protection.
  • Container image scanning (Trivy, Snyk, Grype) — these scan for vulnerable packages inside images, not for host kernel vulnerabilities. They will not flag this CVE.
  • Read-only root filesystem — the exploit operates entirely through syscalls and memory manipulation, never touching the filesystem. readOnlyRootFilesystem: true does not help.
  • Custom seccomp profile blocking AF_UNIX — while technically effective, blocking AF_UNIX sockets breaks systemd, D-Bus, container runtimes (containerd/CRI-O communicate via AF_UNIX), and virtually every system service. This is not deployable in practice.
06 · Verification

Crowdsourced verification payload.

Run this script on each target Linux host (not inside a container) as any user with read access to /proc/version_string and uname. No special privileges required. Example: chmod +x check_cve_2026_80521.sh && ./check_cve_2026_80521.sh

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/bin/bash
# CVE-2026-80521 Checker — af_unix SCC entry use-after-free
# Checks if the running kernel is in the affected version range.
# Exit codes: 1=VULNERABLE, 0=PATCHED, 2=UNKNOWN

set -euo pipefail

KERNEL_VERSION=$(uname -r)
MAJOR=$(echo "$KERNEL_VERSION" | cut -d. -f1)
MINOR=$(echo "$KERNEL_VERSION" | cut -d. -f2)
PATCH=$(echo "$KERNEL_VERSION" | cut -d. -f3 | cut -d- -f1)

echo "[*] CVE-2026-80521 Check"
echo "[*] Running kernel: $KERNEL_VERSION"
echo ""

# Vuln introduced in 6.10 (commit 4090fa37), backported to 6.1.x and 6.6.x stable.
# Fixed in 7.1.10 and 7.2.

# Check if kernel has the fix applied via changelog/patch marker
if [ -f /proc/version ]; then
    PROC_VERSION=$(cat /proc/version)
else
    PROC_VERSION=""
fi

vulnerable=0

if [ "$MAJOR" -lt 6 ]; then
    echo "[+] Kernel $MAJOR.x predates the vulnerable SCC GC rewrite (6.10)."
    echo "PATCHED"
    exit 0
elif [ "$MAJOR" -eq 6 ] && [ "$MINOR" -lt 1 ]; then
    echo "[+] Kernel 6.$MINOR.x predates backported SCC GC code."
    echo "PATCHED"
    exit 0
elif [ "$MAJOR" -eq 6 ] && [ "$MINOR" -ge 1 ] && [ "$MINOR" -le 6 ]; then
    # 6.1.x and 6.6.x received backports of the vulnerable SCC code
    echo "[!] Kernel 6.$MINOR.x received SCC GC backport — likely VULNERABLE."
    vulnerable=1
elif [ "$MAJOR" -eq 6 ] && [ "$MINOR" -ge 10 ]; then
    # 6.10+ is where the SCC GC was originally introduced
    echo "[!] Kernel 6.$MINOR.x contains original SCC GC code — VULNERABLE."
    vulnerable=1
elif [ "$MAJOR" -eq 7 ] && [ "$MINOR" -eq 0 ]; then
    echo "[!] Kernel 7.0.x predates the fix (7.1.10 / 7.2) — VULNERABLE."
    vulnerable=1
elif [ "$MAJOR" -eq 7 ] && [ "$MINOR" -eq 1 ]; then
    if [ -n "$PATCH" ] && [ "$PATCH" -ge 10 ]; then
        echo "[+] Kernel 7.1.$PATCH contains the fix (>=7.1.10)."
        echo "PATCHED"
        exit 0
    else
        echo "[!] Kernel 7.1.$PATCH predates the fix (7.1.10) — VULNERABLE."
        vulnerable=1
    fi
elif [ "$MAJOR" -eq 7 ] && [ "$MINOR" -ge 2 ]; then
    echo "[+] Kernel 7.$MINOR.x contains the fix (>=7.2)."
    echo "PATCHED"
    exit 0
elif [ "$MAJOR" -gt 7 ]; then
    echo "[+] Kernel $MAJOR.x is newer than the fix."
    echo "PATCHED"
    exit 0
else
    echo "[?] Could not determine vulnerability status for kernel $KERNEL_VERSION."
    echo "UNKNOWN"
    exit 2
fi

if [ "$vulnerable" -eq 1 ]; then
    # Additional check: see if distro backported the fix
    # Look for the fix commit message in kernel changelog if available
    FIX_MARKER="594d905195024b228c962627ae5ae7c17bd582a4"
    PATCHED_BY_DISTRO=0
    if command -v dpkg &>/dev/null; then
        CHANGELOG="/usr/share/doc/linux-image-${KERNEL_VERSION}/changelog.Debian.gz"
        if [ -f "$CHANGELOG" ]; then
            if zgrep -q "$FIX_MARKER" "$CHANGELOG" 2>/dev/null || zgrep -q "CVE-2026-80521" "$CHANGELOG" 2>/dev/null; then
                PATCHED_BY_DISTRO=1
            fi
        fi
    elif command -v rpm &>/dev/null; then
        if rpm -q --changelog kernel-"$KERNEL_VERSION" 2>/dev/null | grep -q "CVE-2026-80521"; then
            PATCHED_BY_DISTRO=1
        fi
    fi

    if [ "$PATCHED_BY_DISTRO" -eq 1 ]; then
        echo "[+] Distro has backported the CVE-2026-80521 fix."
        echo "PATCHED"
        exit 0
    fi

    # Check if containers are running (amplifies risk)
    CONTAINER_RISK=""
    if command -v docker &>/dev/null && docker info &>/dev/null 2>&1; then
        RUNNING=$(docker ps -q 2>/dev/null | wc -l)
        if [ "$RUNNING" -gt 0 ]; then
            CONTAINER_RISK=" ($RUNNING Docker containers running — container escape risk is ACTIVE)"
        fi
    fi
    if command -v crictl &>/dev/null; then
        PODS=$(crictl pods -q 2>/dev/null | wc -l)
        if [ "$PODS" -gt 0 ]; then
            CONTAINER_RISK=" ($PODS Kubernetes pods running — container escape risk is ACTIVE)"
        fi
    fi

    echo ""
    echo "[!] VULNERABLE — kernel $KERNEL_VERSION is affected by CVE-2026-80521$CONTAINER_RISK"
    echo "[!] Upgrade to kernel >= 7.1.10 or >= 7.2, or apply distro patch when available."
    echo "VULNERABLE"
    exit 1
fi
07 · Sources

Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.