Dirty Frag on KnightLi的博客

AI 漏洞挖掘時代來了：Copy Fail、Dirty Frag、Fragnesia 與 ssh-keysign-pwn 為何集中爆發

Thu, 21 May 2026 09:30:01 +0800

最近一段時間，Linux 內核相關漏洞密集出現：Copy Fail、Dirty Frag、Fragnesia、ssh-keysign-pwn 接連進入安全圈討論。它們有的可以本地提權，有的能洩露高敏感文件，有的影響容器宿主機和多租戶環境。很多人的第一反應是：Linux 怎麼突然變得這麼不安全？

更準確的說法是：Linux 不是突然變差了，而是隱藏很久的問題被更快、更系統地挖了出來。

這輪事件真正值得關注的，不只是某幾個 CVE 的修復，而是漏洞發現方式變了。過去需要少數頂級研究員花很久才能串起來的跨子系統邏輯漏洞，現在正在被 AI 輔助審計、自動化靜態分析、模糊測試和安全研究平台批量放大。漏洞沒有一夜之間多出來，但漏洞被發現、被復現、被擴散的速度變快了。

這幾次漏洞有什麼共同點

先把最近幾次事件放到一張表裡看。

漏洞	主要影響	關鍵特徵	風險重點
Copy Fail / CVE-2026-31431	本地提權	Linux crypto / AF_ALG 相關路徑，涉及 page cache 寫入問題	普通使用者到 root，容器環境尤其敏感
Dirty Frag / CVE-2026-43284、CVE-2026-43500	本地提權	XFRM/ESP、RxRPC 等路徑裡的 page cache 寫入原語	可鏈式利用，影響宿主機與容器邊界
Fragnesia / CVE-2026-46300	本地提權	XFRM ESP-in-TCP 子系統邏輯問題	與 Dirty Frag 同屬相近攻擊面
ssh-keysign-pwn / CVE-2026-46333	本地敏感資訊洩露與提權風險	Linux kernel `__ptrace_may_access()` 邏輯缺陷	SSH 主機金鑰、`/etc/shadow` 等敏感文件風險

它們不完全是同一個漏洞，但背後有幾個共同點：

都不是傳統遠端 RCE，而是本地權限提升或本地敏感資訊洩露。
都要求攻擊者先拿到某種本地執行能力，比如普通 shell、容器內命令執行、CI 任務權限或低權限帳戶。
多數風險集中在內核邊界：page cache、加密/網路子系統、ptrace 權限判斷、容器共享內核。
影響面會被現代雲原生環境放大，因為容器不是強安全邊界，宿主機內核仍然是共同底座。

所以問題不只是「有沒有補丁」。更深的問題是：為什麼這些看起來很底層、很隱蔽、潛伏很久的問題，會在短時間內集中出現？

第一層原因：很多漏洞是歷史債，不是剛寫進去

很多人看到漏洞披露時間，會誤以為漏洞是在最近版本裡新引入的。實際往往不是這樣。

Copy Fail 這類問題的關鍵點在於：漏洞可以潛伏多年，直到有人把正確的呼叫路徑、權限邊界和記憶體語義串起來。公開資訊顯示，Copy Fail 與 2017 年前後的內核優化歷史有關。Dirty Frag、Fragnesia 也都指向網路、加密、page cache 這類深層交叉路徑。

這類漏洞的可怕之處，不是某一行程式碼看起來明顯危險，而是多個前提剛好疊在一起：

某個子系統為了效能做了原地處理。
某個介面允許非特權使用者觸達內核功能。
某個路徑把唯讀文件頁、page cache、網路包片段、加密緩衝區連接到一起。
某個隱式約束沒有寫進型別系統、斷言或文件。
最終形成「普通使用者能影響本不該影響的內核狀態」的路徑。

這不是普通程式碼審查最擅長發現的問題。審查者可能懂 crypto 子系統，另一個人懂網路子系統，第三個人懂記憶體管理，但漏洞剛好藏在它們的交界處。

第二層原因：Linux 內核複雜度已經超出人工審查極限

Linux 的優勢是開放、通用、硬體支援廣、生態強。但這些優勢也帶來了代價。

