Live › vulnerability › CVE-2026-99263
In the Linux kernel's io_uring poll path, a wakeup that arrives at the wrong moment can be lost, leaving a request stalled until an unrelated wakeup occurs. The sources describe a stall (denial of service style impact), not code execution or data access.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-11-03 12:20 UTC. All times on this page are UTC.
Systems running a Linux kernel with io_uring poll operations, typically servers running io_uring-based network or file I/O. The sources do not state the affected kernel version ranges. Hosts without io_uring in use are unlikely to be exposed.
No product ranges from the sources yet.
uname -r to see the running kernel versioncat /proc/sys/kernel/io_uring_disabled on kernels that expose it)Unknown from the sources.
Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
In the Linux kernel, the following vulnerability has been resolved:
io_uring/poll: avoid retry wakeup loss when dropping ownership
If a wakeup sets IO_POLL_RETRY_FLAG between the owning task consuming the existing instance of IO_POLL_RETRY_FLAG and the loop check of io_poll_check_events(), then we stall on processing the request until an unrelated wakeup comes along.
Using atomic_cmpxchg instead of atomic_sub_return to guarantee both the count v and poll_refs are 0 and no wake-ups are missed.
This page as .md · .json · in your agent: get_signal("CVE-2026-99263")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.