CVE-2026-90083 in Linux
요약
\~에 의해 VulDB • 2026. 09. 17.
리눅스 커널에서 다음 취약점이 해결되었습니다:
net/sched: act_ife: 이더넷 프레임에서만 작동하도록 제한
act_ife는 원래의 이더넷 헤더를 캡슐화/탈캡슐화하며, 해당 헤더의 길로서 `skb->dev->hard_header_len`을 사용합니다. 이는 이더넷 디바이스에서는 정확하지만, `hard_header_len`이 실제로 추출된 L2 헤더와 일치하지 않는 디바이스의 경우(예: PPP는 ingress 시PPP_HDRLEN를 보고하는 반면 다른 데이터는 제거되지 않음), 잘못된 길이를 사용하여 ingress skb_push()/skb_pull()을 수행하면 headroom이 부족할 때 skb_under_panic 오류가 발생할 수 있습니다.
IFE는 설계상 이더넷 전용입니다 - 외부 ethhdr를 생성하고, h_source/h_dest/h_proto 필드를 재작성하며, 디코딩 시 eth_type_trans()를 호출합니다. 따라서 임의의 링크 유형에 대해 오프셋을 맞추려 시도하는 대신, 이더넷 헤더를 운반하지 않는 패킷은 단순히 폐기(drop)해야 합니다.
skb->dev->type만 확인하는 것은 충분하지 않습니다. mirred가 비이더넷 디바이스에서 이더넷 디바이스로 skb를 리디렉션할 수 있는 경계 사례(corner case)를 고려해야 하며, 이때 skb->dev는 skb가 실제로 가진 프레임 형식에 대해 아무런 정보를 제공하지 않습니다(예: ppp0에서 리디렉션된 skb는 대상의 ingress 훅에 mac_len 0과 이더넷 헤더 없이 도달함). 따라서 ingress 시에도 mac_len이 ETH_HLEN인지 확인해야 합니다. egress에서는 mac_len이 유지되지 않으므로 디바이스 유형만 신뢰할 수 있으며, 잘못된 리디렉션은 경계 초과 push(out-of-bounds push)보다는 malformed frame를 초래하며, 이는 IFE 유무와 관계없이 malformed 상태가 됩니다.
이러한 경계 사례는 이론적이지 않습니다 - ppp0에서 ife encode 액션이 ingress 훅에 설정된 veth로 리디렉션하면 패치 없이도 panic이 발생합니다:
skbuff: skb_under_panic: len:98 put:14 head:ffff88800e410000 data:ffff88800e40fff5 tail:0x57 end:0x640 dev:veth3 kernel BUG at net/core/skbuff.c:214! Call Trace: skb_push (net/core/skbuff.c:224 net/core/skbuff.c:2657) tcf_ife_act (net/sched/act_ife.c:829 net/sched/act_ife.c:874) tc_run (net/core/dev.c:4463) netif_receive_skb (net/core/dev.c:6463 net/core/dev.c:6522) tcf_mirred_to_dev (net/sched/act_mirred.c:248 net/sched/act_mirred.c:328) tcf_mirred_act (net/sched/act_mirred.c:489) tc_run (net/core/dev.c:4463) process_backlog (net/core/dev.c:6728)
이더넷 프레임 형식이 보장되므로, hard_header_len 대신 ETH_HLEN을 사용합니다.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.