在修复CVE-2026-31431的过程中，同事希望能有一个热补丁方案，减少对现有业务的影响。
该方案不仅要防御攻击，还要避免影响现在和未来的业务。
所以就有了下面对热补丁方案的探索。

具体原理，0xlane大佬已经分析的很详细了——
Copy Fail 深度研究：Linux 页缓存漏洞的根因、利用与检测
这里只做简析：

该漏洞主要利用了2个点：

基于 rfc4303 的描述，该数据的实际使用场景是IPsec的ESP（Encapsulating Security Payload）部分，用于应对重放攻击。

这是实际数据网络数据包的内容。

这是解密时所需要的内容。

其中有一点需要指出的是：

经过解密算法的调整，就变成了应用数据的样子。

通过 strongwan 应用模拟使用场景，发现跟上面文档有些许出入，但流程是一样的。
先说 AEAD （Authenticated Encryption with Additional Data）—— 通过附加数据进行认证和加密。
该算法同时具备：认证和加密的功能。这样的好处除了保证数据的完整性和机密性外，认证机制还能防御密文攻击。
该算法的解密过程，分为两个部分：认证检查、密文解码。
而实际过程可能有所变化：比如 echainiv(authencesn(hmac(sha1),cbc(aes)))
其中算法解释：

其中数据移动部分的示意图如下：

其中authencesn部分用python模拟的代码如下（其中数据是从模拟环境中抓取的）：

结论：通过详细分析 authencesn 部分的逻辑，最终可得出——被改写且未还原的Seq high数据，在后面的解密过程并未用到。

官方补丁 主要是回滚了 “_aead_recvmsg 函数中 将 输入源 直接用作 输出源” 的代码，但这个方案无法做热补丁（涉及面太广，存在运行时数据等原因）
该方案可以作为后续升级内核时使用，在此就暂且不论。

热补丁方案只能通过修补 ——“crypto_authenc_esn_decrypt 函数中，将 输出源 用于存放临时数据，且未还原完全”——这一点来做。
查看近期其他几个类似漏洞 Dirty Frag 、Fragnesia 的官方修复方案，都是采用了和本漏洞 Copy Fail相同 的封堵策略，丝毫没有修改 crypto_authenc_esn_decrypt 的意思。
所以我们要动此函数，要更加谨慎才行。
通过分析漏洞机制，热补丁方案主要想了以下几种：

该方案的目标是尝试不修改最后的4字节，因为前面有未使用的4字节空间。
原作者设计代码时，应该是本着性能考量的目的，尽量减少内存拷贝。

通过上面的示意图，可以看到内存平移方案不会修改最后的4字节数据。
但依然还是要修改4字节数据，只是位置发生了移动。
攻击者，只需要扩大splice页的长度，就可以绕过此方案。
所以该方案还需要一个数据还原操作，来预防此问题。
这样的话还不如直接使用下面的 “内存还原” 方案。
PS: patchwork中的补丁 使用的是此方案

该方案只是解决，原实现代码在最后只还原了aead associated data部分内存的问题。
猜想是因为，最终需要向用户态返回这部分数据，所以必须要还原。
我们需要再加一个操作，将最后4字节也还原，这样就达到了不修改原数据的目的，从而截断了攻击。

crypto_authenc_esn_decrypt_tail 函数是 crypto_authenc_esn_decrypt 最后还原数据的地方。
其中，[2] 和 [3] 是读取 低4位 和 高4低的数据，然后通过 [4] 将数据移动到最初始的位置。
我需要在下面加一个还原最后4字节的操作，数据在 [1] 处的 ihash 里。
但我们需要保证这块数据不会被后面的操作用到。
[5] 和 [6] 处限定了后面要使用的数据的范围。

通过上面的示意图，我们看到，后面所使用的数据并未使用到后面的 4字节数据，因为前面有强制性约束 authsize >=4。
至于为什么原作者不还原这4字节数据，个人认为是性能方面的考量（因为没必要），但也不排除可能是有的加密算法需要——这个需要后面跟原作者或相关内核开发者交流确认。
目前的暂时用于测试的补丁方案会是这样：

PS: 该方案存在一个可以绕过的地方，如果在认证阶段找到抛异常的路径，依然可以绕过。

各家操作系统的修复方案，都没有推出CopyFail热补丁，是我不敢按官方方案做热补丁的主要原因。
做为一个临时的修补方案，我想内存还原法可以在不怎么影响性能、不影响业务逻辑的情况下，防御漏洞攻击。

[内核课程]《Windows内核攻防实战》！从零到实战，融合AI与Windows内核攻防全技术栈，打造具备自动化能力的内核开发高手。