CVE-2026-31431「Copy Fail」：一行 732 位元組的 Python 腳本，讓所有 Linux 發行版回歸到 2017 年

一個 732 位元組的 Python 腳本。不需要 race condition，不需要 kernel 版本相關的 offset，不需要網路連線。在同一個終端機上，連續 root 了 Ubuntu、Amazon Linux、RHEL 和 SUSE——而且完全不需要修改程式碼。

這不是電影情節。這是 Xint Code 團隊在 2026 年 3 月 23 日向 Linux 核心安全團隊通報的 CVE-2026-31431，一個潛伏在 Linux 核心中將近十年（2017→2026）的直線邏輯漏洞。官方將其命名為 Copy Fail。

所謂「Copy Fail」，到底是哪裡出錯了？

要理解這個漏洞，不需要你是核心開發者，但需要知道一個底層機制：Linux 核心的頁快取（page cache） 是怎麼工作的。

當你讀取一個檔案時，核心不會每次都從磁碟讀取。它會把檔案內容暫存在記憶體的 page cache 中。當兩個程式讀取同一個檔案時，它們實際上是共用同一塊 page cache 記憶體，而不是各自複製一份。這是一個非常有效率的設計，但它也有一個致命的假設：page cache 的內容應該是唯讀的。

因為 page cache 是共用的，任何寫入行為都應該先觸發「寫入時複製」（Copy on Write），確保一個程式寫入的內容不會污染另一個程式的 page cache。

CVE-2026-31431 就是在這個假設上出了問題。

漏洞的根源在 Linux 核心的 algif_aead 模組中。這個模組是核心加密 API（AF_ALG）的一部分，讓用戶空間程式可以直接使用核心的加密功能，像是 AES-GCM 這類需要認證加密（AEAD）的演算法。

2017 年，algif_aead 引入了一個看似無害的優化——in-place 加密操作。意思是，加密過程中輸入和輸出可以使用同一塊記憶體，省下一次複製的開銷。聽起來很合理，不是嗎？

問題在於，這個模組搭配另一個系統呼叫——splice() ——產生了意想不到的連鎖效應。

splice() 是一個高效率的資料傳送機制，可以在兩個檔案描述符之間直接傳送資料，完全繞過用戶空間的緩衝區。當 splice() 和 AF_ALG 搭配使用時，核心會直接從 page cache 中抓取頁面，傳送給加密引擎。而加密引擎在 in-place 模式下，會直接修改這個 page cache 頁面的內容。

這就是問題的關鍵：page cache 中的內容被非法寫入了。

4 個位元組，足以讓一個 root 權限化為烏有

這個漏洞的攻擊鏈非常優雅，也令人不安。Xint Code 團隊將其描述為一條「直線」：沒有 race condition，沒有複雜的記憶體布局安排，不需要猜測 kernel 記憶體位址。

攻擊流程大致如下：

建立一個 AF_ALG AEAD socket：任何沒有特權的用戶都可以這麼做，因為 AF_ALG 在幾乎所有 Linux 發行版的預設配置中都是啟用的。
透過 splice() 將一個 setuid 二進位檔案的 page cache 頁面傳送給加密引擎：setuid 二進位檔案（如 /usr/bin/su）在執行的時候會以 root 權限運行。攻擊者不需要寫入檔案本身（因為沒有權限），而是透過 splice() 操作 page cache。
利用 in-place 加密修改 page cache：加密引擎在處理資料時，會直接在 page cache 頁面上寫入 4 個位元組的資料。這個修改會「污染」該頁面，使得下一次執行該 setuid 程式時，核心載入的已經是被修改過的內容。
執行被污染的 setuid 程式：由於 page cache 的內容已被修改，該程式（如 /usr/bin/su）在執行時的行為會和原始程式完全不同。攻擊者精心設計的修改，可以使其跳過身分驗證，直接給予 root shell。

而這一切，只需要一個 732 位元組的 Python 腳本。

「這不只是一般的漏洞，」Xint Code 團隊在報告中寫道，「這是一個存在了將近十年的邏輯錯誤。不需要競爭條件，不需要不同的核心偏移量。所有於 2017 年之後建構的 Linux 發行版，全都受到影響。」

事實證明，他們的 PoC 在 Ubuntu 24.04 LTS、Amazon Linux 2023、RHEL 10 和 SUSE 16 上都能直接運行。所有測試中，不需要任何修改。

誰在射程範圍內？

如果使用 Linux——不論是跑在 AWS 上的雲端主機、公司內部的開發伺服器、Kubernetes 叢集的 worker node、還是 CI/CD runner——只要你的核心是在 2017 年之後建構，且尚未套用修補程式，就在影響範圍內。

Xint Code 團隊將受影響的場景分為幾個層級：

高風險場景：
– 多租戶 Linux 主機：開發共享主機、shell-as-a-service、跳板機、建置伺服器——任何讓多個用戶共用同一個核心的環境，只要任何一個用戶執行這個腳本，就能取得 root 權限。
– Kubernetes / 容器叢集：page cache 在主機層級是共用的。一個具有適當權限的 pod 可以透過這個漏洞侵入節點，跨越租戶邊界。
– CI runner 與建置農場：GitHub Actions self-hosted runner、GitLab runner、Jenkins agent——任何會執行不受信任 PR 程式碼的環境。一個 PR 就能讓 runner 變成 root。

中等風險：
– SaaS 平台中的用戶程式碼執行環境：notebook host、agent sandbox、serverless function。租戶程式碼可以取得主機 root 權限。