現代 Linux 內核不只是一個「小內核」。它包含排程、記憶體管理、檔案系統、網路協定棧、加密框架、驅動、虛擬化、容器相關機制、eBPF、LSM、安全模組、硬體平台適配等大量子系統。每個子系統都有自己的歷史、維護者、效能目標和相容性包袱。

問題在於，漏洞常常不在單個模組裡，而在模組交叉點：

splice() 把文件頁和管道連接起來。
AF_ALG 把使用者態和內核 crypto API 連接起來。
XFRM/ESP 把網路包、加密和記憶體頁連接起來。
RxRPC、ESP-in-TCP 這類路徑讓網路協定棧更加複雜。
容器讓低權限本地執行變成更常見的現實前提。

從工程角度看，Linux 內核已經不是「足夠多的眼睛就能看完」的規模。開源確實讓問題更容易被修復和複核，但不等於每個角落都會被持續、安全地審查。真正能理解跨子系統漏洞的人很少，而這類漏洞偏偏最容易造成高影響。

第三層原因：效能優化經常把安全邊界壓得很薄

這輪漏洞裡反覆出現一個主題：為了效能減少拷貝、複用緩衝區、原地處理資料。

這類優化非常合理。內核是基礎設施，效能差一點，雲廠商、資料庫、網路、儲存、容器平台都會感受到。一次少拷貝、一次更快的加解密、一次更少的記憶體分配，都可能在真實生產環境中帶來收益。

但安全代價也很清楚：當「唯讀資料」「共享頁」「使用者可控輸入」「內核緩衝區」「加密輸出」之間的邊界變薄，只要某個子系統對輸入輸出契約理解不一致，就可能產生越權寫入或越權讀取。

也就是說，效能優化本身不是錯，但它會製造更脆弱的組合：

原地加解密減少了複製，但也更依賴輸入輸出緩衝區的正確隔離。
page cache 提升了文件訪問效率，但也可能成為攻擊面。
零拷貝提升吞吐，但也讓不同子系統共享同一批記憶體物件。
容器提升部署效率，但共享內核意味著本地 LPE 的爆炸半徑更大。

安全邊界不是靠「大家都記得別犯錯」維持的。邊界必須落實到型別、權限檢查、不可變約束、測試、fuzzing 和持續審計裡。否則，效能優化越多，隱式假設越多，漏洞遲早會被挖出來。

第四層原因：容器讓本地漏洞的價值變高了

過去說「本地提權」，很多人會覺得風險低於遠端漏洞，因為攻擊者已經需要本地帳戶。但雲原生時代改變了這個判斷。

今天的「本地執行」來源太多了：

Web 應用被打出普通 shell。
CI/CD 任務執行了不可信程式碼。
容器裡跑了使用者上傳任務。
多租戶平台允許使用者運行 notebook、外掛、腳本或構建任務。
AI 程式碼執行環境、沙箱和線上評測平台越來越常見。

一旦攻擊者在容器裡有執行能力，內核 LPE 就不再只是「本機小問題」。因為容器共享宿主機內核，內核漏洞可能直接跨過容器邊界，影響宿主機和其他租戶。

這也是為什麼 Copy Fail、Dirty Frag 這類漏洞會被雲、安全、容器團隊高度關注。它們把「低權限本地程式碼執行」升級成「宿主機級風險」的可能性提高了。

AI 的影響：漏洞發現成本被壓低了

這輪事件裡最有時代感的部分，是 AI 輔助漏洞挖掘。

Copy Fail 的公開資料提到，Theori 的 Xint Code 參與了漏洞發現過程。無論具體工具能力如何，這件事代表了一個趨勢：AI 不一定自己「憑空發明漏洞」，但它很擅長幫助研究員縮短搜尋路徑。

AI 對漏洞研究的影響主要體現在幾件事上：

更快掃過陌生程式碼
內核子系統程式碼量很大，研究員不可能手工閱讀所有路徑。AI 可以幫助快速總結函式、呼叫鏈、輸入輸出關係和可疑模式。
更容易發現跨模組連接
很多漏洞藏在「使用者態入口 -> 網路棧 -> 加密框架 -> 記憶體頁 -> 文件快取」的鏈條裡。AI 可以輔助梳理這些跨文件、跨目錄、跨子系統的路徑。
更容易生成審計假設
比如「哪些路徑會把使用者可控資料寫入 page cache」「哪些 API 允許非特權使用者觸達 crypto 子系統」「哪些函式假設輸入輸出緩衝區不會重疊」。這些問題以前靠經驗慢慢想，現在可以被更系統地枚舉。
更容易把漏洞變成可復現樣例
AI 不能替代內核研究員的判斷，但可以幫助寫驗證程式碼、整理 PoC 思路、解釋錯誤路徑、生成測試用例。

