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，而是盡快完成三件事：確認內核是否受影響，安裝發行版安全更新並重啟；在補丁窗口前評估停用相關模組；對已經暴露或疑似被入侵的系統做完整性和持久化檢查。

參考連結：

內核安全 on KnightLi的博客