0xblackash/cve-2026-81000CVE-2026-81000(TUNderflow) 연구 저장소로, 로컬 권한 상승을 가능하게 하는 Linux 커널 TUN/TAP 수신 헤드룸 정수 언더플로우에 대한 PoC, 근본 원인 분석, 실습 환경 구성을 제공합니다.
TUNderflow
TUN/TAP 네트워킹 서브시스템의 Linux 커널 메모리 손상 취약점으로, 수신 헤드룸에 대한 불충분한 경계 설정과 패킷 할당 경로의 정수 언더플로로 인해 발생합니다.
이 저장소는 승인된 보안 연구, 취약점 분석, CTF 환경, 커널 디버깅 및 방어적 테스트를 위해 제공됩니다.
명시적인 승인 없이 시스템에 대해 개념 증명 코드를 사용하지 마십시오.
| 필드 | 세부 정보 |
|---|---|
| CVE | CVE-2026-81000 |
| 코드명 | TUNderflow |
| 구성 요소 | Linux 커널 |
| 서브시스템 | TUN/TAP |
| 영향받는 코드 | drivers/net/tun.c |
| 주요 함수 | tun_get_user() |
| 버그 분류 | 정수 언더플로 / 범위를 벗어난 메모리 접근 |
| 영향 | 커널 메모리 손상 |
| 잠재적 영향 | 로컬 권한 상승 |
| CVSS v3.1 | 7.8 — 높음 |
| 공격 벡터 | 로컬 |
| 필요 권한 | 낮음 |
| 사용자 상호작용 | 없음 |
| 상태 | 패치됨 |
CVE 권고문은 이 문제를 skb->data가 할당된 skb 헤드 범위를 벗어난 위치에
배치될 수 있게 하는 정수 언더플로로 설명합니다.
이 취약점은 Linux 커널의 TUN/TAP 수신 경로에 존재합니다.
영향받는 코드는 TUN 장치에 구성된 수신 헤드룸을 패킷 헤드룸으로 사용하는 동시에, 얼마나 많은 패킷 데이터가 선형으로 유지되어야 하는지 계산할 때도 사용합니다.
따라서 과도하게 큰 헤드룸 값은 다음과 같은 잘못된 계산을 초래할 수 있습니다:
SKB_MAX_HEAD(align)
When the supplied value exceeds the usable one-page skb head, the calculation can underflow.
Conceptually:
Oversized receive headroom
│
▼
SKB_MAX_HEAD()
│
▼
Integer underflow
│
▼
Negative value
│
▼
size_t wrap
│
▼
Invalid skb data placement
│
▼
Kernel memory corruption
취약한 구현은 다음 위치에 있습니다:
drivers/net/tun.c
tun_get_user()가 취약한 경로의 핵심에 있습니다.
근본적인 문제는 충분히 제한되지 않은 TUN 수신 헤드룸입니다.
커널은 해당 값을 TUN/TAP으로 전파하는 네트워크 장치 경로를 통해 과도하게 큰 헤드룸 요청을 수신할 수 있습니다.
이 취약점은 복잡한 가상 네트워킹 구성으로 인해 큰 헤드룸 값이 TUN 장치에 도달하는 경우 특히 흥미로워집니다.
공개된 내용은 다음과 관련된 시나리오를 설명합니다:
Netkit
│
▼
VXLAN
│
▼
Open vSwitch
│
▼
TUN
예시 구성은 원시 TUN 포트에 약 4160바이트의 여유 공간을 전파하여 취약한 산술 연산이 언더플로우를 일으킬 수 있습니다.
손상은 커널 네트워킹 메모리 관리 로직에서 발생합니다.
잠재적 결과는 다음과 같습니다:
공개된 내용에 따르면 이 취약점은 Linux 로컬 루트 취약점 그룹 중 하나로 보고되며, 공개된 PoC가 지원 대상에서 비권한 로컬 사용자에서 루트로의 실행을 달성할 수 있다고 명시하고 있습니다.
악용 가능성은 환경에 따라 다르며, 관련 TUN/네트워크 장치 구성과 지원 기능이 필요합니다.
ATTACKER
│
▼
Oversized network headroom
│
▼
Virtual network device
│
▼
Open vSwitch
│
▼
TUN/TAP
│
▼
tun_get_user()
│
▼
SKB_MAX_HEAD(align)
│
▼
Integer underflow
│
▼
size_t wraparound
│
▼
Invalid skb->data offset
│
▼
Kernel memory corruption
중요한 구성 요소는 다음과 같습니다:
drivers/net/tun.c
│
├── tun_set_headroom()
│
├── tun_get_user()
│
└── tun_alloc_skb()
취약한 관계는 다음과 같이 단순화할 수 있습니다:
tun->align
│
├── skb headroom
│
└── linear-data calculation
동일한 과대 값을 두 계산 모두에 사용하면 요청된 여유 공간과 실제 skb 헤드 예산 사이에 안전하지 않은 관계가 형성됩니다.
핵심 보안 속성은 개념적으로 다음과 같이 나타낼 수 있습니다:
usable_head < requested_headroom
다음과 같은 결과가 발생할 수 있습니다:
SKB_MAX_HEAD(align) < 0
뒤이어 부호 없는 변환이 이어집니다:
negative value
↓
size_t
↓
very large unsigned value
이는 궁극적으로 skb 할당/데이터 배치에 영향을 미칠 수 있습니다.
공식 설명에서는 결과 값이 size_t linear 변수에 할당될 때 래핑된다는 점을 특히 언급하고 있습니다.
업스트림 수정은 다음과 같습니다:
447c9303942c439a117d9b76ce6d6e2116c38ee7
커밋:
net: tun: bound receive headroom
이 수정은 TUN이 저장하는 헤드룸을 사용 가능한 1페이지 skb 헤드 예산과 최대 유효 16비트 skb 헤더 오프셋에 대해 제한합니다. 또한 raw TUN 및 TAP 처리에 충분한 선형 데이터가 사용 가능하도록 보장합니다.
User / network device
│
▼
Large headroom
│
▼
tun->align
│
▼
Unsafe arithmetic
│
▼
Potential OOB access
User / network device
│
▼
Large headroom
│
▼
Bounded headroom
│
▼
Safe skb calculation
│
▼
Normal packet processing
| 보안 속성 | 취약 | 패치 |
|---|---|---|
| 헤드룸 제한됨 | ❌ | ✅ |
| 큰 헤드룸 안전하게 처리됨 | ❌ | ✅ |
| 언더플로 조건 방지됨 | ❌ | ✅ |
| skb 데이터 배치 보호됨 | ❌ | ✅ |
| 잘못된 네트워크 구성 안전하게 거부됨 | ❌ | ✅ |
권장 실험실 토폴로지:
┌─────────────────────────────────────────┐
│ Linux VM / Host │
│ │
│ ┌─────────┐ ┌──────────────┐ │
│ │ Netkit │────▶│ VXLAN │ │
│ └─────────┘ └──────┬───────┘ │
│ │ │
│ ┌──────▼───────┐ │
│ │ Open vSwitch │ │
│ └──────┬───────┘ │
│ │ │
│ ┌──────▼───────┐ │
│ │ TUN/TAP │ │
│ └──────────────┘ │
│ │
└─────────────────────────────────────────┘
유용한 도구:
uname -a
ip link
ip tuntap
bridge link
ovs-vsctl show
dmesg -w
커널 디버깅의 경우:
GDB
GDB + GEF
GDB + pwndbg
crash
objdump
readelf
pahole
실행 중인 커널을 확인합니다:
uname -r
커널 구성 확인:
grep CONFIG_TUN /boot/config-$(uname -r)
예상 구성:
CONFIG_TUN=y
또는:
CONFIG_TUN=m
모듈이 로드되었는지 확인합니다:
lsmod | grep tun
공개 공개 자료는 통제된 검증을 위한 전용 TUNderflow PoC 저장소를 제공합니다.
안전한 연구 워크플로를 위해:
1. Build vulnerable kernel
2. Boot isolated VM
3. Configure TUN/TAP
4. Reproduce oversized headroom
5. Monitor kernel messages
6. Capture crash/corruption behavior
7. Apply upstream patch
8. Repeat test
9. Compare results
커널을 모니터링합니다: