CVE-2026-80713: Linux Kernel Privilege Escalation Vulnerability

CVE-2026-80713 Overview

CVE-2026-80713 is a Linux kernel vulnerability in the io_uring subsystem. Per-task restrictions installed on io_uring rings are dropped when a task calls exec. A ring created after exec runs without any of the previously enforced restrictions. This breaks the security boundary that per-task restrictions are intended to provide.

The kernel maintainers resolved the issue by splitting task context cleanup into io_uring_free_tctx() and calling it from the exec cancellation path, while retaining __io_uring_free() for final task cleanup.

Critical Impact

A local, low-privileged attacker can bypass io_uring per-task restrictions after exec, enabling operations that a restricted parent process was explicitly prevented from performing.

Affected Products

• Linux kernel versions containing the io_uring per-task restriction code path prior to the fix commits
• Distributions shipping stable kernels that have not yet backported commits bc0e8faf90e7 and fcef9325afee
• Workloads relying on IORING_REGISTER_RESTRICTIONS as a sandboxing primitive

Discovery Timeline

• 2026-08-28 - CVE-2026-80713 published to NVD
• 2026-08-29 - Last updated in NVD database

Technical Details for CVE-2026-80713

Vulnerability Analysis

The io_uring interface allows a task to install per-task restrictions through IORING_REGISTER_RESTRICTIONS. These restrictions constrain which opcodes, registration operations, and sqe flags any ring created by that task may use. The restrictions are stored in the task's io_uring task context (tctx) and are expected to persist for the lifetime of the task.

On exec, the kernel cancels outstanding io_uring work associated with the task. The cancellation path called __io_uring_free(), which released both the task context and the attached per-task restriction structure. When the post-exec program subsequently created a new ring, no restriction was present, and the ring operated without limits. This constitutes a kernel-level access control flaw [CWE-284] in a security-sensitive syscall interface.

Root Cause

The root cause is conflated cleanup semantics inside __io_uring_free(). The function was invoked both from the exec cancellation path, where the task continues to live, and from final task teardown, where the task exits. Because it freed the restriction object in both cases, the exec path incorrectly dropped state that must survive across exec.

The fix splits the logic. io_uring_free_tctx() handles context cleanup that is safe across exec, preserving the restriction. __io_uring_free() remains for final teardown, where releasing both context and restriction is correct.

Attack Vector

Exploitation requires local code execution as a low-privileged user. An attacker crafts a process that installs restrictive io_uring restrictions, then executes a follow-on binary via execve. After exec, the process creates a new io_uring instance and issues opcodes or registrations that the original restriction set forbade. The scope-changed impact reflects that the bypass can affect resources beyond the original restricted context.

See the kernel change notifications at commit bc0e8faf90e7 and commit fcef9325afee for the authoritative patch details.

Detection Methods for CVE-2026-80713

Indicators of Compromise

• Processes that call io_uring_register with IORING_REGISTER_RESTRICTIONS and subsequently invoke execve
• New io_uring_setup calls issued by a task immediately after exec, followed by opcodes outside the pre-exec restriction set
• Unexpected io_uring activity from binaries executed inside sandboxes or container runtimes that rely on task restrictions

Detection Strategies

• Audit execve events correlated with prior io_uring_register restriction calls from the same task lineage using auditd or eBPF-based telemetry
• Instrument io_uring_setup and io_uring_enter syscalls to log opcode usage per task and flag divergence across exec boundaries
• Review sandbox and container profiles that assume IORING_REGISTER_RESTRICTIONS survive exec and treat any post-exec ring creation as suspicious

Monitoring Recommendations

• Enable kernel audit rules for the io_uring_setup, io_uring_register, and io_uring_enter syscalls on multi-tenant hosts
• Alert on unprivileged processes that create io_uring instances shortly after execve in production workloads
• Track kernel version and patch level across the fleet to identify hosts missing the upstream fix

How to Mitigate CVE-2026-80713

Immediate Actions Required

• Apply the stable kernel updates containing commits bc0e8faf90e7 and fcef9325afee as soon as vendor builds are available
• Inventory hosts and container images that rely on io_uring per-task restrictions as a sandbox boundary
• Restrict access to io_uring for untrusted workloads until patched kernels are deployed

Patch Information

The upstream fix introduces io_uring_free_tctx() and calls it from the exec cancellation path, preserving per-task restrictions across exec. __io_uring_free() is retained for final task cleanup. Refer to commit bc0e8faf90e7 and commit fcef9325afee for the authoritative changes. Consume the fix through your distribution's stable kernel channel.

Workarounds

• Disable io_uring for untrusted users by setting kernel.io_uring_disabled=2 via sysctl where the kernel supports it
• Block io_uring_setup, io_uring_register, and io_uring_enter in seccomp profiles for sandboxed workloads
• Avoid relying solely on IORING_REGISTER_RESTRICTIONS for privilege separation across exec; combine with seccomp and namespace controls

# Disable io_uring globally for unprivileged users (kernel >= 6.6)
sysctl -w kernel.io_uring_disabled=2
echo 'kernel.io_uring_disabled=2' >> /etc/sysctl.d/99-io_uring.conf