LiveActive security incident?Get immediate response
CVE Record

CVE-2026-23113: io_uring/io-wq: check IO_WQ_BIT_EXIT inside work run loop

In the Linux kernel, the following vulnerability has been resolved: io_uring/io-wq: check IO_WQ_BIT_EXIT inside work run loop Currently this is checked before running the pending work. Normally this is quite fine, as work items either end up blocking (which will create a new worker for other items), or they complete fairly quickly. But syzbot reports an issue where io-wq takes seemingly forever to exit, and with a bit of debugging, this turns out to be because it queues a bunch of big (2GB - 4096b) reads with a /dev/msr* file. Since this file type doesn't support ->read_iter(), loop_rw_iter() ends up handling them. Each read returns 16MB of data read, which takes 20 (!!) seconds. With a bunch of these pending, processing the whole chain can take a long time. Easily longer than the syzbot uninterruptible sleep timeout of 140 seconds. This then triggers a complaint off the io-wq exit path: INFO: task syz.4.135:6326 blocked for more than 143 seconds. Not tainted syzkaller #0 Blocked by coredump. "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:syz.4.135 state:D stack:26824 pid:6326 tgid:6324 ppid:5957 task_flags:0x400548 flags:0x00080000 Call Trace: <TASK> context_switch kernel/sched/core.c:5256 [inline] __schedule+0x1139/0x6150 kernel/sched/core.c:6863 __schedule_loop kernel/sched/core.c:6945 [inline] schedule+0xe7/0x3a0 kernel/sched/core.c:6960 schedule_timeout+0x257/0x290 kernel/time/sleep_timeout.c:75 do_wait_for_common kernel/sched/completion.c:100 [inline] __wait_for_common+0x2fc/0x4e0 kernel/sched/completion.c:121 io_wq_exit_workers io_uring/io-wq.c:1328 [inline] io_wq_put_and_exit+0x271/0x8a0 io_uring/io-wq.c:1356 io_uring_clean_tctx+0x10d/0x190 io_uring/tctx.c:203 io_uring_cancel_generic+0x69c/0x9a0 io_uring/cancel.c:651 io_uring_files_cancel include/linux/io_uring.h:19 [inline] do_exit+0x2ce/0x2bd0 kernel/exit.c:911 do_group_exit+0xd3/0x2a0 kernel/exit.c:1112 get_signal+0x2671/0x26d0 kernel/signal.c:3034 arch_do_signal_or_restart+0x8f/0x7e0 arch/x86/kernel/signal.c:337 __exit_to_user_mode_loop kernel/entry/common.c:41 [inline] exit_to_user_mode_loop+0x8c/0x540 kernel/entry/common.c:75 __exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [inline] syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:256 [inline] syscall_exit_to_user_mode_work include/linux/entry-common.h:159 [inline] syscall_exit_to_user_mode include/linux/entry-common.h:194 [inline] do_syscall_64+0x4ee/0xf80 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fa02738f749 RSP: 002b:00007fa0281ae0e8 EFLAGS: 00000246 ORIG_RAX: 00000000000000ca RAX: fffffffffffffe00 RBX: 00007fa0275e6098 RCX: 00007fa02738f749 RDX: 0000000000000000 RSI: 0000000000000080 RDI: 00007fa0275e6098 RBP: 00007fa0275e6090 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007fa0275e6128 R14: 00007fff14e4fcb0 R15: 00007fff14e4fd98 There's really nothing wrong here, outside of processing these reads will take a LONG time. However, we can speed up the exit by checking the IO_WQ_BIT_EXIT inside the io_worker_handle_work() loop, as syzbot will exit the ring after queueing up all of these reads. Then once the first item is processed, io-wq will simply cancel the rest. That should avoid syzbot running into this complaint again.

UnknownCVSS not scoredNot KEV-listedUpdated
Discuss exposureBack to CVEs
Glexia's TakeAutomated analysisunknown

Security readout for executives and security teams

Plain-English summary

