8月17日，一个名为 loongleakattack.com 的漏洞网站悄然上线。有名字、有logo、有专属域名——经历过2018年 Meltdown/Spectre 风暴的人，看到这个阵仗会立刻意识到：又出现了一个"品牌化漏洞"。只是这次的主角，换成了龙芯的 LoongArch 架构。
几乎同一时间，龙芯中科在官网发布《关于USENIX Security 2026会议论文中龙芯相关安全漏洞的说明》，确认部分型号的龙芯3号系列CPU存在侧信道数据泄露隐患，8月19日起被媒体集中报道。龙芯官网知乎上相关讨论迅速积累起两百多个赞同，评论区画风却出人意料：不少人不是在唱衰，而是在说"恭喜"。
这个漏洞到底是什么？严重吗？自己的机器受影响要不要慌？这篇文章一次说清。
LoongLeak 是个什么漏洞
论文发表在安全顶会 USENIX Security 2026 上，作者是德国 CISPA 亥姆霍兹信息安全中心的四名研究人员。漏洞被命名为 LoongLeak，本质是一类微架构数据泄露漏洞。
发现方法很"工科"：研究人员让同一段指令分别在真实龙芯芯片和 QEMU 模拟器上运行，再比对两边结果，哪里对不上，哪里就有问题。知乎
问题出在一条叫 FLD.S 的浮点加载指令上。LoongArch 手册对它的描述是"不确定"——寄存器的高位数据未定义，软件不要依赖它。这种写法在指令集手册里很常见，x86、ARM 手册里也有大量 UNPREDICTABLE、undefined 字样。但关键在于，"软件不该依赖"和"软件读不到"是两码事。
实测中，真实芯片吐出来的"不确定"值，其实是 L1 数据缓存里的残留旧数据。由于 L1 缓存在不同程序之间没有做隔离，任意程序就有可能读到其他程序甚至操作系统留下的数据。更厉害的是，攻击者还能主动塑造 CPU 内部状态，把泄露精确引导到特定的缓存集合。
论文给出的演示是完整攻击链：从内核中提取全盘 AES 加密密钥、在用户态获取部分 root 密码哈希、绕过 ASLR 和栈保护（stack canary）这两道经典防线，全部在数秒内完成。更麻烦的是，攻击可以从非特权用户态、容器甚至虚拟机内部发起，能跨越虚拟机边界，从客户机里泄露宿主机数据。知乎
时间线：这不是一场"突袭"
知乎上有这样的问题：国外机构单独给龙芯漏洞开网站，是不是针对？先把时间线摆出来，大家可以自行判断：
2025年7月23日，研究团队按负责任披露流程将漏洞报告给龙芯；
龙芯复现并确认问题，同时希望研究团队将细节保密一年，为分析和修复预留时间；
这一年里，龙芯完成根因定位和软硬件修复，并按国内法规向主管部门报备、申请了官方漏洞编号；
2026年8月，保密期结束，论文在 USENIX Security 2026 正式公开；
8月17日，龙芯中科在官网发布《关于USENIX Security 2026会议论文中龙芯相关安全漏洞的说明》，8月19日起被媒体集中报道。
这是一套完整的协调披露流程，不是零日突袭。至于给漏洞起名、配logo、开专属域名，其实是 2018 年 Meltdown/Spectre 之后安全学术圈的标准操作——当年的 meltdownattack.com 就是同款格式，连 logo 都标注了 CC0 授权。
值得一提的是，龙芯在说明里专门向 CISPA 团队致谢，还提到了"其他国内独立研究者"的专业挖掘——也就是说，盯上这个漏洞的不止境外研究者。龙芯官网
官方说"中低风险"，论文演示"秒级提密钥"，该信谁
两边放在一起看，其实说的是不同层面的事。
龙芯官方说明的要点：受影响的是龙芯3A5000/3A6000、3C5000/3C6000系列的部分版本。触发条件是应用调用 LSX/LASX 向量指令集或浮点指令集的加载指令时，同一物理核心上不同程序之间的微结构资源隔离不充分，可能泄露少量运行残留数据。官方定性为"中低风险"，属于微结构实现层面的问题，不是 LoongArch 指令集架构的设计缺陷。利用必须依托本机本地运行权限，无法远程攻击、无法跨设备攻击，也只能读取一级缓存中的随机残留数据，无法指定地址定向窃取。官方还对比了熔断、幽灵等经典侧信道漏洞，认为 LoongLeak 受空间和时间局部性约束更强，泄露数据难以识别、无法直接解析有效语义，实际危害低于同类漏洞。龙芯官网新版 3A6000、3C6000 及后续迭代芯片已完成微结构加固并经流片验证，龙芯其余全系芯片均不涉及。
论文一方演示的则是"能力上限"：在拥有本地执行权限的前提下，秒级完成窃取密钥等实际攻击。
两边有一个微妙的分歧：龙芯说明称已向操作系统合作厂商推送安全补丁，“可彻底消除该漏洞隐患”，且补丁对设备整体性能影响较小。龙芯官网而研究者和社区技术讨论普遍认为，架构层面的泄露在软件上只能缓解（比如内核缓存清空补丁、高敏感环境关闭 SMT），谈不上"彻底"。信哪边，取决于你对"彻底"这个词的标准。但有一点没有分歧：嵌入式、单用户终端等常规场景，官方明确说可以不进行专项处置。
受影响的用户，分场景该怎么办
个人桌面用户（3A5000/3A6000 个人机）：官方口径是单用户场景基本无影响，可不专项处置。利用需要本地权限，单人环境风险有限，日常留意所用发行版的安全更新即可；
多用户服务器、虚拟化与云环境（3C5000/3C6000）：这是最需要行动的场景。尽快通过操作系统厂商渠道安装官方补丁；高敏感多租户环境可以再评估是否临时关闭 SMT（类似超线程的多线程技术），代价是损失一部分性能；
涉密内网存量机：最棘手的一类。不少涉密机器从上线起就没打过补丁，靠物理隔离保安全，LoongLeak 对这类"永不更新"的部署模式是个考验，补丁落地要看信创运维体系的响应；
准备买新机的人：新版 3A6000、3C6000 已在硬件层面修复，采购时留意具体版本和批次说明。
Debian、Arch、openSUSE 等已支持 LoongArch 的 Linux 发行版，预计会跟进标准化的内核缓解补丁，可以留意自己所用发行版的安全公告。
为什么社区反而在说"恭喜"
知乎讨论区的氛围有点出人意料。
点赞第一的评论带着调侃：“说难听点，存量问题不大，大概率都在某个角落吃灰”，拿了38个赞。知乎但更多人是从另一个角度看的：
“我擦 好事啊 说明真的有人在用 在研究 龙芯也真的在进化 可喜可贺”——这条观点拿了11个赞；
“倒不如说发现有漏洞之后直接爆出来了也是好事，爆出来了至少龙芯知道了，反过来如果发现了还不说，而是借此作为一张攻击手段的底牌，那才要命呢。”——18个赞。
这不只是精神胜利法。看看先例：2023年，英特尔部分酷睿、至强处理器（Downfall）和 AMD Zen 2 架构（INCEPTION）都曾曝出微架构数据泄露漏洞，英特尔靠微码和固件更新缓解，AMD 靠微码和 BIOS 更新修复。对成熟的 CPU 架构来说，被安全研究者拿着显微镜挖出品牌化漏洞，几乎是"标配待遇"——这本身说明你的保有量够大、微架构值得研究。龙芯 3A6000 累计出货量刚刚突破100万片。知乎安全研究者的"关照"才刚刚开始。
技术讨论区还有一个视角值得记住：有人问"difftest（差分测试）🤔龙芯竟然没做过吗"，下面的回答是"UNPREDICTABLE本身就没法测吧"——未定义行为以谁为准来测？这个教训对所有指令集设计者通用：未定义行为到底是清零、固定值还是可能泄露历史数据，必须写清楚。
这件事给 LoongArch 留下了什么
短期看，是一次响应机制的考验。龙芯这次的处理——复现确认、一年内完成修复、披露前推送补丁、公开致谢研究者——流程上是及格的；真正要被检验的，是存量芯片补丁的落地速度。
中期看，是生态补课的窗口。一个背景是：8月20日的龙架构双周会上，社区照常推进——Linux 内核收到针对新 SMC 接口的 CPU 动态调频调压功能修复，Box64 转译层初步实现 16KiB 分页支持，安同 OS 开始推动 Core14 集成测试。哔哩哔哩PostgreSQL 官方仓库（PGDG）也把 loong64 加入官方支持，成为继 AMD64、ARM64、PPC64EL 之后第四个获此待遇的 CPU 架构。知乎上游生态的节奏，并没有被这次漏洞风波打断。
长期看，是信任的分水岭。龙芯芯片主要部署在党政、教育、医疗这类最不能容忍跨特权边界数据泄露的场景——北京市2025年终端设备集中带量采购项目中，龙芯路线产品以63%的市场份额胜出，在45个教育、医疗、交通出行等民生领域直属单位批量落地。中国经济网在这样的市场里，每一起安全事件都会被放大；但处理得透明，每一次也是"自主可控"的背书。
接下来值得盯几个信号：各发行版内核缓解补丁的推送进度、龙芯是否会为存量芯片提供明确的版本识别和升级路径。3B6600 桌面处理器明年预期可购，新微架构能不能从根上避开这类坑，是另一个看点。知乎
对一个出货刚破百万的架构来说，被挖出一个有名字、有logo、有专属网站的漏洞，不是死刑，是"成人礼"。真正决定 LoongArch 能走多远的，从来不是有没有漏洞，而是修漏洞的速度和透明度。
