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.
Published: 2026-06-08
Score: 7.8 High
EPSS: < 1% Very Low
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

The flaw resides in the Linux kernel's io_wq_remove_pending() routine, where the code fails to verify that a predecessor work item is hashed before reusing hash_tail pointers. When a hashed work entry is cancelled while an un-hashed predecessor is present, a stale pointer to freed memory is stored in wq->hash_tail[0]. Because the fast path for non‑hashed work never clears this pointer, it becomes a dangling reference that may later be dereferenced by io_wq_insert_work, leading to kernel memory corruption (a Use‑After‑Free, CWE‑825).

Affected Systems

The defect is present in all Linux kernel releases prior to the commit that introduced the fix. The CVE data does not specify exact kernel version numbers, so the scope includes any installation that has not yet applied the patch commit or a later stable kernel that incorporates it.

Risk and Exploitability

The CVSS score of 7.8 indicates high severity. EPSS data is not available, and the vulnerability is not listed in CISA KEV. No public exploits have been documented, but a local attacker who can manipulate IO operations could trigger the use‑after‑free and cause a crash or potentially elevate privileges by corrupting kernel memory.

Generated by OpenCVE AI on June 9, 2026 at 02:29 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Apply a kernel update that includes the patch commit 252c5051 or any newer stable release containing the fix.
  • Reboot the system to load the patched kernel and discard any lingering dangling pointers.
  • If updating the kernel is not immediately possible, restrict or disable the use of IO work queue functionality in applications, or apply system controls to limit scheduled IO operations that could trigger the fault.

Generated by OpenCVE AI on June 9, 2026 at 02:29 UTC.

Tracking

Sign in to view the affected projects.

Advisories
Source ID Title
Debian DSA Debian DSA DSA-6355-1 linux security update
History

Tue, 09 Jun 2026 00:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-825
References
Metrics threat_severity

None

cvssV3_1

{'score': 7.8, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H'}

threat_severity

Moderate


Mon, 08 Jun 2026 15:45:00 +0000

Type Values Removed Values Added
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.
Title io-wq: check that the predecessor is hashed in io_wq_remove_pending()
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-06-14T18:05:34.336Z

Reserved: 2026-05-13T15:03:33.109Z

Link: CVE-2026-46274

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-06-08T16:16:40.707

Modified: 2026-06-14T06:16:22.063

Link: CVE-2026-46274

cve-icon Redhat

Severity : Moderate

Publid Date: 2026-06-08T00:00:00Z

Links: CVE-2026-46274 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-06-09T02:30:26Z

Weaknesses
  • CWE-825

    Expired Pointer Dereference