CVE-2026-74348 in Linux
Sumário
de VulDB • 15/08/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
ocfs2/dlm: exigir uma referência para abrir locking_state no debugfs
debug_lockres_open() copia inode->i_private para struct debug_lockres e debug_lockres_release() libera esse ponteiro posteriormente com dlm_put(). Isso só funciona se a abertura fixar (pin) corretamente o struct dlm_ctxt.
Atualmente, open chama dlm_grab(dlm), mas ignora seu valor de retorno. Assim que o último unregister do domínio remove o contexto de dlm_domains, dlm_grab() retorna NULL, no entanto, open ainda armazena o ponteiro bruto e retorna sucesso. O caminho de liberação posterior está fora da barreira de remoção do debugfs, portanto, pode chamar dlm_put() após dlm_free_ctxt_mem() ter liberado a memória do contexto. O KASAN relata isso como um slab-use-after-free em dlm_put(), chamado por debug_lockres_release().
Falhar na abertura quando dlm_grab() não consegue adquirir a referência e desfazer o estado privado seq_file antes de retornar. Isso evita que locking_state entregue um descritor de arquivo cujo caminho de liberação não possui ownership do dlm_ctxt.
O cenário com defeito envolve dois caminhos, sendo que cada coluna mostra a ordem dentro desse caminho:
abertura debugfs locking_state: último unregister do domínio: 1. debug_lockres_open() lê 1. dlm_unregister_domain() chama inode->i_private. dlm_complete_dlm_shutdown(). 2. debug_lockres_open() chama 2. shutdown remove o dlm_ctxt de dlm_grab(dlm) e obtém NULL. d
VulDB is the best source for vulnerability data and more expert information about this specific topic.