io-wq: check that the predecessor is hashed in io_wq_remove_pending()
Summary
| CVE | CVE-2026-46274 |
| State | PUBLISHED |
| Assigner | Linux |
| Source Priority | CVE Program / NVD first with legacy fallback |
| Published | 2026-06-08 16:16:40 UTC |
| Updated | 2026-06-08 16:16:40 UTC |
| 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. |
Vendor Declared Affected Products
| Source | Vendor | Product | Version | Platforms |
|---|
| CNA |
Linux |
Linux |
affected 204361a77f4018627addd4a06877448f088ddfc0 d6bda9df0c0a3080804181464d5c0f4d78a4e769 git |
Not specified |
| CNA |
Linux |
Linux |
affected 204361a77f4018627addd4a06877448f088ddfc0 5a20ebf0c81b61f5ea3b1b529c100cad69b9f603 git |
Not specified |
| CNA |
Linux |
Linux |
affected 204361a77f4018627addd4a06877448f088ddfc0 252c5051dba9c709b6a72f2866f93e5e618b3f06 git |
Not specified |
| CNA |
Linux |
Linux |
affected 204361a77f4018627addd4a06877448f088ddfc0 d376c131af7c7739a87ff037ed2fdb67c2542c8a git |
Not specified |
| CNA |
Linux |
Linux |
affected 204361a77f4018627addd4a06877448f088ddfc0 d6a2d7b04b5a093021a7a0e2e69e9d5237dfa8cc git |
Not specified |
| CNA |
Linux |
Linux |
affected 13f35a2c0fd5c6a4fcd8903542b053bcc914fcf5 git |
Not specified |
| CNA |
Linux |
Linux |
affected 5.8.6 5.9 semver |
Not specified |
| CNA |
Linux |
Linux |
affected 5.9 |
Not specified |
| CNA |
Linux |
Linux |
unaffected 5.9 semver |
Not specified |
| CNA |
Linux |
Linux |
unaffected 6.6.141 6.6.* semver |
Not specified |
| CNA |
Linux |
Linux |
unaffected 6.12.91 6.12.* semver |
Not specified |
| CNA |
Linux |
Linux |
unaffected 6.18.33 6.18.* semver |
Not specified |
| CNA |
Linux |
Linux |
unaffected 7.0.10 7.0.* semver |
Not specified |
| CNA |
Linux |
Linux |
unaffected 7.1-rc4 * original_commit_for_fix |
Not specified |
References
| Reference | Source | Link | Tags |
|---|
| git.kernel.org/stable/c/5a20ebf0c81b61f5ea3b1b529c100cad69b9f603 |
416baaa9-dc9f-4396-8d5f-8c081fb06d67 |
git.kernel.org |
|
| git.kernel.org/stable/c/d376c131af7c7739a87ff037ed2fdb67c2542c8a |
416baaa9-dc9f-4396-8d5f-8c081fb06d67 |
git.kernel.org |
|
| git.kernel.org/stable/c/d6bda9df0c0a3080804181464d5c0f4d78a4e769 |
416baaa9-dc9f-4396-8d5f-8c081fb06d67 |
git.kernel.org |
|
| git.kernel.org/stable/c/252c5051dba9c709b6a72f2866f93e5e618b3f06 |
416baaa9-dc9f-4396-8d5f-8c081fb06d67 |
git.kernel.org |
|
| git.kernel.org/stable/c/d6a2d7b04b5a093021a7a0e2e69e9d5237dfa8cc |
416baaa9-dc9f-4396-8d5f-8c081fb06d67 |
git.kernel.org |
|
| CVE Program record |
CVE.ORG |
www.cve.org |
canonical |
| NVD vulnerability detail |
NVD |
nvd.nist.gov |
canonical, analysis |
No vendor comments have been submitted for this CVE.
There are currently no legacy QID mappings associated with this CVE.