⚡ CVE-2026-81000 - `TUNderflow`

Linux 内核 TUN/TAP 接收预留空间内存破坏漏洞

Linux 内核 TUN/TAP 网络子系统中的一个内存破坏漏洞，由接收预留空间边界不足以及数据包分配路径中的整数下溢引起。

⚠️ 免责声明

本仓库仅用于授权的安全研究、漏洞分析、CTF 环境、内核调试和防御性测试。

请勿在未经明确授权的情况下对系统使用概念验证代码。

📌 漏洞概述

CVE 公告将该问题描述为整数下溢，可能导致 skb->data 被定位到已分配的 skb head 之外。

🧬 漏洞描述

该漏洞存在于 Linux 内核的 TUN/TAP 接收路径中。

受影响的代码将 TUN 设备配置的接收预留空间同时用作数据包预留空间，并在计算应保留多少线性数据包数据时使用该值。

因此，过大的预留空间值会在以下计算中产生无效结果：

SKB_MAX_HEAD(align)

当提供的值超过可用的一页 skb head 时，该计算可能发生下溢。

概念上：

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

一个示例配置可以将大约 4160 字节的预留空间传播到原始 TUN 端口，从而导致存在漏洞的算术运算发生下溢。

💥 安全影响

该破坏发生在内核网络内存管理逻辑中。

潜在后果包括：

内核内存破坏
内核崩溃
拒绝服务
内核结构破坏
潜在的内核代码执行
本地权限提升

公开披露将该漏洞报告为一组 Linux 本地 root 漏洞之一，并指出已发布的 PoC 可在受支持的目标上实现非特权本地用户到 root 的执行。

可利用性取决于环境，并且需要相关的 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 head 预算之间产生不安全的关系。

🧮 整数下溢

关键安全属性可以概念化表示为：

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

该修复根据可用的一页 skb head 预算和最大的有效 16 位 skb 头部偏移来限制 TUN 存储的预留空间。它还确保为原始 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

📊 漏洞版本与已修补版本对比

🧪 研究环境

推荐的实验拓扑：

┌─────────────────────────────────────────┐
│             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

🧪 PoC 研究

公开披露提供了一个专门的 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

监控内核：

sudo dmesg -w

该实验的目标是展示漏洞版本与已修补版本行为之间的差异，而不是攻击生产系统。

📂 仓库结构

CVE-2026-81000-TUNderflow/
│
├── README.md
│
├── exploit/
│   ├── poc.c
│   └── Makefile
│
├── analysis/
│   ├── root-cause.md
│   ├── kernel-path.md
│   ├── integer-underflow.md
│   └── patch-analysis.md
│
├── kernel/
│   ├── vulnerable/
│   └── patched/
│
├── lab/
│   ├── setup.sh
│   ├── cleanup.sh
│   └── topology.md
│
├── screenshots/
│
├── docs/
│   └── research-notes.md
│
└── LICENSE

🔐 缓解措施

推荐的缓解措施是安装包含上游安全修复或相应发行版向后移植补丁的内核。

对于 Debian/Kali：

sudo apt update
sudo apt full-upgrade

然后重启：

sudo reboot

验证：

uname -r

对于生产环境，请根据供应商的安全公告验证已安装的发行版内核，而不是仅依赖上游版本号。

例如，Oracle Linux 已发布包含 net: tun: bound receive headroom 修复的安全更新。

📦 稳定内核修复

公开披露指出，以下稳定内核版本是首批包含四个已披露本地 root 漏洞（包括 TUNderflow）修复的版本：

🧩 安全经验教训

TUNderflow 展示了若干重要的内核安全原则：

01 — 限制受外部影响的值

网络配置值绝不能被盲目信任。

02 — 在分配前验证算术运算

整数下溢可以将看似无害的计算转变为内存安全原语。

03 — 将元数据与内存假设分离

网络设备预留空间值必须与实际 skb 内存预算保持一致。

04 — 复杂网络栈增加攻击面

虚拟网络层可以将意外的数据包元数据传播到多个子系统。

05 — 补丁分析很重要

研究上游修复通常比仅查看崩溃更能清晰地理解原始漏洞。

📚 参考资料

CVE： CVE-2026-81000
组件： Linux 内核 TUN/TAP
受影响文件： drivers/net/tun.c
主要函数： tun_get_user()
上游修复： 447c9303942c439a117d9b76ce6d6e2116c38ee7
修复： net: tun: bound receive headroom
披露： Linux 内核安全公告 / oss-security

👤 研究

0xBlackash

网络安全研究 · Linux 内核安全 · 漏洞研究 · CTF

CVE-2026-81000 · TUNderflow · TUN/TAP · Linux Kernel · LPE

CVE	CVE-2026-81000
代号	TUNderflow
组件	Linux 内核
子系统	TUN/TAP
受影响代码	`drivers/net/tun.c`
主要函数	`tun_get_user()`
漏洞类别	整数下溢 / 越界内存访问
影响	内核内存破坏
潜在影响	本地权限提升
CVSS v3.1	7.8 — 高
攻击向量	本地
所需权限	低
用户交互	无
状态	已修补

预留空间受限	❌	✅
安全处理过大的预留空间	❌	✅
防止下溢条件	❌	✅
保护 skb 数据放置	❌	✅
安全拒绝畸形网络配置	❌	✅

5.10	5.10.270
5.15	5.15.221
6.1	6.1.188
6.6	6.6.157
6.12	6.12.109
6.18	6.18.50
7.2	7.2.4

CVE-2026-81000

最受欢迎

⚡ CVE-2026-81000 - TUNderflow