CVE-2026-99231 Uso después de liberar en io_uring/waitid al limpiar -head
En el kernel de Linux, io_waitid_wait() limpia -head antes de incrementar -refs para tomar propiedad de la solicitud. Si otro la posee, puede completarla y liberarla mientras el manejador de despertar aún la usa, lo que lleva a un uso después de liberar.
CVSS 3.1
- Probabilidad de explotación · EPSS del 09/110,1 % · percentil 1
- Explotada activamenteNo confirmada
- Exploit públicoNo conocido
Afectados
Linux
desde 09951a4d37e33b0197afc7fb77e39f09a3213ee6 hasta antes de bf01da1a9cca4a54e5c30b8344e52c26afb87be7desde 934ffdd1cdef232eb125e63c2ebafb7f2deff6af hasta antes de 8381a912c65b8de16e8a848225c7c5a56b6ea834desde ab673c1bcaf20ac70352eeb6bf5b828462676693 hasta antes de c10ad2813e15186fb51b37a4d17fafddc99e89a5desde ab673c1bcaf20ac70352eeb6bf5b828462676693 hasta antes de 6e11ce129b34fb9a43b2bbe838df49ea52878d5cdesde ab673c1bcaf20ac70352eeb6bf5b828462676693 hasta antes de c254eec4364b9f4b4cbdce43be3fb4df5a651a70desde 6.12.113 hasta antes de 6.12.115desde 6.18.52 hasta antes de 6.18.60
Linux
6.19
Qué hacer
- Verificá si usás Linux y en qué versión.
- Actualizá a la versión corregida que indique el fabricante en su aviso o aplicá su mitigación.
- Revisá registros y accesos de los sistemas expuestos para descartar un uso previo.
Calculadora CVSS
CVSS 3.1 · 7.8 ALTA
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
- Vector de ataqueLocal
- Complejidad del ataqueBaja
- Privilegios requeridosBajos
- Interacción del usuarioNinguna
- AlcanceSin cambio
- ConfidencialidadAlta
- IntegridadAlta
- DisponibilidadAlta
Descripción original
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.
Referencias (5)
- git.kernel.org/stable/c/bf01da1a9cca4a54e5c30b8344e52c26afb87be7
- git.kernel.org/stable/c/8381a912c65b8de16e8a848225c7c5a56b6ea834
- git.kernel.org/stable/c/c10ad2813e15186fb51b37a4d17fafddc99e89a5
- git.kernel.org/stable/c/6e11ce129b34fb9a43b2bbe838df49ea52878d5c
- git.kernel.org/stable/c/c254eec4364b9f4b4cbdce43be3fb4df5a651a70
Resumen traducido automáticamente de la descripción original. Fuente: Nureq Monitor. Cómo funciona.