{"id":"CVE-2026-99254","kind":"vulnerability","aliases":["CVE-2026-99254"],"related":[],"title":"Linux kernel io_uring: exiting task flooded with task_work, stalling CPUs","description":"In the Linux kernel, the following vulnerability has been resolved:\n\nio_uring: don't flood a cancelling task with task_work\n\nio_ring_exit_work() asks each task which has used the ring to remove its\ntctx node, by task_work, and repeats that until the list is empty.\nio_tctx_exit_cb() doesn't touch the node while the task is in\nio_uring_cancel_generic(), which removes all the nodes at its end. So the\nwork item queues the callback again as soon as it has completed, for\nnothing.\n\nThat is more than a waste of time. task_work_run() only returns when it\nfinds the list empty. If the rings are released from inside the\ncancellation, because requests of other rings held the last references to\ntheir files, up to 64 work items keep sending callbacks to the one task\nwhich is running them. It never finds the list empty, never gets back to\nthe cancellation, the nodes stay, and so it goes on: a task with 60 pairs\nof rings which poll each other ran 280000 callbacks in 5 seconds, 20\nseconds after exit_group(). It ends when all the senders happen to be late\nat the same time. Until then the task keeps a CPU and the work items busy.\n\nAn exiting task can't be killed meanwhile. execve() cancels the requests in\nthe same way, so a live task can get stuck there as well, for minutes. If\nit takes more than five, the work items run into the\nWARN_ON_ONCE(time_after(jiffies, timeout)) of io_ring_exit_work(). No\nprivilege is needed for any of this.\n\nIf the callback has met a task in cancellation, wait a little before it is\nsent again. Nobody has to wake the work item up for that: either the node\nis gone by then, or it is the turn of the next round.","summary":"In the Linux kernel's io_uring subsystem, the ring-exit work item keeps re-queuing cleanup callbacks to a task already in cancellation, so that task never returns from cancellation. The effect is a task that cannot be killed and keeps a CPU busy for seconds to minutes, with no privilege needed to trigger it.","severity":"unknown","cvss":null,"epss":null,"exploited":false,"exploited_at":null,"products":[],"ecosystems":[],"tags":["io_uring","kernel","kubernetes","linux","runtime","self-hosted"],"not_affected_if":["no-io_uring-use"],"how_to_check":"- Check the running kernel version with `uname -r` and compare it against the fixed kernel releases in the NVD entry for CVE-2026-99254.\n- Look for io_uring use in your workloads: `grep -r io_uring /proc/*/maps` or check whether services use liburing.","fix":"- Linux kernel: the fixed version is unknown; the sources do not list specific kernel ranges.","status":"open","published_at":"2026-11-03T12:17:32+00:00","first_seen_at":"2026-11-03T12:20:39+00:00","triaged_at":"2026-11-03T12:22:53+00:00","updated_at":"2026-11-03T12:22:53+00:00","category":"runtime","confidence":0.6,"triage":{"at":"2026-11-03T12:22:53Z","model":"claude-haiku-5-5","output":{"fix":"- Linux kernel: the fixed version is unknown; the sources do not list specific kernel ranges.","reach":"local","title":"Linux kernel io_uring: exiting task flooded with task_work, stalling CPUs","impact":"low","summary":"In the Linux kernel's io_uring subsystem, the ring-exit work item keeps re-queuing cleanup callbacks to a task already in cancellation, so that task never returns from cancellation. The effect is a task that cannot be killed and keeps a CPU busy for seconds to minutes, with no privilege needed to trigger it.","audience":"businesses","category":"runtime","nicknames":[],"who_cares":["linux","kernel","io_uring","self-hosted","kubernetes"],"confidence":0.6,"fix_status":"unknown","needs_auth":"no","worst_case":"Denial of service: a task stuck in cancellation holds a CPU indefinitely","analyst_note":"Find the affected and fixed kernel versions and the stable commit for this fix in the NVD entry at https://nvd.nist.gov/vuln/detail/CVE-2026-99254 or the kernel.org stable tree.","how_to_check":"- Check the running kernel version with `uname -r` and compare it against the fixed kernel releases in the NVD entry for CVE-2026-99254.\n- Look for io_uring use in your workloads: `grep -r io_uring /proc/*/maps` or check whether services use liburing.\n- unknown, the sources do not list affected kernel version ranges.","plain_action":"","needs_analyst":true,"not_affected_if":["no-io_uring-use"],"who_is_affected":"The flaw is in the Linux kernel's io_uring code, so any host running a kernel with the affected io_uring code and workloads that create io_uring rings can hit it. Systems that do not use io_uring are not exposed through this path. The sources do not say which kernel versions are affected.","user_interaction":"no","needs_special_setup":"unknown","severity_if_unknown":"unknown"},"cost_usd":0.000805,"input_tokens":4576,"output_tokens":695,"severity_before":"unknown"},"analyst_status":null,"analyst_note":null,"search":"'-2026':14A,17A '-99254':15A,18A '20':269C '280000':264C '5':267C '60':255C '64':218C 'alreadi':51B 'ask':110C 'back':240C 'busi':74B,299C 'callback':47B,166C,223C,265C,362C 'cancel':53B,60B,101C,150C,203C,243C,309C,368C 'cannot':67B 'cb':137C 'cleanup':46B 'complet':173C 'cpu':73B,294C 'cpus':12A 'cve':13A,16A 'doesn':138C 'effect':62B 'either':387C 'empti':133C,194C,237C 'end':159C,275C 'execv':308C 'exit':5A,39B,108C,136C,272C,301C,350C 'file':215C 'find':191C,234C 'five':333C 'flood':7A,99C 'follow':90C 'generic':151C 'get':239C,321C 'goe':250C 'gone':391C 'group':273C 'happen':280C 'held':209C 'host':27B 'insid':201C 'io':3A,19B,33B,95C,106C,134C,148C,348C 'item':41B,163C,220C,298C,336C,383C 'jiffi':345C 'keep':42B,71B,221C,292C 'kernel':2A,21B,31B,88C 'kill':69B,306C 'kubernet':22B 'last':211C 'late':283C 'linux':1A,23B,30B,87C 'list':131C,193C,236C 'littl':371C 'live':318C 'meanwhil':307C 'met':364C 'minut':78B,327C 'need':82B,355C 'never':57B,233C,238C 'next':401C 'nobodi':377C 'node':122C,142C,156C,245C,389C 'noth':175C 'one':226C 'pair':256C 'poll':260C 'privileg':81B,353C 'queu':45B 'queue':164C 'ran':263C 're':44B 're-queu':43B 'refer':212C 'releas':199C 'remov':119C,153C 'repeat':127C 'request':205C,311C 'resolv':94C 'return':58B,188C 'ring':38B,107C,117C,197C,208C,258C,349C 'ring-exit':37B 'round':402C 'run':186C,230C,337C 'runtim':24B 'second':76B,268C,270C 'self':26B 'self-host':25B 'send':222C 'sender':279C 'sent':375C 'soon':169C 'stall':11A 'stay':246C 'stuck':322C 'subsystem':35B 'take':330C 'task':6A,9A,50B,56B,65B,102C,104C,112C,124C,145C,184C,227C,253C,291C,302C,319C,366C 'tctx':121C,135C 'time':183C,287C,343C 'timeout':346C 'touch':140C 'trigger':84B 'turn':398C 'ure':4A,20B,34B,96C,149C 'use':115C 'vulner':91C 'wait':369C 'wake':380C 'warn':340C 'wast':181C 'way':315C 'well':325C 'work':10A,40B,105C,109C,125C,162C,185C,219C,297C,335C,351C,382C","nicknames":[],"mitigations":[],"who_affected":"The flaw is in the Linux kernel's io_uring code, so any host running a kernel with the affected io_uring code and workloads that create io_uring rings can hit it. Systems that do not use io_uring are not exposed through this path. The sources do not say which kernel versions are affected.","tier":"C","verified":{},"analyst_revisit_at":null,"fix_status":"unknown","audience":"businesses","plain_action":null,"pkeys":[],"ptokens":[],"labels":["iouring","kernel","kubernetes","linux","runtime","selfhosted","unknown"],"first_public_at":"2026-11-03T12:17:32+00:00","kev":null,"cvss_vector":null,"cvss_by":null,"poc_count":0,"sources":[{"source":"nvd","external_id":"CVE-2026-99254","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-99254","severity":null,"published_at":"2026-11-03T12:17:32+00:00","modified_at":"2026-11-03T12:17:32+00:00","first_seen_at":"2026-11-03T12:20:39+00:00","fetched_at":"2026-11-03T12:20:39+00:00","note":null}],"documents":[],"notice":"Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai"}