CVE-2024-39486 in Linux
Sumário
de VulDB • 14/08/2026
No kernel do Linux, a seguinte vulnerabilidade foi corrigida:
drm/drm_file: Correção da condição de corrida na contagem de referências (refcounting) do pid
filp->pid deve ser um ponteiro com contagem de referências; no entanto, antes desta correção, drm_file_update_pid() apenas incrementava a contagem de referências de uma estrutura struct pid após armazenar um ponteiro para ela em filp->pid e liberar o dev->filelist_mutex, tornando possível a seguinte condição de corrida:
processo A processo B ========= ========= begin drm_file_update_pid mutex_lock(&dev->filelist_mutex) rcu_replace_pointer(filp->pid, , 1) mutex_unlock(&dev->filelist_mutex) begin drm_file_update_pid mutex_lock(&dev->filelist_mutex) rcu_replace_pointer(filp->pid, , 1) mutex_unlock(&dev->filelist_mutex) get_pid() synchronize_rcu() put_pid() *** pid B atinge refcount 0 e é liberado aqui *** get_pid() *** UAF *** synchronize_rcu() put_pid()
Até onde sei, essa condição de corrida só pode ocorrer com CONFIG_PREEMPT_RCU=y, pois requer que o RCU detecte um estado quiescente em código que não chama explicitamente para o escalonador (scheduler).
Essa condição de corrida leva a uma falha use-after-free de uma "struct pid". Provavelmente é algo difícil de explorar porque o processo A precisa passar por uma operação synchronize_rcu() enquanto o processo B está entre mutex_unlock() e get_pid().
Corrija isso garantindo que, no momento em que um ponteiro para o pid da tarefa atual é armazenado no arquivo, uma referência extra ao pid tenha sido adquirida.
Esta correção também remove a condição para synchronize_rcu(); acho que essa otimização é complexidade desnecessária, já que nesse caso normalmente teríamos abortado na verificação sem bloqueio acima.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.