漏洞 on KnightLi的博客

Dirty Frag、Copy Fail 與 Fragnesia：近期三個 Linux 本地提權漏洞對比

Fri, 15 May 2026 13:24:04 +0800

最近 Linux 核心連續出現幾個高關注度的本地提權漏洞：Dirty Frag、Copy Fail 和 Fragnesia。它們看起來像一組「同類事件」，因為最終效果都很接近：低權限本地使用者可能把權限提升到 root。

但從維運處置角度看，不能把它們混成一個漏洞。三者的入口模組、觸發路徑、緩解方式和補丁節奏都不同。更準確的理解是：它們暴露了 Linux 核心在「頁面快取、splice、socket buffer、加密路徑」這些複雜交界處的共同風險。

本文只做風險和處置分析，不展開可復現利用步驟。

三個漏洞分別是什麼

Dirty Frag：CVE-2026-43284

Dirty Frag 主要指向 Linux 核心網路路徑裡的頁面快取寫入問題。公開資料中，它通常和兩個問題一起討論：xfrm-ESP 側的 CVE-2026-43284，以及 rxrpc 側的 CVE-2026-43500。

其中 CVE-2026-43284 與 ESP 處理共享 skb fragment 時的原地解密有關。問題的關鍵不是攻擊者直接修改磁碟檔案，而是讓核心在不該寫的共享頁面上發生寫入，進而影響頁面快取裡的檔案內容。

維運上最需要記住的是：Dirty Frag 觸達的是 esp4、esp6、rxrpc 這一組核心模組和網路子系統路徑。它和 IPsec、ESP、RxRPC 相關，臨時緩解也會圍繞這些模組展開。

Copy Fail：CVE-2026-31431

Copy Fail 是 Theori / Xint Code 披露的 Linux 核心本地提權漏洞。它的入口不在 IPsec 網路路徑，而在核心使用者態加密 API 的 algif_aead / AF_ALG 相關路徑。

公開說明中提到，它源於 2017 年引入的一處原地最佳化：某些情況下，核心沒有按預期複製資料，而是把頁面快取頁放進可寫目標路徑裡。攻擊者可以借助 AF_ALG 與 splice() 組合，對頁面快取支援的頁面做小範圍可控寫入。

它的風險點在於可利用性很強，而且影響面跨多個主流發行版。和 Dirty Frag 不同，Copy Fail 的臨時緩解重點是限制或禁用 algif_aead，以及在容器和 CI 環境中限制 AF_ALG socket。

Fragnesia：CVE-2026-46300

Fragnesia 是 V12 Security 披露的另一個 Linux 核心本地提權漏洞，和 Dirty Frag 屬於相近攻擊面。它不是 Dirty Frag 的同一個 bug，但仍然圍繞 IPsec ESP / rxrpc 相關模組，以及頁面快取寫入效果展開。

AlmaLinux 的說明把它定位為同一程式碼區域裡的第三個本地 root 問題。其關鍵點在於 skb_try_coalesce() 在合併 socket buffer 片段時沒有正確保留共享 fragment 標記，導致後續 XFRM ESP-in-TCP 接收路徑可能在外部頁面快取頁上做原地解密。

也就是說，Fragnesia 和 Dirty Frag 更接近：兩者都繞著 esp4、esp6、rxrpc、skb fragment、ESP 解密路徑轉。它們的臨時緩解也高度重疊。

相同點：為什麼都危險

這三個漏洞的共同點不是「程式碼位置完全一樣」，而是攻擊結果和風險模型非常像。

第一，它們都是本地提權。攻擊者通常需要先在機器上取得普通使用者程式碼執行能力，然後再把權限提升到 root。對單使用者桌面來說，它不是遠端一鍵入侵；但對多使用者伺服器、CI runner、容器宿主機、共享開發機和暴露 SSH 的 VPS 來說，低權限入口並不罕見。

第二，它們都和頁面快取寫入有關。攻擊者不一定永久改寫磁碟檔案，而是影響記憶體中的頁面快取副本。這會讓傳統檔案完整性檢查變得不夠可靠：磁碟 hash 可能正常，但執行路徑讀到的頁面快取內容已經被污染。

