Look up another CVE · open CVE-2026-80713 in the interactive tracker
CVE-2026-80713
io_uring: preserve task restrictions across exec
Published 2026-08-28 (2 months ago) by the Linux kernel CNA. Subsystem io_uring. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-80713 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | not affected | 6.1.190-1 | Nothing to do. bookworm never shipped the vulnerable code. |
| Debian 13trixie | not affected | 6.12.113-1 | Nothing to do. trixie never shipped the vulnerable code. |
| Debian 14forky | fixed | 7.1.8-1 | Update the kernel and reboot. Fixed in 7.1.8-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.1.8-1 | Update the kernel and reboot. Fixed in 7.1.8-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
Per-task restrictions apply to all rings created by a task. Once installed, they should not be dropped across exec. For a task that has used io_uring, the exec cancellation path calls __io_uring_free(). This frees both the task context and the per-task restriction, so a ring created after exec is unrestricted. Split task context cleanup into io_uring_free_tctx(), and use it from the exec cancellation path. Keep __io_uring_free() for final task cleanup, where both the context and restriction are released.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
io_uring/cancel.c
io_uring/tctx.c
io_uring/tctx.h
- What this is
- IO_URINGMAINTAINERS section matched on io_uring/ · io-uring@vger.kernel.org · Maintained
Check it on the machine
grep -w CONFIG_IO_URING /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
Show whether Debian builds this, per release
Debian builds this code. Every release below compiles the affected file into the kernels it ships.
- bookworm, trixie, forky, sidy
- y
- built into the kernel image on every flavour - only a patch removes it
- Build switch
- CONFIG_IO_URING
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-08-28 (2 months ago)source
- CVSS
- 8.4 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:Nsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.16%, higher than 5.1% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- Subsystem
- io_uring
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 7.0 | 7.1.8 | fcef9325afee |
| 7.0 | 7.2 | bc0e8faf90e7 |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- The flaw is reached only via local io_uring syscalls (io_uring_setup/io_uring_register) and execve(); fs/exec.c calls io_uring_task_cancel() which invokes the buggy __io_uring_free() path, and per kernel guidance io_uring is Local not Network.
- AC:LAttack complexity, low
- The attacker fully controls the trigger by calling io_uring_setup() to create a task context then execve(); exec deterministically runs io_uring_cancel_generic(true) and frees per-task restrictions without races, special memory layout, or other uncontrollable conditions.
- PR:LPrivileges required, low
- Exploitation requires only an unprivileged local process that had per-task io_uring restrictions installed by a parent/sandbox; the attacker needs no init-namespace CAP_SYS_ADMIN and can use io_uring unless blocked by sysctl or LSM policy.
- UI:NUser interaction, none
- No victim interaction is required; the confined attacker process itself performs io_uring_setup and execve to drop restrictions, then io_uring_setup again to obtain an unrestricted ring without administrator or other-user action.
- S:CScope, changed
- Per-task io_uring restrictions are a confinement policy enforced by a separate sandbox/parent authority; clearing them across exec lets post-exec code exceed that policy and access kernel interfaces explicitly withheld, crossing the intended sandbox security boundary.
- C:HConfidentiality impact, high
- Dropping restrictions re-enables blocked io_uring SQEs, register operations, and BPF filters, including IORING_OP_URING_CMD and read-oriented ops against kernel/driver interfaces denied by policy, enabling disclosure beyond the confinement authority's intent.
- I:HIntegrity impact, high
- Bypass restores the full unrestricted io_uring opcode and register surface (writes, open/link ops, IORING_OP_URING_CMD, buffer/file registration), allowing post-exec integrity-affecting kernel and driver interactions explicitly denied by per-task restrictions.
- A:NAvailability impact, none
- The vulnerability only incorrectly frees restriction metadata during exec cleanup; it does not directly cause kernel panics, oopses, deadlocks, or hangs, so there is no availability impact from the bug itself.