Description

In the Linux kernel, the following vulnerability has been resolved: io_uring: preserve task restrictions across exec 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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.4",
  "pubDate": "2026-08-28T08:16:56.957Z",
  "pubdate": "2026-08-28T08:16:56.957Z",
  "executiveSummary": "A security vulnerability exists in the Linux kernel's io_uring subsystem where task-level restrictions are improperly handled during the execve(2) system call.\nThe vulnerability involves the premature deallocation of per-task restriction structures during the exec cancellation path, effectively resetting security constraints for subsequent io_uring operations.\nAn attacker capable of executing a process can bypass intended security restrictions by leveraging the state transition during exec, potentially gaining elevated access to io_uring features that were explicitly restricted by the task's parent or initial configuration.\nThis flaw represents a policy enforcement failure within the kernel, where the persistence of security context is not maintained across the exec boundary, creating a discrepancy between the intended and actual security posture of the process.\nSuccessful exploitation allows a user-space process to create unrestricted io_uring rings following an exec, circumventing kernel-enforced limits. This poses significant risks in environments relying on io_uring restrictions for sandboxing or process isolation.",
  "technicalDetails": "The root cause of this vulnerability lies in the improper management of task context (tctx) and per-task restrictions within the io_uring subsystem during the process execution lifecycle.\nIn the Linux kernel, io_uring allows for the application of per-task restrictions that govern the capabilities of any ring created by that task. These restrictions are intended to be persistent across the lifetime of the task, including transitions through the execve(2) system call.\nWhen a task initiates an exec, the kernel triggers an exec cancellation path, which invokes __io_uring_free(). Historically, this function was responsible for releasing both the task context and the associated per-task restrictions. This implementation is fundamentally flawed because it fails to distinguish between a permanent process exit and an exec transition.\nBecause the per-task restriction is discarded during the exec transition, the task enters its new execution state without the previously imposed security boundaries. Consequently, any new io_uring rings created by the process post-exec are instantiated without the necessary restrictions, effectively bypassing the security policy defined for the initial task.\nThe exploitation flow proceeds as follows: 1) A privileged or sandboxed process defines strict io_uring constraints. 2) The process calls exec to execute a new program image. 3) The kernel executes the cancellation path, incorrectly deallocating the restriction structure. 4) The new program image initializes an io_uring instance, which is now unrestricted because the kernel failed to preserve the original task's restrictions across the exec boundary. 5) The attacker leverages the unrestricted ring to perform disallowed operations.\nThe vulnerable component is identified within the task cancellation path of the io_uring subsystem. The fix involves splitting the cleanup process into two distinct operations: io_uring_free_tctx(), which manages the task context cleanup during exec, and the existing __io_uring_free(), which is reserved for the final cleanup of both context and restrictions upon process termination. This separation ensures that restriction state is preserved across exec calls, maintaining the integrity of the process security model throughout its lifecycle."
}