CVE-2026-46274

/// Technical 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

/// Remediation

Check the references section for vendor advisories, patches, and mitigation guidance. If immediate patching is not possible, review the CVSS vector to understand the attack surface and apply compensating controls such as network segmentation or access restrictions.

/// References