Vulnerabilidad en kernel de Linux (CVE-2022-48983)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: io_uring: Se corrige un null-ptr-deref en io_tctx_exit_cb() Syzkaller informa un error de desreferencia NULL de la siguiente manera: ERROR: KASAN: null-ptr-deref en io_tctx_exit_cb+0x53/0xd3 Lectura de tamaño 4 en la dirección 0000000000000138 por la tarea file1/1955 CPU: 1 PID: 1955 Comm: file1 No contaminado 6.1.0-rc7-00103-gef4d3ea40565 #75 Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014 Seguimiento de llamadas: nivel_pila_volcado+0xcd/0x134 ? io_tctx_salir_cb+0x53/0xd3 informe_kasan+0xbb/0x1f0 ? io_tctx_salir_cb+0x53/0xd3 rango_comprobación_kasan+0x140/0x190 io_tctx_salir_cb+0x53/0xd3 ejecución_trabajo_tarea+0x164/0x250 ? cancelación_trabajo_tarea+0x30/0x30 obtener_señal+0x1c3/0x2440 ? degradación_bloqueo+0x6e0/0x6e0 ? degradación_bloqueo+0x6e0/0x6e0 ? señales_salida+0x8b0/0x8b0 ? desbloqueo_lectura_sin_datos+0x3b/0x70 ? obtener_sigframe_size+0x10/0x10 ? bloquear_hardirqs_on+0x79/0x100 ? poner_nombre+0xfe/0x140 ? do_execveat_common.isra.0+0x238/0x710 exit_to_user_mode_prepare+0x15f/0x250 syscall_exit_to_user_mode+0x19/0x50 do_syscall_64+0x42/0xb0 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0023:0x0 Código: No se puede acceder a los bytes del código de operación en 0xffffffffffffffd6. RSP: 002b:00000000fffb7790 EFLAGS: 00000200 ORIG_RAX: 000000000000000b RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 000000000000000 RDI: 000000000000000 RBP: 000000000000000 R08: 0000000000000000 R09: 00000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 Pánico del kernel: no se sincroniza: panic_on_warn establecido ... Esto sucede porque la adición de task_work desde io_ring_exit_work() no está sincronizada con la cancelación de todos los elementos de trabajo, por ejemplo, de exec. La ejecución de los dos está ordenada de manera que ambos son ejecutados por la propia tarea, pero si io_tctx_exit_cb() está en cola mientras cancelamos todos los elementos de trabajo de exec Y se ejecuta cuando la tarea sale al espacio de usuario en lugar de en el bucle principal en io_uring_cancel_generic(), entonces podemos encontrar current->io_uring == NULL y alcanzar el bloqueo anterior. Es seguro agregar esta verificación NULL aquí, porque la ejecución de las dos rutas las realiza la propia tarea. [axboe: agregue un comentario de código y también coloque una explicación en el mensaje de confirmación]