第三，它們都偏向確定性邏輯漏洞，而不是傳統意義上很吃時序的競爭條件。公開資料多次強調這類漏洞不依賴贏得 race condition。對防守方來說，這意味著「利用成功率」不能按老經驗低估。

第四，它們都放大了容器和自動化執行環境的風險。容器內的低權限程式碼、CI 任務、建置腳本、第三方外掛，一旦能觸達宿主核心相關介面，就可能把漏洞從「本地問題」變成「平台問題」。

不同點：不要用一個補丁思路套全部

三者最大的區別在入口模組。

Copy Fail 的關鍵入口是 algif_aead / AF_ALG，屬於核心使用者態加密 API。它的臨時防護重點是禁用或限制 algif_aead，以及用 seccomp 阻斷容器裡建立 AF_ALG socket。

Dirty Frag 的關鍵入口在 xfrm-ESP 和 rxrpc。它更接近網路協定和 socket buffer 處理路徑，臨時防護通常會考慮禁用 esp4、esp6、rxrpc。但這可能影響 IPsec、VPN、隧道或相關網路能力。

Fragnesia 的入口也在 Dirty Frag 相近區域，但具體問題落在 skb_try_coalesce() 沒有保留共享 fragment 標記。它更像是 Dirty Frag 風險面裡的另一個分支，而不是 Copy Fail 的加密 API 問題。

所以，不能因為已經處理了 Copy Fail，就認為 Dirty Frag 和 Fragnesia 也被覆蓋；也不能因為禁用了 esp4 / esp6，就認為 Copy Fail 自動消失。它們需要分別確認補丁狀態和緩解策略。

影響範圍該怎麼判斷

判斷這類漏洞是否受影響，不要只看發行版名字，也不要只看核心大版本號。發行版會回合補丁，雲廠商會維護自己的核心分支，企業發行版還可能有額外 backport。

更穩妥的順序是：

先看發行版安全公告和核心套件 changelog。
再核對 CVE 是否已被目前核心套件修復。
對雲主機、容器宿主機和 CI 節點，額外關注雲廠商或平台方公告。
對臨時緩解，確認業務是否依賴對應模組。
完成核心升級後安排重啟，確保實際執行核心已經切換。

這一步最容易踩坑的是「套件已經更新，但機器還沒重啟」。核心漏洞不是普通使用者態服務升級，安裝新套件之後，舊核心仍可能繼續執行。

維運優先級

這些漏洞最該優先處理的機器，不是「所有 Linux 平均排隊」，而是低權限程式碼最容易出現的地方。

優先級最高的環境包括：

多使用者登入伺服器
CI / CD runner
建置機和製品打包機
容器宿主機和 Kubernetes 節點
共享開發機
暴露 SSH 的雲主機和 VPS
執行第三方腳本、外掛、任務佇列的平台
有 Web 漏洞、弱密碼或歷史入侵痕跡的機器

相對封閉、單使用者、沒有外部程式碼執行入口的機器，風險仍然存在，但處置順序可以排在後面。

臨時緩解應該怎麼理解

臨時緩解不是補丁替代品。它的價值是幫你在無法立刻重啟或等待發行版補丁時降低暴露面。

對 Copy Fail，重點關注 algif_aead 和 AF_ALG。如果業務沒有使用核心 AF_ALG 加密介面，可以評估禁用相關模組；容器環境則應優先檢查 seccomp 策略，避免不受信任工作負載隨意建立對應 socket。

對 Dirty Frag 和 Fragnesia，重點關注 esp4、esp6、rxrpc。如果系統不依賴 IPsec ESP、相關 VPN、隧道或 RxRPC，可以評估臨時禁用。但生產環境不要盲目執行，因為這些模組可能影響真實網路業務。

最終仍然要回到核心更新。臨時緩解只能減少攻擊面，不能證明系統已經徹底安全。

這三個漏洞說明了什麼

這組漏洞真正值得警惕的地方，不只是 CVE 數量，而是它們都集中在核心高複雜度路徑：零拷貝、splice、socket buffer、頁面快取、加密介面、協定堆疊最佳化。

