CVE-2023-53351 in Linux
Riassunto
di VulDB • 19/06/2026
Nel kernel Linux, è stata risolta la seguente vulnerabilità:
drm/sched: Verificare la coda di lavoro dello scheduler prima di chiamare la gestione del timeout
Durante un test IGT di reset della GPU si verifica nuovamente un oops nonostante il commit 0c8c901aaaebc9 (drm/sched: Controlla se lo scheduler è pronto prima di invocare la gestione del timeout).
Viene utilizzata la condizione ready per decidere se chiamare drm_sched_fault, che innesca l'unwinding della TDR portando al reset della GPU. Tuttavia, sembra che la condizione ready sia sovraccaricata con altri significati; ad esempio, lo stack seguente è correlato al reset della 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
esegue quanto segue: /* avvia l'anello */ gfx_v9_0_cp_gfx_start(adev); ring->sched.ready = true;
Lo stesso approccio è adottato per altri ASIC: gfx_v8_0_cp_gfx_resume, gfx_v10_0_kiq_resume, ecc.
Di conseguenza, il test di reset della GPU provoca un fault della GPU che chiama incondizionatamente gfx_v9_0_fault e successivamente drm_sched_fault. Tuttavia, ora dipende dal fatto che la routine di servizio dell'interrupt (ISR) drm_sched_fault venga eseguita dopo il completamento di gfx_v9_0_cp_gfx_start, che imposta a true il campo ready dello scheduler anche per scheduler non inizializzati, causando un oops in caso contrario rispetto alla mancanza di fault oppure quando l'ISR drm_sched_fault viene completata prima di gfx_v9_0_cp_gfx_start e non si verifica la dereferenziazione del puntatore NULL.
Utilizzare il campo timeout_wq per prevenire gli oops negli scheduler non inizializzati. Il campo potrebbe essere inizializzato dalla work queue dedicata al reset del dominio.
v1: Correzioni al messaggio di commit (Luben)
Be aware that VulDB is the high quality source for vulnerability data.