技術文件 on KnightLi的博客

Copy Fail 漏洞 CVE-2026-31431：Linux 核心檔案複製路徑中的容器逃逸風險

Fri, 01 May 2026 18:42:34 +0800

Copy Fail 是一個影響 Linux 核心檔案複製路徑的漏洞，編號為 CVE-2026-31431。 Bugcrowd 的分析把它稱為一個值得關注的核心級問題：在特定條件下，非特權使用者可以利用檔案複製相關邏輯觸發越權寫入，進而造成權限提升或容器逃逸。

從風險角度看，它不是普通應用層漏洞。問題發生在核心處理檔案複製和頁面快取的路徑上，因此影響面會延伸到容器、共享主機、CI/CD Runner、PaaS 平台和多租戶 Linux 環境。如果攻擊者已經能在系統裡執行低權限程式碼，漏洞就可能成為進一步突破隔離邊界的跳板。

漏洞大致發生在哪裡

Copy Fail 關聯的是 Linux 核心中的檔案複製能力。現代 Linux 提供了多種高效複製路徑，例如 copy_file_range、splice 類路徑以及不同檔案系統之間的資料複製最佳化。這些機制的目標是減少使用者態和核心態之間的資料搬運，提高大檔案複製效能。

問題在於，高效能複製路徑通常會複用頁面快取、檔案偏移、權限檢查和檔案系統回呼。如果其中某個邊界條件處理不嚴，核心可能在錯誤的權限上下文裡執行寫入，或者把本不應該被修改的資料頁暴露給攻擊者控制。

Copy Fail 的核心風險可以概括為：

攻擊者不需要 root 權限；
攻擊入口來自常見檔案複製能力；
影響點在核心態；
在容器環境裡，漏洞可能繞過命名空間和掛載隔離；
成功利用後可能寫入宿主機上不應被容器修改的內容。

這也是它被重點討論的原因。容器安全依賴 Linux 核心提供隔離能力，一旦核心路徑本身出現越權寫入，容器邊界就會變得脆弱。

為什麼容器場景更敏感

容器並不是虛擬機。容器內行程和宿主機共享同一個 Linux 核心，只是透過 namespace、cgroup、capability、seccomp、AppArmor/SELinux 等機制做隔離。

如果漏洞發生在使用者態服務裡，通常只影響某個容器或某個行程。但如果漏洞發生在核心裡，尤其是可以被非特權使用者觸發的核心漏洞，攻擊者可能從容器內部影響宿主機。

Copy Fail 的危險點就在這裡。很多平台允許使用者提交建置任務、執行腳本、啟動容器或執行外掛。攻擊者只要能在容器裡執行程式碼，就可能嘗試利用核心檔案複製路徑突破隔離。

高風險環境包括：

Kubernetes 叢集中的不可信工作負載；
CI/CD 平台的共享 Runner；
允許使用者上傳程式碼執行的沙箱平台；
多租戶 Linux 主機；
容器化 PaaS；
執行第三方外掛或擴充的系統。

如果這些環境裡的核心版本處於受影響範圍，而且缺少額外限制，風險就會明顯升高。

受影響範圍要看核心補丁狀態

這類漏洞的判斷不能只看發行版名稱。同一個 Ubuntu、Debian、RHEL、Fedora 或 Arch 版本，是否受影響取決於目前實際執行的核心套件，以及發行版是否已經回補補丁。

排查時應優先確認三件事：

目前執行核心版本；
發行版安全公告是否提到 CVE-2026-31431；
雲端廠商或託管平台是否已經完成宿主機核心修復。

可以先在系統上確認核心版本：

`1`	`uname -a`

然後查看發行版安全公告、核心 changelog 或雲端平台公告。不要只根據主版本號判斷是否安全，因為很多企業發行版會把安全補丁回補到舊版本核心裡。

臨時緩解思路

最可靠的修復方式仍然是更新核心。但在補丁無法立刻部署的環境裡，可以先降低暴露面。

常見緩解方向包括：

禁止不可信使用者執行特權容器；
避免給容器掛載敏感宿主機路徑；
收緊容器 capability，尤其不要隨意授予 CAP_SYS_ADMIN；
使用 seccomp、AppArmor 或 SELinux 限制危險系統呼叫和檔案存取；
將不可信工作負載遷移到隔離更強的虛擬機；
對 CI/CD Runner 做按任務銷毀，避免長期複用同一宿主機；
監控異常檔案寫入、權限變更和容器逃逸跡象。

這些措施不能替代補丁。它們的作用是降低攻擊成功率和影響面，特別是在補丁發布到生產環境之前爭取緩衝時間。

修復優先級

建議按環境風險排序處理。

優先修復：

對外提供容器執行能力的平台；
執行不可信程式碼的 CI/CD 節點；
多租戶 Kubernetes 節點；
有使用者自定義外掛或腳本執行能力的系統；
共享開發機、教學機、實驗平台。

相對低優先級：

