CVE-2026-99096 in Linux
Summary
by MITRE • 10/26/2026
In the Linux kernel, the following vulnerability has been resolved:
io_uring/register: don't exempt disabled rings from task restrictions
A ring created with IORING_SETUP_R_DISABLED is exempt from its register restrictions until it is enabled. This lets the creator register the restrictions and then enable the ring with IORING_REGISTER_ENABLE_RINGS, whether or not that opcode is in the allowed set.
Since commit ed82f35b926b ("io_uring: allow registration of per-task restrictions"), a ring also inherits restrictions from the task that creates it, and the same exemption applies to those. A task whose register opcodes are restricted can therefore create a disabled ring, issue any register opcode on it, and then enable it.
Mark rings whose restrictions were inherited from the task, and keep checking register opcodes for them while the ring is disabled. Enabling such a ring now requires IORING_REGISTER_ENABLE_RINGS to be in the task's allowed set. Per-ring restrictions registered on a disabled ring work as before.
[axboe: amend with inheritance flag fixup]
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/26/2026
The Linux kernel io_uring subsystem contains a logic flaw regarding the enforcement of registration restrictions for rings created with the IORING_SETUP_R_DISABLED flag. This vulnerability allows an unprivileged user to bypass intended security controls by exploiting the state transition between disabled and enabled ring states. Specifically, when a ring is initially registered in a disabled state, it was incorrectly exempted from the task-level register restrictions that apply to active operations. This exemption persisted until the ring was explicitly enabled using the IORING_REGISTER_ENABLE_RINGS opcode, creating a window of opportunity for privilege escalation or unauthorized access to restricted kernel resources.
The root cause lies in how io_uring handles inheritance and enforcement of per-task restrictions introduced by commit ed82f35b926b. Under normal circumstances, an io_uring instance inherits the register opcodes allowed set from the creating task, restricting which operations can be performed on that ring. However, for rings marked as disabled at creation time, this inheritance mechanism failed to apply enforcement checks during the registration phase of restricted opcodes. Consequently, a malicious actor could create a disabled ring, issue any register opcode regardless of whether it was in their allowed set, and subsequently enable the ring using IORING_REGISTER_ENABLE_RINGS. This sequence effectively circumvented the access control list defined for the task, allowing operations that should have been denied by the kernel's security model.
This flaw represents an Access Control Bypass vulnerability, aligning with CWE-284: Improper Access Control. The attacker leverages a race-like condition in state management rather than a traditional timing attack; specifically, they exploit the lack of validation during the disabled phase to register restricted resources or configurations that are only enforced once the ring becomes active. In terms of the MITRE ATT&CK framework, this behavior corresponds to T1068: Exploitation for Privilege Escalation if the registered restrictions involve kernel capabilities or memory mappings that grant elevated privileges, or more broadly to defense evasion techniques where standard access controls are bypassed through state manipulation. The operational impact includes potential unauthorized modification of io_uring ring configurations, which could lead to denial of service by corrupting internal structures or privilege escalation if specific restricted opcodes allow interaction with sensitive kernel subsystems.
The resolution involves modifying the io_uring registration logic to ensure that restrictions inherited from the creating task are enforced even when the ring is in a disabled state. The patch marks rings whose restrictions were derived from the parent task and ensures that register opcode validation occurs continuously, regardless of the ring's enabled or disabled status. This change mandates that enabling such a restricted ring now requires IORING_REGISTER_ENABLE_RINGS to be present in the task's allowed set, thereby closing the bypass vector. Per-ring restrictions registered on a disabled ring continue to function as before, maintaining backward compatibility for legitimate use cases while hardening the security posture against unauthorized registration attempts. System administrators should apply kernel updates that include this fix and monitor for unusual io_uring registration patterns that may indicate exploitation attempts in environments where untrusted users have access to create io_uring instances.