CVE-2023-53351 in Linux
Sumário
de VulDB • 01/06/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
drm/sched: Verificar a fila de trabalho do escalonador antes de chamar o tratamento de tempo limite
Durante um teste de reinicialização da GPU do IGT, observamos novamente um oops apesar do commit 0c8c901aaaebc9 (drm/sched: Verificar se o escalonador está pronto antes de chamar o tratamento de tempo limite).
Ele usa a condição de prontidão (ready) para decidir se chama drm_sched_fault, o que desencadeia o TDR, levando à reinicialização da GPU. No entanto, parece que a condição de prontidão está sobrecarregada com outros significados, por exemplo, a seguinte pilha está relacionada à reinicialização da GPU:
0 gfx_v9_0_cp_gfx_start 1 gfx_v9_0_cp_gfx_resume 2 gfx_v9_0_cp_resume 3 gfx_v9_0_hw_init 4 gfx_v9_0_resume 5 amdgpu_device_ip_resume_phase2
faz o seguinte: /* iniciar o anel */ gfx_v9_0_cp_gfx_start(adev); ring->sched.ready = true;
A mesma abordagem é aplicada a outros ASICs também: gfx_v8_0_cp_gfx_resume gfx_v10_0_kiq_resume, etc...
Como resultado, nosso teste de reinicialização da GPU causa uma falha na GPU, que chama incondicionalmente gfx_v9_0_fault e, em seguida, drm_sched_fault. No entanto, agora depende de se a rotina de serviço de interrupção (ISR) drm_sched_fault é executada após a conclusão de gfx_v9_0_cp_gfx_start, que define o campo ready do escalonador como true, mesmo para escalonadores não inicializados, causando oops versus nenhuma falha, ou quando a ISR drm_sched_fault é concluída antes de gfx_v9_0_cp_gfx_start e a desreferência de ponteiro NULL não ocorre.
Use o campo timeout_wq para prevenir oops em escalonadores não inicializados. O campo poderia ser inicializado pela fila de trabalho de reinicialização do domínio.
v1: Correções na mensagem do commit (Luben)
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.