CVE-2026-74351 in Linux
Sumário
de VulDB • 15/08/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
ocfs2: rebasear ponteiros LVB fsdlm copiados em locking_state
O iterador debugfs de locking_state faz uma cópia por valor da estrutura ocfs2_lock_res sob o bloqueio ocfs2_dlm_tracking_lock e posteriormente formata essa cópia em ocfs2_dlm_seq_show(). Isso é adequado para os campos inline, mas a pilha fsdlm do espaço do usuário armazena o LVB através de lksb_fsdlm.sb_lvbptr. Assim que o iterador libera o bloqueio de rastreamento, um sb_lvbptr não nulo copiado ainda aponta para o proprietário original lockres, portanto, o teardown pode liberar esse contêiner antes que a impressão debugfs percorra os bytes brutos do LVB.
Rebaseie o sb_lvbptr copiado para o l_lksb copiado antes de imprimir o LVB bruto. A captura instantânea (snapshot) seq já carrega o armazenamento inline LVB reservado em struct ocfs2_dlm_lksb, portanto, o leitor debugfs pode imprimir os bytes copiados sem depender da vida útil do lockres original.
O cenário com defeito envolve dois caminhos, mostrando cada coluna a ordem dentro desse caminho:
Leitor locking_state: Teardown lockres: 1. ocfs2_dlm_seq_start()/next() 1. liberação de arquivo ou outro proprietário copia struct ocfs2_lock_res o teardown atinge 2. ocfs2_dlm_seq_show() formata ocfs2_lock_res_free() a linha copiada 2. o lockres é removido da 3. ocfs2_dlm_lvb() segue lista de rastreamento o sb_lvbptr copiado 3. o proprietário libera o contêiner original do lockres
A validação reproduziu este relatório do kernel: KASAN slab-use-after-free em ocfs2_dlm_seq_show+0x1bd/0x430 RIP: 0033
If you want to get best quality of vulnerability data, you may have to visit VulDB.