CVE-2025-61618漏洞深度剖析：5G NR调制解调器输入验证缺陷与远程DoS攻击

1. 项目概述：从CVE编号到真实威胁的映射

看到CVE-2025-61618这个编号，很多做移动通信安全或者终端设备固件分析的朋友可能会心头一紧。NR，也就是New Radio，5G网络的空中接口标准，而调制解调器（Modem）则是手机、物联网设备连接5G网络的核心通信芯片。一个在NR调制解调器上被曝光的远程拒绝服务漏洞，意味着攻击者可能不需要接触你的设备，只要你的设备连着网，就能让它“罢工”。这听起来有点吓人，但更吓人的是，很多公开的分析往往停留在CVSS评分7.5、攻击向量是网络这类表面信息上，对于漏洞到底怎么触发、在代码的哪个环节出了问题、实际影响范围有多大，却语焉不详。

我花了些时间，结合对蜂窝网络协议栈和嵌入式系统安全的理解，来深挖一下这个漏洞。它被标记为“输入验证不当”，这五个字在安全报告里太常见了，常见到几乎失去了信息量。但在NR调制解调器的上下文里，这个“输入”特指什么？是来自基站的无线信号（RRC消息），还是来自设备上层应用的数据包？验证“不当”又具体指哪种不当？是长度检查缺失、范围校验错误，还是对异常状态的处理逻辑有缺陷？搞清这些，你才能判断这个漏洞是实验室里的理论风险，还是能写出稳定攻击代码的真实威胁。另外，热词里提到的“nr drb的建立”非常关键，这指向了5G中数据无线承载（Data Radio Bearer）的建立过程，这通常是协议栈中状态复杂、容易出错的环节，很可能就是漏洞的藏身之处。

这篇文章，我会从一个实战分析者的角度，带你还原CVE-2025-61618。我们不止看公开的描述，更要结合5G NR协议栈的实现特点、嵌入式实时操作系统（RTOS）的常见缺陷模式，以及模糊测试（Fuzzing）在挖掘这类漏洞时的思路，把“输入验证不当”这个模糊的概念，还原成具体的代码逻辑缺陷和可复现的崩溃场景。无论你是从事物联网安全研究、移动终端测试，还是对底层系统安全感兴趣，相信都能从中看到一些门道。

2. 漏洞核心原理与NR协议栈背景剖析

2.1 NR调制解调器的软件架构与风险面

要理解这个漏洞，首先得知道NR调制解调器软件大概是怎么工作的。它不是一个简单的驱动程序，而是一个复杂的、实时性要求极高的嵌入式软件系统，通常运行在专用的基带处理器上。其核心是协议栈软件，遵循3GPP标准，层层实现从物理层（PHY）到无线资源控制层（RRC）的功能。

一个简化的分层视图如下：

1. L1（物理层）：处理最底层的编码、调制、信号处理。这部分的代码很多是高度优化的汇编或专用DSP代码，漏洞多与内存操作溢出相关。
2. L2（数据链路层）：包括MAC（媒体接入控制）、RLC（无线链路控制）、PDCP（分组数据汇聚协议）。负责调度、重传、加密和完整性保护。这一层要处理大量的数据包和状态机，是逻辑漏洞的高发区。
3. L3（网络层）：核心就是RRC层。它负责连接管理、移动性管理、承载建立/修改/释放等。RRC层是调制解调器与网络（基站）进行“对话”的指挥官，也是接收并解析所有来自网络的“命令”（RRC消息）的地方。这里就是“输入验证”的主战场。

所有的“输入”，最终都来源于基站通过空口发送的、符合3GPP 38.331规范定义的RRC消息。调制解调器的协议栈需要解析这些ASN.1编码的二进制消息，将其转化为内部数据结构，并驱动相应的状态转换和资源配置。

注意：这里存在一个关键的安全假设偏差。协议栈开发者的潜意识里，往往默认基站是“善意的”，发送的消息是符合规范的。因此，代码中对消息内容的校验可能不够充分，或者只考虑了“合法但错误”的情况，而没考虑“故意畸形、旨在破坏”的情况。CVE-2025-61618的根源很可能就在这里。