結果是：漏洞挖掘的單位成本下降了。

過去，一個高品質內核漏洞可能需要很長時間才能被頂尖研究員發現。現在，懂系統的人加上 AI 工具，可以更快把可疑路徑篩出來。漏洞供給的天花板被抬高，集中爆發就更容易出現。

但 AI 不是唯一原因

也要避免另一個極端：把所有問題都歸因於 AI。

AI 只是加速器，不是漏洞根源。漏洞真正的根源仍然是：

歷史程式碼長期累積。
效能優化中的隱式契約沒有被強制化。
跨子系統複雜度太高。
預設暴露的內核功能太多。
安全測試沒有覆蓋所有組合路徑。
容器、多租戶和自動化執行環境擴大了本地漏洞價值。

如果沒有這些基礎條件，AI 再強也挖不出這麼多高影響漏洞。反過來，只要這些條件存在，AI 越成熟，漏洞就越容易被系統性挖出。

對防守方意味著什麼

對維運、安全和平台團隊來說，這輪事件有幾個直接啟示。

第一，不要再把「本地提權」當低優先級。
只要你的環境裡有容器、CI、線上執行、外掛、notebook、多租戶任務，本地提權就可能變成宿主機風險。

第二，內核補丁節奏要更快。
關鍵宿主機、Kubernetes 節點、CI Runner、AI 沙箱、虛擬化宿主機，不應該長期停留在舊內核。內核更新、重啟窗口、live patch、灰度回滾都要有明確流程。

第三，減少不必要的內核攻擊面。
不需要的協定、模組、使用者命名空間、特殊 socket、除錯介面，要按業務需要收緊。預設開啟不等於預設應該暴露。

第四，容器安全要假設內核可能被打穿。
容器裡使用非 root、最小 capabilities、seccomp、AppArmor/SELinux、唯讀文件系統、隔離敏感掛載，仍然很重要。它們未必能擋住所有內核漏洞，但能減少前置條件和後續破壞。

第五，監控要關注提權鏈條。
不僅要看遠端入口，也要看異常進程、敏感文件讀取、內核模組載入、容器逃逸跡象、CI Runner 異常行為、/etc/shadow、SSH host key 等高價值文件訪問。

對開源社群意味著什麼

對 Linux 社群和大型開源項目來說，AI 漏洞挖掘會帶來雙重壓力。

一方面，AI 會幫防守方更快找到老問題。更多潛伏漏洞被公開修復，從長期看是好事。

另一方面，AI 也會製造噪音。低品質自動報告、誤報、重複報告、沒有上下文的「AI 找 bug」會消耗維護者時間。真正的挑戰不是「是否使用 AI」，而是如何把 AI 輸出納入負責任的安全流程：

報告必須有最小復現。
必須明確影響範圍和威脅模型。
必須區分理論問題、可觸發 bug、可利用漏洞。
必須尊重 embargo、發行版協調和修復窗口。
維護者需要更好的自動化測試、fuzzing、靜態分析和回歸驗證。

AI 讓漏洞發現更快，也要求修復和協調機制更成熟。否則，安全研究的生產力提升會轉化成維護者的壓力和使用者的恐慌。

結論：不是神話破滅，而是安全現實變了

Linux 仍然是最透明、最可控、最能被修復和加固的主流作業系統基礎設施之一。問題不在於 Linux 突然「不安全」，而在於現代內核的複雜度、雲原生使用方式和 AI 輔助漏洞挖掘，正在改變漏洞暴露速度。

以後類似事件很可能還會出現。不是因為每次都有新的災難，而是因為過去積累的複雜路徑正在被更高效率地搜尋。

真正該改變的是我們的安全假設：

