文章总结： Binarly团队在u-boot引导加载程序中发现6个高危漏洞，均位于FIT镜像校验阶段，其中2个可导致任意代码执行，4个可导致拒绝服务。漏洞影响自v2013.07版本以来的所有版本，波及路由器、摄像头、服务器BMC等大量嵌入式设备。攻击者可远程利用这些漏洞绕过安全启动机制，建议厂商尽快通过固件更新部署补丁。 综合评分： 85 文章分类： 漏洞分析,应急响应,安全建设,iot安全

U-Boot 存在高危漏洞，数百万设备的安全启动机制遭到破坏

鹏鹏同学 鹏鹏同学

黑猫安全

2026年7月13日 09:16 湖北

在小说阅读器读本章

去阅读

Binarly 研究团队在开源引导加载程序 U-Boot 中发现了 6 处漏洞。U-Boot 被广泛应用于家用路由器、智能摄像头、服务器管理控制器，以及支撑互联网运转的绝大多数嵌入式硬件中。

这 6 处漏洞均在 FIT 镜像校验阶段被触发，FIT 镜像是 U-Boot 用于打包和校验待加载软件的格式。其中 2 处漏洞可导致任意代码执行，另外 4 处可引发拒绝服务攻击。受影响代码自 v2013.07 版本起就已存在于 U-Boot 中，意味着总计超过 50 个稳定版本都可能受到波及。

U-Boot 的地位至关重要：它的运行时机早于操作系统、早于所有安全软件，几乎早于所有组件。

Binarly 在报告中指出：“U-Boot 是设备启动流程中最先运行的组件之一，具备极高的安全敏感性。一旦该环节出现高危漏洞，攻击者即可借此篡改后续所有加载和运行的程序。意识到该组件的关键安全属性后，Binarly 研究团队对 U-Boot 项目的核心功能开展了深度审计，最终发现这 6 处独立漏洞 —— 危害程度从拒绝服务（DoS）攻击，到在非可信镜像校验过程中实现任意代码执行不等。”

在引导阶段植入恶意代码极难被检测，若不通过硬件方式重刷设备存储芯片，几乎无法彻底清除。

FIT 的全称是 Flattened Image Tree（扁平镜像树），是 U-Boot 的标准镜像格式，可将内核、设备树、内存盘与固件打包为单个文件包，同时内嵌密码哈希值与数字签名。FIT 签名校验就是在执行镜像前验证签名、确认镜像可信性的环节。

Binarly 专门聚焦该校验模块开展研究，因为一旦绕过它，整个可信启动机制就会形同虚设。可信启动机制的核心目的，就是保证设备启动各阶段仅运行可信代码。此前该代码路径就曾披露过多起漏洞，例如 CVE-2020-10648、CVE-2021-27097。基于过往研究，Binarly 判断该模块仍存在更多隐患。

BRLY-2026-037

根源在于 fdt_find_regions 函数。该函数遍历 FIT 镜像内的设备树结构，生成待做哈希校验的内存区域列表，遍历过程中调用 fdt_get_name 获取节点名称。 问题在于：在处理版本低于 0x10 的旧版 FIT 镜像、且节点名称不含斜杠字符时，fdt_get_name 可能返回空指针（NULL），而原有代码并未做空值校验，会直接调用空指针。

• 若为根节点：会造成程序立刻崩溃；
• 若为子节点：后续调用 strcpy 直接从空指针读取数据并复制至父函数的栈缓冲区。现代多数系统会将零页设为不可访问内存，同样会直接崩溃；但很多嵌入式设备并未做零页保护。攻击者若可控内存地址 0x0 处的数据，即可将空指针引用漏洞转化为栈缓冲区溢出漏洞，进而实现任意代码执行。Binarly 已在 U-Boot 沙箱编译版本中复现该漏洞。

BRLY-2026-038

与上一个漏洞根源一致，但可造成不同后果。 当 fdt_get_name 调用失败时，会向长度参数 len 写入负数错误码；后续代码直接用这个 len 值移动栈缓冲区指针，并未校验数值正负。负数会使指针反向向前偏移，引发栈缓冲区下溢漏洞。

报告补充说明：

“利用该下溢漏洞，每处理一条恶意构造的设备树条目，即可将末端指针向前偏移 10 字节（错误码 FDT_ERR_BADSTRUCTURE 为 -11，且循环内会执行 *end++ = ‘/’），直至覆盖 fdt_find_regions 函数的返回地址。之所以能够做到，是因为目标缓冲区位于上层 fit_config_check_sig 函数的栈帧中。之后通过精心构造合法节点名称，即可覆写 fdt_find_regions 的返回地址并植入攻击载荷。”

