CVE-2026-99268 - Vulnerability Details

Vendors	Products
Linux	Linux Linux Kernel

Link	Providers
https://git.kernel.org/stable/c/2c88d978f1dfd03edf67924ea8fd25cc45499eef
https://git.kernel.org/stable/c/92bfadcbe0a9a001beb5e58a2abaf040b873deb6
https://git.kernel.org/stable/c/9bb28e7740ce78beecafc5db074b45f4cbeb8a47
https://git.kernel.org/stable/c/b88902d8745a701d24275d012f0830e3628e2a22
https://git.kernel.org/stable/c/d8c618747a6aa90022e19ec614aa7157d0302108

Type	Values Removed	Values Added
Description	In the Linux kernel, the following vulnerability has been resolved: io_uring: wake ring pollers for local task_work With IORING_SETUP_DEFER_TASKRUN completions are queued as local work, and only become CQEs when the submitter enters the kernel to wait for events. For an application that finds out via poll() or epoll on the ring fd when it is time to do that, io_uring_poll() reports EPOLLIN if local work is pending. That only helps if the work is there at the time of the call. When DEFER_TASKRUN was added, io_req_local_work_add() did io_cqring_wake(), which took care of tasks sleeping in poll() as well. Then polling got a wait queue of its own, ->poll_wq, and the wake up in io_req_local_work_add() was replaced by waking the submitter directly. Since then ->poll_wq is only woken when CQEs are committed, which for such a ring is done by the very task that is waiting to be told to: submitter completion poll(ring_fd) io_uring_poll() // nothing yet schedule() io_req_local_work_add() // ->cq_wait_nr: nobody waits // sleeps on Wake ->poll_wq when the first entry is put on the work list. Like for the eventfd, that must not be done right away if the work is queued from a wake up handler, as the chain of wake ups could get back to the wait queue whose lock is held. Use an RCU callback in that case, with a reference to the ring.	This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Title	io_uring: wake ring pollers for local task_work
CPEs	cpe:2.3:o:linux:linux_kernel::::::::

Type	Values Removed	Values Added
References		https://git.kernel.org/stable/c/b88902d8745a701d24275d012f0830e3628e2a22

Type	Values Removed	Values Added
First Time appeared		Linux linux
Weaknesses		CWE-754
Vendors & Products		Linux linux

Type	Values Removed	Values Added
Description		In the Linux kernel, the following vulnerability has been resolved: io_uring: wake ring pollers for local task_work With IORING_SETUP_DEFER_TASKRUN completions are queued as local work, and only become CQEs when the submitter enters the kernel to wait for events. For an application that finds out via poll() or epoll on the ring fd when it is time to do that, io_uring_poll() reports EPOLLIN if local work is pending. That only helps if the work is there at the time of the call. When DEFER_TASKRUN was added, io_req_local_work_add() did io_cqring_wake(), which took care of tasks sleeping in poll() as well. Then polling got a wait queue of its own, ->poll_wq, and the wake up in io_req_local_work_add() was replaced by waking the submitter directly. Since then ->poll_wq is only woken when CQEs are committed, which for such a ring is done by the very task that is waiting to be told to: submitter completion poll(ring_fd) io_uring_poll() // nothing yet schedule() io_req_local_work_add() // ->cq_wait_nr: nobody waits // sleeps on Wake ->poll_wq when the first entry is put on the work list. Like for the eventfd, that must not be done right away if the work is queued from a wake up handler, as the chain of wake ups could get back to the wait queue whose lock is held. Use an RCU callback in that case, with a reference to the ring.
Title		io_uring: wake ring pollers for local task_work
First Time appeared		Linux Linux linux Kernel
CPEs		cpe:2.3:o:linux:linux_kernel::::::::
Vendors & Products		Linux Linux linux Kernel
References		https://git.kernel.org/stable/c/2c88d978f1dfd03edf67924ea8fd25cc45499eef https://git.kernel.org/stable/c/92bfadcbe0a9a001beb5e58a2abaf040b873deb6 https://git.kernel.org/stable/c/9bb28e7740ce78beecafc5db074b45f4cbeb8a47 https://git.kernel.org/stable/c/d8c618747a6aa90022e19ec614aa7157d0302108

{"dataType": "CVE_RECORD", "dataVersion": "5.2", "cveMetadata": {"cveId": "CVE-2026-99268", "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "state": "REJECTED", "assignerShortName": "Linux", "dateReserved": "2026-09-25T10:25:14.404Z", "datePublished": "2026-11-03T11:48:17.911Z", "dateUpdated": "2026-11-04T18:21:42.034Z", "dateRejected": "2026-11-04T18:21:42.034Z"}, "containers": {"cna": {"rejectedReasons": [{"lang": "en", "value": "This CVE ID has been rejected or withdrawn by its CVE Numbering Authority."}], "providerMetadata": {"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "shortName": "Linux", "dateUpdated": "2026-11-04T18:21:42.034Z"}, "x_generator": {"engine": "cvelib 1.8.0"}}}}

