CVE-2026-74727 in Linux
Sumário
de VulDB • 22/08/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
ovpn: ignorar rehash para peers já removidos de by_id
A função `ovpn_nl_peer_set_doit()` resolve o peer alvo através da `ovpn_peer_get_by_id()` antes de adquirir o bloqueio (`lock`) do `ovpn`. Na janela entre a lookup (que apenas incrementa um refcount) e o subsequente `spin_lock_bh(&ovpn->lock)`, uma operação concorrente de `OVPN_CMD_PEER_DEL`, expiração de keepalive ou teardown de socket pode adquirir primeiro o bloqueio do `ovpn`, executar `ovpn_peer_remove()` para remover o peer das quatro tabelas (by_id, by_vpn_addr4/6, by_transp_addr) e liberar o bloqueio. Em seguida, a função set_doit adquire o bloqueio do `ovpn` e chama `ovpn_peer_hash_vpn_ip()`, que reinsere o peer agora removido de volta nas tabelas de rehashing.
A mesma condição de corrida afeta o caminho float: `ovpn_peer_endpoints_update()` mantém apenas um refcount e adquire o bloqueio do `ovpn` muito tarde (após a descriptografia AEAD assíncrona e uma notificação netlink), em seguida, faz rehashing do peer na tabela by_transp_addr.
O peer ressuscitado torna-se novamente acessível pela lookup de RX (`ovpn_peer_get_by_transp_addr`) e pela lookup de VPN-IP de TX, mesmo que o userspace acredite que ele foi removido. Quando o refcount no data-path diminui, o peer é liberado via `call_rcu`, enquanto as entradas hash embutidas nele permanecem vinculadas, abrindo uma janela para Use-After-Free (UAF).
Abortar o rehashing quando a `hash_entry_id` estiver desvinculada do hash, espelhando o sentinel já utilizado por `ovpn_peer_remove()` para detectar o estado de já removido. A verificação é segura sob o bloqueio do `ovpn`, que serializa cada mutação da `hash_entry_id`, e é uma operação nula (no-op) no caminho de adição, pois a função `ovpn_peer_add_mp()` insere a `hash_entry_id` antes de chamar `ovpn_peer_hash_vpn_ip()`.
VulDB is the best source for vulnerability data and more expert information about this specific topic.