單使用者桌面；
只執行可信服務的內網主機；
已經使用虛擬機隔離不可信程式碼的環境。

即便風險較低，也建議隨發行版更新核心。核心漏洞常常會被組合進更複雜的攻擊鏈裡，拖延補丁沒有太多收益。

給維運團隊的檢查清單

可以按下面順序處理：

盤點所有 Linux 主機和容器節點；
標記會執行不可信程式碼的機器；
檢查目前核心版本和發行版安全公告；
優先更新高風險節點；
對無法立即更新的節點啟用臨時隔離策略；
檢查容器執行時設定，移除不必要的特權和宿主機掛載；
更新後重啟節點，確認新核心已經實際生效；
保留變更記錄，方便後續稽核。

核心套件安裝完成並不代表系統已經執行在新核心上。更新後必須重啟，並再次確認：

`1`	`uname -a`

小結

Copy Fail / CVE-2026-31431 的重點不是某個應用崩潰，而是 Linux 核心檔案複製路徑中的權限邊界問題。它讓非特權程式碼有機會觸碰更高權限的資料寫入路徑，因此在容器和多租戶環境裡尤其值得重視。

處理這類漏洞時，最重要的是兩件事：

盡快跟進發行版或雲端廠商提供的核心補丁；
在補丁部署前限制不可信程式碼、特權容器和敏感宿主機掛載。

對個人桌面來說，它可能不是馬上需要恐慌的問題。但對執行容器平台、CI/CD、沙箱和共享主機的團隊來說，應該把它當作高優先級核心安全更新處理。

參考來源：

Linux Kernel 7.0 更新特性整理

Fri, 01 May 2026 14:46:07 +0800

Linux 核心版本號一直不是語意化版本號，主版本號提升更多是維護節奏上的滾動。 Linus Torvalds 在發布郵件中也把 7.0 描述成一次正常發布：最後一週主要是網路、架構、工具、自測和驅動等方向的小修小補。

真正值得關注的是這批增量更新本身。 Linux 7.0 覆蓋了檔案系統、記憶體管理、硬體支援、安全隔離、Rust 支援和驅動清理等多個方向。

檔案系統：XFS、EXT4、NTFS3 都有變化

Linux 7.0 最容易被感知的一類更新在檔案系統。

XFS 引入了自我修復相關能力。配合新的通用檔案系統錯誤回報機制，檔案系統可以把 metadata 損壞和 I/O 錯誤透過更統一的方式傳遞到使用者空間。在合適的系統服務配合下，XFS 可以在檔案系統仍然掛載時自動處理部分修復流程。這並不等於所有磁碟損壞都能無痛修好，但對伺服器和長期執行系統來說，錯誤發現和修復鏈路更完整。

EXT4 繼續改善並行 direct I/O 寫入表現。如果機器上經常有備份、建置、下載、資料庫或日誌任務同時寫盤，這類最佳化會讓並行寫入路徑更穩。它不是那種所有桌面使用者馬上能感知的變化，但對高 I/O 場景有意義。

NTFS3 也獲得了較大的驅動更新，包括 delayed allocation、基於 iomap 的檔案操作，以及大目錄掃描場景下更好的 readahead。如果經常在 Linux 下存取 Windows 分割區或外接 NTFS 磁碟，這類更新更值得留意。

此外，exFAT 改進了多 cluster 順序讀取，部分小 cluster 裝置在順序讀取時會更快。

記憶體與 swap：繼續最佳化記憶體壓力下的表現

Linux 7.0 延續了前幾個版本對 swap 子系統的整理。這次重點之一是改進從 swap 讀回記憶體的路徑，尤其是多個行程共享同一批被換出的記憶體頁時，吞吐會更好。

對桌面使用者來說，這不一定會變成明顯的「系統突然更快」。但在記憶體緊張、容器密集、Redis 這類服務啟用持久化，或 zram 搭配後端磁碟的場景裡，這類變化會減少系統在記憶體壓力下的抖動。

zram 相關路徑也有最佳化。過去某些情況下，核心需要先把 zram 頁面解壓再寫入後端裝置；新的路徑可以直接寫入壓縮資料，減少不必要的處理。

CPU 與效能：Intel TSX auto、執行緒和檔案操作更快

Linux 7.0 對 Intel TSX 的預設策略做了調整。過去因為安全問題，TSX 在不少處理器上預設關閉。現在核心採用更細的 auto 策略：受影響的 CPU 繼續關閉，不受影響或適合啟用的 CPU 可以自動打開。

這對部分多執行緒工作負載會有幫助，尤其是依賴事務同步擴展的應用。不過它不是通用加速開關，實際收益仍取決於 CPU 型號和應用是否使用相關能力。

另外，Linux 7.0 還包含 PID 分配、執行緒建立/銷毀、檔案 open/close 等路徑的最佳化。這些最佳化通常不會單獨成為宣傳點，但會累積成系統回應和高並行服務上的細微收益。

硬體支援：新平台預備和現有裝置改善