2.2 “输入验证不当”在NR上下文中的具体含义

在公开描述中，“输入验证不当”导致系统崩溃。在NR调制解调器的RRC层，输入验证通常包括以下几个维度，任何一个维度的缺失或错误都可能导致崩溃：

1. 消息结构完整性验证：ASN.1 PER（压缩编码）或Unaligned PER解码后，检查必选字段是否存在，可选字段标记是否合理。例如，一条携带“nr drb的建立”相关配置的RRCReconfiguration消息，其中必须包含radioBearerConfig字段。如果攻击者伪造的消息中该字段缺失或标记为“不存在”，但后续代码逻辑又强制去访问它，就会导致空指针解引用。
2. 字段值域边界验证：检查字段值是否在协议规定的有效范围内。例如，DRB-Identity（数据无线承载标识）的值范围是1~32。如果攻击者将其设置为0或33，而协议栈代码使用这个值作为数组索引（如drb_context[identity]），且没有进行边界检查，就会导致数组越界访问，可能读/写到非法内存。
3. 逻辑一致性验证：检查不同字段之间的逻辑关系是否合理。例如，在配置一个DRB时，会同时配置其对应的PDCP-Config、RLC-Config和LogicalChannelConfig。如果RLC-Config中指定了“确认模式（AM）”，但LogicalChannelConfig中却配置了一个不允许重传的优先级，这种组合在协议上可能是无效的。如果协议栈代码没有检查这种跨字段的一致性，在后续处理时进入未预期的代码路径，就可能引发断言失败或资源分配错误。
4. 状态机上下文验证：检查收到的消息是否与当前协议栈的状态匹配。例如，在RRC_IDLE状态下，突然收到一条要求修改DRB的RRCReconfiguration消息，这显然是不合法的。代码需要拒绝此消息。如果状态检查被绕过，可能导致协议栈状态混乱。

结合“nr drb的建立”这个热词，我高度怀疑漏洞触发点与RRCReconfiguration消息处理流程强相关。这条消息用于建立、修改或释放DRB。建立DRB是一个多步骤的复杂过程，涉及L2各子层（PDCP、RLC、MAC）实体创建、资源配置、与网络侧参数协商等。在这个过程中，如果攻击者伪造的RRCReconfiguration消息包含一个无效的、或自相矛盾的DRB-ToAddMod列表，而协议栈在解析并尝试应用这些配置时，某一步的验证缺失，就可能在分配内存、初始化数据结构、配置硬件寄存器时发生致命错误，导致内核崩溃（如看门狗超时、非法内存访问）。

2.3 漏洞利用场景与影响分析

这个漏洞被标记为“远程利用：是”，且攻击向量是“网络”，所需权限和用户交互都是“无”。这意味着：

• 攻击者位置：理论上，攻击者可以伪装成一个恶意的基站（伪基站）。在5G NSA组网下，甚至可能通过控制核心网侧的某些网元，向目标用户发送恶意的RRC信令。
• 攻击条件：目标设备需要处于蜂窝网络覆盖下（不一定是5G，也可能是4G锚点），并且与网络建立了RRC连接。设备不需要安装任何恶意软件，用户也无需进行任何点击操作。
• 攻击效果：导致调制解调器固件崩溃。最直接的表现就是设备“脱网”——信号栏显示无服务，无法拨打/接听电话，无法使用移动数据。根据调制解调器与主处理器（AP）的耦合程度以及复位机制，可能导致：
  • 调制解调器子系统重启：相对温和，几秒到几十秒后恢复服务。
  • 整个设备重启：如果调制解调器崩溃触发了整个系统的看门狗复位，用户体验就是手机突然黑屏重启。
  • 永久性拒绝服务：如果崩溃破坏了关键的非易失性配置数据（如NV项），可能导致调制解调器无法正常初始化，需要返厂维修。

