Linux Kernel up to 7.2.13 io_uring io_ring_exit_work resource consumption

| CVSS Meta Temp Score | Current Exploit Price (≈) | CTI Interest Score |
|---|---|---|
| 7.2 | $0-$5k | 1.86 |
Summary
A vulnerability classified as critical has been found in Linux Kernel up to 6.1.190/6.6.160/6.12.114/6.18.59/7.2.13. Affected by this issue is the function io_ring_exit_work of the component io_uring. Performing a manipulation results in resource consumption.
This vulnerability was named CVE-2026-99254. The attack may be initiated remotely. There is no available exploit.
It is recommended to upgrade the affected component.
Details
A vulnerability was found in Linux Kernel up to 6.1.190/6.6.160/6.12.114/6.18.59/7.2.13. It has been classified as critical. This affects the function io_ring_exit_work of the component io_uring. The manipulation with an unknown input leads to a resource consumption vulnerability. CWE is classifying the issue as CWE-400. The product does not properly control the allocation and maintenance of a limited resource, thereby enabling an actor to influence the amount of resources consumed, eventually leading to the exhaustion of available resources. This is going to have an impact on availability. The summary by CVE is:
In the Linux kernel, the following vulnerability has been resolved: io_uring: don't flood a cancelling task with task_work io_ring_exit_work() asks each task which has used the ring to remove its tctx node, by task_work, and repeats that until the list is empty. io_tctx_exit_cb() doesn't touch the node while the task is in io_uring_cancel_generic(), which removes all the nodes at its end. So the work item queues the callback again as soon as it has completed, for nothing. That is more than a waste of time. task_work_run() only returns when it finds the list empty. If the rings are released from inside the cancellation, because requests of other rings held the last references to their files, up to 64 work items keep sending callbacks to the one task which is running them. It never finds the list empty, never gets back to the cancellation, the nodes stay, and so it goes on: a task with 60 pairs of rings which poll each other ran 280000 callbacks in 5 seconds, 20 seconds after exit_group(). It ends when all the senders happen to be late at the same time. Until then the task keeps a CPU and the work items busy. An exiting task can't be killed meanwhile. execve() cancels the requests in the same way, so a live task can get stuck there as well, for minutes. If it takes more than five, the work items run into the WARN_ON_ONCE(time_after(jiffies, timeout)) of io_ring_exit_work(). No privilege is needed for any of this. If the callback has met a task in cancellation, wait a little before it is sent again. Nobody has to wake the work item up for that: either the node is gone by then, or it is the turn of the next round.
The advisory is shared at git.kernel.org. This vulnerability is uniquely identified as CVE-2026-99254 since 09/25/2026. The exploitability is told to be easy. It is possible to initiate the attack remotely. No form of authentication is needed for exploitation. Technical details are known, but no exploit is available. The price for an exploit might be around USD $0-$5k at the moment (estimation calculated on 11/03/2026). MITRE ATT&CK project uses the attack technique T1499 for this issue.
Upgrading to version 6.1.191, 6.6.161, 6.12.115, 6.18.60 or 7.2.14 eliminates this vulnerability. Applying the patch a22fb44e988b01b82235ea07f0bf0fc73e256596/2c75ebae8a7f09c99e31c7042b7d4d595f03b2b1/61c761fc21e00e45c33c2bb596be442d92fb8792/14f56e9c0b8fdc2e178acdbec9781e90ef46f7e9/abdc57c7ebabaaf0b622178a6a85834e1e54ff80 is able to eliminate this problem. The best possible mitigation is suggested to be upgrading to the latest version.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Product
Type
Vendor
Name
Version
- 6.1.190
- 6.6.160
- 6.12.114
- 6.18.0
- 6.18.1
- 6.18.2
- 6.18.3
- 6.18.4
- 6.18.5
- 6.18.6
- 6.18.7
- 6.18.8
- 6.18.9
- 6.18.10
- 6.18.11
- 6.18.12
- 6.18.13
- 6.18.14
- 6.18.15
- 6.18.16
- 6.18.17
- 6.18.18
- 6.18.19
- 6.18.20
- 6.18.21
- 6.18.22
- 6.18.23
- 6.18.24
- 6.18.25
- 6.18.26
- 6.18.27
- 6.18.28
- 6.18.29
- 6.18.30
- 6.18.31
- 6.18.32
- 6.18.33
- 6.18.34
- 6.18.35
- 6.18.36
- 6.18.37
- 6.18.38
- 6.18.39
- 6.18.40
- 6.18.41
- 6.18.42
- 6.18.43
- 6.18.44
- 6.18.45
- 6.18.46
- 6.18.47
- 6.18.48
- 6.18.49
- 6.18.50
- 6.18.51
- 6.18.52
- 6.18.53
- 6.18.54
- 6.18.55
- 6.18.56
- 6.18.57
- 6.18.58
- 6.18.59
- 7.2.0
- 7.2.1
- 7.2.2
- 7.2.3
- 7.2.4
- 7.2.5
- 7.2.6
- 7.2.7
- 7.2.8
- 7.2.9
- 7.2.10
- 7.2.11
- 7.2.12
- 7.2.13
License
Website
- Vendor: https://www.kernel.org/
CPE 2.3
CPE 2.2
CVSSv4
VulDB Vector: 🔒VulDB Reliability: 🔍
CVSSv3
VulDB Meta Base Score: 7.5VulDB Meta Temp Score: 7.2
VulDB Base Score: 7.5
VulDB Temp Score: 7.2
VulDB Vector: 🔒
VulDB Reliability: 🔍
CVSSv2
| AV | AC | Au | C | I | A |
|---|---|---|---|---|---|
| 💳 | 💳 | 💳 | 💳 | 💳 | 💳 |
| 💳 | 💳 | 💳 | 💳 | 💳 | 💳 |
| 💳 | 💳 | 💳 | 💳 | 💳 | 💳 |
| Vector | Complexity | Authentication | Confidentiality | Integrity | Availability |
|---|---|---|---|---|---|
| Unlock | Unlock | Unlock | Unlock | Unlock | Unlock |
| Unlock | Unlock | Unlock | Unlock | Unlock | Unlock |
| Unlock | Unlock | Unlock | Unlock | Unlock | Unlock |
VulDB Base Score: 🔒
VulDB Temp Score: 🔒
VulDB Reliability: 🔍
Exploiting
Class: Resource consumptionCWE: CWE-400 / CWE-404
CAPEC: 🔒
ATT&CK: 🔒
Physical: No
Local: No
Remote: Yes
Availability: 🔒
Status: Not defined
Price Prediction: 🔍
Current Price Estimation: 🔒
| 0-Day | Unlock | Unlock | Unlock | Unlock |
|---|---|---|---|---|
| Today | Unlock | Unlock | Unlock | Unlock |
Threat Intelligence
Interest: 🔍Active Actors: 🔍
Active APT Groups: 🔍
Countermeasures
Recommended: UpgradeStatus: 🔍
0-Day Time: 🔒
Upgrade: Kernel 6.1.191/6.6.161/6.12.115/6.18.60/7.2.14
Patch: a22fb44e988b01b82235ea07f0bf0fc73e256596/2c75ebae8a7f09c99e31c7042b7d4d595f03b2b1/61c761fc21e00e45c33c2bb596be442d92fb8792/14f56e9c0b8fdc2e178acdbec9781e90ef46f7e9/abdc57c7ebabaaf0b622178a6a85834e1e54ff80
Timeline
09/25/2026 CVE reserved11/03/2026 Advisory disclosed
11/03/2026 VulDB entry created
11/03/2026 VulDB entry last update
Sources
Vendor: kernel.orgAdvisory: git.kernel.org
Status: Confirmed
CNA: Linux
CVE: CVE-2026-99254 (🔒)
GCVE (CVE): GCVE-0-2026-99254
GCVE (VulDB): GCVE-100-430233
Entry
Created: 11/03/2026 12:42Changes: 11/03/2026 12:42 (59)
Complete: 🔍
Cache ID: 216::103
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
No comments yet. Languages: en.
Please log in to comment.