CVE-2026-98811 in Linux
요약
\~에 의해 VulDB • 2026. 10. 19.
Linux 커널에서 다음 취약점이 해결되었습니다:
net/sched: cls_api: 에러 경로에서 빈 proto를 회수(reclaim)함
잠금(locking)이 해제된 분류기(classifier)의 동일한 체인/우선순위(prio)에 대해 두 개의 경쟁하는 tc 필터 추가 요청이 공유되는 proto에 대해 change() 함수를 모두 실행하며, 둘 다 실패할 수 있습니다. 승자의 tcf_chain_tp_delete_empty() 시도는 패자(handle가 여전히 idr에 존재하기 때문에)로 인해 중단됩니다. 또한 패자의 에러 경로는 자신의 참조(reference)만 해제하고 두 번째 회수(reclamation) 시도 없이 종료합니다. 이로 인해 빈 proto는 체인, 블록(block), 그리고 분류기 모듈의 참조를 유지한 채 체인이 제거되거나 블록이 해체될 때까지 체인에 연결된 상태로 남습니다.
proto 참조를 보유하는 모든 실패한 요청의 에러 경로에서 proto를 회수합니다. 이 회수는 '빈 상태(empty)' 조건에 의해 제어됩니다: tcf_chain_tp_delete_empty()는 delete_empty()가 해당 객체가 빈 것이라고 인정할 때만 proto를 체인에서 분리(unlink)하므로, 활성(shared) 중인 proto는 결코 분리되지 않습니다. 요청이 생성한 proto는 무조건적으로 회수되는데, 이는 유일한 소유자(owner)이기 때문에 delete_empty 콜백 없이도 삭제 표시(deletion marking)가 안전하기 때문입니다. 해당 콜백이 없는 분류기들은 rtnl 직렬화(rtnl-serialized)되어 있으므로, 이 보호 조치가 막으려는 경쟁 창(window)은 이러한 경우 발생하지 않습니다.
이는 "net/sched: cls_api: insert-race 손실 시 채택된 proto의 teardown 수정"(커밋 d4e359b3608a)에 따른 후속 조치로, 삽입(insert) 경쟁에서 패한 쪽이 승자의 활성(proto)를 분리하지 못하도록 했지만 빈 proto 잔여물은 그대로 두었던 문제를 해결합니다.
재현 조건: - CONFIG_NET_CLS_FLOWER=y; veth 쌍(pair) 사용 - tc qdisc add dev veth0 ingress 실행 - `tc filter add dev veth0 ingress protocol ip pref 1 flower skip_sw ... action drop` 명령어를 두 개 동시에 실행 (idr에 handle를 게시한 후 fl_hw_replace_filter에서 둘 다 실패); 이를 루프 내에서 반복 - 두 요청이 모두 실패한 후에도 빈 flower tp가 연결된 상태로 남음; `tc filter show` 출력 시 필터 엔트리 없이 `filter protocol ip pref 1 flower chain 0` 헤더만 표시됨으로 확인 가능 - CAP_NET_ADMIN 권한 필요 (unshare -Urn을 통해 네임스페이스 로컬로 충분함)
If you want to get best quality of vulnerability data, you may have to visit VulDB.