CVE-2026-46274
Received Received - Intake
Use-After-Free in Linux Kernel io-wq

Publication date: 2026-06-08

Last updated on: 2026-06-08

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: io-wq: check that the predecessor is hashed in io_wq_remove_pending() io_wq_remove_pending() needs to fix up wq->hash_tail[] if the cancelled work was the tail of its hash bucket. When doing this, it checks whether the preceding entry in acct->work_list has the same hash value, but never checks that the predecessor is hashed at all. io_get_work_hash() is simply atomic_read(&work->flags) >> IO_WQ_HASH_SHIFT, and the hash bits are never set for non-hashed work, so it returns 0. Thus, when a hashed bucket-0 work is cancelled while a non-hashed work is its list predecessor, the check spuriously passes and a pointer to the non-hashed io_kiocb is stored in wq->hash_tail[0]. Because non-hashed work is dequeued via the fast path in io_get_next_work(), which never touches hash_tail[], the stale pointer is never cleared. Therefore, after the non-hashed io_kiocb completes and is freed back to req_cachep, wq->hash_tail[0] is a dangling pointer. The io_wq is per-task (tctx->io_wq) and survives ring open/close, so the dangling pointer persists for the lifetime of the task; the next hashed bucket-0 enqueue dereferences it in io_wq_insert_work() and wq_list_add_after() writes through freed memory. Add the missing io_wq_is_hashed() check so a non-hashed predecessor never inherits a hash_tail[] slot.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-06-08
Last Modified
2026-06-08
Generated
2026-06-09
AI Q&A
2026-06-08
EPSS Evaluated
N/A
NVD
CVE-2026-46274
EUVD
EUVD-2026-35078
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
linux linux_kernel *
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Quick Actions
Instant insights powered by AI
Executive Summary

This vulnerability exists in the Linux kernel's io-wq subsystem, specifically in the function io_wq_remove_pending(). The issue arises because the function does not properly verify that the predecessor work item in a work queue is hashed before using it. When a hashed work item is cancelled and its predecessor is a non-hashed work item, the code mistakenly treats the non-hashed predecessor as hashed, leading to storing a dangling pointer in the hash_tail array.

Since non-hashed work items are dequeued through a fast path that does not clear this stale pointer, the dangling pointer remains for the lifetime of the task. When the next hashed work item is enqueued, the code dereferences this dangling pointer and writes through freed memory, potentially causing memory corruption.

The fix involves adding a check (io_wq_is_hashed()) to ensure that only hashed predecessors can be assigned to hash_tail[], preventing the use of invalid pointers.

Impact Analysis

This vulnerability can lead to memory corruption in the Linux kernel's io-wq subsystem. Specifically, it can cause the kernel to write through freed memory due to dereferencing a dangling pointer.

Such memory corruption can result in system instability, crashes, or potentially allow an attacker to execute arbitrary code with kernel privileges, depending on the exploitation scenario.

Chat Assistant
Ask questions about this CVE
Hi! I’m here to help you understand CVE-2026-46274. Ask me anything about the vulnerability, its impact, or mitigation strategies.
0/70
EPSS Chart