不能把「沒披露漏洞」當作「沒有漏洞」。
不能把「本地提權」當作低風險。
不能把「容器隔離」當作強安全邊界。
不能只靠人工審查面對千萬行級別系統軟體。
不能只等補丁，而要提前縮小攻擊面、加快補丁節奏、建立縱深防禦。

AI 讓漏洞挖掘進入更高產能時代。對攻擊者是這樣，對防守者也一樣。區別在於，防守方能不能把這種能力變成更快的審計、更早的修復和更穩的基礎設施治理。

參考資料

Dirty Frag CVE-2026-43284：Linux 本地提權漏洞風險與緩解指南

Sat, 09 May 2026 07:25:55 +0800

Dirty Frag 是 2026 年 5 月公開並已出現利用跡象的一組 Linux 內核本地提權漏洞。Microsoft 將其描述為攻擊者在已經獲得低權限執行能力後，用來把權限提升到 root 的後滲透風險；Ubuntu 也將 CVE-2026-43284 標為 High。

這類漏洞最危險的地方不在「遠端直接打進來」，而在「進來以後迅速擴大控制權」。一旦攻擊者透過弱 SSH 帳號、WebShell、容器逃逸、低權限服務帳號或釣魚後的遠端存取拿到本地執行機會，就可能利用 Dirty Frag 取得 root，進而關閉安全工具、讀取敏感憑證、篡改日誌、橫向移動或建立持久化。

Dirty Frag 涉及哪些 CVE

目前公開資訊裡，Dirty Frag 主要關聯兩個編號：

CVE-2026-43284：涉及 Linux 內核 xfrm/ESP 路徑，Microsoft 提到的 esp4、esp6 元件屬於這一類風險。
CVE-2026-43500：Microsoft 稱其與 rxrpc 相關，但截至 2026 年 5 月 8 日，該 CVE 在 NVD 尚未正式發布，修補狀態也仍在變化。

因此，實際排查時不要只盯一個 CVE。更穩妥的思路是同時關注 esp4、esp6、rxrpc 以及相關 xfrm/IPsec 功能是否啟用、是否需要、是否已有發行版內核修補。

技術原因簡單理解

根據 Microsoft 和 Ubuntu 的說明，CVE-2026-43284 與 Linux 內核網路和記憶體碎片處理有關，尤其是 ESP/IPsec 路徑中對共享頁面片段的處理。

更具體地說，某些場景下，資料頁可能透過 splice 等機制被掛到網路緩衝區裡。如果內核後續路徑把這些片段當成可以原地修改的私有資料處理，就可能在不該寫的位置發生原地解密或修改。攻擊者可以藉此操縱 page cache 行為，最終達到本地提權。

這和此前披露的 CopyFail（CVE-2026-31431）有相似背景：都圍繞 Linux page cache、內核資料路徑和本地提權展開。Dirty Frag 的危險點在於，它引入了更多攻擊路徑，可能比傳統依賴競態窗口的 LPE 更穩定。

哪些環境需要優先關注

Dirty Frag 是本地提權漏洞，所以前提是攻擊者已經能在目標機器上執行程式碼。需要優先關注的環境包括：

暴露 SSH 的 Linux 伺服器。
執行 Web 應用、可能被寫入 WebShell 的伺服器。
多使用者登入、跳板機、開發機、CI/CD runner。
容器宿主機、Kubernetes 節點、OpenShift 節點。
使用 IPsec、VPN、xfrm、RxRPC 相關功能的系統。
執行 Ubuntu、RHEL、CentOS Stream、AlmaLinux、Fedora、openSUSE 等主流發行版的伺服器。

如果你的伺服器完全沒有本地多使用者、沒有容器、沒有暴露可被利用的應用入口，風險會低一些；但只要存在「攻擊者可能拿到低權限 shell」的路徑，就應該把它作為高優先級內核漏洞處理。

先做修補優先

最穩妥的修復方式永遠是安裝發行版提供的內核安全更新，並重啟進入新內核。

Ubuntu 的 CVE 頁面顯示，CVE-2026-43284 發布於 2026 年 5 月 8 日，優先級為 High。Microsoft 也指出 Linux Kernel Organization 已經發布 CVE-2026-43284 相關修復，並建議盡快應用補丁。

實際操作建議：

1
2

uname -a
cat /etc/os-release