影响范围：虽然公开的受影响产品列表为空（常见于漏洞刚被分配CVE时），但可以推断，使用特定厂商（如Unisoc展锐，漏洞来源方）基带芯片或协议栈软件的设备都可能受影响。这包括大量中低端智能手机、物联网模块（如Cat.1, Cat.4模组）、车载T-Box等。由于基带固件更新通常滞后且依赖厂商推送，漏洞的潜在影响周期会很长。

3. 漏洞深度挖掘与逆向分析思路

3.1 基于模糊测试（Fuzzing）的漏洞发现路径

像CVE-2025-61618这类输入验证漏洞，在现代安全研究中，很大概率是通过模糊测试发现的。对于NR协议栈，一个高效的Fuzzing策略如下：

1. 目标选择：不直接Fuzz整个调制解调器固件（太难）。而是Fuzz运行在应用处理器（AP）上的“协议栈适配层”或“测试接口”（如Diag端口、AT命令端口）。很多厂商会有用于内部测试的RRC消息注入工具。
2. 语料库生成：以3GPP 38.331规范为基础，收集合法的RRC消息流（通过空口抓取或从测试用例中提取）。使用asn1c编译器将规范生成编解码代码，以此为基础构建Fuzzer。
3. 变异策略：
   • 结构变异：随机删除、添加、重复消息中的字段或IE（信息元素）。
   • 值域变异：对整型、枚举值进行极值（0, -1, MAX+1）或随机值替换。
   • 逻辑变异：故意制造字段间的矛盾，比如在配置DRB时，设置一个超大的logicalChannelGroup值，或者将rlc-Config设置为空。
4. 监控与反馈：Fuzzer需要监控目标进程的异常，如崩溃（SIGSEGV, SIGABRT）、断言失败、内存泄漏、以及协议栈状态异常（如状态机卡死）。覆盖率引导（Coverage-guided）的Fuzzer（如AFL++， libFuzzer）能有效探索新的代码路径。

实操心得：对嵌入式协议栈Fuzzing，最大的挑战是执行速度和环境依赖。直接运行在实机或仿真器上太慢。一个可行的办法是将协议栈的关键消息处理函数（如rrc_reconfiguration_decode_and_process）剥离出来，编译成一个运行在Linux用户空间的库，然后针对这个库进行内存Fuzzing。这需要一定的逆向工程和代码移植工作，但一旦成功，Fuzzing效率将大大提升。

3.2 静态代码分析与可疑代码模式定位

如果没有Fuzzing环境，通过静态分析寻找此类漏洞也有迹可循。假设我们能获得疑似受影响版本的协议栈二进制文件（哪怕是某个IoT模组的固件提取物），可以尝试以下步骤：

1. 符号恢复与字符串搜索：在二进制中搜索关键字符串，如“DRB-ToAddMod”、“RRCReconfiguration”、“reconfigurationWithSync”等。这些往往是编解码或日志打印函数中的标志，能帮我们快速定位到关键函数。
2. 关注ASN.1解码回调函数：协议栈使用ASN.1编译器生成的代码进行解码。解码器会对每个字段调用一个asn1c_xxx_decoder函数，最终调用到协议栈自己实现的xxx_ies_decoder。漏洞往往就藏在xxx_ies_decoder或其调用的验证函数里。我们需要反汇编这些函数，查看：
   • 在字段赋值给内部结构体（struct drb_config_t）之前，是否有明显的边界检查指令（如CMP+BHI/BLS）。
   • 是否有对指针解引用前的判空检查（LDR指令前是否有CBZ或CMP）。
