Page Cache 与 AF_ALG#

Linux 在读取磁盘文件时，并不每次都去访问磁盘，而是先到 Page Cache 里寻找是否有缓存：找到就直接使用缓存数据，没找到再去访问磁盘。

但 Page Cache 是多个进程共享的，如果有人能修改它，所有进程都会看到修改后的内容。

然后我们需要去了解AF_ALG接口，也就是User Space Crypto API，用户态程序可以直接调用内核加密算法。

比如

1
socket(AF_ALG)

1
User
2
 ↓
3
AF_ALG Socket
4
 ↓
5
Crypto Subsystem
6
 ↓
7
Kernel

当调用 authencesn 算法时，copy_fail 漏洞就出现了。

AEAD 与 authencesn#

AEAD即Authenticated Encryption with Associated Data，带关联数据的认证加密，是一种同时提供数据加密、完整性验证和身份认证的加密模式。

AEAD不仅对数据进行加密以保证保密性，还通过认证机制确保数据在传输或存储过程中未被篡改，同时验证密钥和数据的正确性。

简单来说就是把密文和不加密但要认证的数据同时参与认证。aad就是表示需要认证但是不需要加密的附加数据。比如tls里面的记录头信息。

AEAD算法比如aes-gcm,

1
AEAD(
2
   key,
3
   nonce,
4
   plaintext,
5
   aad
6
)
7
=
8
(ciphertext, tag)

而Authencesn全称是： Authenticated Encryption with Associated Data and Extended Sequence Numbers，具有关联数据和扩展序列号的认证加密。主要是给IPsec ESP使用的。普通的aead是aad、payload参与认证，authencesn则是aad,payload,sequence number参与认证。这样攻击者即使复制了整个包，也会因为sequence number的不同而过不了认证。

copy_fail 漏洞与 authencesn 的处理有关：研究人员发现，authencesn 在处理时会重新组织内存布局并交给 copy_from_iter()，而用户空间可以通过 AF_ALG 接口调用 authencesn 并完全控制 aad 的内容。authencesn 并没有对 aad 进行完整校验，导致 Page Cache 的内容被 authencesn 修改。

splice 与 ESN Scratch Write#

splice() 是 Linux 提供的零拷贝数据传输机制。在支持的场景下，它不会复制实际数据，而是让 pipe_buffer 直接引用已有的内核页（例如文件的 page cache 页），从而减少内存拷贝开销。

在 file→pipe 的 splice 路径中，pipe_buffer 通常不会保存文件内容的副本，而是持有对应 page cache 页的引用。因此后续内核组件如果错误地将这些页当作可修改的临时缓冲区，就可能直接修改底层 page cache，而不仅仅是修改 pipe 中的数据。

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

引用自参考博客

我们还需要理解 IPsec ESP 协议中 ESN（Extended Sequence Number）机制 。

ESP 协议最初只有一个 32 位序列号。发送一个数据包，序列号就加一。

但 32 位最多只能表示约 42 亿个包。在高速网络环境下，这个数字并没有想象中那么大。如果序列号最终重新回到 0，就可能出现重放攻击问题，因为旧的数据包又拥有了相同的序列号。

因此 IPsec 引入了 ESN（Extended Sequence Number）。

ESN 实际上把序列号扩展成了 64 位，其中：

• 低 32 位仍然放在网络数据包中传输；
• 高 32 位由通信双方在本地维护。

这样序列号几乎不可能发生回绕。

ESP 的认证机制需要计算 HMAC。

如果 HMAC 只覆盖低 32 位序列号，那么当序列号从 0x00000000FFFFFFFF 增加到 0x00000001FFFFFFFF 时，网络上传输的低 32 位仍然都是 0xFFFFFFFF

这样两个不同的数据包可能得到相同的认证输入。

因此 RFC 要求：认证计算必须包含完整的 64 位序列号。也就是说，高 32 位虽然没有发送出去，但仍然必须参与 HMAC 运算。

Linux 原来的 authenc 框架是在 ESN 出现之前设计的。它默认认为参与认证的数据只有：

