Linux内核bonding驱动19年0day：CVE-2026-43456深度分析

导语：日本GMO Cybersecurity安全研究团队近日披露一起极为罕见的”老兵级”零日漏洞——CVE-2026-43456。该漏洞藏身于Linux内核网络子系统bonding驱动之中，自2007年引入以来已在全球服务器中潜伏长达19年。攻击者只需拥有CAP_NET_ADMIN权限即可实现本地权限提升，稳定性高达99%以上。国内运行Linux服务器的企业需立即展开排查。

来源：本文综合编译自GMO Cybersecurity安全博客及Twitter/X安全研究员@0x0SojalSec、@rqda_A公开披露信息。

一、漏洞概述

GMO Cybersecurity（极爱网络安全）上席执行役員/CTO小池与高度解析课兼职研究员户田，于2026年7月3日联合披露了这起震惊安全社区的漏洞。

该漏洞具有以下核心特征：

漏洞类型：类型混淆（Type Confusion）

影响组件：Linux内核网络子系统 net/bonding

影响范围：Linux 2.6.24 至 6.12.77，涵盖几乎所有主流内核版本

触发条件：需持有 CAP_NET_ADMIN 权限

危害程度：本地权限提升至root + KASLR泄露 + 任意代码执行

引入时间：2007年（commit 1284cd3a2b740d0118458d2ea470a1e5bc19b187）

修复时间：2026年3月（commit 950803f7254721c1c15858fbbfae3deaaeeecb11）

漏洞奖励：Google kernelCTF bug bounty 奖金逾8万美元

二、漏洞根因分析

2.1 bonding驱动的设计初衷

bonding（链路聚合）是Linux内核提供的网络功能，可将多个物理网络接口聚合为一个逻辑接口，实现负载均衡和故障容错。创建的逻辑接口称为bond设备，下位物理接口称为slave设备。

研究团队指出，该漏洞的根因仅在bond_setup_by_slave函数中一行代码：

bond_dev->header_ops = slave_dev->header_ops;  // ★ 漏洞触发行

header_ops是Linux内核用于处理网络协议包头的函数指针表。bond设备设计为对上层透明，因此直接将slave设备的header_ops复制过来看似合理。

然而，问题在于：部分header_ops函数会访问设备的私有存储区域（dev->priv），而bond设备的私有区域类型为struct bonding，slave设备的私有区域类型则各异——当slave为GRE隧道时，其私有区域为struct ip_tunnel。两种结构体内存布局完全不同，直接混用导致了类型混淆。

2.2 为什么19年未被发现了？

研究人员在博客中指出，利用此漏洞需要极其精巧的设备链式构造。具体而言，需要创建329个GRE设备形成链式结构，才能将bond设备的LL_RESERVED_SPACE精确调整为特定值（0x3ec0），使skb->data与skb_shared_info结构重叠，从而触发可控的内存越界写入。

这种精确条件意味着漏洞虽然真实存在，但在大多数正常配置下不会产生任何可观测的崩溃——内存写入发生在从未被使用的填充区域，甚至连KASAN等内存检测工具也无法察觉。安全社区在19年间与它”相安无事”，正是因为缺乏针对性的极端构造场景。

研究团队坦言：最初是由模糊测试工具syzkaller偶然触发了崩溃，而后才顺藤摸瓜进行深度逆向分析，最终定位到2007年引入的那行代码。

三、漏洞利用技术链

3.1 第一阶段：KASLR地址泄露

攻击者首先利用IP6GRE（IPv6 GRE隧道）设备进行KASLR泄露。

struct bonding的recv_probe函数指针位于结构体偏移0x38处；当bond设备通过type confusion被当作IP6GRE设备时，偏移0x38处实际对应struct ip6_tnl的laddr字段（IPv6源地址），而该值来自接收数据包中的可控内容。

由于bonding的recv_probe初始化时被设置为bond_rcv_validate函数地址，泄露该地址即可计算内核基址，从而绕过KASLR随机化。

3.2 第二阶段：任意代码执行

接下来，攻击者改用普通GRE（IPv4版）进行内存破坏，核心思路分为两步：

第一步：SKBFL_ZEROCOPY_ENABLE标志篡改

在GRE的header_ops函数中，由于type confusion，t->hlen被错误读取为0（struct bonding中该字段为0，而真正的GRE设备该字段非零），导致skb_push()计算错误，使得greh->flags写入位置与skb_shared_info->flags重叠。通过构造特定值（0x07ff），成功设置SKBFL_ZEROCOPY_ENABLE位。

第二步：触发callback调用

