这个 Linux 漏洞，嵌入式设备也别当没看见
这两天安全圈在聊一个 Linux 内核漏洞：Copy Fail，编号 CVE-2026-31431。
如果你平时只做 MCU 裸机，可能感觉这事离你有点远。但只要项目里有网关、工控机、边缘盒子、树莓派类设备、Ubuntu 开发机、Yocto/Buildroot 做出来的 rootfs，或者 CI 服务器上跑着 Linux，这事就不能完全当新闻看。
它不是那种“黑客远程一点就进来了”的漏洞。更准确地说，它是本地提权：攻击者已经能在系统里跑普通用户权限的程序，然后利用漏洞把自己变成 root。
听起来门槛高一点，但嵌入式现场里，“普通用户能跑代码”的情况其实不少。
比如售后开了 SSH 账号，产测脚本能执行命令，Web 后台有上传插件，容器里跑了第三方服务，甚至开发机上跑了别人给的调试脚本。只要这些入口管得不严，本地提权就会从“理论风险”变成“设备被接管”。
先说人话：Copy Fail 到底危险在哪？
Copy Fail 出在 Linux 内核的加密相关模块里，主要涉及 algif_aead、AF_ALG 和 splice() 这一串调用链。
你不需要记住这些名字。工程上只要记住三点：
第一，它影响的是内核，不是某个普通应用。
第二，它是本地提权，不是单独远程漏洞。
第三，公开 PoC 已经出现，所以防守窗口比较短。
CERT-EU 在 2026 年 4 月 30 日的安全公告里提到，这个漏洞影响很多使用 2017 年以来内核构建的主流 Linux 发行版，也提醒优先处理 Kubernetes 节点和 CI/CD runner 这类能跑不可信任务的机器。
这句话放到嵌入式项目里，就是：
别只盯线上服务器。
开发机、构建机、产测机、边缘网关，也要查。
嵌入式设备为什么容易“中招不自知”？
很多嵌入式 Linux 项目有个习惯：设备一旦量产，就很少动内核。
应用可以 OTA，配置可以远程改，业务逻辑可以灰度，但内核更新经常被往后排。原因也很现实：
内核一升级，驱动会不会挂？
4G 模块还能不能拨号？
CAN、RS485、GPIO、屏幕、摄像头还稳不稳？
客户现场能不能接受重启？
万一升级失败，谁去现场救？
这些担心都对。但问题是，安全漏洞不会因为你不好升级就不影响你。
尤其是那些跑通用 Linux 的设备，比如：
这些设备常常有本地服务、有脚本、有容器、有运维账号。一旦普通权限被拿到，内核本地提权就可能成为最后一脚。
今天先别慌，先查这几件事
第一步，看内核版本和模块是否存在：
uname -a
lsmod | grep algif_aead || true
modinfo algif_aead 2>/dev/null || true
这不能直接证明一定有漏洞，但能帮你快速判断系统是否暴露了相关模块。
第二步，看设备有没有这些入口：
ps aux | grep -E "sshd|dropbear|docker|containerd|podman|nginx|boa|lighttpd"
如果设备有 SSH、Web 后台、容器运行时、插件机制、脚本执行功能，就要更认真处理。
第三步，查你的内核来源：
- 是 Ubuntu/Debian/RHEL/SUSE 这类发行版内核？
这一点很重要。因为不同来源的内核，补丁路径完全不一样。
发行版内核可以等 vendor 更新。
Yocto/Buildroot 项目要看 kernel recipe 和 patch。
芯片厂 BSP 往往要自己确认补丁是否 backport。
临时缓解：不用 AF_ALG 的设备，可以先关掉
CERT-EU 和 Copy Fail 官方说明都提到，在打补丁前可以临时禁用 algif_aead 模块：
echo"install algif_aead /bin/false" | sudo tee /etc/modprobe.d/disable-algif.conf
sudo modprobe -r algif_aead 2>/dev/null || true
这招不是最终修复，但能先降低风险。
不过小站提醒一句：不要复制完就完事。你要先确认自己的业务有没有显式使用 AF_ALG。
大多数普通应用、SSH、OpenSSL 默认用法、LUKS/dm-crypt 通常不直接走这个用户态接口；但有些嵌入式项目会为了加速加密，把用户态程序接到内核 crypto API 或硬件加密路径上。这种项目就要测试。
可以先粗略看一下：
sudo lsof | grep AF_ALG || true
ss -xa | grep alg || true
如果产线设备不能随便操作，就先在同版本测试机上验证，别直接上客户现场。
真正的修复：还是补内核
临时禁模块只能挡一阵，不能替代内核补丁。
如果你用 Ubuntu、Debian、RHEL、SUSE、Amazon Linux 这类发行版，优先看厂商安全公告和内核包更新。
如果你用 Yocto，可以把这件事变成一个明确任务：
bitbake -e virtual/kernel | grep "^PV="
bitbake -e virtual/kernel | grep "^SRCREV="
确认内核版本和源码提交后，再检查是否包含修复提交或对应 backport。
如果你维护自己的 kernel patch 队列，建议把安全补丁单独归档，不要混在一堆驱动魔改里。否则半年后你自己都不知道哪个 patch 是修安全，哪个 patch 是为了点亮屏幕。
嵌入式项目最该补的不是一个补丁，而是一套流程
这类漏洞一出来，很多团队第一反应是：“有没有一条命令能修？”
有时候有，有时候没有。但真正拉开差距的是流程。
一个靠谱的嵌入式 Linux 项目，至少要能回答：
这几件事不性感，但非常要命。
因为安全事件来的时候，最怕的不是漏洞本身，而是团队连“哪些设备受影响”都说不清。
给一份排查清单
可以先按这个顺序来，不用一上来就开大会。
开发和测试环境：
uname -r
lsmod | grep algif_aead || true
构建系统：
grep -R "CONFIG_CRYPTO_USER_API_AEAD" ./build ./output ./tmp 2>/dev/null
Yocto 项目：
bitbake virtual/kernel -c menuconfig
检查：
CONFIG_CRYPTO_USER_API
CONFIG_CRYPTO_USER_API_AEAD
设备侧：
cat /proc/version
cat /proc/modules | grep algif_aead || true
上线前验证：
不要只验证“系统能启动”。嵌入式设备最怕启动是启动了，业务半死不活。
小站观点
Copy Fail 这件事，对嵌入式工程师最大的提醒不是“Linux 不安全”。
Linux 当然会有漏洞，RTOS 也会有漏洞，裸机代码一样会有坑。真正的问题是：你的设备有没有能力把补丁安全地送进去。
很多项目开发阶段很猛，板子点亮、外设跑通、功能验收都没问题。但到了量产后，内核版本、补丁记录、OTA 回滚、现场升级方案，全都靠人记。
这就很危险。
安全不是最后加一个防火墙，也不是写一页合规文档。对嵌入式来说，安全最终会落到很具体的事情上：
设备清单有没有？
版本号准不准？
补丁能不能打？
升级失败能不能回来？
现场工程师有没有操作手册？
这些做好了，漏洞来了才不会手忙脚乱。
今天你可以先做一件小事：找一台你们正在用的 Linux 设备，查一下内核版本和 algif_aead。不用急着下结论，先把家底摸清楚。
评论区也可以聊聊：你们项目里，内核升级最卡的地方是什么？是驱动兼容、客户现场、OTA 风险，还是根本没人敢动 BSP？