Linux 7.0 繼續做大量硬體啟用工作。這類更新通常分成兩類：一類是還沒大規模上市的新平台預備，另一類是已經在使用者手上的裝置改善。

新平台方面，Linux 7.0 包含更多 Intel Nova Lake、Intel Crescent Island、AMD 新圖形 IP、AMD Zen 6 相關準備工作。這類改動對普通使用者不一定馬上有用，但它決定了新硬體上市後能否更快獲得主線核心支援。

ARM64 和單板機方向，Rockchip RK3588/RK3576 的 H.264/H.265 硬體影片解碼進入主線支援範圍。這意味著 Orange Pi 5、Radxa ROCK 5 等裝置不再完全依賴廠商 BSP 核心才能獲得硬解體驗。

筆電和外設方向也有不少細節更新：

ASUS WMI 改善 ROG、TUF 機型的背光、鍵盤燈和風扇快捷鍵支援；
HP WMI 增加部分 Victus 機型的手動風扇控制和音訊指示燈修正；
Lenovo WMI 為 Legion 裝置暴露更多 HWMON 監控資訊；
Intel Xe 圖形驅動暴露更多溫度感測器；
Intel Arc B 系列獨顯可以進入更深的 PCIe 省電狀態；
Rock Band 4 藍牙吉他和 Logitech K980 藍牙鍵盤獲得更好的核心支援。

這些變化單看都不大，但對筆電、遊戲裝置、開發板和外設使用者來說，主線核心支援越完整，後續發行版維護越省心。

安全與隔離：io_uring 可以做 BPF 過濾

Linux 7.0 給 io_uring 增加了 BPF 過濾能力。這對容器、沙箱和高安全要求環境比較重要。

過去一些管理員為了降低攻擊面，會直接停用 io_uring。現在透過 BPF 過濾，可以更細地限制允許的操作，而不是只能在「全開」和「全關」之間選擇。

這不會讓 io_uring 的安全風險自動消失，但給系統管理員和執行時框架提供了更可控的隔離手段。

Rust 支援不再只是實驗標籤

Linux 7.0 中，Rust for Linux 的狀態進一步穩定。這不意味著核心會大規模改寫成 Rust，也不意味著 C 會被替代。

更準確地說，Rust 在核心裡的基礎設施已經進入更正式的階段。後續新驅動、新子系統或部分安全敏感程式碼，可以在合適場景下選擇 Rust。這是一條漸進路線：先把介面、建置、文件和維護流程打穩，再讓具體程式碼慢慢增加。

清理舊功能：laptop_mode 被移除

Linux 7.0 移除了 laptop_mode。這是一個歷史很久的省電功能，主要面向機械硬碟時代的筆電，透過減少磁碟喚醒來節省電量。

現在筆電主流已經是 SSD，核心裡的記憶體回收、區塊裝置和檔案系統路徑也發生了很多變化。繼續保留這種老機制會增加維護成本，而且測試覆蓋並不理想。移除它可以減少舊程式碼對現代路徑的干擾。

AI 相關按鍵：面向新一代鍵盤互動

Linux 7.0 增加了幾個新的 HID keycode，用於上下文 AI 互動場景，例如對選中內容執行動作、插入上下文生成內容、發起上下文查詢等。

這並不是核心內建 AI 功能。它更像是給未來筆電鍵盤和外設留好輸入事件定義，讓桌面環境、應用或廠商工具可以識別這些按鍵。實際能做什麼，仍取決於發行版、桌面環境和應用層整合。

是否應該馬上升級

如果你使用滾動發行版，Linux 7.0 很可能會自然進入系統更新。如果你使用 Ubuntu 26.04 LTS 這類新發行版，7.0 也會作為預設或主要核心版本出現。

但如果你的機器是生產環境、NAS、虛擬化宿主機，或依賴閉源驅動和專有核心模組，不建議只因為版本號變成 7.0 就立刻手動升級。更穩妥的做法是：

等發行版提供正式核心套件；
查看顯示卡、網卡、ZFS、VirtualBox、VMware、DKMS 模組相容性；
在測試機或快照環境裡先驗證；
關注 7.0.x 小版本修復情況。

截至 kernel.org v7.x 目錄，7.0.1、7.0.2、7.0.3 已經陸續發布。如果要手動建置或測試，優先選擇最新的 7.0.x 穩定小版本，而不是只盯著最初的 7.0 tarball。

小結

Linux Kernel 7.0 不是一次「因為大版本號而重寫一切」的發布。它更像是一次覆蓋面很廣的常規核心更新：檔案系統更可靠，swap 和 I/O 路徑繼續最佳化，新硬體支援繼續前移，Rust、io_uring 隔離和 HID 輸入定義也在補齊長期演進所需的基礎設施。

對普通桌面使用者來說，最實際的變化可能來自硬體支援、圖形驅動、省電和檔案系統修復。對伺服器和開發者來說，XFS 錯誤回報、自我修復、io_uring BPF 過濾、swap 最佳化和新平台支援更值得關注。

參考來源：