CVE-2026-99033 in Linux
요약
\~에 의해 VulDB • 2026. 10. 24.
리눅스 커널에서 다음 취약점이 해결되었습니다:
net/packet: packet_rcv_spkt()에서 ll 헤더 푸시를 보호하십시오
packet_rcv_spkt()는 다음과 같이 링크 레이어 헤더를 복원합니다:
skb_push(skb, skb->data - skb_mac_header(skb));
이 뺄셈은 장치가 실제로 링크 레이어 헤더를 가지고 있을 때만 의미가 있습니다. packet_rcv()와 tpacket_rcv()는 이를 dev_has_header()로 감싸고 있으며, 이는 파일 상단의 블록 주석에서 복원을 설명하는 데 사용되는 술어이기도 합니다. 반면 packet_rcv_spkt()는 그렇지 않습니다. 커밋 d549699048b4("net/packet: L3 장치에서의 패킷 수신 수정")은 헬퍼를 도입하고 두 호출 사이트를 변경했으며, 이 사이트만 뒤처졌습니다.
가시적인 ll 헤더가 없는 장치는 skb->mac_header을 __alloc_skb()에서 초기화하는 0xFFFF 센티넬 값으로 남겨둘 수 있습니다. CAN skb의 경우: init_can_skb()는 pkt_type과 ip_summed를 설정하지만 헤더를 재설정하지 않으며, 커밋 9f10374bb024("can: private CAN skb headroom 인프라 제거")은 이전에 존재했던 skb_reset_*_header() 호출들을 삭제했습니다. 따라서 skb_mac_header()는 0xFFFF가 되고 길이는 큰 음수가 되며, skb_push()는 이를 skb_under_panic()를 통해 보고합니다 -- softirq 컨텍스트에서 발생하므로 panic_on_oops=0이라도 전체 시스템 패닉이 발생합니다:
skbuff: skb_under_panic: text:ffffffff8bd21bc1 len:-65455 put:-65471 head:... data:... tail:0x50 end:0x180 dev:can0 kernel BUG at net/core/skbuff.c:214! RIP: 0010:skb_panic+0x50/0x60 Call Trace: <IRQ> skb_push+0x38/0x40 packet_rcv_spkt+0xe1/0x170 __netif_receive_skb_core.constprop.0+0x7e8/0xd30 ... Kernel panic - not syncing: Fatal exception in interrupt
소켓 유형은 접근 가능합니다: packet_create()는 CAP_NET_RAW 확인 뒤에 SOCK_PACKET을 SOCK_RAW 및 SOCK_DGRAM과 함께 수락하며, 소켓 길이 또는 능력(capability) 체크가 CAN 인터페이스에서 이를 차단하지 않습니다.
init_can_skb()에 있는 누락된 skb_reset_*_header() 호출들은 그 자체로 회귀(regression)이며 별도로 수정되고 있지만, 패킷 소켓은 mac 헤더를 초기화하지 않은 링크 레이어를 커널 패닉으로 전환해서는 안 됩니다. 다른 두 수신 경로와 마찬가지로 푸시를 보호하십시오.
QEMU에서 slcan 장치를 pty에 연결하여 v7.3-rc5에서 테스트했습니다(이는 드라이버 RX 경로입니다). vcan은 can_send()가 출력 시 헤더를 재설정하기 때문에 이를 재생산하지 않습니다. can0에 바인딩된 SOCK_PACKET 소켓 하나와 라인 디스플린(line discipline)으로 작성된 하나의 프레임이 패치되지 않은 커널을 위의 트레이스와 함께 패닉시킵니다. 동일한 이미지를 이 패치로 실행하면 패닉 없이 정상적으로 전원이 꺼집니다. 두 커널 모두 이 트리의 defconfig에 CONFIG_CAN_SLCAN=y를 추가한 것으로, 이 hunks에서만 다릅니다.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.