• SPI
• 低 32 位序列号
• 数据负载

它并不知道还有一个“高 32 位”。但协议要求高 32 位必须参与认证，因此 authencesn 就必须想办法把这 4 个字节塞进认证计算的数据流中。

在 ESP 输出数据包时，数据包尾部通常会预留一块空间，用于存放最终计算出来的认证标签（auth tag）。

而在 HMAC 尚未计算完成之前，这块空间实际上还是空的。开发人员发现，既然这里反正暂时没有内容，不如先借用这块空间。于是 authencesn 会把 ESN 的高 32 位临时写到这块区域中。这样 HMAC 在遍历整个缓冲区时，就能够看到完整的 64 位序列号。

因此：

1. 把高 32 位写进去；
2. 执行 HMAC；
3. HMAC 计算完成；
4. 再把真正的 auth tag 写回去。

从最终网络数据包来看，这 4 个字节从来不会真正发送出去，它只是一个临时工作区。这就是所谓的：ESN scratch write（ESN 临时写入）。

正常情况下，整个过程是：

首先，高 32 位被写入认证标签的位置。随后加密和认证过程成功执行。最后，真正计算出来的 auth tag 会覆盖掉这 4 个字节。

因此最终数据包中只会留下：

• payload
• auth tag

临时写入的数据已经消失。

所以很多年里，这种设计一直都正常工作。

直到 copy_fail 的发现：

开发者默认认为，后续步骤一定会成功。但是实际上，加密或者认证操作可能失败。

例如：

• 内存分配失败；
• 加密请求失败；
• 异步操作失败；
• 驱动返回错误。

如果错误发生在高 32 位已经写入之后，而真正的 auth tag 还没有写回之前，那么流程会提前退出。这样就出现了一个问题：那 4 个字节仍然残留在 dst buffer 中。原本只是临时工作区的数据，没有被恢复。

因此：

• 缓冲区内容变得异常；
• 某些内核数据可能泄漏；
• 后续代码可能读取到错误的数据；
• 用户空间可能观察到不应该看到的内容。

这就是 Copy Fail 的本质。

漏洞的出现#

前面已经提到了一些漏洞的背景原理，现在具体到copy fail漏洞是怎么发生的。

漏洞的引入要追溯到 2017 年。

在 2017 年之前，algif_aead 的解密采用的是 out-of-place 解密模式。

所谓 out-of-place，就是：

• 输入缓冲区（src）和输出缓冲区（dst）不是同一个。
• 解密后的数据写入另外一块内存。

当时的代码逻辑是：

• TX SGL（发送缓冲区）作为输入。
• RX SGL（接收缓冲区）作为输出。

TX SGL 里面保存了用户发送进来的全部数据：

• AAD
• 密文
• Auth Tag

而 RX SGL 是用户调用 recvmsg() 时提供的接收缓冲区。

1
解密前：
2
TX：
3
[AAD][密文][TAG]
4

5
RX：
6
[空]
7

8
解密后：
9

10
RX：
11
[？？][明文]

这里的问题在于：AEAD 算法本身只负责处理密文。它不会主动去处理 AAD。

AEAD 的工作流程实际上是：

• AAD：参与认证，但不加密。
• 密文：参与认证，并且需要解密。
• Tag：用于验证完整性。

因此解密结束以后：密文部分变成明文，AAD 理论上应原样保留。

但是底层加密算法只会操作密文区域。

然而对 algif_aead 而言：AAD 在 src 中，dst 中对应位置是空的。

于是解密完成以后：

1
dst:
2

3
[AAD区域] [明文]

前面的 AAD 区域没人填。

结果用户收到的数据变成：

1
0000000000000000 + plaintext

AAD 全是 0——这违反了 AEAD 接口的语义。

内核开发者 Stephan Mueller 提交的 commit 72548b093ee3 就是专门解决这个问题的。

开发者的思路非常简单：既然算法不会复制 AAD，那么调用者自己复制： 先把 AAD 和密文复制到 RX， 然后算法直接在RX上解密。

