CVE-2026-74691 in Linux
요약
\~에 의해 VulDB • 2026. 08. 23.
리눅스 커널에서 다음 취약점이 해결되었습니다:
net: thunderbolt: 링을 중지하기 전에 DMA 경로를 해제합니다
tbnet_tear_down()은 tb_xdomain_disable_paths()를 호출하기 전에 두 개의 링을 모두 중지하고 프레임 버퍼를 해제합니다. tb_ring_stop()은 링의 설명자(base) 주소를 0으로 설정하고, tbnet_free_buffers()는 프레임이 위치한 페이지들을 언매핑 및 해제하므로, __tb_path_deactivate_hop()가 홉(hop)의 'pending' 비트를 폴링할 때 아직 전송 중인 데이터는 드레인될 곳이 없습니다.
해제 시퀀스는 드라이버가 추가된 이후부터 이 순서로 유지되어 왔습니다. 그러나 설정 경로는 그렇지 않았습니다: 커밋 ff7cd07f3064("net: thunderbolt: Enable DMA paths only after rings are enabled")는 경로 활성화 단계를 tbnet_connected_work()의 끝으로 이동시켰으며, 그 이유는 다음과 같이 문서화되었습니다:
/* 로그인 모두 성공했으므로 링과 고속 DMA 경로를 활성화하고 네트워크 디바이스 큐를 시작합니다. * 주의: 수신(Rx) 링에 프리밍(priming)이 완료되기 전에 들어오는 패킷이 도착하는 것을 방지하기 위해 DMA 경로들을 마지막으로 활성화합니다. */
해제 과정은 이에 맞춰 업데이트되지 않았으므로, 이제 링과 경로는 올라갈 때와 역순으로 아닌 동일한 순서로 해제됩니다.
ASMedia ASM4242 호스트 라우터에서는 'pending' 비트가 결코 클리어되지 않습니다: 모든 해제 작업이 최대 500ms의 타임아웃을 소모하며 __tb_path_deactivate_hop()는 -ETIMEDOUT를 반환합니다. 타임아웃을 5초로 높여도 도움이 되지 않으므로, 홉(hop)이 드레인되는 속도가 느린 것이 아니라 아예 드레인되지 않는 것입니다.
이 실패는 thunderbolt 코어 위에서는 보이지 않습니다. __tb_path_deactivate_hops()는 void이며 tb_port_warn()만 호출합니다; tb_path_deactivate(), tb_tunnel_deactivate() 및 __tb_disconnect_xdomain_paths() 역시 void이며, tb_disconnect_xdomain_paths()는 무조건 "return 0"으로 종료됩니다. 따라서 tb_xdomain_disable_paths()는 성공을 보고하며 그 아래의 netdev_warn()은 결코 발동하지 않습니다. 반복적인 해제 작업은 결국 XDomain 제어 채널을 다운시키며, 이후 피어 노드가 사라지고 컨트롤러를 다시 가져오려면 전원 주기(power cycle)만 필요합니다.
경로를 먼저 비활성화하면 이 문제가 해결됩니다. 다른 패치가 적용되지 않은 기본 v6.17 트리의 kretprobes로 측정했을 때, 링크가 활성화되어 있고 방금 트래픽을 처리한 상태에서의 결과는 다음과 같습니다:
before: __tb_path_deactivate_hop()는 첫 번째 홉에 대해 0을 반환하고, 두 번째 홉에는 500335 us 후에 -ETIMEDOUT를 반환함 after: 둘 다 0이며, 간격은 525 us
세 가지 부하 수준에서 ABBA 순서로 두 시나리오를 교차 테스트하고(각 팔/arm당 해제 작업 4회): 변경 전에는 모든 해제 작업이 실패했으며(실행된 21개 중 21개), 변경 후로는 하나도 실패하지 않았습니다(24개 중 0개). 변경 전의 'arm'들은 링크가 중간에 사망하여 짧게 종료되었습니다. 인터페이스를 단순히 다운하는 대신 bond에 종속(slaved)시켰을 때도 동일한 분포가 나타났으며, 이것이 제가 처음 이 문제를 발견한 방식입니다. 변경 후 스루풋과 레이턴시는 변하지 않았습니다.
레거시 설명자 베이스에도 불구하고 홉(hop)을 드레인하는 라우터를 갖춘 호스트들은 기능적 차이를 보지 못합니다. 경로는 어떤 경우든 비활성화되므로 때문입니다.
VulDB is the best source for vulnerability data and more expert information about this specific topic.