Skip to content
CVE Ledger
  • Newest CVEsPage
  • Recently added to KEVPage
  • Rising exploitation (EPSS)Page
  • Weekly digestPage
  • StatisticsPage
  • WatchlistPage
  • API docsPage
  • MCP serverPage
  • AboutPage
  • Data sourcesPage
  • Data statusPage
  • ChangelogPage
  • How it's builtPage
  • Support the projectPage

14 results

Back

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

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

  1. ID reserved

    By Linux

  2. · 38 days later

    Published

  3. · 4 days later

    Record updated

Changes after publication (a new score, a public exploit, EPSS crossing 1, 10 or 50 %, leaving KEV) are kept since November 2026; earlier ones are not known.

Scores

CVSS scores of CVE-2026-99231, by who scored it
Scored byCVSSScoreVector
LinuxCNA (assigner)3.1High7.8CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
NVDNVD · Received3.1High7.8CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
EPSS (exploitation in 30 days)
0.12% · top 98% of all CVEs (12 Nov 2026)
Loading the EPSS history…

The list uses the assigner's score when there is one, then CISA's, then NVD's: High 7.8.

Affected products

  • Linux · Linux

    • affected 09951a4d37e33b0197afc7fb77e39f09a3213ee6 – < bf01da1a9cca4a54e5c30b8344e52c26afb87be7
    • affected 934ffdd1cdef232eb125e63c2ebafb7f2deff6af – < 8381a912c65b8de16e8a848225c7c5a56b6ea834
    • affected ab673c1bcaf20ac70352eeb6bf5b828462676693 – < c10ad2813e15186fb51b37a4d17fafddc99e89a5
    • affected ab673c1bcaf20ac70352eeb6bf5b828462676693 – < 6e11ce129b34fb9a43b2bbe838df49ea52878d5c
    • affected ab673c1bcaf20ac70352eeb6bf5b828462676693 – < c254eec4364b9f4b4cbdce43be3fb4df5a651a70
    • affected 6.12.113 – < 6.12.115
    • affected 6.18.52 – < 6.18.60

  • Linux · Linux

    • affected 6.19
    • unaffected < 6.19
    • unaffected 6.12.115 – ≤ 6.12.*
    • unaffected 6.18.60 – ≤ 6.18.*
    • unaffected 7.2.14 – ≤ 7.2.*
    • unaffected 7.3.2 – ≤ 7.3.*
    • unaffected 7.4-rc1 – ≤ *

References

References5

Sources

The same CVE in the primary databases and aggregators, to check against.

Badge for a README or a ticket

CVE-2026-99231 badge
[![CVE-2026-99231](https://cveledger.app/badge/CVE-2026-99231.svg)](https://cveledger.app/cve/CVE-2026-99231)

Record last updated .