跳至內容
Linux 核心 DirtyClone 本地提權漏洞:Gentoo 更新建議

Linux 核心 DirtyClone 本地提權漏洞:Gentoo 更新建議

2026-06-27·Zakk
Zakk

JFrog 安全研究團隊於 2026 年 6 月 25 日公開了 Linux 核心本地提權利用 DirtyClone。它利用 CVE-2026-43503 中 socket buffer(skb)共享分片旗標傳遞不完整的問題,可將原本只讀的檔案頁快取變成核心中的寫入目標。該漏洞的 CVSS v3.1 評分為 8.8。

截至 2026-06-27,Gentoo 目前提供的受支援核心版本已經包含 CVE-2026-43503 的上游修復。更新核心軟體套件後需要重啟才能切換到新版本;舊核心仍在執行期間不受保護。

修復方案

Gentoo 對以下三個核心軟體套件提供安全支援:

軟體套件名稱目前狀態
sys-kernel/gentoo-kernel目前版本已覆蓋上游修復
sys-kernel/gentoo-kernel-bin目前版本已覆蓋上游修復
sys-kernel/gentoo-sources目前版本已覆蓋上游修復

sys-kernel/vanilla-sources 不在 Gentoo 安全支援範圍內。

先同步倉庫,再更新自己正在使用的核心軟體套件。Gentoo 的 Distribution Kernel 文件說明,這類核心透過 Portage 安裝並隨軟體套件更新。下面以預編譯核心為例;使用其他受支援核心時替換軟體套件名稱:

emerge --sync
emerge --ask --update sys-kernel/gentoo-kernel-bin

gentoo-kernelgentoo-kernel-bin 使用者應確認新核心已經安裝並由載入程式選中。gentoo-sources 使用者還需要按自己的配置重新編譯和安裝核心。隨後重啟,並確認實際執行的版本:

uname -r

Linux CNA 記錄列出的各穩定分支修復下限如下;主線方面,JFrog 記錄的首個修復標籤是 v7.1-rc5,Linux CNA 列出的正式修復版本是 7.1。使用自行配置的核心或不受 Gentoo 支援的核心軟體套件時,可據此檢查:

核心分支首個修復版本
5.105.10.257
5.155.15.208
6.16.1.174
6.66.6.141
6.126.12.91
6.186.18.33
7.07.0.10
7.1v7.1-rc5;正式版為 7.1
Gentoo 已宣佈正在終止對 5.10 和 5.15 分支的支援,並計劃於 2026-07-03 從倉庫移除相關包。仍在使用這些分支的使用者應遷移到受支援的新 LTS 分支。

漏洞影響

成功利用需要同時具備以下條件:

  • 系統執行缺少完整修復的核心;
  • 攻擊者能夠在本機執行程式碼;
  • 攻擊者擁有或能夠在使用者/網路名稱空間中取得 CAP_NET_ADMIN
  • 核心允許攻擊者配置所需的 XFRM/IPsec 和資料包(packet)複製路徑。

非特權使用者名稱空間常被用來取得網路名稱空間內的 CAP_NET_ADMIN,因此啟用該功能的主機風險更高。允許不受信任工作負載建立使用者和網路名稱空間,或向容器授予網路管理能力的多租戶與容器環境,也應優先更新。

JFrog 的利用會讓 IPsec 對檔案頁快取執行原地解密,從而修改記憶體中的特權程式,例如 /usr/bin/su。磁碟檔案本身不會改變,常規的磁碟完整性檢查可能無法發現攻擊;研究人員也沒有觀察到相應的核心日誌或審計記錄。

技術原因

SKBFL_SHARED_FRAG 表示 skb 的分片引用了由外部持有或與其他物件共享的記憶體。後續程式碼準備原地寫入時,應根據這個旗標先執行寫時複製,避免修改仍與檔案頁快取共享的物理頁。

CVE-2026-43503 修復前,__pskb_copy_fclone()skb_shift()skb_gro_receive()skb_gro_receive_list()skb_segment()tcp_clone_payload() 等分片轉移路徑沒有完整傳遞該旗標。複製後的 skb 仍引用相同頁面,卻被錯誤報告為沒有共享分片。攻擊者可藉助資料包(packet)複製路徑將這樣的 skb 送入 ESP 原地解密流程,最終寫入只讀檔案的頁快取。