于是新增了一步：

1
src ----copy----> dst
2
      AAD区域

这样：

• AAD 被提前写入 dst。
• 解密时算法只处理密文。
• 最终用户收到：

1
AAD + plaintext

这才符合 AEAD API 的要求。

因此这个补丁本身其实是完全正确的。

但是这样修复之后，解密收到的是

1
RX：
2
[AAD][明文]

AEAD 算法还需要验证 Tag，开发者采用了直接引用的方法：

1
RX：
2
[AAD][密文]
3
         ↓
4
       TAG页面

也就是 sg_chain()。

这里没有复制 Tag，而是在 scatterlist 后面再挂一个节点。

这为漏洞的出现提供了机会。

在 Linux 内核中，为了追求极致的性能，用户经常会使用 splice() 或 sendfile() 系统调用。这些调用的核心优化就是零拷贝（Zero-Copy）。

当用户通过 splice() 将一个文件中的数据发送到 algif_aead 的 Socket 时，内核为了省去将数据从内核复制到用户空间的开销，会直接把该文件在 Page Cache（页面缓存）中的物理页面（Pages）拿过来，作为 TX SGL 的内存流。

这意味着：

• 此时 TX SGL 里的 AAD、密文等数据，在物理上就是 Page Cache 里的页面。
• 这些页面是由内核的管理机制（如文件系统、块设备层）锁定的，通常是只读的。

但是漏洞单靠 splice 还不够，攻击者还需要利用一个网络编程中常见的标志：MSG_MORE。

当调用 sendmsg() 或 splice() 时如果带了 MSG_MORE，意思是：“我后面还有数据要发，你先别急着提交给硬件/加密算法，先在内核里攒着。”

此时，algif_aead 会把当前的 TX SGL（来自于 Page Cache 的页面）暂存到内核的 Socket 缓冲区中（即 ctx->tsgl）。

漏洞的触发还需要 copy_from_iter 参与。

用户接下来调用 recvmsg() 尝试去解密并接收数据。

正如我们前面分析的，commit 72548b093ee3 引入了一个修复操作：在解密前，必须先把 AAD 区域从 src（TX SGL）复制到 dst（RX SGL）。

内核在执行这个复制时，使用的是底层内存拷贝函数（如 copy_from_iter 或 memcpy_from_page）。 它的意图是：从 TX SGL（源）读取 AAD，写入 RX SGL（目的）。

但是，如果攻击者故意进行恶意构造，让 RX SGL 的接收缓冲区，“正好”也指向刚才那个 Page Cache 页面呢？（或者由于并发、重用等原因导致了页面的重叠）。

更严重的是，即使没有完全重叠，根据前面讲的 sg_chain() 逻辑： 解密时，算法需要验证 Tag。为了效率，内核直接用 sg_chain() 把 TX 的 Tag 页面挂到了 RX SGL 的尾部。

此时的 RX SGL 变成了这样一个“缝合怪”：

1
RX SGL: [ 用户Rx缓冲区 ] -> [ 链表指针 ] -> [ 来自TX的Tag页面 (实质是Page Cache) ]

如果此时调用发生错误，或者在复杂的并发套接字操作中，内核在执行：

1
// 伪代码：本意是将数据拷入RX，但RX的某个节点（比如Tag）其实指向了Page Cache
2
crypto_aead_copy_aad(...);

由于对输入/输出边界缺乏严格的检查，内核在复制（Copy）时如果发生失败（Fail）——这正是 copy_fail 名字的由来：

1. 内核尝试向 RX SGL 写入 AAD 或者是解密后的明文。
2. 结果由于某些页面的共享或重用，这个写入目标错误地指向了尾部挂载的那个属于 Page Cache 的只读页面。
3. copy_from_iter 这种函数在向一个“只读”的 Page Cache 页面强制写入数据时（内核态有最高权限，可以绕过写保护），直接污染了（Dirtied）系统全局的 Page Cache！

copy_fail 的闭环：

