CVE-2026-46274io-wq: check that the predecessor is hashed in io_wq_remove_pending()
- 7.8HighCVSS base score
- 0.14%Exploitation in 30 daysEPSS · top 97% of all CVEs
- NoKnown exploitednot in CISA's KEV catalog
- NonePublic exploitsnone known yet
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.
Timeline
ID reserved
By Linux
- 26 days later
· 26 days later
Published
- 58 days later
· 58 days later
Record updated
Changes after publication (a new score, a public exploit, EPSS crossing 1, 10 or 50 %, leaving KEV) are kept since November 2026; earlier ones are not known.
Scores
| Scored by | CVSS | Score | Vector |
|---|---|---|---|
| LinuxCNA (assigner) | 3.1 | High7.8 | CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H |
| NVDNVD · Analyzed | 3.1 | High7.8 | CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H |
- EPSS (exploitation in 30 days)
- 0.14% · top 97% of all CVEs (15 Nov 2026)
The list uses the assigner's score when there is one, then CISA's, then NVD's: High 7.8.
Affected products
- affected 204361a77f4018627addd4a06877448f088ddfc0 – < d6bda9df0c0a3080804181464d5c0f4d78a4e769
- affected 204361a77f4018627addd4a06877448f088ddfc0 – < 5a20ebf0c81b61f5ea3b1b529c100cad69b9f603
- affected 204361a77f4018627addd4a06877448f088ddfc0 – < 252c5051dba9c709b6a72f2866f93e5e618b3f06
- affected 204361a77f4018627addd4a06877448f088ddfc0 – < d376c131af7c7739a87ff037ed2fdb67c2542c8a
- affected 204361a77f4018627addd4a06877448f088ddfc0 – < d6a2d7b04b5a093021a7a0e2e69e9d5237dfa8cc
- affected 13f35a2c0fd5c6a4fcd8903542b053bcc914fcf5
- affected 5.8.6 – < 5.9
- affected 5.9
- unaffected < 5.9
- unaffected 6.6.141 – ≤ 6.6.*
- unaffected 6.12.91 – ≤ 6.12.*
- unaffected 6.18.33 – ≤ 6.18.*
- unaffected 7.0.10 – ≤ 7.0.*
- unaffected 7.1 – ≤ *
References
References5
- https://git.kernel.org/stable/c/d6bda9df0c0a3080804181464d5c0f4d78a4e769 (opens in a new tab)
- https://git.kernel.org/stable/c/5a20ebf0c81b61f5ea3b1b529c100cad69b9f603 (opens in a new tab)
- https://git.kernel.org/stable/c/252c5051dba9c709b6a72f2866f93e5e618b3f06 (opens in a new tab)
- https://git.kernel.org/stable/c/d376c131af7c7739a87ff037ed2fdb67c2542c8a (opens in a new tab)
- https://git.kernel.org/stable/c/d6a2d7b04b5a093021a7a0e2e69e9d5237dfa8cc (opens in a new tab)
Sources
The same CVE in the primary databases and aggregators, to check against.
- CVE.org record (opens in a new tab)
- CVE List JSON (GitHub) (opens in a new tab)
- NVD (opens in a new tab)
- FIRST EPSS (opens in a new tab)
- EUVD EUVD-2026-35078 (opens in a new tab)
- OSV.dev (opens in a new tab)
- GitHub Advisories (opens in a new tab)
- CIRCL Vulnerability-Lookup (opens in a new tab)
Badge for a README or a ticket
[](https://cveledger.app/cve/CVE-2026-46274)Record last updated .