Linux Kernel CVE-2026-46274

Requires the ability to call io_uring_setup/io_uring_enter on the target host, i.e., an unprivileged local account or code execution inside a container or sandbox whose seccomp/landlock policy permits io_uring; on distributions that ship with kernel.io_uring_disabled=0 (the default on most stock kernels in the 5.9-7.0 range) this is satisfied by any logged-in user. The attacker must additionally win a small race - queue a non-hashed work item, get it placed immediately before a hashed bucket-0 work item on the same per-task io_wq work_list, then cancel the hashed item before the worker drains it - and must control slab allocations well enough to re-occupy the freed io_kiocb before the next bucket-0 hashed enqueue. Exploitation is LIMITED to systems where io_uring is enabled and reachable (so kernel.io_uring_disabled=1/2, containers with seccomp blocking the io_uring_* syscalls, and kernels built without CONFIG_IO_URING are not exposed), and is bounded to the lifetime of the offending task because the vulnerable io_wq is per-tctx; no remote network path exists (AV:L).

CVSS 3.1 base score 7.8 (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) is consistent with a local UAF that yields full kernel compromise once reached, and the trigger is reachable from any process able to call io_uring_setup/io_uring_enter - no special capability beyond what unprivileged users normally have on most distros. EPSS of 0.02% (5th percentile) and absence from CISA KEV indicate no observed exploitation in the wild, but that is expected: kernel-internal race-condition UAFs are typically weaponized as part of local-privilege-escalation chains rather than mass-scanned, so a low EPSS does not equal low real-world risk for multi-tenant Linux hosts, container hosts, or sandbox-escape scenarios. The reproduction primitive (queue a non-hashed work item ahead of a hashed bucket-0 item, cancel the hashed one, free the non-hashed one, then enqueue another hashed bucket-0 work) is described in enough detail in the commit message to guide an exploit writer, so the practical timeline-to-PoC is short. No conflicting signals between sources; the main uncertainty is which mainline and stable trees a given fleet runs, since the introducing commit (204361a77f40) ships in 5.9 and the fix has been backported to 6.6.141, 6.12.91, 7.0.10, and 6.18.33 per EUVD.

An unprivileged local user on a multi-tenant Linux host (e.g., a shared build server, a container that shares the host kernel, or a SaaS sandbox) crafts a sequence of io_uring submissions that places a non-hashed request immediately before a hashed bucket-0 request on the same io-wq work_list, cancels the hashed request to trigger the buggy hash_tail[] fix-up, lets the non-hashed io_kiocb complete and return to the slab, then sprays the slab with attacker-controlled data before submitting another hashed bucket-0 work to weaponize the dangling pointer dereferenced by io_wq_insert_work(). The resulting controlled kernel write is then converted to arbitrary code execution or credential overwrite to obtain root or escape the container. No public exploit identified at time of analysis, but the upstream commit message documents the racing sequence in enough detail to seed PoC development.