Linux Kernel up to 7.2.13 io_uring io_uring_try_cancel_requests cq_wait_nr race condition

| CVSS Meta Temp Score | Current Exploit Price (≈) | CTI Interest Score |
|---|---|---|
| 6.2 | $0-$5k | 1.38 |
Summary
A vulnerability classified as critical has been found in Linux Kernel up to 7.2.13. This issue affects the function io_uring_try_cancel_requests of the component io_uring. The manipulation of the argument cq_wait_nr leads to race condition.
This vulnerability is uniquely identified as CVE-2026-99253. The attack is possible to be carried out remotely. No exploit exists.
It is recommended to upgrade the affected component.
Details
A vulnerability, which was classified as critical, has been found in Linux Kernel up to 7.2.13. This issue affects the function io_uring_try_cancel_requests of the component io_uring. The manipulation of the argument cq_wait_nr with an unknown input leads to a race condition vulnerability. Using CWE to declare the problem leads to CWE-362. The product contains a code sequence that can run concurrently with other code, and the code sequence requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence that is operating concurrently. Impacted is availability. The summary by CVE is:
In the Linux kernel, the following vulnerability has been resolved: io_uring/cancel: rearm local work wake up before sleep io_uring_try_cancel_requests() sets ->cq_wait_nr to 1 so that the next io_req_local_work_add() wakes the cancelling task. The add that takes the count to zero is the only one that wakes, later ones see a count <= 0 and return. io_uring_cancel_generic() however only becomes TASK_INTERRUPTIBLE much later, so the one wake up can be spent on a running task. That is fine as long as the entry of that add is still queued, as the io_local_work_pending() check then skips the sleep. It is not if the add was delayed after queueing its entry: CPU0 (submitter in exec or exit) CPU1 (io_req_local_work_add) mpscq_push(req A) io_uring_try_cancel_requests() io_run_local_work() // runs req A io_uring_try_cancel_requests() atomic_set(&ctx->cq_wait_nr, 1) atomic_read(&ctx->cq_wait_nr) == 1 count taken, wake_up_state() // task is running, no-op prepare_to_wait(TASK_INTERRUPTIBLE) io_local_work_pending() == false schedule() mpscq_push(req B) cq_wait_nr <= 0, return Only the sleeping task can run req B, so it is stuck in execve() until a signal happens to wake it. An exiting task doesn't even get that. Arm the count again once the task state is set and before the work list is checked, for the rings whose local work this task is the one to run.
It is possible to read the advisory at git.kernel.org. The identification of this vulnerability is CVE-2026-99253 since 09/25/2026. The exploitation is known to be easy. The attack may be initiated remotely. Technical details of the vulnerability are known, but there is no available exploit. The pricing for an exploit might be around USD $0-$5k at the moment (estimation calculated on 11/04/2026).
The vulnerability scanner Nessus provides a plugin with the ID 375582 (Linux Distros Unpatched Vulnerability : CVE-2026-99253), which helps to determine the existence of the flaw in a target environment.
Upgrading to version 7.2.14 eliminates this vulnerability. Applying the patch aaa06bb9fc03384f7cf2dbc3e43f2939cc7791b2 is able to eliminate this problem. The best possible mitigation is suggested to be upgrading to the latest version.
The vulnerability is also documented in the vulnerability database at Tenable (375582). Be aware that VulDB is the high quality source for vulnerability data.
Product
Type
Vendor
Name
Version
License
Website
- Vendor: https://www.kernel.org/
CPE 2.3
CPE 2.2
CVSSv4
VulDB Vector: 🔒VulDB Reliability: 🔍
CVSSv3
VulDB Meta Base Score: 6.5VulDB Meta Temp Score: 6.2
VulDB Base Score: 6.5
VulDB Temp Score: 6.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: Race conditionCWE: CWE-362
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 |
Nessus ID: 375582
Nessus Name: Linux Distros Unpatched Vulnerability : CVE-2026-99253
Threat Intelligence
Interest: 🔍Active Actors: 🔍
Active APT Groups: 🔍
Countermeasures
Recommended: UpgradeStatus: 🔍
0-Day Time: 🔒
Upgrade: Kernel 7.2.14
Patch: aaa06bb9fc03384f7cf2dbc3e43f2939cc7791b2
Timeline
09/25/2026 CVE reserved11/03/2026 Advisory disclosed
11/03/2026 VulDB entry created
11/04/2026 VulDB entry last update
Sources
Vendor: kernel.orgAdvisory: git.kernel.org
Status: Confirmed
CNA: Linux
CVE: CVE-2026-99253 (🔒)
GCVE (CVE): GCVE-0-2026-99253
GCVE (VulDB): GCVE-100-430247
Entry
Created: 11/03/2026 12:46Updated: 11/04/2026 08:00
Changes: 11/03/2026 12:46 (60), 11/04/2026 08:00 (2)
Complete: 🔍
Cache ID: 216::103
Be aware that VulDB is the high quality source for vulnerability data.
No comments yet. Languages: en.
Please log in to comment.