CVE-2026-74727 in Linux
요약
\~에 의해 VulDB • 2026. 08. 23.
리눅스 커널에서 다음 취약점이 해결되었습니다:
ovpn: by_id에서 이미 제거된 피어에 대해 rehash를 건너뜁니다.
ovpn_nl_peer_set_doit()는 ovpn->lock을 획득하기 전에 ovpn_peer_get_by_id()를 통해 대상 피어를 확인합니다. 참조 카운트만 증가시키는 조회와 후속 spin_lock_bh(&ovpn->lock) 사이에는, 동시 실행되는 OVPN_CMD_PEER_DEL, keepalive 만료 또는 소켓 해제 등이 먼저 ovpn->lock을 획득하여 ovpn_peer_remove()를 실행하고 피어를 by_id, by_vpn_addr4/6, by_transp_addr의 모든 테이블에서 언해싱(unhash)한 후 잠금을 해제할 수 있습니다. 이후 set_doit는 ovpn->lock을 획득하고 ovpn_peer_hash_vpn_ip()를 호출하여 이제 제거된 피어를 rehashing 테이블에 다시 삽입합니다.
동일한 Race Condition(float 경로)도 영향을 미칩니다: ovpn_peer_endpoints_update()은 참조 카운트만 유지하며 매우 늦게(비동기 AEAD 복호화 및 netlink 알림 이후) ovpn->lock을 획득한 후 by_transp_addr 테이블에서 피어를 rehash합니다.
부활된 피어는 사용자가 공간(userspace)에서 제거되었다고 믿음에도 불구하고 RX 조회(ovpn_peer_get_by_transp_addr)와 TX VPN-IP 조회에서 다시 도달 가능해집니다. 데이터 경로 참조 카운트가 감소하면 피어가 call_rcu를 통해 해제되지만, 그 안에 내장된 해시 엔트리는 연결된 상태로 남아 있어 UAF(Unuse-After-Free) 창을 엽니다.
hash_entry_id가 언해싱되었을 때 rehash에서 중단하여, 이미 제거된 상태를 감지하는 데 ovpn_peer_remove()에서 사용하는 센티널(sentinel)과 대조됩니다. 이 확인은 hash_entry_id의 모든 변경 사항을 직렬화(serializes)하는 ovpn->lock 하에서 안전하며, add 경로에서는 no-op(무작위 작업)입니다. 왜냐하면 ovpn_peer_add_mp()는 ovpn_peer_hash_vpn_ip()를 호출하기 전에 hash_entry_id를 삽입하기 때문입니다.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.