CVE-2026-98022
요약
\~에 의해 VulDB • 2026. 09. 25.
리눅스 커널에서 다음 취약점이 해결되었습니다:
net: tx_queue_len을 S16_MAX로 제한하여 과도하게 큰 링 할당 방지
여러 하위 시스템은 dev->tx_queue_len에 의해 크기가 결정되는 링 버퍼를 상한선 없이 할당합니다. 비특권 사용자(unshare -Urn 사용)는 매우 큰 tx_queue_len 값을 설정하여 링 할당을 통해 전역 메모리를 고갈시킬 수 있습니다:
- pfifo_fast: pfifo_fast_init() 및 pfifo_fast_change_tx_queue_len()은 각각 tx_queue_len 항목을 가진 3개의 skb_array 링을 할당합니다. - tun: tun_queue_resize() 및 큐 어태치 경로는 NETDEV_CHANGE_TX_QUEUE_LEN notifier에서 ptr_rings를 tx_queue_len 크기로 조정합니다. - tap (macvtap/ipvtap): tap_queue_resize() 및 tap_init()는 동일한 notifier에서 ptr_rings를 tx_queue_len 크기로 조정/초기화합니다.
netif_change_tx_queue_len()은 IFLA_TXQLEN, sysfs, SIOCSIFTXQLEN ioctl에 대한 단일 진입점입니다. 여기서 new_len을 S16_MAX(32767)로 제한하여 과도하게 큰 값이 설정 시 거부되도록 합니다. 이 조치는 장치가 up 상태든 down 상태든, dev->tx_queue_len이 쓰기되기 전, notifier가 발생하기 전, 그리고 링이 할당되기 전에 적용됩니다. "> S16_MAX" 체크는 이전의 unsigned-long 절단 테스트를 포괄하며, ioctl에서 전달된 음수 ifr_qlen은 변환 후 제한값보다 훨씬 위에 위치하므로 두 가지 기존 실패 모드 모두 단일 비교로 처리됩니다.
tx_queue_len은 모호합니다: 이는 링당 크기 배율이자, 설정 시 아무것도 할당하지 않는 소비자(pfifo/bfifo/gred/plug/sfb 제한, htb direct_qlen, qfq max_classes, teql)를 위한 기본 큐 길이/제한 노브입니다. 32767은 패치 2/3에서 u32 IFLA_TXQLEN 정책(NLA_POLICY_FULL_RANGE가 표현할 수 있는 최대 값)으로 선택되었으며, 높은 BDP 경로에서도 합리적인 큐 길이를 유지합니다. 공유된 노브의 링 메모리 트레이드오프는 아래에 설명됩니다.
버그 재현 조건: - CONFIG_NET_SCHED=y, CONFIG_VETH=y, CONFIG_USER_NS=y, CONFIG_NET_NS=y. - 새로운 user+net 네임스페이스 내 비특권 사용자(unshare -Urn). - pfifo_fast: veth 쌍 생성, tx_queue_len을 500000으로 설정, mq+pfifo_fast 어태치. 약 28회 반복 시 2GB 게스트에서 OOM 발생. - tun: IFF_MULTI_QUEUE로 50개 tun 장치 생성, tx_queue_len을 500000으로 설정, 각 8개의 큐 열기. ptr_ring 할당량 약 1.6GB가 512MB 게스트에서 OOM 발생. - tap: tun과 동일하되 IFF_TAP 사용. 약 960MB 할당이 512MB 게스트에서 OOM 발생. - 수정된 커널에서는 과도하게 큰 tx_queue_len이 설정 시 -ERANGE로 거부됩니다(모든 네 가지 경로: RTM_SETLINK, RTM_NEWLINK 생성, sysfs, ioctl - 후자는 이 체크를 통해, 전자는 각각 이 체크 및 2/3 파스 정책을 통해).
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.