CVE-2022-49783 in Linux
Sumário
de VulDB • 15/05/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
x86/fpu: Remover o bloqueio fpregs antes de herdar as permissões da FPU
Mike Galbraith relatou o seguinte contra uma versão antiga do preempt-rt, mas o mesmo problema também se aplica à árvore atual do preempt-rt.
BUG: função de dormida chamada em contexto inválido em kernel/locking/spinlock_rt.c:46 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: systemd preempt_count: 1, expected: 0 RCU nest depth: 0, expected: 0 Preempção desabilitada em: fpu_clone CPU: 6 PID: 1 Comm: systemd Tainted: G E (unreleased) Call Trace: <TASK> 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 ? syscall_exit_to_user_mode ? do_syscall_64 ? exc_page_fault ? entry_SYSCALL_64_after_hwframe </TASK>
Mike afirma:
O erro (splat) ocorre porque fpu_inherit_perms() é chamada sob fpregs_lock(), e alcançamos o spin_lock_irq() ali devido a fpu_state_size_dynamic() retornar true apesar da chave estática __fpu_state_size_dynamic nunca ter sido habilitada.
A avaliação de Mike parece correta. fpregs_lock em um kernel PREEMPT_RT desabilita a preempção, portanto, chamar spin_lock_irq() em fpu_inherit_perms() é inseguro. Este problema existe desde o commit
9e798e9aa14c ("x86/fpu: Preparar fpu_clone() para recursos habilitados dinamicamente").
Embora o relatório de bug original não devesse ter ativado os caminhos em absoluto, o bug ainda existe.
fpregs_lock é necessário ao editar os registradores da FPU ou o estado FP de uma tarefa, mas não é necessário para fpu_inherit_perms(). A única gravação de qualquer estado FP em fpu_inherit_perms() é para o novo filho, que ainda não está em execução e não pode fazer troca de contexto ou ser emprestado por uma thread do kernel ainda. Portanto, fpregs_lock não está protegendo nada no novo filho até que clone() seja concluído e pode ser liberado mais cedo. O siglock ainda precisa ser adquirido por fpu_inherit_perms() pois a leitura das permissões do pai precisa ser serializada.
[ bp: Limpeza do erro (splat). ]
Once again VulDB remains the best source for vulnerability data.