這些路徑的共同特點是效能收益很大，但所有權邊界也更難維護。一個 fragment 是否共享、一個頁面是否還能原地寫、一個最佳化是否真的只是減少複製，都會變成安全邊界的一部分。

對安全團隊和維運團隊來說，結論很實際：

本地提權漏洞要按「已有低權限入口會被放大」處理。
容器不是核心漏洞的天然隔離邊界。
檔案完整性檢查不能只看磁碟內容。
CI、建置機、外掛平台要當成高優先級資產。
核心補丁需要驗證「已安裝」和「已執行」兩個狀態。

小結

Dirty Frag、Copy Fail 和 Fragnesia 都是近期 Linux 本地提權風險裡的高優先級事件，但它們不是同一個漏洞的三個名字。

Copy Fail 走的是 algif_aead / AF_ALG 加密介面路徑；Dirty Frag 走的是 xfrm-ESP 與 rxrpc 相關路徑；Fragnesia 則在 Dirty Frag 相近攻擊面上，透過 skb fragment 標記處理問題再次觸發頁面快取寫入風險。

處置上，最穩妥的做法是：按發行版公告升級核心並重啟；對無法立即升級的系統，分別按漏洞入口評估臨時禁用模組或收緊 seccomp；對多租戶、CI、容器宿主機和共享開發環境優先處理。

參考資料：

Theori Copy Fail 說明：https://github.com/theori-io/copy-fail-CVE-2026-31431
CERT-EU Copy Fail 安全公告：https://cert.europa.eu/publications/security-advisories/2026-005/
AlmaLinux Dirty Frag 說明：https://almalinux.org/blog/2026-05-07-dirty-frag/
AlmaLinux Fragnesia 說明：https://almalinux.org/blog/2026-05-13-fragnesia-cve-2026-46300/
V12 Security Fragnesia PoC 說明：https://github.com/v12-security/pocs/tree/main/fragnesia

Fragnesia (CVE-2026-46300)：Linux 核心本地提權漏洞影響與緩解

Fri, 15 May 2026 13:18:01 +0800

Linux 核心最近又曝出一個和 Dirty Frag 同一類攻擊面相關的本地提權漏洞：Fragnesia (CVE-2026-46300)。

根據 V12 Security 的披露，Fragnesia 是一個 Linux 本地提權漏洞。攻擊者不需要在宿主機上已有高權限，只要能在本地執行程式碼，就可能借助核心 XFRM ESP-in-TCP 子系統中的邏輯缺陷，把唯讀檔案的頁面快取內容按位元組改寫，最終觸發 root shell。

原始資料：

V12 Security PoC 說明：https://github.com/v12-security/pocs/blob/main/fragnesia/README.md

本文不展開可復現利用步驟，只整理維運側需要知道的風險點和處置思路。

它和 Dirty Frag 是什麼關係

V12 Security 在說明中把 Fragnesia 歸到 Dirty Frag 漏洞類別裡。它不是 Dirty Frag 本身的同一個 bug，而是同一攻擊面上的另一個問題：Linux 核心的 XFRM ESP-in-TCP。

XFRM 是 Linux 核心裡處理 IPsec 的框架。ESP-in-TCP 則和透過 TCP 承載 ESP 加密流量有關。Fragnesia 的問題出在共享頁面片段和 socket buffer 合併過程中的邏輯處理：某些情況下，核心會「忘記」某個 fragment 仍然是共享狀態，進而留下可控寫入空間。

這類問題讓人聯想到 Dirty Pipe / Dirty Frag 這一類頁面快取寫入漏洞。共同點不是具體程式碼完全相同，而是都把攻擊效果落到了頁面快取裡的唯讀檔案副本上。

風險為什麼高

Fragnesia 的危險之處有三個。

第一，它是本地提權。只要攻擊者已經能在系統上執行普通使用者程式碼，就可能把權限提升到 root。對多使用者伺服器、容器宿主機、CI runner、共享開發機、VPS 和暴露 Shell 的環境來說，這類漏洞比普通桌面更敏感。

第二，它不依賴傳統競爭條件。V12 的說明中提到，該漏洞透過構造 ESP-in-TCP 處理流程，讓核心把加密流處理到已經 splice 進 socket buffer 的檔案頁面上，進而按位元組影響頁面快取內容。這意味著風險不只是「理論上可能」，而是研究團隊已經驗證了穩定利用路徑。