A Linux io_uring worker pool can take minutes to shut down because it continues processing queued, unusually slow reads instead of promptly cancelling them. The reported result was a task blocked for more than 143 seconds. The supplied evidence describes delayed cleanup and hung-task warnings, not data corruption or code execution.

Executive priority

Treat this as a routine availability-focused kernel update unless affected systems show hangs or operate latency-sensitive workloads. Prioritise impacted shared hosts and appliances after confirming vendor applicability. Escalation to emergency status is unsupported because severity, exploitability, and active exploitation evidence are absent.

Technical view

io-wq checked IO_WQ_BIT_EXIT before beginning pending work, but not during its work-processing loop. A syzbot case queued many large reads against /dev/msr*, each taking about 20 seconds, so ring teardown waited through the chain. The stable change rechecks the exit bit inside the loop and cancels remaining work after the current item.

Likely exposure

Potential exposure includes systems running the listed affected Linux versions where relevant io_uring/io-wq workloads can queue slow operations. The bundle identifies versions 5.12, 5.15.203, 6.1.167, 6.6.122, 6.12.68, 6.18.8, and 6.19, but does not clearly establish distribution backport status or attacker prerequisites.

Exploitation context

The bundle marks this CVE as absent from KEV and provides no evidence of active exploitation. The reported condition came from syzbot testing and caused prolonged uninterruptible sleep during exit. No CVSS score, CWE, public exploit, remote attack path, privilege requirement, or demonstrated security impact beyond availability delay is supplied.

Researcher notes

The observable failure is teardown latency: exit is noticed only before the run loop, allowing an accumulated chain of slow work to continue. The fix improves cancellation responsiveness rather than correcting the underlying slow read. Researchers should avoid inferring confidentiality, integrity, remote reachability, or privilege impact from the supplied record.

Mitigation direction

  • Update to a vendor-supported kernel containing the applicable stable fix or distribution backport.
  • Check Linux distribution and appliance-vendor advisories before choosing a target kernel version.
  • If updating is delayed, request vendor-supported mitigations; none are specified in the supplied sources.

Validation and detection

  • Inventory kernel versions across Linux hosts, appliances, containers' hosts, and virtualisation platforms.
  • Check vendor kernel changelogs for CVE-2026-23113 or the applicable stable fix commit.
  • Review logs for prolonged io-wq exits, hung-task warnings, or blocked teardown paths.
  • After updating, confirm the running kernel includes the backport and restart requirements were completed.
Prepared
Confidence
high
Sources
8

Public sources used

Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.

Potential ATT&CK relevance

Conservative CVE-to-ATT&CK context

These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.

ATT&CK lookup starting points

Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.

cve · low confidence lookup

CVE-2026-23113 mapping review

Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.

Open ATT&CK lookup
Vulnerability profileCVE Program record
Severity
Unknown
CVSS
Not scored
Known Exploited
No
Published
Official CVE source material

CNA and ADP enrichment extracted from CVE v5

These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.

0CVSS vectors
3Timeline events
1ADP providers
9Source links

Vulnerability timeline

Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.

  1. CVE reservedCVE Program

    The CVE ID was reserved by the assigning CNA.

  2. CVE publishedCVE Program

    The CVE record was published.

  3. CVE updatedCVE Program

    The CVE record metadata indicates this as the latest update time.

ADP provider summaries

siemens-SADPADP container

Source materials

Affected products

Products and packages named in the record

VendorProductVersion / packageStatus
LinuxLinuxc60eb049f4a19ddddcd3ee97a9c79ab8066a6a03, c60eb049f4a19ddddcd3ee97a9c79ab8066a6a03, c60eb049f4a19ddddcd3ee97a9c79ab8066a6a03, c60eb049f4a19ddddcd3ee97a9c79ab8066a6a03, c60eb049f4a19ddddcd3ee97a9c79ab8066a6a03, c60eb049f4a19ddddcd3ee97a9c79ab8066a6a03unaffected
LinuxLinux5.12, 0, 5.15.203, 6.1.167, 6.6.122, 6.12.68, 6.18.8, 6.19affected
Weakness

CWE details

No CWE listed

CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.