Skip to main content
No exploitation reportedAwaiting NVD analysis

CVE-2026-99231

io_uring/waitid: own the request before clearing ->head

No exploitation reported by the sources we read.

  • Published2026-11-02

Am I affected?

With a domain, we read the version its public headers and pages expose. A distribution build can carry the fix under an older number.

Description

In the Linux kernel, the following vulnerability has been resolved: io_uring/waitid: own the request before clearing ->head io_waitid_remove_wq() only takes the wait queue lock if ->head is set. io_waitid_wait() clears ->head first thing, before it tries to become the owner of the request by bumping ->refs. If somebody else owns the request at that point, nothing keeps it from completing the request while the wake up handler is still going to touch it: CPU0 (io_waitid_wait) CPU1 (io_waitid, holds a ref) list_del_init(&wait->entry) smp_store_release(&iw->head, NULL) __do_wait() finds another child io_waitid_remove_wq() // ->head == NULL, no locking io_waitid_finish(), IOU_COMPLETE // request freed and reused atomic_fetch_inc(&iw->refs) The same goes for __io_waitid_cancel() if it claims the request in that window. ->refs is part of the per opcode data of the request, so this increments whatever the next user of the request keeps there. If that happens to be zero, the handler concludes that it owns the request, and queues io_waitid_cb() for it. With the window held open by a delay, and the request reused for a receive that is waiting for data: BUG: KASAN: slab-use-after-free in __wake_up_common+0x1ca/0x1f0 __wake_up_sync_key+0x36/0x50 sock_def_readable+0xf1/0x420 unix_stream_sendmsg+0x60b/0x1110 Allocated by task 87: io_arm_apoll+0x1ed/0x940 Freed by task 87: __io_submit_flush_completions+0x118d/0x1a10 tctx_task_work_run+0x327/0x950 Only clear ->head once the handler owns the request. If it doesn't, the owner finds ->head set and has to wait for the lock, which is held by the caller of the handler. Deleting the already deleted entry again is harmless.

Timeline

dates in UTC
  1. 2026-11-0216:06CVE publishedCNA

Observed activity

isMalicious corpus · updated 2026-11-02 15:37 UTC
Indicators tagged with this CVE, per day0 indicators over 7 days
Block these indicators
  • Firewall list (EDL, text): https://api.ismalicious.com/edl/cve/CVE-2026-99231?format=txt
  • CSV export: https://api.ismalicious.com/edl/cve/CVE-2026-99231?format=csv
  • TAXII collection of exploited CVEs
  • The EDL and CSV take an API key on the Pro plan.

Versions per branch

Products declared by the CNA

As Linux, the CNA that assigned this CVE, declared them in the CVE record; versions as written. NVD lists no product for this CVE yet: this is the only product data so far.

  • Linuxother versions: not affected

    https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git

    Affected
    • ≥ 09951a4d37e33b0197afc7fb77e39f09a3213ee6, < bf01da1a9cca4a54e5c30b8344e52c26afb87be7fixed in bf01da1a9cca4a54e5c30b8344e52c26afb87be7git
    • ≥ 934ffdd1cdef232eb125e63c2ebafb7f2deff6af, < 8381a912c65b8de16e8a848225c7c5a56b6ea834fixed in 8381a912c65b8de16e8a848225c7c5a56b6ea834git
    • ≥ ab673c1bcaf20ac70352eeb6bf5b828462676693, < c10ad2813e15186fb51b37a4d17fafddc99e89a5fixed in c10ad2813e15186fb51b37a4d17fafddc99e89a5git
    • ≥ 6.12.113, < 6.12.115fixed in 6.12.115semver
    • ≥ 6.18.52, < 6.18.60fixed in 6.18.60semver
  • Linuxother versions: affected

    https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git

    Affected
    • = 6.19no fix stated

    Not affected < 6.19 · ≥ 6.12.115, ≤ 6.12.* · ≥ 6.18.60, ≤ 6.18.* · ≥ 7.2.14, ≤ 7.2.*

Source: the CNA record (CVE Program), © The MITRE Corporation,CVE Terms of UseCVE recordupdated 2026-11-02

Neither OSV.dev nor the vendor advisories we read list affected versions for CVE-2026-99231 yet.

Full record on NVD

Fix

No fix published by the sources we read yet. NVD record

Detection

Nuclei template
none so far
ProjectDiscovery
Exploit-DB
no entry
Exploit-DB
Proof-of-concept repositories
none listed
PoC-in-GitHub
Metasploit modules
none listed
Metasploit Framework

Sources

  • NVDCVE record2026-11-02
  • CNACVSS 3.17.82026-11-02

Technical details

CVSS v3 Vector
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Published
2026-11-02

Frequently asked questions

What is CVE-2026-99231?

In the Linux kernel, the following vulnerability has been resolved: io_uring/waitid: own the request before clearing ->head io_waitid_remove_wq() only takes the wait queue lock if ->head is set. io_waitid_wait() clears ->head first thing, before it tries to become the owner of the request by bumping ->refs. If somebody else owns the request at that point, nothing keeps it from completing the request while the wake up handler is still going to touch it: CPU0 (io_waitid_wait) CPU1 (io_waitid, holds a ref) list_del_init(&wait->entry) smp_store_release(&iw->head, NULL) __do_wait() finds another child io_waitid_remove_wq() // ->head == NULL, no locking io_waitid_finish(), IOU_COMPLETE // request freed and reused atomic_fetch_inc(&iw->refs) The same goes for __io_waitid_cancel() if it claims the request in that window. ->refs is part of the per opcode data of the request, so this increments whatever the next user of the request keeps there. If that happens to be zero, the handler concludes that it owns the request, and queues io_waitid_cb() for it. With the window held open by a delay, and the request reused for a receive that is waiting for data: BUG: KASAN: slab-use-after-free in __wake_up_common+0x1ca/0x1f0 __wake_up_sync_key+0x36/0x50 sock_def_readable+0xf1/0x420 unix_stream_sendmsg+0x60b/0x1110 Allocated by task 87: io_arm_apoll+0x1ed/0x940 Freed by task 87: __io_submit_flush_completions+0x118d/0x1a10 tctx_task_work_run+0x327/0x950 Only clear ->head once the handler owns the request. If it doesn't, the owner finds ->head set and has to wait for the lock, which is held by the caller of the handler. Deleting the already deleted entry again is harmless.

Is CVE-2026-99231 actively exploited?

Active exploitation of CVE-2026-99231 has not been confirmed.

What is the CVSS score for CVE-2026-99231?

CVE-2026-99231 has a CVSS v3 base score of 7.8 (HIGH severity), with vector string CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H.

Running Linux kernel? Hear about its next vulnerability

Surveillance reads the versions in your stack — a domain, a lockfile or a list — checks each CVE against the ranges its sources publish, and alerts you when one you run is exploited or enters CISA KEV. A version it cannot read stays « version not verified ».

Get alerts for this productCISA KEV additions, October 2026Search CVEs

No credit card required · No monthly cap on website lookups · 250 API requests/month

Go further

Related vulnerabilities

Same product first, then the same vendor advisory and the same publication week.

Back to CVE Database

Sources for this record