{"affected": [{"affectedData": [{"defaultStatus": "unaffected", "product": "Linux", "programFiles": ["include/linux/io_uring_types.h", "io_uring/tw.c"], "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "vendor": "Linux", "versions": [{"lessThan": "9bb28e7740ce78beecafc5db074b45f4cbeb8a47", "status": "affected", "version": "130bd686d9be918e4cc8c03abf5794ba2d860502", "versionType": "git"}, {"lessThan": "d8c618747a6aa90022e19ec614aa7157d0302108", "status": "affected", "version": "130bd686d9be918e4cc8c03abf5794ba2d860502", "versionType": "git"}, {"lessThan": "2c88d978f1dfd03edf67924ea8fd25cc45499eef", "status": "affected", "version": "130bd686d9be918e4cc8c03abf5794ba2d860502", "versionType": "git"}, {"lessThan": "92bfadcbe0a9a001beb5e58a2abaf040b873deb6", "status": "affected", "version": "130bd686d9be918e4cc8c03abf5794ba2d860502", "versionType": "git"}, {"lessThan": "b88902d8745a701d24275d012f0830e3628e2a22", "status": "affected", "version": "130bd686d9be918e4cc8c03abf5794ba2d860502", "versionType": "git"}]}, {"defaultStatus": "affected", "product": "Linux", "programFiles": ["include/linux/io_uring_types.h", "io_uring/tw.c"], "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "vendor": "Linux", "versions": [{"status": "affected", "version": "6.3"}, {"lessThan": "6.3", "status": "unaffected", "version": "0", "versionType": "semver"}, {"lessThanOrEqual": "6.6.*", "status": "unaffected", "version": "6.6.161", "versionType": "semver"}, {"lessThanOrEqual": "6.12.*", "status": "unaffected", "version": "6.12.115", "versionType": "semver"}, {"lessThanOrEqual": "6.18.*", "status": "unaffected", "version": "6.18.60", "versionType": "semver"}, {"lessThanOrEqual": "7.2.*", "status": "unaffected", "version": "7.2.14", "versionType": "semver"}, {"lessThanOrEqual": "*", "status": "unaffected", "version": "7.4-rc1", "versionType": "original_commit_for_fix"}]}], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}], "cveTags": [], "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nio_uring: wake ring pollers for local task_work\n\nWith IORING_SETUP_DEFER_TASKRUN completions are queued as local work, and\nonly become CQEs when the submitter enters the kernel to wait for events.\nFor an application that finds out via poll() or epoll on the ring fd when\nit is time to do that, io_uring_poll() reports EPOLLIN if local work is\npending.\n\nThat only helps if the work is there at the time of the call. When\nDEFER_TASKRUN was added, io_req_local_work_add() did io_cqring_wake(),\nwhich took care of tasks sleeping in poll() as well. Then polling got a\nwait queue of its own, ->poll_wq, and the wake up in\nio_req_local_work_add() was replaced by waking the submitter directly.\nSince then ->poll_wq is only woken when CQEs are committed, which for\nsuch a ring is done by the very task that is waiting to be told to:\n\n submitter completion\n poll(ring_fd)\n io_uring_poll() // nothing yet\n schedule()\n io_req_local_work_add()\n // ->cq_wait_nr: nobody waits\n // sleeps on\n\nWake ->poll_wq when the first entry is put on the work list. Like for the\neventfd, that must not be done right away if the work is queued from a\nwake up handler, as the chain of wake ups could get back to the wait\nqueue whose lock is held. Use an RCU callback in that case, with a\nreference to the ring."}], "id": "CVE-2026-99268", "lastModified": "2026-11-03T20:18:32.503", "metrics": {}, "published": "2026-11-03T12:17:33.980", "references": [{"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/2c88d978f1dfd03edf67924ea8fd25cc45499eef"}, {"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/92bfadcbe0a9a001beb5e58a2abaf040b873deb6"}, {"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/9bb28e7740ce78beecafc5db074b45f4cbeb8a47"}, {"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/b88902d8745a701d24275d012f0830e3628e2a22"}, {"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/d8c618747a6aa90022e19ec614aa7157d0302108"}], "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "vulnStatus": "Received"}

Metrics

Affected Vendors & Products

Metrics

Affected Vendors & Products

JSON object

JSON object

JSON object

JSON object