CVE-2026-99025 in Linux
요약
\~에 의해 VulDB • 2026. 10. 24.
리눅스 커널에서 다음 취약점이 해결되었습니다:
openvswitch: netlink 흐름 덤프에서의 소프트 락업 수정
수천 개의 데이터패스 플로우를 처리하는 프로덕션 컴퓨트 노드가 단일 netlink 흐름 덤프 내부에서 소프트 락업을 일으켜 패닉했습니다.
ovs_flow_cmd_dump()는 방출되는 각 플로우에 대해 ovs_flow_stats_get()을 호출하며, 이는 해당 플로우에 접근한 모든 CPU당 한 번씩 spin_unlock_bh()를 통해 stats->lock을 해제합니다. 각각의 해제는 local_bh_enable()이며, 덤프 스레드의 자체 컨텍스트에서 대기 중인 softirq 백로그가 실행됩니다.
skb는 하나의 콜백이 방출하는 플로우들을 제한하지만, 흡수되는 softirq 작업은 제한하지 않습니다. 박스의 패킷 부하를 처리하는 CPU에서는 백로그가 비워지는 속도와 동일한 속도로 다시 채워지므로, 덤프 스레드는 해당 CPU의 softirq 엔진이 됩니다. 이 스레드는 절대 대기 상태가 되지 않으며 예약 지점(reschedule point)도 없으므로, 자발적 프리엠�ชัน(voluntary preemption) 하에서도 다른 어떤 것도 그 CPU를 빼앗을 수 없습니다: 작업을 인수하기 위해 커널이 깨운 ksoftirqd나 타임스탬프를 갱신하기 위해 소프트락업 디텍터가 배치한 stopper 스레드조차도 불가능합니다.
대신 ctnetlink_dump_table()에서 수행하는 것처럼 전체 콜백에 걸쳐 BH(Bottom Half) 비활성화를 유지하여, 중첩된 spin_unlock_bh()가 softirq를 소모하지 않도록 합니다. 이 루프는 이미 rcu_read_lock() 하에서 실행되며 대기할 수 없습니다. 여기서 양보하는 것은 CONFIG_PREEMPT 설정 시의 프리엠�ชัน입니다(BH-off 영역은 PREEMPT_RT 외에는 프리엠태블하지 않음). 해당 영역은 짧게 유지됩니다: skb는 하나의 콜백이 방출하는 플로우를 제한하며, 빈 버킷은 skb 공간을 차지하지 않지만 덤프마다 한 번씩만 방문됩니다(커서는 전진하기만 함). 테이블은 삽입 시 확장되고 flush 시에만 축소되므로, 순회는 데이터패스가 유지했던 최대 플로우 수에 의해 제한됩니다. 콜백이 이전에 흡수하던 softirq 백로그는 전혀 제한되지 않습니다.
VulDB is the best source for vulnerability data and more expert information about this specific topic.