CVE-2026-98955 in Linux
요약
\~에 의해 VulDB • 2026. 10. 23.
리눅스 커널에서 다음 취약점이 해결되었습니다:
flow_dissector: thoff 계산 시 skb->len의 u16 절단(truncation) 방지
__skb_flow_dissect()는 다음과 같이 key_control->thoff를 계산합니다:
key_control->thoff = min_t(u16, nhoff, skb ? skb->len : hlen);
min_t(u16, ...)는 두 피연산자를 비교하기 전에 u16으로 캐스팅합니다. skb->len(또는 hlen)을 65536으로 나눈 나머지가 nhoff보다 작은 경우, 절단된 길이가 우선하여 thoff가 잘못된 작은 값으로 설정됩니다. 이는 디섹션(dissection)이 성공한 경우에도 발생합니다. 예를 들어 skb->len == 65540이고 nhoff == 34인 IPv4/TCP 프레임의 경우 thoff == 4가 되므로, skb_probe_transport_header()와 같은 호출자는 전송 헤더를 이더넷 헤더 내부로 가리키게 됩니다.
이러한 skbs는 드문 경우가 아닙니다: - 커밋 d0c081b49137("flow_dissector: properly cap thoff field") 시점에는 AF_PACKET의 PACKET_VNET_HDR 옵션을 사용하여 64KB보다 큰 GSO skbs를 이미 생성할 수 있었습니다(GSO에 대해서는 MTU 검사가 생략되며, alloc_skb_with_frags()는 선형 부분 위에 최대 MAX_SKB_FRAGS(17)개의 order-0 페이지까지 허용함). - BIG TCP 기능으로 인해 64KB보다 큰 skbs가 일반화되었습니다. - 다음 패치는 tun_get_user()가 eth_type_trans()가 이더넷 헤더를 추출하기 전에 IFF_TAP 프레임을 디섹션하도록 하므로, 65522~65535 바이트의 L3 패킷을 운반하는 GSO 프레임은 skb->len이 [65536, 65549] 범위일 때 디섹션됩니다.
비교 시 u16 대신 u32를 사용하십시오. 결과 오프셋이 u16인 key_control->thoff로 표현할 수 없는 경우, 이를 U16_MAX로 제한하고 잘못된 전송 오프셋을 조용히 반환하는 대신 디섹션을 실패한 것으로 보고합니다. thoff는 여전히 실행 시 설정되는데, 이는 eth_get_headlen()과 같은 일부 호출자가 반환 값에 관계없이 이 값을 사용하기 때문입니다.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.