一旦skb被标记为zerocopy，后续skb_zcopy_clear()调用将执行uarg->callback()。通过前期泄露的KASLR基址，攻击者可将callback函数指针覆写为kernel Text区域内的任意地址（如commit_creds或prepare_kernel_cred），最终完成从普通用户到root的权限提升。

整个利用过程稳定率超过99%，耗时不足1秒。

四、影响范围评估

根据MITRE/NVD披露及国内实际情况，该漏洞影响面极广：

所有启用bonding模块且允许CAP_NET_ADMIN权限用户操作的Linux服务器
云服务商提供的部分默认镜像（部分默认启用bonding或存在相关配置）
容器宿主机（如果容器逃逸结合此漏洞，威胁将进一步扩大）

值得注意的是，CAP_NET_ADMIN权限本身已属于较高等级的系统权限——非root用户通过user namespaces、某些网络命名空间配置可获得该权限。因此，该漏洞的实际利用门槛并非”零门槛”，但在多租户环境（如公有云）中仍构成严重风险。

五、防御与修复建议

5.1 紧急修复（最高优先级）

立即更新内核至最新稳定版本。2026年3月的安全更新（commit 950803f7254）已修复此漏洞，各主流Linux发行版应已在后续更新中同步。蓝队建议通过以下命令快速核查当前内核版本是否存在漏洞：

# 检查内核版本是否在受影响范围内
uname -r
# 查询发行版安全公告
dnf check-update --security 2>/dev/null || apt-get -s upgrade 2>/dev/null | grep -i security

5.2 临时缓解措施

如因业务连续性要求暂时无法重启内核，可采取以下任一缓解措施：

措施一：禁用bonding模块（推荐）

# 阻止bonding模块加载
echo "install bonding /bin/false" > /etc/modprobe.d/disable-bonding.conf
rmmod bonding 2>/dev/null

大多数Linux发行版默认未启用bonding，该措施对正常业务无影响。

措施二：限制CAP_NET_ADMIN权限扩散

# 禁用非特权用户的user namespaces（防止获取CAP_NET_ADMIN）
echo 0 > /proc/sys/kernel/unallowed_userns_clone
# 或
sysctl -w kernel.unprivileged_userns_clone=0

代价：rootless Docker等工具将无法正常使用。

措施三：网络命名空间隔离

对需要运行不可信代码的环境（如容器平台、多租户VPS），建议启用网络命名空间严格隔离，限制容器获取CAP_NET_ADMIN能力。

5.3 检测与监控

蓝队建议在SOC平台部署以下检测规则：

SIEM规则：监控bonding接口的异常创建行为（短时间内创建大量GRE slave设备）
HIDS规则：检测bonding模块是否异常加载，lsmod | grep bonding
网络监控：关注来自容器/非特权用户的GRE隧道流量异常

六、漏洞发现方法论启示

GMO团队在复盘中发现，该漏洞的发现过程中AI助手发挥了关键作用。在2025年上半年，大型语言模型对Linux内核等开源项目的代码理解能力已相当成熟，协助团队在分析syzkaller崩溃日志时快速缩小可疑范围。

然而研究人员也指出，即便在AI能力大幅跃升的2026年，对于此类需要构造极端条件才能触发可观测效应的”沉睡型漏洞”，完全依赖AI自动发现仍存在相当难度。这提醒安全社区：AI是强大的辅助工具，但系统性的模糊测试与资深研究人员的深度分析仍不可替代。

七、总结

CVE-2026-43456的披露再次说明，代码审视的时间跨度与漏洞隐蔽性并不成正比——一个看似无害的赋值语句，可以在代码库中存在19年而始终未被任何静态分析工具发现，直至遇到精心构造的触发条件才暴露其破坏力。

对于安全运营团队而言，这起事件的教训是明确的：多层防御纵深仍是根本。即便内核已更新到安全版本，也应通过最小权限原则限制CAP_NET_ADMIN的获取路径；同时，持续监控与事件响应能力的建设，才是应对”已知”漏洞乃至”未知”0day的最终防线。

参考资料：

GMO Cybersecurity – 19年以上見過ごされていたLinux kernelのゼロデイ脆弱性を報告した話：CVE-2026-43456 – GMOサイバーセキュリティ by イエラエ，发表于 2026年7月
@rqda_A – Twitter/X披露推文 – 发表于 2026年7月3日
Google Security Blog – kernelCTF规则与奖励机制 – Google

文章版权归作者所有，未经允许请勿转载。

THE END

Linux内核bonding驱动19年0day：类型混淆漏洞CVE-2026-43456分析