3. 寻找“危险”的数组或链表操作：在DRB配置处理函数中，极有可能存在一个以DRB-Identity为索引的全局数组或链表，用于管理所有DRB的上下文。反汇编代码中寻找类似ldr r1, [r0, r3, lsl #2]（数组访问）或遍历链表的循环。检查索引值r3是否在访问前与数组大小（如32）进行了比较。
4. 分析崩溃上下文：如果能有崩溃现场的日志或内存转储（如ramdump），价值巨大。查看崩溃时的程序计数器（PC）和调用栈，看它死在哪个函数里。如果死在memcpy、memset或某个内存分配函数里，结合当时的参数，基本就能断定是缓冲区溢出。如果死在访问0x00000000或0xdeadbeef这样的地址，那就是空指针或野指针。

一个假设的漏洞代码模式示例（伪代码）：

// 假设这是处理 DRB-ToAddMod 列表的函数，存在漏洞 void process_drb_add_mod_list(asn1c_drb_to_add_mod_list_t *asn1_list) { drb_config_t *drb_context = get_global_drb_context_array(); // 全局数组，大小32 for (int i = 0; i < asn1_list->count; i++) { asn1c_drb_to_add_mod_t *asn1_drb = &asn1_list->items[i]; int drb_id = asn1_drb->drb_Identity; // [漏洞点] 未验证 drb_id 是否在1~32范围内 // 直接使用 drb_id 作为索引，如果 drb_id=0 或 33，则越界！ drb_config_t *config = &drb_context[drb_id]; config->pdcp_config = decode_pdcp_config(&asn1_drb->pdcp_Config); config->rlc_config = decode_rlc_config(&asn1_drb->rlc_Config); // ... 其他配置 if (asn1_drb->cellGroupId) { // 这是一个可选字段 // [另一个可能的漏洞点] 如果 cellGroupId 指向一个非常大的值，可能导致后续计算溢出 config->cell_group = *asn1_drb->cellGroupId; } } }

上面这段伪代码展示了两个典型的漏洞模式：数组索引越界和可选字段未校验即使用。攻击者通过精心构造一个包含drb_Identity = 0或33的RRCReconfiguration消息，即可触发崩溃。

4. 漏洞复现与调试环境搭建构想

4.1 模拟复现环境的搭建思路

完全在真实网络和真实设备上复现此类漏洞成本高、风险大，且难以调试。一个更可行的思路是搭建一个软件模拟的测试环境：

1. 目标协议栈获取：
   • 理想情况：获得目标调制解调器芯片的SDK或协议栈库文件（.a或.so）。这通常来自设备固件提取或通过某些渠道获得。
   • 替代方案：使用开源实现进行原理性复现。例如，研究OAI（OpenAirInterface）的5G UE协议栈实现。虽然与商业实现差异大，但其代码结构、消息处理流程是相似的，可以用来理解漏洞模式并构建攻击样本。
2. 测试框架构建：
   • 编写一个简单的测试程序，链接协议栈库。
   • 实现一个模拟的“RRC消息注入器”，能够构造并发送二进制格式的RRC消息（如RRCReconfiguration）到协议栈的入口函数。
   • 协议栈运行在一个独立的线程或进程中，通过IPC接收消息。
3. 崩溃监控与调试：
   • 使用gdb附加到测试进程，设置catchpoint来捕捉SIGSEGV、SIGABRT等信号。
   • 使用AddressSanitizer (ASAN)或UndefinedBehaviorSanitizer (UBSAN)编译测试程序和协议栈库（如果可能）。这能极大帮助发现内存错误。
   • 记录完整的函数调用栈、寄存器状态以及触发崩溃的原始消息数据。

4.2 构造PoC（概念验证）攻击消息

基于前面的分析，我们可以尝试构造一个能触发崩溃的恶意RRCReconfiguration消息。这里以ASN.1 PER编码为例，描述其结构：

1. 消息头：设置messageType = c1 -> rrcReconfiguration。
2. 关键攻击载荷 -radioBearerConfig：
   • 确保该字段存在。
   • 在drb-ToAddModList中，放置一个或多个DRB-ToAddMod元素。
   • 针对第一个漏洞模式（数组越界）：设置drb-Identity = 0。根据规范，有效值是1-32，0是无效值。
   • 针对第二个漏洞模式（逻辑矛盾）：同时设置pdcp-Config为discardTimer = ms100（一个合法值），但将rlc-Config设置为ul-AM-RLC，却把sn-FieldLength设为size2（对于AM模式，通常需要size12或size18），制造一个协议栈可能未处理的矛盾配置。
   • 更复杂的组合：设置drb-Identity = 32（边界值），然后在其rlc-Config中嵌套一个深度异常或长度异常的子结构，考验解析器的递归深度或栈空间。
3. 编码与发送：使用asn1c生成的编码函数，将上述结构体编码成二进制串。通过测试框架的注入接口，将该二进制串发送给协议栈。

注意事项：商业协议栈通常有很强的鲁棒性，简单的无效值可能只会导致消息被静默丢弃并记录错误日志。要触发崩溃，可能需要找到多个验证缺失点的组合，或者利用验证逻辑本身的缺陷（比如先校验了范围，但在后续的某个分支又使用了未经验证的原始值）。这需要反复试验和动态调试。

5. 缓解措施、修复方案与深度防御

5.1 厂商层面的修复与补丁分析

根据漏洞描述，解决方案是“解决输入验证不当的问题”。对于厂商而言，这意味着需要在协议栈代码中增加严格的校验。修复可能涉及以下文件（以假设的代码结构为例）：

• src/rrc/rrc_reconfiguration_decoder.c：在解码函数中，对drb_Identity增加范围检查，并立即拒绝无效消息。
• src/rrc/rrc_config_validator.c：增加一个专门的配置验证模块，在应用任何配置之前，检查跨字段的逻辑一致性（例如，DRB配置与UE能力是否匹配，各层配置之间是否兼容）。
• src/pdcp/pdcp_entity_management.c和src/rlc/rlc_entity_management.c：在根据配置创建实体时，增加对配置参数的运行时断言（assert），在调试版本中及早发现问题。

一个健壮的修复不仅仅是打补丁，更应建立长效机制：

• 代码审计：对所有来自外部的消息处理函数进行人工或自动化审计，确保每个输入点都有验证。
• 模糊测试常态化：将针对RRC层的Fuzzing集成到CI/CD流水线中，持续发现潜在问题。
• 防御性编程：使用安全的内存操作函数（如memcpy_s），启用栈保护（-fstack-protector），将关键数据结构隔离到受保护的内存区域。

5.2 设备用户与企业的应对策略

对于使用可能受影响设备的个人用户和企业来说，等待厂商推送固件更新是主要手段，但也可以采取一些缓解措施：

1. 更新固件：密切关注设备制造商或芯片提供商（如Unisoc）的安全公告，及时应用基带固件更新。对于物联网设备，这可能需要通过OTA或返厂进行。
2. 网络层防护：在企业环境中，可以通过移动安全网关或具有信令过滤功能的防火墙，尝试检测和拦截异常的RRC信令流量。但这需要深厚的协议分析能力，且可能影响正常业务。
3. 物理与网络隔离：对重要的物联网设备，将其部署在受控的物理环境和专网中，减少暴露在公共蜂窝网络下的攻击面。
4. 监控与响应：建立设备异常行为监控，如频繁的调制解调器复位、异常的网络掉线。这些可能是正在遭受攻击的迹象。

5.3 对安全研究人员的启示

CVE-2025-61618再次凸显了嵌入式系统和通信协议安全的重要性。这类漏洞往往深藏在专有、闭源的固件中，挖掘门槛高，但一旦利用，影响广泛且难以防御。

• 研究方向：除了传统的二进制漏洞挖掘，可以更多关注协议状态机安全。思考如何通过发送一系列合法的消息，将协议栈引导至一个非预期的、脆弱的中间状态，再发送恶意消息触发漏洞。这种“逻辑漏洞”往往能绕过简单的输入校验。
• 工具链：熟练掌握针对ARM Cortex-R/M系列（常用于基带处理器）的逆向分析工具（如IDA Pro, Ghidra）和调试手段（如JTAG）。学习使用asn1c和相关的Fuzzing框架（如boofuzz针对协议Fuzzing）构建针对性的测试工具。
• 协作：与蜂窝网络领域的工程师交流，理解协议的实际实现细节和常见的“技术债”区域，这能极大提升漏洞挖掘的效率和精准度。

这个漏洞的分析过程，本质上是一次对复杂系统“信任边界”的审视。在万物互联的时代，那些默认为可信的通信链路和协议实现，正在成为攻击者眼中新的、富有吸引力的攻击面。