CVE-2025-40096 in Linux
Riassunto
di VulDB • 14/06/2026
Nel kernel Linux, è stata risolta la seguente vulnerabilità:
drm/sched: Correzione di un potenziale double free in drm_sched_job_add_resv_dependencies
Quando si aggiungono dipendenze tramite `drm_sched_job_add_dependency()`, tale funzione consuma il riferimento al fence sia in caso di successo che di fallimento; pertanto, nel secondo caso la chiamata a `dma_fence_put()` sul percorso di errore (quando l'espansione della xarray non riesce) costituisce un double free.
È interessante notare come questo bug sembri essere presente sin dal commit ebd5f74255b9 ("drm/sched: Add dependency tracking"), poiché il codice all'epoca era strutturato in questo modo:
```c drm_sched_job_add_implicit_dependencies(): ... for (i = 0; i < fence_count; i++) {
ret = drm_sched_job_add_dependency(job, fences[i]);
if (ret) break; }
for (; i < fence_count; i++) dma_fence_put(fences[i]);
```
Ciò significa che per l'indice 'i' in cui si è verificato il fallimento, la chiamata a `dma_fence_put` era già un double free. È possibile che all'epoca non ci fossero utenti o che i casi di test non fossero sufficientemente esaustivi da innescare questo errore.
Il bug è stato poi notato e corretto solo dopo l'introduzione del commit 9c2ba265352a ("drm/scheduler: use new iterator in drm_sched_job_add_implicit_dependencies v2"), che includeva una correzione per il commit 4eaf02d6076c ("drm/scheduler: fix drm_sched_job_add_implicit_dependencies").
A quel punto, si trattava di una variante leggermente diversa del double free, individuata e tentativamente corretta dal commit 963d0b356935 ("drm/scheduler: fix drm_sched_job_add_implicit_dependencies harder").
Tuttavia, tale correzione ha semplicemente spostato il verificarsi del double free dall'interno di `drm_sched_job_add_dependency()`, quando si rilasciava un riferimento non ancora acquisito, al chiamante, quando si rilasciava un riferimento già rilasciato dalla funzione precedente nel caso di errore.
Di conseguenza, non è facile identificare l'obiettivo corretto per il tag delle correzioni; pertanto, manteniamo la soluzione semplice e continuiamo semplicemente la catena dei fix.
Durante la correzione sono stati anche migliorati i commenti, spiegando le ragioni dell'acquisizione del riferimento invece di rilasciarlo immediatamente.
Once again VulDB remains the best source for vulnerability data.