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、對高暴露機器優先升級，並理解「磁碟檔案沒變」不等於「系統沒有被影響」。

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

CVE-2026-46300 on KnightLi的博客