Vulnerabilidad en Linux (CVE-2026-23113)

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> io_uring/io-wq: verificar IO_WQ_BIT_EXIT dentro del bucle de ejecución de trabajo<br /> <br /> Actualmente esto se verifica antes de ejecutar el trabajo pendiente. Normalmente esto está bastante bien, ya que los elementos de trabajo o terminan bloqueándose (lo que creará un nuevo trabajador para otros elementos), o se completan bastante rápido. Pero syzbot informa un problema donde io-wq tarda aparentemente una eternidad en salir, y con un poco de depuración, esto resulta ser porque encola un montón de lecturas grandes (2GB - 4096b) con un archivo /dev/msr*. Dado que este tipo de archivo no soporta -&amp;gt;read_iter(), loop_rw_iter() termina manejándolos. Cada lectura devuelve 16MB de datos leídos, lo que toma 20 (!!) segundos. Con un montón de estos pendientes, procesar toda la cadena puede tomar mucho tiempo. Fácilmente más largo que el tiempo de espera de suspensión ininterrumpible de syzbot de 140 segundos. Esto entonces desencadena una queja de la ruta de salida de io-wq:<br /> <br /> INFO: tarea syz.4.135:6326 bloqueada por más de 143 segundos.<br /> No contaminado syzkaller #0<br /> Bloqueado por coredump.<br /> &amp;#39;echo 0 &amp;gt; /proc/sys/kernel/hung_task_timeout_secs&amp;#39; deshabilita este mensaje.<br /> task:syz.4.135 estado:D stack:26824 pid:6326 tgid:6324 ppid:5957 task_flags:0x400548 flags:0x00080000<br /> Traza de Llamada:<br /> <br /> context_switch kernel/sched/core.c:5256 [en línea]<br /> __schedule+0x1139/0x6150 kernel/sched/core.c:6863<br /> __schedule_loop kernel/sched/core.c:6945 [en línea]<br /> schedule+0xe7/0x3a0 kernel/sched/core.c:6960<br /> schedule_timeout+0x257/0x290 kernel/time/sleep_timeout.c:75<br /> do_wait_for_common kernel/sched/completion.c:100 [en línea]<br /> __wait_for_common+0x2fc/0x4e0 kernel/sched/completion.c:121<br /> io_wq_exit_workers io_uring/io-wq.c:1328 [en línea]<br /> io_wq_put_and_exit+0x271/0x8a0 io_uring/io-wq.c:1356<br /> io_uring_clean_tctx+0x10d/0x190 io_uring/tctx.c:203<br /> io_uring_cancel_generic+0x69c/0x9a0 io_uring/cancel.c:651<br /> io_uring_files_cancel include/linux/io_uring.h:19 [en línea]<br /> do_exit+0x2ce/0x2bd0 kernel/exit.c:911<br /> do_group_exit+0xd3/0x2a0 kernel/exit.c:1112<br /> get_signal+0x2671/0x26d0 kernel/signal.c:3034<br /> arch_do_signal_or_restart+0x8f/0x7e0 arch/x86/kernel/signal.c:337<br /> __exit_to_user_mode_loop kernel/entry/common.c:41 [en línea]<br /> exit_to_user_mode_loop+0x8c/0x540 kernel/entry/common.c:75<br /> __exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [en línea]<br /> syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:256 [en línea]<br /> syscall_exit_to_user_mode_work include/linux/entry-common.h:159 [en línea]<br /> syscall_exit_to_user_mode include/linux/entry-common.h:194 [en línea]<br /> do_syscall_64+0x4ee/0xf80 arch/x86/entry/syscall_64.c:100<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7fa02738f749<br /> RSP: 002b:00007fa0281ae0e8 EFLAGS: 00000246 ORIG_RAX: 00000000000000ca<br /> RAX: fffffffffffffe00 RBX: 00007fa0275e6098 RCX: 00007fa02738f749<br /> RDX: 0000000000000000 RSI: 0000000000000080 RDI: 00007fa0275e6098<br /> RBP: 00007fa0275e6090 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000<br /> R13: 00007fa0275e6128 R14: 00007fff14e4fcb0 R15: 00007fff14e4fd98<br /> <br /> Realmente no hay nada malo aquí, aparte de que procesar estas lecturas tomará MUCHO tiempo. Sin embargo, podemos acelerar la salida verificando el IO_WQ_BIT_EXIT dentro del bucle io_worker_handle_work(), ya que syzbot saldrá del anillo después de encolar todas estas lecturas. Luego, una vez que se procesa el primer elemento, io-wq simplemente cancelará el resto. Eso debería evitar que syzbot se encuentre con esta queja de nuevo.