CVE-2026-99096
NoneCVSS
—
EPSS
0.2%
Published
Oct 26, 2026
CISA due date
—
Cloudanix analysis
A recent Linux kernel bug let certain programs bypass security limits on low-level operations by using a temporarily disabled feature, potentially allowing unauthorized actions on the system.
- Exploitation
- Local Privilege
- Attacker needs
- Low Privilege
- Complexity
- Low
- Impact
- Privilege Gain
- Component
- OS kernel
- Class
- Authorization Bypass
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
The flaw allows tasks with restricted register opcodes to bypass those restrictions by creating an io_uring ring with IORING_SETUP_R_DISABLED, issuing any register opcode on the disabled ring, and then enabling it; the same exemption applies to inherited per-task restrictions.
Why it matters to the business
Attackers on recently published Linux kernels could perform unauthorized kernel registration operations, increasing risk of privilege escalation or container escape in environments that rely on io_uring task restrictions for security boundaries.
How an attack unfolds
An attacker running under a restricted task creates a disabled io_uring ring, uses the ring to issue register opcodes that would normally be blocked, then enables the ring; the inherited task restrictions are not enforced while the ring remains disabled.
How to fix it
Update the Linux kernel to a version containing the fix that marks rings inheriting task restrictions and continues enforcing register opcode checks on disabled rings; rebuild and deploy any custom kernels or distributions that include the vulnerable io_uring code.
How to confirm the fix worked
Confirm the kernel source contains the inheritance flag fixup, run io_uring restriction test suites that exercise disabled rings, and verify that register operations on a disabled inherited ring are now denied until IORING_REGISTER_ENABLE_RINGS is allowed.
Typical attack path
- Obtain or create a process whose io_uring register opcodes are restricted
- Create an io_uring ring using IORING_SETUP_R_DISABLED
- Issue arbitrary IORING_REGISTER_* opcodes on the disabled ring
- Enable the ring with IORING_REGISTER_ENABLE_RINGS
How to detect it
Inspect kernel audit logs, io_uring tracepoints, and seccomp violation records for sequences of ring creation with the disabled flag followed immediately by register opcodes that would be blocked on an enabled ring.
What your security team should do
- Prioritize kernel updates on systems that use io_uring with per-task restrictions
- Review workloads that create io_uring rings under seccomp or other opcode filters
- Monitor for new exploit code targeting this four-day-old disclosure
The record
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]
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|