該修復提交的 author date 是 5 月 16 日,5 月 21 日由網路子系統維護者合併;包含該提交的首個主線標籤是 5 月 24 日釋出的 Linux v7.1-rc5。CVE 於 5 月 23 日公開,JFrog 於 6 月 25 日釋出完整分析。

緩解方案

以下措施只用於暫時阻斷公開的 DirtyClone 利用路徑,不能替代核心更新。所有指令需要以 root 身份執行(sudo su 或在每條指令前加 sudo)。

禁止建立新的使用者名稱空間

Gentoo 可以使用 Linux 官方 max_user_namespaces 引數,臨時設定並寫入持久配置:

sysctl -w user.max_user_namespaces=0
printf '%s\n' 'user.max_user_namespaces=0' > /etc/sysctl.d/99-disable-userns.conf

sysctl -w 執行時會直接輸出確認行:

user.max_user_namespaces = 0

確認當前值和持久配置均已生效:

sysctl user.max_user_namespaces
# user.max_user_namespaces = 0

cat /etc/sysctl.d/99-disable-userns.conf
# user.max_user_namespaces=0

這會把當前使用者名稱空間中任一使用者可新建的使用者名稱空間數量設為 0;在宿主機的初始使用者名稱空間中執行時,也會限制特權程序。已經存在的名稱空間不會因此消失;如果依賴這項措施臨時防護,建議寫入持久配置後在維護視窗重啟。依賴使用者名稱空間的程式和沙盒可能受到影響。

這項措施只阻止一般本地使用者透過新建使用者名稱空間取得 CAP_NET_ADMIN。它不能防護已經持有該 capability 的程式、特權容器或既有使用者名稱空間中的攻擊者,也不能阻斷不依賴使用者名稱空間的 Copy Fail 和 DirtyFrag/RxRPC 路徑;這類環境必須更新核心,或確認相應模組已被有效阻斷。

部分 Debian/Ubuntu 核心另有 kernel.unprivileged_userns_clone 引數,它不是通用的上游或 Gentoo 核心介面。

阻斷相關核心模組

不使用 IPsec 或 RxRPC 的系統可以阻止相關模組載入,並卸載已經載入的模組。對 DirtyClone 本身,關鍵是 esp4/esp6rxrpc 對應的是較早的 DirtyFrag/RxRPC(CVE-2026-43500)路徑:

mkdir -p /etc/modprobe.d
printf '%s\n' \
  'install esp4 /bin/false' \
  'install esp6 /bin/false' \
  'install rxrpc /bin/false' \
  > /etc/modprobe.d/block-dirtyfrag.conf

modprobe -r esp4 esp6 rxrpc

for module in esp4 esp6 rxrpc; do
  test ! -d "/sys/module/$module" || echo "$module is still active"
done

根據 kmod 官方手冊,modprobe.dinstall 指令會用指定指令替代正常模組載入,modprobe-r 引數用於卸載模組。不要忽略卸載錯誤或檢查指令的輸出。如果模組正在使用、已經編入核心,或由 initramfs 提前載入,這項措施不會完整生效;配置還需要進入 initramfs,或改用禁止使用者名稱空間或更新核心。遮蔽 esp4/esp6 會停用相應的 IPv4/IPv6 ESP 功能並影響依賴它們的 IPsec 連線。

更新核心後撤銷緩解措施

完成核心更新並重啟到新版本後,可以移除臨時配置並恢復預設值:

rm /etc/modprobe.d/block-dirtyfrag.conf
rm /etc/sysctl.d/99-disable-userns.conf
sysctl -w user.max_user_namespaces=2147483647

移除 modprobe.d 配置後,esp4/esp6/rxrpc 恢復按需載入,無需手動執行 modprobesysctl -w 立即恢復 user namespace 限制;2147483647 是該引數的核心預設值。

與早期漏洞的關係

DirtyClone 延續了 DirtyFrag 的頁快取寫入手法,但 Copy Fail、DirtyFrag 的兩條路徑和 Fragnesia 各有不同根因,臨時阻斷方式也不能互換。參見背景文章:Linux 頁快取寫入型提權漏洞梳理:Copy Fail、DirtyFrag、Fragnesia 與 DirtyClone

Gentoo 於 5 月 19 日公告,受支援核心當時已經包含最新的 Fragnesia v5 修補。該公告早於 DirtyClone 修復,不能單獨說明 CVE-2026-43503 的狀態;本文以 Linux CVE 記錄和 Gentoo 在 6 月 27 日提供的核心版本為準。

參考資料

最後更新於