Binarly 已在 QEMU ARM 编译环境完成验证，成功在 U-Boot 运行时输出自定义信息。 以上两处漏洞，均可通过增加一行 fdt_get_name 返回值空指针校验代码完成修复。

BRLY-2026-039

漏洞与 FIT 镜像内字符串区域长度参数有关。 签名校验阶段，程序直接读取镜像内 hashed-strings 属性指定的长度值，未校验该数值是否超出镜像实际边界。攻击者可将其设为 0xFFFFFFFF，哈希校验程序会尝试读取近 4GB 数据，超出镜像边界并访问无效内存，最终导致引导程序崩溃。

BRLY-2026-040

同样是 fdt_find_regions 函数的空指针引用漏洞，但触发路径不同。 当遍历设备树属性标签时，程序调用 fdt_get_property_by_offset 读取属性头部信息。对于版本低于 0x10 的 FIT 镜像，该函数会直接返回空指针，不再解析属性内容；原有代码直接解引用该空指针。在零页受保护的平台上，会直接造成 U-Boot 崩溃。

BRLY-2026-041

针对外部载荷格式的 FIT 镜像：镜像仅通过内嵌参数（data-position、data-offset、data-size）指定外部载荷的位置与大小。

“data-position、data-offset、data-size 这三项参数完全由攻击者可控，原有代码均未校验其是否超出 FIT 镜像实际边界。后续哈希校验流程与 BRLY-2026-039 一致。攻击者有两种简便方式造成引导程序崩溃：一是通过位置参数把数据区域指向无效内存；二是设置超大 data-size 参数（例如 0xFFFFFFFF），使哈希读取越界。”

攻击者可通过将数据区域指向无效内存，或把数据尺寸参数设为 0xFFFFFFFF 两种方式造成引导程序崩溃。

BRLY-2026-042

该漏洞触发时机更早：签名校验开始前、FIT 格式合法性校验阶段。 函数 fdt_check_no_at 递归遍历整个 FIT 镜像树，查找含有 @ 符号的节点名称（该字符会干扰 libfdt 库的节点匹配逻辑）。原有代码无递归深度限制，继承上层校验规则后可递归至整型最大值（INT_MAX）层级。 每增加一层嵌套仅占用 12 字节镜像空间，但每次递归调用都会占用至少 16 字节栈内存。恶意构造深层嵌套镜像，会持续消耗栈内存，最终造成栈耗尽崩溃，与设备物理内存总大小无关。

Binarly 表示：“无论设备物理内存容量多大，最终都会出现栈耗尽问题。” 官方修复方案：增加深度计数器，拒绝嵌套层级超过 32 层的镜像。

很多人默认引导加载程序漏洞只能通过物理接触硬件来利用，Binarly 对此提出反驳，并以超微服务器主板管理控制器（BMC）固件历史漏洞作为例证。服务器 BMC 通常开放远程管理接口，Binarly 此前已证实：具备远程接口访问权限的攻击者，可绕过固件校验机制、强制刷入恶意固件镜像。 通用原理同理：任何支持网络固件更新的设备（即便自带校验机制），都有可能被远程攻击，无需物理接触硬件。

目前 6 处漏洞的修复补丁均已合并至上游主线版本（U-Boot master 分支）。最初漏洞披露阶段曾与项目维护方产生沟通阻碍，后续补丁由 Binarly 团队自行开发提交。 使用 U-Boot 的设备厂商与运维机构（尤其是搭载 BMC 控制器的服务器硬件），应尽快通过原厂固件更新渠道部署补丁。Binarly 也已在各漏洞公告中附上概念验证 FIT 镜像与完整复现步骤。

报告末尾提到：“此漏洞对应的安全公告中，已完整提供 PoC FIT 镜像生成脚本以及复现该漏洞的详细步骤。本次修复为 fdt_check_no_at 函数增加了深度计数校验，当嵌套层级达到 FDT_MAX_DEPTH（该参数定义于 boot/fdt_region.c 文件中，值为 32）时，直接拒绝加载该镜像。”

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：黑猫安全 鹏鹏同学 鹏鹏同学《U-Boot 存在高危漏洞，数百万设备的安全启动机制遭到破坏》