第三，它改的是頁面快取，不是磁碟檔案。公開說明裡的示例目標是 /usr/bin/su。利用成功後，磁碟上的檔案並不會被永久改寫，改動存在於記憶體頁面快取中。很多只檢查磁碟檔案 hash 或完整性的巡檢流程，可能看不出異常。

這也是它對管理員麻煩的地方：系統看起來檔案沒變，但一旦執行被污染頁面快取裡的目標二進位檔，就可能觸發提權效果。

已知影響範圍

V12 Security 的說明稱，受 Dirty Frag 影響且沒有套用 2026 年 5 月 13 日相關修補的核心，也會受 Fragnesia 影響。公開驗證環境包括 Ubuntu 22.04、Ubuntu 24.04，以及 6.8.0-111-generic 這類核心版本。

這裡要注意兩點。

第一，不要只看發行版大版本。Ubuntu 22.04 / 24.04 是否受影響，最終取決於核心修補狀態，而不是發行版名字。

第二，不要只看有沒有預設 AppArmor 限制。Ubuntu 對非特權使用者命名空間的 AppArmor 限制可以提高門檻，但披露方明確把它視為額外繞過問題，不是漏洞本體的根治方式。

真正可靠的判斷方式，仍然是查看發行版安全公告和核心套件更新。

臨時緩解思路

如果系統暫時不能立刻升級核心，可以先評估是否依賴相關協定模組。

V12 給出的緩解方向與 Dirty Frag 相同：如果系統不依賴 IPsec ESP 或 RxRPC，可以禁用相關模組，例如 esp4、esp6、rxrpc。這類操作會影響相關網路能力，生產環境不要盲目執行，應先確認業務是否使用 IPsec、VPN、隧道或相關核心功能。

更穩妥的處置順序是：

確認發行版是否已經發布核心安全更新。
優先安裝核心修補並安排重啟。
如果無法立即升級，再評估臨時禁用相關模組。
對多使用者系統和 CI / 建置環境優先處理。
檢查是否開放非必要本地帳號、Shell、容器逃逸面和低權限執行入口。

這裡不要把禁用模組當作最終修復。它更像是臨時降低暴露面。

如果懷疑已經被利用

Fragnesia 的一個特點是頁面快取污染。V12 在說明中強調，利用後目標檔案在頁面快取中的副本可能含有注入內容，後續執行仍可能觸發異常行為，直到頁面被驅逐或系統重啟。

如果懷疑系統已經被利用，至少要做幾件事：

盡快保留現場日誌和稽核記錄。
檢查近期異常本地登入、低權限使用者活動、可疑程序和 root shell 痕跡。
清理相關頁面快取或直接重啟。
升級到已修復核心。
對關鍵二進位檔做完整性檢查，但不要只依賴磁碟 hash。
輪換可能已經暴露的憑證和金鑰。

如果是生產伺服器，更建議把它當作一次潛在本地提權事件處理，而不是只當作普通補丁升級。

維運側該優先看哪些機器

這類漏洞優先級最高的不是所有 Linux 機器平均處理，而是先看攻擊者最容易拿到低權限程式碼執行的地方。

優先級較高的環境包括：

多使用者登入伺服器
CI / CD runner
建置機
共享開發機
容器宿主機
VPS 和雲主機
暴露 SSH 的邊緣節點
執行第三方腳本或外掛的平台

相對封閉、單使用者、沒有外部程式碼執行入口的機器，風險仍然存在，但緊急程度可以低一些。

小結

Fragnesia 值得關注，不是因為它名字新，而是因為它再次把 Linux 本地提權問題拉回到頁面快取和核心網路子系統這一類複雜交界處。

對管理員來說，最重要的不是研究利用細節，而是確認核心修補狀態、評估是否依賴 ESP / RxRPC、對高暴露機器優先升級，並理解「磁碟檔案沒變」不等於「系統沒有被影響」。

如果系統受影響，最終答案仍然是盡快安裝發行版提供的核心更新。臨時禁用模組只能算過渡措施，不能替代補丁。