CVE-2026-99096: 
Linux Kernel vulnerability analysis and mitigation

CVE-2026-99096 is an authorization bypass vulnerability in the Linux kernel's io_uring subsystem, specifically in the io_uring/register component. The flaw allows a local task with restricted register opcodes to circumvent those restrictions by creating a disabled ring (using IORING_SETUP_R_DISABLED), issuing any register opcode on it while disabled, and then enabling it — bypassing the intended access controls introduced by commit ed82f35b926b. Affected versions span Linux kernel 7.0 up to (but not including) the patched commits; versions prior to 7.0 and versions 7.2.11+ and 7.3+ are unaffected. The CVSS score has not been formally assigned; Feedly estimates severity as Medium with an EPSS score of 0.0 (GitHub Advisory, Feedly).

The root cause is an improper authorization check (related to CWE-863: Incorrect Authorization) in the io_uring registration path. When a ring is created with IORING_SETUP_R_DISABLED, it is intentionally exempt from register restrictions to allow initial setup — but since commit ed82f35b926b introduced per-task restriction inheritance, this exemption was incorrectly extended to task-inherited restrictions as well. An attacker can exploit this by creating a disabled ring that inherits the task's restrictions, then invoking any restricted register opcode (including those not in the allowed set) before enabling the ring with IORING_REGISTER_ENABLE_RINGS, which itself did not require being in the task's allowed set. The fix marks rings whose restrictions were inherited from the task and enforces opcode checking even while the ring is disabled (GitHub Advisory, Kernel Patch 1, Kernel Patch 2).

A local attacker with limited privileges operating under restricted io_uring register opcodes can bypass those restrictions to execute otherwise-forbidden register operations, effectively escalating their capabilities within the io_uring subsystem. This could allow unauthorized manipulation of io_uring rings and associated kernel resources, potentially undermining security policies enforced at the task level. The impact is primarily an integrity and authorization concern; there is no direct evidence of remote code execution or data exfiltration potential from this vulnerability alone (GitHub Advisory, Feedly).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation as of the disclosure date (GitHub Advisory, Feedly). The vulnerability requires local access to the system and the ability to create io_uring rings, limiting the attack surface to authenticated local users. The EPSS score is 0.0, indicating a very low probability of exploitation in the near term. The CVE is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. No threat actor attribution has been reported.

1. Prerequisite: Obtain local access to a Linux system running kernel version 7.0 up to the patched commits, where the attacker's task has restricted io_uring register opcodes set via per-task restrictions.
2. Create a disabled ring: Use the io_uring_setup() syscall with the IORING_SETUP_R_DISABLED flag to create a new io_uring ring. This ring inherits the task's register restrictions but is initially exempt from enforcement.
3. Issue restricted register opcodes: While the ring is in the disabled state, call io_uring_register() with opcodes that would normally be blocked by the task's restriction policy (e.g., opcodes not in the allowed set).
4. Enable the ring: Call io_uring_register() with IORING_REGISTER_ENABLE_RINGS to activate the ring. Prior to the fix, this step did not require IORING_REGISTER_ENABLE_RINGS to be in the task's allowed set, completing the bypass.
5. Leverage unrestricted ring: Use the now-enabled ring with previously restricted capabilities to perform unauthorized io_uring operations beyond the intended security policy (GitHub Advisory, Feedly).

• Logs: Audit logs showing io_uring_setup() calls with IORING_SETUP_R_DISABLED flag followed immediately by io_uring_register() calls using opcodes inconsistent with the task's expected allowed set.
• Process Behavior: Processes operating under restricted io_uring policies that unexpectedly invoke io_uring_register() with a broad range of opcodes while a ring is in the disabled state.
• Kernel Audit: Linux kernel audit subsystem events (auditd) capturing io_uring syscall sequences from low-privilege processes that should not have access to certain register opcodes.

Apply the upstream kernel patches that fix this issue: commit f55c240192ded562386de843bfa067671d2731d5 (for one stable branch) and commit 6da8f402e362b2f546e2efb7167fc9597aef6faf (for another stable branch). Patched versions include Linux kernel 7.2.11 and 7.3+; upgrading to these versions is the recommended remediation. As a temporary workaround where patching is not immediately possible, consider restricting unprivileged access to io_uring via seccomp policies or by setting /proc/sys/kernel/io_uring_disabled to limit io_uring usage to privileged processes (GitHub Advisory, Kernel Patch 1, Kernel Patch 2).