較低但非零風險：
– 標準 Linux 伺服器：如果你的團隊是唯一擁有 shell 存取權限的人，風險較低。但若與其他漏洞（如 RCE、憑證竊取）鏈結，這個漏洞就會成為將一般使用者攻擊升級為 root 權限的關鍵一步。
– 個人工作站：你已經是唯一的使用者。這個漏洞本身無法讓攻擊者遠端進入你的系統，但任何當地的程式碼執行都可以透過它升級到 root。

值得注意的是，這個漏洞不需要網路連線。只需一個無特權的本機用戶帳號就能觸發。這意味著，任何能夠在你的 Linux 主機上執行任意程式的人，都可以透過 Copy Fail 取得完整控制權。

為什麼它隱藏了將近十年？

這個問題從 2017 年代碼引入開始，一直潛伏到 2026 年 3 月才被發現。近十年的時間，一個直線邏輯漏洞，一直在那裏。

為什麼這麼久才被發現？答案是：因為代碼檢查和自動化掃描工具傳統上不擅長發現這類跨模組的連鎖效應。

algif_aead 模組的 in-place 優化本身不是漏洞。splice() 系統呼叫也不是漏洞。page cache 的寫入保護設計也不是漏洞。但當三者以特定的方式組合在一起時，問題就出現了。

傳統的靜態分析工具通常只檢查單一模組或單一函數的安全性。它們很難看到「A 模組的某個優化 + B 系統呼叫的某個行爲 + C 核心子系統的某個假設 → 安全漏洞」這樣的跨層級關聯。

Xint Code 團隊使用的是自己的 AI 輔助程式碼審計平台，花了大約一個小時掃描 Linux 核心的 crypto/ 子系統，就發現了這個漏洞。同樣的平台也在其他資料庫系統中找到了零日漏洞。這正在改變我們對軟體安全測試的認知——人眼可能永遠無法檢查數百萬行程式碼中的每個交叉路徑，但自動化工具可以。

修補和緩解措施

如果你正在運行 Linux，以下是必須做的事情：

立即修補

Linux 核心主線已於 2026 年 4 月 1 日合併了修補提交（commit a664bf3d603d），主要修正方式為還原 2017 年的 algif_aead in-place 優化。這樣一來，page cache 頁面就不會再出現在可寫入的目的地 scatterlist 中。

大多數主流發行版現在已經開始推送包含這個修補的核心更新。

無法立即修補的臨時措施

如果你無法立即更新核心——這種情況在生產環境中非常常見——可以透過以下方式暫時關閉漏洞路徑：

# 禁用 algif_aead 模組
echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf
rmmod algif_aead 2>/dev/null || true

關閉 algif_aead 會影響什麼嗎？ 對絕大多數系統來說，幾乎沒有影響。

不會影響：dm-crypt / LUKS、kTLS、IPsec/XFRM、核心內建 TLS、OpenSSL/GnuSSL/NSS 預設建構、SSH、核心 keyring 加密。這些全都直接使用核心內建加密 API，不經過 AF_ALG。
可能影響：特定配置為使用 AF_ALG 的用戶空間程式，例如手動啟用了 afalg engine 的 OpenSSL、特定嵌入式加密卸載路徑、或直接綁定 aead/skcipher/hash socket 的應用程式。可以用 lsof | grep AF_ALG 或 ss -xa 檢查。

長期最佳實踐

對於運行不受信任工作負載的環境（容器、sandbox、CI），無論是否已修補，都應該透過 seccomp 封鎖 AF_ALG socket 的建立。這是縱深防禦的基本原則：即使核心層級的漏洞已被修補，核心層級的防護也不應該完全取代應用層級的安全控制。

對台灣開發者與維運團隊的實際意義

這不僅是一個技術漏洞，更是一個提醒。如果你負責管理任何 Linux 系統——不管是雲端主機、內部伺服器還是 CI/CD 管線——這直接影響你的日常工作。

從三個層面來看。

如果你是開發者：
你的開發環境、CI runner、甚至你用來 demo 的伺服器，都可能暴露在這個漏洞下。特別是使用 GitHub Actions self-hosted runner 的團隊，風險最高。建議立即檢查 runner 的核心版本，確認是否已修補或已封鎖 AF_ALG 模組。

如果你是維運工程師：
這是盤點多租戶環境的最佳時機。你是否有共用開發主機？是否有多個團隊共用同一個 Kubernetes 叢集？是否允許用戶上傳程式碼到你的平台執行？如果答案是肯定的，那麼你需要將這個漏洞的修補視為最高優先級。

如果你是創業者或技術管理者：
這個漏洞的發現過程本身非常值得關注——Xint Code 用 AI 輔助程式碼審計，在一個小時內就找到了一個潛伏十年的漏洞。如果你的產品涉及程式碼安全性，無論是開發安全工具、還是你的產品本身需要處理使用者程式碼，都應該開始思考：你的安全測試流程，能夠發現這樣的漏洞嗎？

結語

這個漏洞的技術細節令人驚嘆——不是因為它多麼複雜，而是因為它多麼簡單。一個邏輯錯誤，一個被遺忘的優化，讓所有 Linux 系統暴露在風險中將近十年。

從另一個角度看，這也說明了現代軟體安全的困境：我們的地基已經蓋得太深太廣，沒有人能完全理解底層每一塊磚的相互作用。自動化工具的出現，或許不是可選項，而是必需品。

歷史總在重複，但從不完全相同。這一次，我們能不能在被動修補和主動安全之間，做出不同的選擇？