🇰🇷 한글 설명
Linux 커널의 vlan 모듈에서 __vlan_insert_inner_tag() 함수가 MAC 헤더의 존재 여부를 제대로 확인하지 않아 발생하는 취약점입니다. IFF_TUN 장치를 사용할 경우, 매우 짧은 패킷이 처리되는 과정에서 초기화되지 않은 슬랩(slab) 메모리의 데이터가 패킷에 포함되어 유출될 수 있습니다.
💡 쉬운 설명
네트워크 패킷을 처리할 때 메모리에 남아있던 민감한 정보가 실수로 패킷에 섞여 외부로 나갈 수 있는 문제입니다. 공격자는 이를 통해 시스템 내부의 메모리 주소와 같은 중요한 정보를 훔쳐볼 수 있습니다.
🇺🇸 원문 (English)
In the Linux kernel, the following vulnerability has been resolved:
vlan: require the MAC header to be present in __vlan_insert_inner_tag()
__vlan_insert_inner_tag() only guarantees head room via skb_cow_head(),
never that mac_len bytes of MAC header are present. Its ETH_HLEN
wrappers - __vlan_insert_tag() under skb_vlan_push(), and
vlan_insert_tag() under validate_xmit_vlan() on the generic transmit
path - therefore rewrite the first 16 bytes at skb->data: a 12-byte
memmove plus two 2-byte stores at +12 and +14. No caller supplies the
bound, while the pop helpers use skb_ensure_writable()/pskb_may_pull().
An IFF_TUN device has hard_header_len == 0, so packet_snd() accepts a
one-byte AF_PACKET/SOCK_RAW frame. The first vlan push only sets a
hwaccel tag; the next - clsact "action vlan push" or
bpf_skb_vlan_push() - enters the helper with skb->len still 1. The
head comes from skbuff_small_head without __GFP_ZERO, so each push
drags bytes from beyond skb->tail into the frame. After three the
one-byte send leaves as 13 bytes carrying 11 bytes of uninitialised
slab:
0000: 5a b3 62 12 80 88 ff ff 00 b3 62 12 81
`------------------------------'
only 0x5a was sent; the rest is slab, here the top 56 bits of a
linear-map address
Require the MAC header the helper rewrites to be present, so such a
frame is dropped rather than transmitted.
📍 영향받는 시스템
Linux kernel (IFF_TUN 장치 및 VLAN 관련 기능 사용 시)
⚔️ 공격 벡터
조작된 짧은 길이의 AF_PACKET/SOCK_RAW 프레임을 IFF_TUN 장치를 통해 전송
🛡️ 대응 방법
Linux 커널을 최신 보안 패치가 적용된 버전으로 업데이트
🔧 검증 코드
출력된 커널 버전이 해당 취약점이 해결된 패치 버전 이후인지 확인