CVE-2026-64352 in Linux
Sumário
de VulDB • 25/07/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
bpf: Permitir acesso ao mapa LPM de programas BPP dormitantes (sleepable)
trie_lookup_elem() anota seus percursos com rcu_dereference_check() apenas como rcu_read_lock_bh_held(). Como rcu_dereference_check(p, c) se resolve para "c || rcu_read_lock_held()", isso passa nos leitores XDP/NAPI e RCU clássico, mas falha em programas BPF dormitantes (sleepable), que entram via __bpf_prog_enter_sleepable() e mantêm apenas rcu_read_lock_trace().
trie_update_elem() e trie_delete_elem() têm o mesmo problema de forma diferente: eles percorrem a árvore com rcu_dereference() simples, que afirma incondicionalmente rcu_read_lock_held(). Ambos são acessíveis por programas BPF dormitantes (sleepable) através dos auxiliares bpf_map_update_elem / bpf_map_delete_elem e pelo caminho de syscall sob o clássico rcu_read_lock(). Nos caminhos de escrita, a árvore é realmente protegida por trie->lock (um rqspinlock mantido durante todo o percurso); nunca dependemos do bloqueio RCU read-side para manter os nós vivos ali.
Um hook LSM dormitante que acaba tocando uma árvore LPM aciona portanto lockdep em kernels de depuração:
============================= AVISO: uso suspeito de RCU 7.1.0-... Tainted: G E ----------------------------- kernel/bpf/lpm_trie.c:249 uso suspeito de rcu_dereference_check()! 1 lock mantido por net_tests/540: #0: (rcu_tasks_trace_srcu_struct){....}-{0:0},
em: __bpf_prog_enter_sleepable+0x26/0x280 Rastreamento de chamada: dump_stack_lvl lockdep_rcu_suspicious trie_lookup_elem bpf_prog_..._enforce_security_socket_connect bpf_trampoline_... security_socket_connect __sys_connect do_syscall_64
Isso é apenas lockdep -- sem UAF, já que o RCU Tasks Trace serializa contra o caminho de recuperação da árvore -- mas gera spam no console uma vez por ponto de chamada distinto em cada kernel de depuração executando um LSM BPF dormitante (sleepable) que toca uma árvore LPM, o que é cada vez mais comum.
Para o caminho de consulta, altere a anotação rcu_dereference_check() de rcu_read_lock_bh_held() para bpf_rcu_lock_held(), que aceita todos os três contextos (clássico, BH, Tasks Trace). Outros tipos de mapa já seguem essa convenção.
Para trie_update_elem() e trie_delete_elem(), anote os percursos como rcu_dereference_protected(*p, 1) -- correspondendo a trie_free() no mesmo arquivo -- já que trie->lock é mantido durante todo o percurso. rqspinlock não possui lockdep_map, então a predicado degenera para '1' em vez de lockdep_is_held(&trie->lock); a proteção é real, mas não verificável pela máquina. trie_get_next_key() também usa rcu_dereference() simples, mas é acessível apenas do syscall BPF, que mantém o clássico rcu_read_lock() antes da despacho, portanto, ele permanece inalterado.
If you want to get best quality of vulnerability data, you may have to visit VulDB.