1. Page Cache 提供舞台：用户用 splice 发送文件，导致加密算法的输入源（TX）直接引用了内核的 Page Cache（页面缓存）。
2. Commit 72548b093ee3 引入工具：为了修复 AAD 为 0 的问题，引入了“主动 Copy AAD 到 RX”以及“用 sg_chain 将 Tag 页面直接挂到 RX 尾部”的逻辑。这导致 RX SGL 间接持有了 Page Cache 页面的写权限。
3. Copy Fail 瞬间引爆：在解密、复制的异常处理路径中（Fail 路径），内核未能正确校验边界，导致原本应该写到用户缓冲区的明文或 AAD，直接覆盖写进了 Page Cache 页面。

由于 Page Cache 是全局共享的，一旦它被污染，当其他正常进程（甚至系统核心服务）再次读取该文件时，读到的就是被篡改后的数据。这就完成了从一个“加密 API 语义修复”到“任意文件覆盖 / 本地提权（LPE）”的漏洞演变。

Step 1：用户空间精心构造并发送数据#

在用户空间，攻击者需要通过配置特殊的解密参数，分两步欺骗内核：

• assoclen = 8：通过 sendmsg 的控制消息设置 AAD 长度为 8 字节。
• authsize = 4：通过 setsockopt(ALG_SET_AEAD_AUTHSIZE) 设置认证标签大小为 4 字节。

随后，通过两条路径向 AF_ALG 套接字注入数据：

1
# 1. 构造恶意 4 字节载荷（最终要写入 Page Cache 的数据）
2
evil_bytes = b'\xde\xad\xbe\xef'
3

4
# AAD 前 4 字节任意填充，后 4 字节为 payload
5
aad = b'\x00\x00\x00\x00' + evil_bytes
6
op.sendmsg([aad], cmsg, MSG_MORE)       # 使用 MSG_MORE 标志让内核暂存
7

8
# 2. 通过 splice() 引入目标文件的 Page Cache
9
pipe_r, pipe_w = os.pipe()
10
target_fd = os.open("/usr/bin/su", os.O_RDONLY) # 仅需只读权限！
11
os.splice(target_fd, pipe_w, t + 4, offset_src=0)  # 文件 → 管道 (长度 t + 4)
12
os.splice(pipe_r, op.fileno(), t + 4)               # 管道 → AF_ALG 套接字

Step 2：TX SGL 布局分析#

经过上述操作后，内核在物理内存中为 TX SGL 攒出来的连续视图如下：

1
TX SGL 内存布局:
2
+--------------------+----------------------------------------+
3
| sendmsg data (8B)  | splice data (t+4 bytes)                |
4
| AAD: 4 zero bytes  | file[0:t+4]                            |
5
|      + evil_bytes  | 通过 splice 零拷贝直接引用的物理页面    |
6
|  (kmalloc 堆内存)  | (指向系统全局共享的只读 PAGE CACHE!)   |
7
+--------------------+----------------------------------------+

从内核 AEAD 解密的视角来切分这段大小为 8 + (t + 4) = t + 12 字节的数据：

• AAD（前 assoclen=8 字节）= \x00\x00\x00\x00 + evil_bytes
• 密文（中间 $t$ 字节）= file[0:t]（文件的前 $t$ 字节被当成了“密文”）
• 认证标签 Tag（最后 authsize=4 字节）= file[t:t+4]

Step 3：调用 recv() 触发零拷贝 SGL 缝合#

当用户空间调用 recv() 时，内核触发 _aead_recvmsg() 并计算解密后的输出大小：

$\text{outlen} = \text{assoclen} + \text{cryptlen} - \text{authsize} = 8 + (t + 4) - 4 = t + 8$

此时，受 commit 72548b093ee3 补丁的影响，内核开始构建 combined dst SGL：

1. memcpy_sglist(RX buffer, TX SGL, outlen=t+8)：

内核将 TX SGL 的前 t+8 字节真正复制到用户空间的 RX 缓冲区中。

