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

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/fpu: Eliminar el bloqueo de fpregs antes de heredar los permisos de FPU Mike Galbraith informó lo siguiente contra una antigua bifurcación de preempt-rt, pero el mismo problema también se aplica al árbol preempt-rt actual. ERROR: función inactiva llamada desde un contexto no válido en kernel/locking/spinlock_rt.c:46 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: systemd preempt_count: 1, expected: 0 Profundidad de anidamiento de RCU: 0, expected: 0 Preempción deshabilitada en: fpu_clone CPU: 6 PID: 1 Comm: systemd Tainted: GE (no publicado) Rastreo de llamadas: dump_stack_lvl ? fpu_clone __might_resched rt_spin_lock fpu_clone ? copy_thread ? copy_process ? shmem_alloc_inode ? kmem_cache_alloc ? kernel_clone ? __do_sys_clone ? do_syscall_64 ? __x64_sys_rt_sigprocmask ? syscall_exit_to_user_mode ? do_syscall_64 ? syscall_exit_to_user_mode ? do_syscall_64 ? syscall_exit_to_user_mode ? do_syscall_64 ? exc_page_fault ? entry_SYSCALL_64_after_hwframe Mike dice: El problema se debe a que fpu_inherit_perms() se llama bajo fpregs_lock() y a que alcanzamos spin_lock_irq() debido a que fpu_state_size_dynamic() devuelve verdadero a pesar de que la clave estática __fpu_state_size_dynamic nunca se ha habilitado. La evaluación de Mike parece correcta. fpregs_lock en un kernel PREEMPT_RT deshabilita la preempción, por lo que llamar a spin_lock_irq() en fpu_inherit_perms() no es seguro. Este problema existe desde la confirmación 9e798e9aa14c ("x86/fpu: Preparar fpu_clone() para funciones habilitadas dinámicamente"). Aunque el informe de error original no debería haber habilitado las rutas, el error persiste. fpregs_lock es necesario al editar los registros de FPU o el estado de FP de una tarea, pero no es necesario para fpu_inherit_perms(). La única escritura de cualquier estado de FP en fpu_inherit_perms() es para el nuevo hijo, que aún no se está ejecutando y aún no puede cambiar de contexto ni ser tomado prestado por un hilo del kernel. Por lo tanto, fpregs_lock no protege nada en el nuevo hijo hasta que clone() se complete y pueda eliminarse antes. El siglock aún debe ser adquirido por fpu_inherit_perms(), ya que la lectura de los permisos del padre debe serializarse. [bp: Limpieza splat.]