Copyright © 2012 Red Hat, Inc. All rights reserved. Important 2026-11-02T16:06:38 kernel: kernel: Privilege escalation via use-after-free in io_uring waitid 7.8 CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H CWE-413

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.

A flaw was found in the Linux kernel's io_uring subsystem. A race condition in the waitid operation allows a request to be completed and freed while a wake-up handler is still accessing it, leading to a use-after-free vulnerability. A local user could exploit this flaw to cause a system crash, resulting in a Denial of Service (DoS), or potentially execute arbitrary code to escalate privileges.

--- CME Mitigation Guidance (2026-11-04) --- Disclaimer: The following mitigation solutions are provided as a courtesy, pending the application of an official patch. This content was generated utilizing AI tools in conjunction with data from https://cmetaxonomy.org. Customers are advised to independently evaluate and test these temporary mitigations within their own infrastructure. The highest-value action is to ensure the io_uring waitid wake-up handler claims request ownership before clearing ->head so concurrent operations cannot free the request without wait queue locking: upgrade to the fixed release, which defer clearing ->head until after the wake-up handler has acquired ownership of the request, closing all 2 injection vectors (concurrent io_uring waitid request completion, concurrent io_uring waitid request cancellation). Until patched, this is only a concern on Linux systems where local unprivileged users have permission to submit io_uring operations — non-Linux operating systems are unaffected — so Restrict and audit local unprivileged user access and permissions to submit io_uring operations. As a compensating measure, zero-initialize kernel slab allocations on creation using init_on_alloc or INIT_STACK_ALL_ZERO to reduce predictable reuse of stale request data, maintain SELinux in enforcing mode to confine local process domains and limit post-exploitation damage, map logged-in users to confined SELinux domains to restrict the privileges of unprivileged accounts, deploy an endpoint detection and response agent to identify anomalous privilege elevation and unauthorized shell generation, use Falco or eBPF runtime security to monitor kernel and process behavior for unexpected privilege escalations, and enable kernel address space layout randomization to hinder reliable code-execution payload crafting. These controls limit blast radius and contain exploitation, but they do not fix the underlying race condition use-after-free defect — apply the upstream patch to fully remediate. Highest-impact CME: CME-1005 Runtime Memory Error Detection (KASAN/HWASan) (high) Red Hat Enterprise Linux 10 Not affected kernel Red Hat Enterprise Linux 6 Not affected kernel Red Hat Enterprise Linux 7 Not affected kernel Red Hat Enterprise Linux 7 Not affected kernel-rt Red Hat Enterprise Linux 8 Not affected kernel Red Hat Enterprise Linux 8 Not affected kernel-rt Red Hat Enterprise Linux 9 Not affected kernel Red Hat Enterprise Linux 9 Not affected kernel-rt Red Hat OpenShift Container Platform 4 Not affected openshift/ose-rhel-coreos-8 Red Hat OpenShift Container Platform 4 Not affected openshift/ose-rhel-coreos-9 Red Hat OpenShift Container Platform 5 Not affected openshift/ose-rhel-coreos-10 Red Hat OpenShift Container Platform 5 Not affected openshift/ose-rhel-coreos-9 https://www.cve.org/CVERecord?id=CVE-2026-99231 https://nvd.nist.gov/vuln/detail/CVE-2026-99231 https://git.kernel.org/stable/c/8381a912c65b8de16e8a848225c7c5a56b6ea834 https://git.kernel.org/stable/c/bf01da1a9cca4a54e5c30b8344e52c26afb87be7 https://git.kernel.org/stable/c/c10ad2813e15186fb51b37a4d17fafddc99e89a5