然後按發行版更新內核：

`1`	`sudo apt update && sudo apt full-upgrade`

或：

`1`	`sudo dnf update`

更新後務必確認已重啟到新內核：

`1`	`uname -r`

只安裝內核包但不重啟，舊內核仍在執行，漏洞依然可能存在。

臨時緩解：停用相關模組

如果補丁尚未可用，或生產環境不能立即重啟，可以先評估是否能臨時停用相關模組。Ubuntu 給出的緩解思路是阻止 esp4、esp6、rxrpc 載入，並卸載已經載入的模組。

建立 modprobe 停用規則：

1
2
3

echo "install esp4 /bin/false" | sudo tee /etc/modprobe.d/dirty-frag.conf
echo "install esp6 /bin/false" | sudo tee -a /etc/modprobe.d/dirty-frag.conf
echo "install rxrpc /bin/false" | sudo tee -a /etc/modprobe.d/dirty-frag.conf

更新 initramfs，避免早期啟動階段載入：

`1`	`sudo update-initramfs -u -k all`

卸載已載入模組：

`1`	`sudo rmmod esp4 esp6 rxrpc 2>/dev/null`

確認模組是否仍在：

`1`	`grep -qE '^(esp4\|esp6\|rxrpc) ' /proc/modules && echo "Affected modules are loaded" \|\| echo "Affected modules are NOT loaded"`

如果模組正在被業務使用，可能無法卸載，重啟後停用規則才會生效。

停用前一定要評估業務影響

不要把上面的緩解命令當成無腦複製貼上。esp4、esp6 和 xfrm/IPsec 相關功能可能被 VPN、隧道、加密網路、Kubernetes/容器網路或特定企業網路設定使用。rxrpc 也可能影響依賴該協議的場景。

在生產環境執行前，至少確認：

1
2
3

lsmod | grep -E '^(esp4|esp6|rxrpc|xfrm)'
ip xfrm state
ip xfrm policy

如果你依賴 IPsec VPN 或相關內核網路功能，停用模組可能直接導致連線中斷。此時更推薦盡快安排內核補丁和維護窗口，而不是長期依賴停用模組。

入侵後檢查不能省

Microsoft 特別提醒，緩解措施不一定能撤銷已經發生的成功利用。攻擊者如果已經拿到 root，可能留下持久化、篡改檔案、修改日誌或存取 session 資料。

建議至少檢查：

journalctl -k --since "24 hours ago" | grep -Ei "dirty|frag|exploit|segfault|xfrm|rxrpc|esp"
last -a
lastlog
sudo find /tmp /var/tmp /dev/shm -type f -mtime -3 -ls
sudo find / -perm -4000 -type f -mtime -7 -ls 2>/dev/null

還應重點關注：

異常 su、sudo、SUID/SGID 行程啟動。
近期新增的 ELF 可執行檔。
Web 目錄下的可疑 PHP、JSP、ASP 檔案。
SSH authorized_keys 是否被改動。
systemd service、cron、rc.local 是否新增持久化。
容器宿主機是否有異常特權容器或掛載。

如果懷疑已經被利用，優先隔離主機、保留證據、輪換憑證，再做清理。不要只靠卸載模組或清 cache 就認為安全。

關於 drop_caches

Microsoft 文中提到，在某些入侵後完整性驗證場景，可以評估是否清理 cache：

`1`	`echo 3 \| sudo tee /proc/sys/vm/drop_caches`

但這不是漏洞修復命令，也不是入侵清理命令。清 cache 可能帶來額外磁碟 I/O 和生產效能影響，只適合在理解影響後作為輔助操作。真正的修復仍然是打補丁、重啟、檢查完整性和排查持久化。

總結

Dirty Frag 不是一個「遠端一鍵打穿」的漏洞，但它會顯著放大已經入侵後的風險。只要攻擊者能獲得本地低權限執行機會，就可能藉助 CVE-2026-43284 以及相關 rxrpc 攻擊面把權限提升到 root。

對管理員來說，重點不是研究 PoC，而是盡快完成三件事：確認內核是否受影響，安裝發行版安全更新並重啟；在補丁窗口前評估停用相關模組；對已經暴露或疑似被入侵的系統做完整性和持久化檢查。

參考連結：