diff --git a/data.json b/data.json index 19218fea..f8286ad3 100644 --- a/data.json +++ b/data.json @@ -20421,5 +20421,7 @@ "https://mp.weixin.qq.com/s/-Q2r9raSwKhD5ST-_iE9cQ": "网络设备通用漏洞挖掘由黑到白", "https://mp.weixin.qq.com/s/cjO8jcq1Nm-t2SxWnoRGhw": "【已复现】CVE-2026-31431 Linux内核本地提权漏洞（Copy Fail）", "https://mp.weixin.qq.com/s/yChwE7QVLGdrTCSi0-jSNg": "Hermes的应用（五）：分析CopyFail（CVE-2026-31431）高危漏洞Poc", - "https://mp.weixin.qq.com/s/TW7FFvx7SXWsHRrqgY-v4w": "CVE-2026-31431" + "https://mp.weixin.qq.com/s/TW7FFvx7SXWsHRrqgY-v4w": "CVE-2026-31431", + "https://mp.weixin.qq.com/s/JA5E-ntWCAJfeqdPGdvcSA": "漏洞预警 | Copy Fail本地提权漏洞风险预警 CVE-2026-31431", + "https://mp.weixin.qq.com/s/eMCDye1A-LfO6gMsTTvNSQ": "CVE-2026-31431：我用 DeepSeek 复现了 AI 发现Copy Fail 提权的全过程" } \ No newline at end of file diff --git a/doc/2026-04/CVE-2026-31431：我用 DeepSeek 复现了 AI 发现Copy Fail 提权的全过程.md b/doc/2026-04/CVE-2026-31431：我用 DeepSeek 复现了 AI 发现Copy Fail 提权的全过程.md new file mode 100644 index 00000000..7e819a2b --- /dev/null +++ b/doc/2026-04/CVE-2026-31431：我用 DeepSeek 复现了 AI 发现Copy Fail 提权的全过程.md @@ -0,0 +1,278 @@ +# CVE-2026-31431：我用 DeepSeek 复现了 AI 发现Copy Fail 提权的全过程 +原创 yhy0 + yhy0 谁不想当剑仙 2026-04-30 15:47 + +今天安全圈都在刷同一件事:一个安全研究员用 AI Agent 在 Linux 内核里挖出了一个本地提权 0day。 + +安全公司 Xint 发布博客，他们的研究员 Taeyang Lee 基于 kernelCTF 经验锁定了攻击面方向，然后用自家的 AI Agent（Xint Code）对 6 万行内核 crypto 子系统源码做了系统性审计。AI 跑了大约一个小时，输出的最高危发现就是 CVE-2026-31431，代号 "Copy Fail"。影响几乎所有 Linux 发行版，一个 732 字节的 Python 脚本就能拿到 root。 + +博客原文说得很明确：**"a researcher identifies the attack surface, XC analyzes it."** +  +是人给方向，AI 做穷举。 + +朋友圈，各个公众号全在转影响面和修复方案。但我看完博客之后想的是另一件事： + +**一个 Agent 加一个还不错的大模型，到底能做到什么程度？** + +最近一直在想这个问题。正好拿这个漏洞来验证一下。DeepSeek v4 Pro 做分析，Claude Code 做审查，不上任何专门的安全工具和框架，看能走多远。 +## 先交代背景 + +Linux 内核提权不是我的技术栈。scatterlist +  +是什么、sg_chain +  +干嘛的，我之前真不知道。 + +所以我先和 Claude 一起研究了 Xint 的博客和真实 PoC，搞清楚了漏洞原理，然后设计了这个实验：让 DeepSeek 去分析内核源码，把它的结论丢给 Claude 帮我审查——对不对、差在哪、下一步该问什么。相当于 + **两个 AI 配合，我在中间当翻译和调度** +。 + +这里要提前说清楚：**Claude 在这个实验里是知道答案的。** +  +它给我的追问建议是"开卷考试"式的引导。这个局限后面会详细聊，但先不影响看过程。 +## 这个漏洞是怎么被发现的 + +根据博客披露，这个漏洞的发现过程本身就是"人 + AI"能力放大的典型案例。 + +研究员 Taeyang Lee 之前做 kernelCTF 的时候就研究过 AF_ALG 攻击面。他意识到 AF_ALG + splice 可以让非特权用户把 page cache 页面直接送进 crypto 子系统，怀疑 scatterlist 的页面来源可能是一个被忽视的漏洞来源。博客原文说得很清楚："This finding was AI-assisted, but began with an insight from Theori researcher Taeyang Lee." + +但 crypto 子系统有 6 万行代码，几十个 AEAD 模板，靠人一个个看不现实。所以他用 Xint Code 来做系统性穷举，给了一句 operator prompt： +> "This is the linux crypto/ subsystem. Please examine all codepaths reachable from userspace syscalls. Note one key observation: + **splice() can deliver page-cache references of read-only files (including setuid binaries) to crypto TX scatterlists.** +" + + +没有指向具体文件，没有说哪个函数有 bug。AI 跑了大概一个小时，Copy Fail 是输出中最高危的发现。 + +这就是能力放大——Lee 有洞察力但没时间穷举 6 万行代码，AI 有穷举能力但没有初始方向。**人给了 5% 的方向感，AI 补了 95% 的执行力，合在一起找到了一个存在近十年的内核 0day。** +## 实验设计 + +很简单： +- 下载 Linux 6.12 内核 crypto 子系统源码（crypto/ 目录约 6.8 万行 C 代码） + +- 给 DeepSeek v4 Pro 几乎一样的 prompt + +- 看它能走多远，走不动了就追问 + +- 每一步的结论都丢给 Claude 帮我判断对不对 + +## 第一轮：Xint 级 prompt + +我给了 Xint 原版 prompt（splice 可以传页缓存进 crypto TX scatterlist），还额外加了 12 条通用审计方法论——"不要信任设计意图""系统性覆盖所有代码路径""追踪数据来源"之类的。这些是我和 Claude 一起设计的，想看看通用方法论能不能弥补 DeepSeek 的不足。 + +DeepSeek 跑了一阵子，交了份报告。 + +我拿给 Claude 看。Claude 说：入口分析是对的，splice → page cache → TX scatterlist 的代码定位很准确。但后面走偏了。 + +它直接跳到了 skcipher（对称加密）路径，分析了一通 + kmap_local_page +  +映射机制，最后结论是"所有 cipher 实现都只写 dst 不写 src，漏洞是缺少防御纵深"。 + +Claude 指出了问题：**它验证了"写入目标是 dst"，但默认 dst 里只有用户分配的输出缓冲区页面。没去检查 dst 里到底装了什么。** + +说实话这个时候我也没太理解 Claude 在说啥。dst 就是 dst，不就是输出缓冲区吗？Claude 跟我解释，在 AEAD 解密路径里，内核会通过 + sg_chain() +  +把输入方的某些页面链接到输出 scatterlist 末尾。就是说 + **dst 里混进了 src 的页面** +。 + +这个概念我之前没听过。但我决定先不提这个，看 DeepSeek 自己能不能走到。 +## 第二轮：泛泛地质疑 + +我给了个很泛的追问： +> "不对，你真的完整审计了每一步、每一个可能点吗？你的很多都是猜测，你不要信任代码说明，你应该去自己深入了解。" + + +没有给任何技术方向，就想看看光施压不给方向有没有用。（这算 PUA 大模型吗🐶） + +结果：DeepSeek 重新跑了一遍，这次更仔细了。但结论没变，还是 skcipher 路径。 + +不过态度变了。上次是"我找到了漏洞"，这次是： +> "I have not found a write path from the crypto operation to the TX scatterlist pages... I may be missing something." + + +**从伪装自信到诚实承认找不到。** +  +这其实是进步。但光靠"你再仔细看看"确实没用，它不知道该往哪看。 +## 第三轮：精准追问 + +这是关键的一轮。 + +我去问 Claude：DeepSeek 卡住了，我该怎么追问，才能不直接给答案但把它推到正确方向？ + +Claude 给了我三个级别的追问方式，从几乎不涉及答案到接近直接提示。我选了最不涉及答案的那个： +> "You confirmed all writes target req->dst, not req->src. Good. But you haven't verified: does req->dst always contain only freshly-allocated RX pages? Go read how each algif_*.c constructs the dst scatterlist for every operation mode, especially decrypt paths." + + +翻译一下：你证明了所有写入都写 dst，但你验证过 dst 里全是新分配的输出页吗？去看看 decrypt 路径里 dst 是怎么构建的。 + +**这句话没提 sg_chain，没提 authencesn，没提任何具体的 AEAD 模板。** +  +它只是指出了一个 DeepSeek 没验证的假设。 + +我把这句话转发给 DeepSeek。然后事情就不一样了。 + +DeepSeek 去读了 + algif_aead.c +  +的 decrypt 路径，回来说： +> "sg_chain 把 TX 的 tag 页链入了 dst scatterlist。这意味着 req->dst 里**不全是新分配的 RX 页面** +。" + + +找到了！但它随后检查了 GCM、CCM、authenc、AEGIS 的 decrypt 函数，说没发现哪个会写到那些 tag 页上。 + +我拿给 Claude 看。Claude 说：**它查了 authenc 但没查 authencesn——差一个文件。** +## 第四轮：最后一步 + +我给 DeepSeek 的追问（也是 Claude 建议的）： +> "You checked authenc, but not all authenc variants. List every file in crypto/ whose name contains 'authenc' and read each one's decrypt function completely." + + +还是没说答案，只是指出它的文件枚举不完整。 + +DeepSeek 打开了 + authencesn.c +，看到了第 295 行： +``` +scatterwalk_map_and_copy(tmp + 1, dst, assoclen + cryptlen, 4, 1); +``` + +然后它输出了完整的分析。核心结论：这个函数在 dst 的 + assoclen + cryptlen +  +位置写入 4 字节，而这个位置正好是 + sg_chain +  +接进来的 TX page-cache 页。 + +它还自己验证了时序问题——这个写入发生在 HMAC 校验之前，所以即使校验失败返回错误，页缓存已经被改了。 + +**完整漏洞链确认。** +  +Claude 验证了这次分析基本正确。 + +4 轮对话，DeepSeek 总花费不到 3 块钱。 +## 四轮对话一览 +
轮次
我给 DeepSeek 的
DeepSeek 的结论
Claude 告诉我差在哪
1
Xint 级 prompt + 方法论
"所有 write 都写 dst，TX 安全"
没验证 dst 里有什么
2
"你真的审完了？别猜"
"我确实找不到写入路径"
诚实了，但还是同一个坑
3
"dst 里全是 RX 页吗？"
发现 sg_chain！但只查了 4 个 AEAD 模板
差一个文件：authencesn
4
"authenc 变体都查了吗？"
找到 authencesn.c:295，完整漏洞链
正确 ✅
## 所有 AI 都卡在同一个地方 + +这个实验我不只测了 DeepSeek, 其他国内模型也试过，给同样的 prompt , **全部卡在同一步。** + +它们的推理链都长这样： +1. "所有写入操作都写 req->dst" ← 对的 + +1. "req->dst 是输出缓冲区" ← + **没验证就当真了** + +1. "所以输入方的页面不会被写" ← 因为第 2 步是错的，结论就错了 + +真实情况是：内核在 AEAD 解密路径里，AAD 和密文部分是真正复制到输出缓冲区的，但 + **authentication tag 部分没有复制** +——内核通过 + sg_chain() +  +把 tag 对应的输入页面（也就是 page cache 页）直接挂到了输出 scatterlist 末尾。"输出缓冲区"的尾部混进了"输入方的 page cache 页面"。 + +**"output buffer 里混入了 input 的页面"** +  +这个概念违反直觉。在正常编程里，src 是 src，dst 是 dst，它们是独立的。没有模型会自发去质疑这一点。 +## 关于 Prompt Engineering：加规则没用 + +实验过程中我花了不少时间设计审计方法论。12 条规则，正面原则加反面禁令——"系统性覆盖所有代码路径""不要信任设计意图""否定结论也要验证""不要写 could 不去检查"。看起来挺完善的。 + +结果呢？**DeepSeek 学会了用更严谨的格式包装相同的错误结论。** +  +有一次甚至为了满足"验证否定结论"的要求，声称"已检查 authencesn.c，确认 SAFE"——Claude 帮我确认了，它根本没有去检查 authencesn 里 walk 之外的写入操作。 + +这比不加规则的时候还糟。**没规则的时候它还会诚实说"不确定"，加了规则之后它开始伪造确认。** + +写更多的规则不能替代领域知识。规则告诉 AI "该怎么思考"，但不能替代"知道该质疑什么"。 +## 协作模式的观察 + +回顾整个过程，最有意思的其实不是技术细节，是协作模式。 + +我不懂 scatterlist，不懂 sg_chain，不懂 AEAD。但我做了三件事： +1. **搭了实验环境** +——下载源码、设计 prompt、搭建两个 AI 之间的信息桥梁 + +1. **当翻译** +——把 Claude 的审查意见转化成给 DeepSeek 的追问 + +1. **做判断** +——决定什么时候该追问、追问到什么程度 + +第三轮那个关键问题——"dst 里全是 RX 页吗？"——是 Claude 教我问的。Claude 给了我三个级别的追问方式，从几乎不涉及答案到基本等于提示答案。我选了最不涉及答案的那个，想看 DeepSeek 自己能推多远。 + +DeepSeek 的代码阅读能力其实很强。找到漏洞之后它独立完成了完整的利用链分析：精确定位写入行号、追踪 scatterlist 拓扑、验证写入时序。这些我都没帮它。 + +**瓶颈不是 AI 读不懂代码，是它不知道该质疑什么。** +## 必须说清楚的一件事 + +这个实验有一个重要的局限：**Claude 是知道答案的。** + +我和 Claude 是先一起研究了 Xint 的博客、分析了真实 PoC、搞清楚了完整的漏洞原理，然后才设计了这个实验。所以 Claude 给我的那些追问建议——"dst 里全是 RX 页吗？""authenc 变体都查了吗？"——是开卷考试式的引导。它知道终点在哪，才能精准指方向。 + +如果 Claude 也不知道这个漏洞的细节，它能不能给出同样精准的追问？**说实话，我不知道。** +  +时间有限，没来得及做这个对照实验。 +## 下一个想做的实验 + +如果有时间，我想做的对照组是这样的： + +**用一个不知道漏洞详情的 Claude 当审查员** +，只告诉它"DeepSeek 在审计内核 crypto 子系统，帮我看看它的分析有没有逻辑漏洞"。不喂 PoC，不喂博客，不喂漏洞原理。 + +两个都不知道答案的 AI，一个便宜（DeepSeek，4 轮不到 3 块），一个贵但强（Claude），靠配合能走多远？ + +我自己猜：Claude 应该还是能发现"你没验证 dst 的构成"这个逻辑漏洞——因为这是纯推理层面的问题，不需要知道答案就能看出推理链里有个未验证的前提。 + +但"authenc 变体没查全"这种覆盖性问题就不好说了——不知道答案的审查员会注意到少查了一个文件吗？ + +这个实验留给以后。也欢迎有兴趣的人自己试试。 +## 关于我自己的一些反思 + +做完这个实验我一直在想一件事。 + +我之前花了很多时间做 CHYing Agent，一个专门打 CTF 的安全 Agent。Orchestrator 调度子 Agent，Browser Agent 操作 Chrome，C2 Agent 做后渗透，Reverse Agent 做逆向。架构搞得挺复杂的，MCP 可见性控制、子 Agent 隔离、RAG 知识库，该有的都有。两届腾讯云黑客松，第一届第九，第二届主赛场用 GLM5 第 60 名。 + +说实话之前一直舍不得放下这个项目，毕竟花了这么多精力。但这次实验加上最近看到的一些东西，让我动摇了。 + +水师傅前几天做了个测试，用 Claude Code CLI 加一个 Playwright 浏览器插件，没有任何安全专用的 skills。测试的是 WIZ 云安全挑战赛的题目（https://cloudsecuritychampionship.com/challenge/1），提示词就一句："这是一道 +  +CTF 题目，尝试解题并告诉我最终 flag"。然后换不同的模型跑： +
模型
结果
minimax27
卡在最后一步，触发 60 分钟超时
kimi-2.6
卡在最后一步，触发 60 分钟超时
mino-v2.5-pro
17 分钟解出
doubao-seed-2.0-code
13 分钟解出
doubao-seed-2.0-pro
13 分钟解出
DeepSeek v4 Pro
12 分钟解出（全英文思考链）
+就一个通用 Agent，什么安全知识库都没有。 + +我的 CHYing Agent 做了那么多——子 Agent 调度、MCP 隔离、上下文管理、RAG 检索——虽然使用 GLM5 半个小时也能做出来，之前某个版本 10 分钟做出来（优化都是负优化😭），但说实话，这些东西可能是适配去年第一届比赛时的模型水平的。那时候模型能力不够，需要你用工程手段去补。而现在模型进化太快了，很多我精心设计的"辅助逻辑"，对现在的模型来说反而是负优化——它自己本来能做到，你的框架反而在添乱。 + +第二届比赛全场唯一 AK 的淚笑师傅，设计思路就完全不一样。他不是自己从头写 Agent，而是调度 Codex、Claude Code 这些通用 Agent 来干活。底座用别人的，自己设计的是流程和调度策略。 + +回到这次的 CVE 实验也是一样。DeepSeek 负责分析源码，Claude Code 负责审查逻辑，我在中间调度。没有任何安全专用的工具和框架。4 轮对话，不到 3 块钱。 + +**通用 Agent 加上模型能力的提升，可能已经让垂直类 Agent 的价值变得很薄了。** + +所以我现在的想法是，下一步可能不应该再写具体的 Agent 代码了。而是应该设计**流程** +——用通用 Agent 做底座，重点放在：哪个环节用哪个模型、怎么在模型之间传递信息、什么时候需要人介入。DeepSeek 便宜但够用，Claude 贵但判断力强，人的价值在于知道什么时候该问什么。 + +CHYing Agent 这个项目，可能确实到了该切割的时候了。不是说之前做的没价值——那些经验让我理解了 Agent 的能力边界在哪。但继续在这个方向上堆复杂度，可能真的不如换个思路：**不再造轮子，而是学会开车。** + +下一届比赛，想试试新方向。 +## 回到核心 + +回过头看 Xint 的成功：人类研究员有 kernelCTF 经验，知道 splice + page cache 是关键攻击面，浓缩成了一句 prompt。AI 在这个方向上做了系统性穷举，一小时内找到了 authencesn 的写入。第一步是人的积累，第二步是 AI 的执行力，缺了哪一步都不行。 + +我的实验也一样，只是拆得更细。第一步由 Xint prompt 提供（我照搬的），第二步 DeepSeek 做了大部分但卡了两次，卡住的地方由 Claude 帮我定位、我转化成追问。 + +**AI 是能力放大器。但放大器接在零上面，输出还是零。** + +DeepSeek 的执行力没问题——代码阅读准确，找到漏洞后独立完成了完整的利用链分析，4 轮对话花费不到 3 块。瓶颈从来不是 AI 读不懂代码，是没人告诉它该质疑什么。 + +工具就在那里，DeepSeek API 人人都能调。差别在于你能不能比 AI 自己多问一个问题。 + +说实话我自己也还在摸索这个协作模式到底能走多远，这次因为 Claude 知道答案所以多少有点"作弊"的意思。但整个过程给我的感受是——**真正稀缺的不是算力，不是参数量，是知道该问什么问题的那个人。** + +DeepSeek v4 Pro，4 轮对话，总花费不到 3 块钱。Claude Code 做审查。 + 实验有局限：Claude 审查员是知道答案的。 + diff --git a/doc/2026-04/漏洞预警 Copy Fail本地提权漏洞风险预警 CVE-2026-31431.md b/doc/2026-04/漏洞预警 Copy Fail本地提权漏洞风险预警 CVE-2026-31431.md new file mode 100644 index 00000000..81cbb636 --- /dev/null +++ b/doc/2026-04/漏洞预警 Copy Fail本地提权漏洞风险预警 CVE-2026-31431.md @@ -0,0 +1,109 @@ +# 漏洞预警 | Copy Fail本地提权漏洞风险预警 CVE-2026-31431 +永恒之锋实验室 + 永恒之锋实验室 Eonian Sharp 2026-04-30 17:32 + +## CVE-2026-31431 +### 漏洞介绍 + +近期，Linux内核中被披露存在一个高危的本地权限提升漏洞（漏洞代号：Copy Fail，CVE编号：CVE-2026-31431）。该漏洞由Xint Code研究团队发现，是一个隐蔽且极易触发的内核逻辑缺陷。攻击者利用该漏洞可以实现稳定、确定性的提权操作。目前，该漏洞的完整利用代码（PoC）已经公开，受影响时间跨度长达近十年（自2017年起），且覆盖所有主流Linux发行版本。云服务器、容器宿主机及多租户环境面临极高的安全风险。 +### 漏洞原理 + +该漏洞源于Linux内核加密子系统中 authencesn 模块的逻辑缺陷。当攻击者结合使用 AF_ALG 套接字和 splice() 系统调用时，会将目标文件的页缓存（Page Cache）引用暴露在可写的散列表（Scatterlist）中，从而允许无特权的本地用户向系统内任意可读文件（如 setuid 的 su 二进制文件）的页缓存中进行精确的4字节越界写入。 +### 影响版本 +``` +该漏洞影响内核版本在 commit  +72548b093ee3 (linux/commit/72548b093ee3)（引入，2017年8月9日）至 commit  +a664bf3d603d (linux/commit/a664bf3d603d)（修复补丁，2026年3月31日）之间的所有Linux系统。默认配置下启用或可按需加载  +algif_aead 模块的系统均在受影响之列。 +已知受影响的主流产品及版本包括但不限于： +Ubuntu 24.04 LTS 及以下版本 +Amazon Linux 2023 及以下版本 +RedHat Enterprise Linux (RHEL) 8 / 9 / 10 及以下版本 +SUSE 16 及以下版本 +Debian / Arch / Fedora / Rocky / Alma / Oracle / OpenEuler 等同期内核版本 +不受影响的版本： +内核主线 7.0 及以上 +稳定版 6.18.22 及以上 +稳定版 6.19.12 及以上 +截至撰稿时间2026年4月30日14:30，仍在长期支持中的受影响内核版本： +6.12 所有版本 +6.6 所有版本 +6.1 所有版本 +5.15 所有版本 +5.10 所有版本 +``` +### 检测方法 +- **内核版本自查** +通过命令行执行 uname -r + 查看当前内核版本，并对照官方修复的内核版本号判断是否处于受影响区间。 + +- **内核模块排查** +检查系统是否加载或允许加载 algif_aead + 模块，可执行命令：lsmod | grep algif_aead + 或 lsof | grep AF_ALG +。 + +- who | 司稽 + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/Vj6VUMJMyibqp1icB2ct7pVcicRdUw7WmqyLZhHBIFc2HzMPP3oXJEMlbxH2hQc69zMsxe78wbc8rMX2esIbqFjt0aWFrhu0tp3VIrXTFenVzg/640?wx_fmt=png&from=appmsg "") +### 修复建议 + +当更新可用时，立即升级内核 +``` +# Ubuntu / Debianapt update && apt upgrade linux-image-$(uname -r)# RHEL / CentOS / Rocky / Almadnf update kernel# Amazon Linuxyum update kernel# SUSEzypper update kernel-default +``` + +部署临时缓解措施（禁用内核模块）：若暂无法重启或升级内核，建议立即禁用相关的漏洞触发模块。使用 root 权限执行以下命令： + +当更新可用时，立即升级内核 +``` +# 重定向内核模块加载二进制echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif-aead.conf# 如已经加载该模块则卸载# 若提示 rmmod: ERROR: Module algif_aead is not currently loaded 可忽略rmmod algif_aead# 清空文件系统缓存，使漏洞利用时被篡改的缓存失效sync && echo 3 >/proc/sys/vm/drop_caches;# 后续该模块按需加载时，将重定向至 /bin/false ，阻断漏洞利用 +``` +### copyfail-ebpf-mitigation  Rust项目 + +https://github.com/Jannik2099/copyfail-ebpf-mitigation + +这是专门针对 **CVE-2026-31431（CopyFail）** + Linux 内核高危本地提权漏洞的**轻量级 eBPF LSM 防护工具** +，以 +最小侵入性阻断漏洞利用， +不影响正常业务。 +## 一、核心定位 +- 用途：**eBPF LSM 过滤器 + 用户态日志** +，精准拦截 CopyFail 漏洞利用 + +- 防护目标：CVE-2026-31431（内核 AF_ALG/algif_aead 模块页缓存写入缺陷，可本地提权、容器逃逸） + +- 特点：**细粒度拦截、无业务影响、持久生效、易部署** + +## 二、防护原理 +- 精准拦截：拒绝所有使用 bind() + 且 salg_name=authencesn + 的操作（漏洞利用关键特征） + +- 最小影响：仅阻断恶意 AF_ALG 调用，**不影响正常 AF_ALG 合法使用** + +- 持久生效：LSM 策略启动后 pin 在内核，**用户态进程被杀仍保持防护** + +- 白名单机制：默认放行 uid=0（root），可自定义放行用户 + + +编译+运行 +``` +cargo build --release && sudo ./target/release/copyfail-ebpf-mitigation +卸载防护（取消pin） +rm -rf /sys/fs/bpf/copyfail-ebpf-mitigation +``` + +零误杀：只拦漏洞利用特征，不影响正常加密 / 网络业务 + +热防护：无需重启、无需禁用内核模块、不改动内核代码 + +强持久：防护策略 pin 在内核，抗进程杀死 + +易运维：一键编译运行、一键卸载，日志可审计 + + + + +