• RX buffer [0:8] = AAD 的副本
• RX buffer [8:8+t] = file[0:t] 的副本

2. af_alg_pull_tsgl(TX SGL, skip=t+8, take=4)：

内核跳过前 t+8 字节，提取最后 4 字节的 Tag 区域。由于这 4 字节源于 splice，提取出来的 SGL 条目直接就是文件 Page Cache 的原始页面引用。

3. sg_chain()：

内核将这个带有 Page Cache 引用的 Tag 节点挂载到 RX SGL 的末尾。

1
最终的 combined dst SGL 链表结构:
2

3
+-- RX buffer (用户空间分配，安全) --+   +-- chained tag (PAGE CACHE 物理页!) --+
4
|                                   |   |                                     |
5
| AAD (8B)  |  密文区域 (tB)        |-->| file[t:t+4] 原始文件页面            |
6
|           |  = copy of file[0:t]  |   | (通过 sg_chain 缝合进来的写目标)     |
7
|                                   |   |                                     |
8
+-- 偏移 0               t+8 -------+   +-- 偏移 t+8               t+12 ------+

Step 4：authencesn 的 Scratch Write 致命一击#

当解密器 crypto_authenc_esn_decrypt() 开始执行时，为了处理 ESN（扩展序列号）逻辑，它会执行一段暂存写（Scratch Write）代码：

1
// 1. 先从 dst SGL 偏移 0 处读取 8 字节的 AAD 到临时变量 tmp
2
scatterwalk_map_and_copy(tmp, req->dst, 0, 8, 0);  // tmp[0]=AAD[0:4], tmp[1]=AAD[4:8](evil_bytes)
3

4
unsigned int cryptlen = req->cryptlen;  // = t + 4
5
cryptlen -= authsize;                   // = t
6

7
// 2. 致命写：将 tmp[1] (即 evil_bytes) 写入 dst SGL 的特定偏移处
8
scatterwalk_map_and_copy(tmp + 1, req->dst, assoclen + cryptlen, 4, 1);
9
//                                          ^^^^^^^^^^^^^^^^^^^
10
//                                        = 8 + t 字节处的偏移

根据 Step 3 里的链表图，偏移 8+t 恰好是安全缓冲区 RX buffer 的终点，同时也是 chained tag pages（Page Cache 原始引用）的起点！

内核在内核态拥有最高权限，它会直接绕过 VFS 的只读保护，直接向这个属于 /usr/bin/su 的物理页强行写入 4 字节的 evil_bytes。

正常情况下，解密尾部函数 crypto_authenc_esn_decrypt_tail() 会尝试恢复被暂存写覆盖的数据。但在该漏洞路径下：

1. 它先读取了 dst[8+t] 处的当前值（此时已经是攻击者写入的 evil_bytes）。
2. 然后回写的是 AAD 数据到 dst[0:8]，**dst[8+t]** 处的 Page Cache 页面从未被写回原始值。
3. 随后，由于数据和 Tag 完全是伪造的，HMAC 校验必然宣告失败，内核向用户态返回 -EBADMSG 错误码。

但对攻击者而言，这个错误已经无所谓了——Page Cache（页面缓存）在内存中已经被强行污染（Dirty）。

总结#

• 目标文件：任意当前用户具有只读权限（O_RDONLY）的文件均可被作为目标。
• 写入位置（偏移 $t$）：完全由 splice() 传递的长度决定。通过调整长度控制 $t$，可以精准定位到文件内部的任何位置。
• 写入内容：由 sendmsg 发送的 AAD[4:8] 决定，4 字节完全可控。
• 写入大小：固定 4 字节。这个限制并不是因为 authsize=4，而是因为 authencesn 源码中硬编码了 sizeof(u32) 用于存放 ESN 序列号。

由于 Page Cache 是全局共享的，一旦它在内存中被强行篡改，当系统后续尝试去执行 /usr/bin/su 或读取敏感配置文件时，就会直接在内存中读取到篡改后的后门数据，从而瞬间实现本地提权（LPE）。