CVE-2026-46274: Linux Kernel Use-After-Free Vulnerability

CVE-2026-46274 Overview

CVE-2026-46274 is a use-after-free vulnerability in the Linux kernel's io-wq work queue subsystem, which backs io_uring asynchronous I/O. The flaw resides in io_wq_remove_pending(), where a missing hash check allows a non-hashed work item to be recorded in wq->hash_tail[]. After that work completes and its io_kiocb is freed back to req_cachep, the slot becomes a dangling pointer. A subsequent hashed enqueue dereferences the freed memory, corrupting the kernel heap.

Critical Impact
Local attackers using io_uring can trigger a kernel use-after-free, enabling memory corruption that may lead to privilege escalation or kernel denial of service.

Affected Products

Linux kernel versions containing the io-wq hashed work cancellation logic in io_wq_remove_pending()
Distributions shipping affected stable kernels prior to the fix commits referenced in git.kernel.org
Any system exposing io_uring to unprivileged users

Discovery Timeline

2026-06-08 - CVE-2026-46274 published to NVD
2026-06-08 - Last updated in NVD database

Technical Details for CVE-2026-46274

Vulnerability Analysis

The io-wq subsystem dispatches asynchronous work submitted through io_uring. Hashed work items, used to serialize operations against the same inode, are tracked through per-bucket tails in wq->hash_tail[]. When a hashed work item is cancelled, io_wq_remove_pending() must update the tail pointer if the cancelled item was the last in its bucket.

The function inspects the predecessor entry in acct->work_list and compares its hash bucket via io_get_work_hash(). That helper is defined as atomic_read(&work->flags) >> IO_WQ_HASH_SHIFT and returns 0 for any non-hashed work because the hash bits are unset. When a hashed bucket-0 work item is cancelled while its predecessor is a non-hashed item, the comparison spuriously matches and the non-hashed io_kiocb is written into wq->hash_tail[0].

Non-hashed work is dequeued via the fast path in io_get_next_work(), which never touches hash_tail[]. The pointer is therefore never cleared. Because the io_wq is per-task (tctx->io_wq) and persists across ring open and close, the stale entry survives for the lifetime of the task. On the next hashed bucket-0 enqueue, io_wq_insert_work() and wq_list_add_after() write through the freed io_kiocb.

Root Cause

The predecessor hash comparison in io_wq_remove_pending() assumes the previous entry is itself hashed. The fix adds the missing io_wq_is_hashed() check, preventing a non-hashed predecessor from inheriting a hash_tail[] slot.

Attack Vector

A local user with permission to create io_uring instances can craft a sequence of hashed and non-hashed work submissions followed by a cancellation that triggers the faulty tail fixup. After the non-hashed request completes and its io_kiocb is recycled, a follow-up hashed submission to bucket 0 writes through the dangling pointer, producing a controllable kernel heap write.

The vulnerability mechanism is described in detail in the upstream commits. See the Kernel Git Commit Update 1, Kernel Git Commit Update 2, Kernel Git Commit Update 3, Kernel Git Commit Update 4, and Kernel Git Commit Update 5 for the upstream fix.

Detection Methods for CVE-2026-46274

Indicators of Compromise

Kernel oops or general protection fault traces referencing io_wq_insert_work, wq_list_add_after, or io_wq_remove_pending
KASAN use-after-free reports identifying req_cachep slab objects accessed by io-wq worker threads
Unexpected process crashes or kernel panics correlated with io_uring-heavy workloads

Detection Strategies

Enable KASAN on test and staging kernels to surface use-after-free conditions in io-wq code paths
Monitor dmesg and journal logs for kernel warnings originating from fs/io_uring/ or io-wq.c
Audit running kernel versions against the patched stable releases referenced by the upstream commits

Monitoring Recommendations

Track processes that create io_uring instances via io_uring_setup and correlate with crash telemetry
Forward kernel ring buffer events to a centralized log pipeline for anomaly review
Alert on repeated kernel faults from the same UID, which can indicate exploitation attempts

How to Mitigate CVE-2026-46274

Immediate Actions Required

Apply the upstream stable kernel updates that introduce the io_wq_is_hashed() check in io_wq_remove_pending()
Inventory hosts that expose io_uring to unprivileged users and prioritize patching those systems
Where patching is delayed, restrict io_uring usage to trusted workloads only

Patch Information

The fix adds the missing io_wq_is_hashed() check so that a non-hashed predecessor cannot inherit a hash_tail[] slot. Patched stable kernels are available through the upstream commits referenced above. Distribution maintainers ship backports through their standard kernel update channels.

Workarounds

Set kernel.io_uring_disabled=2 via sysctl to disable io_uring system-wide for unprivileged users where supported
Apply seccomp filters to block io_uring_setup, io_uring_enter, and io_uring_register for untrusted processes
Restrict container workloads from accessing io_uring by enforcing a seccomp profile that denies the related syscalls

bash

# Disable io_uring for unprivileged users (requires kernel support)
sysctl -w kernel.io_uring_disabled=2
echo 'kernel.io_uring_disabled=2' >> /etc/sysctl.d/99-io-uring.conf