CVE-2026-99227 json
io_uring/waitid: prevent cancel reference wrap
published 2026-11-02 6 d ago modified 2026-11-03 5 d ago also EUVD-2026-115269
- cvss
- 7.8
- version 3.1, CNA
- cisa kev
- Not listed
- not in CISA's catalog
- epss
- 0.1%
- EPSS 0.1% chance of exploitation in 30 days, percentile 1%
- public exploits
- 0
- none known
Summary
In the Linux kernel, the following vulnerability has been resolved:
io_uring/waitid: prevent cancel reference wrap
io_waitid packs the cancellation state into bit 31 of ->refs and uses bits 30:0 as a 31-bit reference counter:
#define IO_WAITID_CANCEL_FLAG BIT(31) #define IO_WAITID_REF_MASK GENMASK(30, 0)
__io_waitid_cancel() marks a request canceled, then increments the low bits of ->refs to claim completion ownership. When another path owns the request, the increment remains even though cancellation returns false. The request remains discoverable by cancellation, so repeated failed attempts can wrap the 31-bit reference field to zero. A later cancellation can claim ownership and complete the request a second time.
Use atomic_fetch_or() when setting the cancel flag and inspect the old flag value. The first cancel attempt continues to the existing ownership increment, preserving its wake and issuer handoff semantics. Later attempts see the cancel flag and return without incrementing the reference field.
This makes repeated failed cancellation attempts idempotent while leaving the first-cancel state transitions unchanged.
Patch / fix
- Linux Linux 6.12.115, 6.18.60, 7.2.14, 7.3.1, 7.4-rc1
- linux Debian 13 6.12.115-1
- linux Debian 14 7.2.14-1
debian advisories DEBIAN-CVE-2026-99227
- git.kernel.org/stable/c/20b67288574c7c3df6b8ea7ed3b7af90a868006f commit
- git.kernel.org/stable/c/5bfeee1774791602a0d53eb717f00f172127a017 commit
- git.kernel.org/stable/c/857aa2012b91cad6fdef54a4b6c632d9d0b6e64f commit
- git.kernel.org/stable/c/22fb4a4518e305164c7f203608287564de292f34 commit
- git.kernel.org/stable/c/98787d3fa4e99564d2b2bc21255b21f670c450d0 commit
Vendor advisories
What the vendors themselves say about their products: affected, fixed or not affected, and what to do.
red hat product security vex CVE-2026-99227 updated cvss 7.8
kernel: kernel: Privilege escalation via reference counter wrap in io_uring
-
Red Hat Enterprise Linux 9 rv, perf, rtla, kernel, bpftool, libperf, +82 more Red Hat Enterprise Linux 10 kernel Red Hat OpenShift Container Platform 4 openshift/ose-rhel-coreos-9 Red Hat OpenShift Container Platform 5 openshift/ose-rhel-coreos-9, openshift/ose-rhel-coreos-10affected: workaround, no fix available
-
Red Hat Enterprise Linux 6 perf, kernel, python-perf, kernel-kdump, kernel-firmware, kernel-bootwrapper, +1 more Red Hat Enterprise Linux 7 perf, kernel, bpftool, kernel-rt, python-perf, kernel-kdump, +8 more Red Hat Enterprise Linux 8 perf, kernel, bpftool, kernel-rt, kernel-core, kernel-tools, +29 more Red Hat Enterprise Linux 9 kernel-rt, kernel-rt-selftests-internal Red Hat OpenShift Container Platform 4 openshift/ose-rhel-coreos-8not affected: vulnerable code not present
Red Hat CSAF VEX © Red Hat, Inc., from https://security.access.redhat.com/data/csaf/v2/vex/; changed: reduced to product statuses and remediations. CC BY 4.0 · csaf
Exploit prediction
0.12% chance of exploitation in the next 30 days, higher than 1% of all scored CVEs (FIRST EPSS, 2026-11-08).
CVSS scores
| assigned by | version | score | vector |
|---|---|---|---|
| CNA | 3.1 | 7.8 | CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H |
Affected products
- Linux Linux
Classification
- Technology feeds
References
- git.kernel.org /stable/c/20b67288574c7c3df6b8ea7ed3b7af90a868006f
- git.kernel.org /stable/c/5bfeee1774791602a0d53eb717f00f172127a017
- git.kernel.org /stable/c/857aa2012b91cad6fdef54a4b6c632d9d0b6e64f
- git.kernel.org /stable/c/22fb4a4518e305164c7f203608287564de292f34
- git.kernel.org /stable/c/98787d3fa4e99564d2b2bc21255b21f670c450d0
Sources
- CVE List CVE-2026-99227
- NVD CVE-2026-99227
Fencer Vulns keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.