漏洞分析 on KnightLi的博客

CVE-2026-43494 / PinTheft：Linux RDS 與 io_uring 組合出的本地提權風險

Fri, 22 May 2026 15:16:59 +0800

CVE-2026-43494 是一個 Linux 核心本地權限提升風險，外界也用 PinTheft 來稱呼相關利用鏈。它的關鍵不在遠端入口，而在於本地低權限使用者能否同時碰到 RDS zerocopy、io_uring fixed buffer、可讀 SUID-root 程式和合適的核心版本。

需要先說明一個編號細節：Unclecheng-li/poc-lab 倉庫目錄名寫的是 CVE-2026-43494 PinTheft，README 標題裡又寫了 QVD-2026-27616 - PinTheft。從公開 CVE 條目和第三方通告來看，CVE-2026-43494 指向的是 Linux kernel RDS zerocopy 中 op_nents 未正確重置引發的 double-free / 引用計數異常問題；QVD-2026-27616 更像是奇安信風險通告編號。實際排查時建議同時記錄這兩個標識，但以發行版安全公告和核心補丁狀態為準。

漏洞核心是什麼？

這個問題出現在 Linux RDS，也就是 Reliable Datagram Sockets 的 zerocopy 發送路徑中。公開描述裡的關鍵函式是：

1
2

rds_message_zcopy_from_user()
rds_message_purge()

當 iov_iter_get_pages2() 在 rds_message_zcopy_from_user() 中失敗時，已經 pin 住的頁面會先被錯誤路徑釋放；但相關 op_nents 資訊沒有被正確清零，後續 rds_message_purge() 仍可能按殘留條目再釋放一次。結果就是同一批頁面引用被多減，形成可被利用的引用計數錯誤。

單看 RDS bug，它是核心記憶體管理裡的錯誤路徑問題。PinTheft 的危險之處在於利用鏈把它和 io_uring 固定緩衝區機制連了起來：io_uring 仍保存著舊的 struct page *，而頁面本身已經被釋放並重新分配給其他用途。PoC 進一步把這個狀態引向 SUID-root 程式的 page cache 覆寫，最終達到本地提權。

為什麼叫 PinTheft

io_uring REGISTER_BUFFERS 會固定使用者頁。對普通頁面來說，FOLL_PIN 並不只是簡單增加一個引用，而是透過較大的 bias 增加 page refcount。公開 PoC 中使用了 GUP_PIN_COUNTING_BIAS = 1024 這個概念。

PinTheft 這個名字的意思是：攻擊鏈透過 RDS zerocopy 的失敗路徑，一次次「偷走」這些 pin 引用。等引用被耗掉後，io_uring 仍以為自己持有有效頁面，但該實體頁已經可以被釋放並被 page cache 重新占用。

這類漏洞容易被誤讀成「直接改了磁碟上的 /usr/bin/su」。更準確的說法是：利用鏈嘗試覆寫的是記憶體中的 page cache。檔案本體不一定被寫回磁碟，但核心執行該 SUID 程式時可能從被污染的頁快取取指令，從而執行攻擊載荷。

觸發條件並不寬

這不是一個「任意 Linux 伺服器都能遠端打」的漏洞。公開資訊顯示，利用鏈至少依賴這些條件：

核心啟用了 CONFIG_RDS 和 CONFIG_RDS_TCP。
系統啟用了 CONFIG_IO_URING，且 kernel.io_uring_disabled=0。
rds / rds_tcp 模組已經載入，或低權限使用者可以觸發自動載入。
本地存在可讀的 SUID-root 二進位程式，例如 /usr/bin/su、/usr/bin/passwd、/usr/bin/pkexec。
公開 PoC 還依賴較新的 IORING_REGISTER_CLONE_BUFFERS API，CloudLinux 的分析提到公共 PoC 更偏向 kernel 6.13 及以上形態。

只要其中一環不成立，公開鏈路就會斷掉。比如很多 RHEL 系發行版預設不編譯 RDS，Ubuntu 舊核心可能缺少 PoC 需要的 io_uring clone buffer API，部分環境也會限制非特權使用者自動載入 RDS 模組。

一分鐘自查

先看核心設定：

1
2

zgrep -E "CONFIG_(RDS|RDS_TCP|IO_URING)" /proc/config.gz 2>/dev/null \
  || grep -E "CONFIG_(RDS|RDS_TCP|IO_URING)" /boot/config-$(uname -r)

再看 io_uring 是否被禁用：

`1`	`cat /proc/sys/kernel/io_uring_disabled 2>/dev/null`

常見含義可以按這個思路理解：

0：允許使用，風險面最大。
1：限制非特權使用者使用，具體行為看核心版本和發行版策略。
2：禁用 io_uring。

檢查 RDS 模組是否存在、是否可載入：

1
2

lsmod | grep -E "^rds|^rds_tcp"
modprobe -n -v rds_tcp 2>&1 | head -3

如果 CONFIG_RDS 是 not set，或者系統根本沒有 rds_tcp 模組，通常就無法走到這個 bug。反過來，如果 RDS 可用、io_uring 未禁用、系統又是較新的通用核心，就應該提高優先級繼續確認發行版修復狀態。

哪些機器更值得優先看？

優先排查這些環境：

多使用者 Linux 主機、教學機、跳板機、共享開發機。
容器宿主機，尤其是允許不可信本地使用者或較寬鬆容器逃逸面的環境。
開啟較新 mainline / rolling kernel 的桌面或伺服器，例如 Arch 一類滾動發行版。
HPC、Oracle RAC 或其他可能真實使用 RDS 的場景。
允許非特權使用者執行大量本地程式碼的 CI worker、建置機和實驗環境。

普通 Web 服務如果只有受控服務帳號執行應用，並且 RDS 未啟用，實際風險會低很多。但「低很多」不等於不用處理：核心本地提權的典型影響是攻擊者先透過 Web、SSH、CI、容器或應用漏洞拿到低權限，再用本地提權擴大控制面。

臨時緩解建議

正式修復仍應以發行版核心更新為準。補丁、回溯版本和受影響範圍需要看 Debian、Ubuntu、RHEL、AlmaLinux、Rocky Linux、SUSE、Arch、雲廠商或容器基礎映像各自的安全公告，不要只按上游版本號判斷。

在等待補丁或無法馬上重啟核心時，可以按環境選擇臨時措施：

# 如果業務不依賴 RDS，可阻止相關模組載入
sudo sh -c "printf 'install rds /bin/false\ninstall rds_tcp /bin/false\ninstall rds_rdma /bin/false\n' > /etc/modprobe.d/pintheft.conf"
sudo rmmod rds_tcp 2>/dev/null
sudo rmmod rds_rdma 2>/dev/null
sudo rmmod rds 2>/dev/null

如果業務不依賴 io_uring，也可以考慮禁用或限制它：

`1`	`sudo sysctl -w kernel.io_uring_disabled=2`

持久化設定需要寫入對應的 /etc/sysctl.d/*.conf。不過這一步要謹慎，現代資料庫、代理、執行時或高效能 I/O 程式可能使用 io_uring；生產環境修改前最好先確認業務依賴。

修復後怎麼驗證

升級核心後，不要只看套件管理器輸出成功。建議確認三件事：

1
2
3

uname -a
cat /proc/sys/kernel/io_uring_disabled 2>/dev/null
modprobe -n -v rds_tcp 2>&1 | head -3

如果發行版公告明確寫明已修復 CVE-2026-43494，即使 uname -r 看起來不是最新上游版本，也可能是已經回溯補丁的穩定核心。反過來，如果核心來源是自行編譯、第三方倉庫、雲市場映像或容器宿主機模板，就要繼續核對補丁 commit 和建置時間。

參考資訊

CVE-2026-42945 怎麼排查？Nginx Rift 漏洞觸發條件、版本檢查與升級建議

Fri, 15 May 2026 17:55:42 +0800

CVE-2026-42945 是 NGINX Open Source 和 NGINX Plus 中的一個安全漏洞，外界也把它稱為 Nginx Rift。它出現在 ngx_http_rewrite_module，漏洞類型是 heap-based buffer overflow。

這類新聞很容易被寫成「潛伏 18 年」「不用密碼遠端控制」「三成伺服器中招」。這些說法有傳播性，但看補丁和 NVD 描述時，最好把風險拆開看：它確實嚴重，也確實不需要登入帳號；但並不是所有 Nginx 實例都會自動被接管，觸發需要特定 rewrite 設定和請求條件。

先看官方描述

NVD 對 CVE-2026-42945 的描述可以概括為：

影響 NGINX Plus 和 NGINX Open Source。
漏洞位於 ngx_http_rewrite_module。
當 rewrite 指令後面跟著 rewrite、if 或 set 指令，並且使用未命名的 PCRE 捕獲組，例如 $1、$2，同時替換字串裡包含問號 ? 時，可能觸發問題。
未認證攻擊者可以傳送構造請求觸發漏洞。
結果可能是 NGINX worker 程序發生 heap buffer overflow 並重啟。
如果系統關閉了 ASLR，存在程式碼執行可能。

F5 作為 CNA 給出的評分是：

CVSS v4.0：9.2，Critical。
CVSS v3.1：8.1，High。
CWE：CWE-122 Heap-based Buffer Overflow。

所以，這不是普通的「設定寫錯導致 404」問題，而是 Nginx 官方安全修復範圍內的記憶體安全漏洞。

哪些說法需要降溫

第一，「不用密碼」基本可以理解為未認證攻擊。也就是說，攻擊者不需要登入 Nginx 後台，不需要拿到 SSH，也不需要應用系統帳號。但這不等於任何公網 Nginx 都能被隨手接管。

第二，「直接遠端控制」要看條件。官方描述裡更穩妥的說法是：漏洞可導致 worker 程序重啟；在 ASLR 關閉的系統上，程式碼執行是可能結果。對啟用了 ASLR、發行版編譯加固完整、執行權限受限的環境，風險路徑會更複雜。

第三，「30% 伺服器中招」不能簡單等同於「所有 Nginx 市占率都是漏洞暴露面」。真正暴露要同時看版本、是否啟用受影響模組、是否存在特定 rewrite 設定、發行版是否已經回補補丁，以及 Nginx 執行環境的加固狀態。

更準確的判斷方式是：只要你在生產環境執行 Nginx，就應該盡快檢查；但不要只按標題裡的比例判斷自己是否中招。

受影響範圍怎麼判斷

從 nginx.org 發布資訊看，2026 年 5 月 13 日發布的 nginx-1.30.1 stable 和 nginx-1.31.0 mainline 包含多項安全修復，其中包括 ngx_http_rewrite_module 的 buffer overflow，也就是 CVE-2026-42945。

如果你使用官方 Nginx 原始碼或官方套件，可以優先關注：

NGINX Open Source stable：升級到 1.30.1 或之後版本。
NGINX Open Source mainline：升級到 1.31.0 或之後版本。
NGINX Plus：查看 F5 對應分支的修復版本。

如果你使用 Debian、Ubuntu、RHEL、AlmaLinux、Rocky Linux、Alpine、容器映像、Plesk、控制面板、Ingress Controller 或雲廠商託管元件，不要只看 nginx -v 裡的上游版本號。很多發行版會把安全補丁 backport 到舊版本套件裡，版本號看起來舊，但補丁可能已經合入。

一分鐘判斷是否需要緊急處理

可以先按下面幾個問題快速分級：

這台 Nginx 是否直接暴露在公網，或者位於 API Gateway、反向代理、負載均衡、Ingress 入口層？
是否使用官方 Nginx 套件、原始碼編譯套件、第三方面板、容器映像，且還沒有確認 CVE-2026-42945 修復狀態？
設定裡是否存在複雜 rewrite 規則，尤其是連續 rewrite、if、set，以及 $1、$2 這類未命名捕獲組？
是否存在把請求路徑、查詢參數或使用者可控輸入帶入 rewrite 目標的場景？
系統加固是否較弱，例如 ASLR 被關閉、worker 權限過高、容器權限過寬？

如果前兩項命中，並且 rewrite 設定還沒有排查，建議按高優先級處理。公網入口、共享環境、Kubernetes Ingress、邊緣代理和承載登入/API 流量的 Nginx，應該優先升級或替換到確認修復的套件。

Debian / Ubuntu / RHEL / Alpine 如何確認修復

發行版使用者不要只看 nginx -v。Debian、Ubuntu、RHEL、AlmaLinux、Rocky Linux、Alpine 這類系統經常把安全補丁回補到穩定分支，表面版本號可能仍然低於 nginx.org 的 1.30.1 或 1.31.0。

Debian / Ubuntu 可以優先看安全公告、套件 changelog 和可升級列表：

nginx -v
nginx -V
apt list --upgradable | grep nginx
apt changelog nginx | grep -i "CVE-2026-42945"

RHEL / AlmaLinux / Rocky Linux 可以看安全更新和套件變更記錄：

1
2

yum updateinfo list security | grep -i nginx
rpm -q --changelog nginx | grep -i "CVE-2026-42945"

Alpine 可以檢查目前套件版本和安全分支更新：

1
2

apk info -v nginx
apk version -v nginx

如果套件管理器、發行版安全公告或廠商 advisory 明確寫明已修復 CVE-2026-42945，即使上游版本號看起來不新，也可以按「已回補修復」處理。反過來，如果只是版本號較高但來源不明，仍然要確認建置日期和補丁來源。

容器映像與 Ingress Controller 怎麼查

容器環境要檢查映像裡的 Nginx，而不是只看宿主機。先確認映像實際內建版本：

1
2

docker run --rm your-nginx-image nginx -v
docker run --rm your-nginx-image nginx -V

還要看基礎映像是否更新過。如果映像基於 Debian、Ubuntu、Alpine 或發行版套件建置，判斷方式應回到對應發行版的安全公告和套件 changelog。只重啟舊映像沒有意義，映像本身需要重新建置或替換。

Kubernetes Ingress 需要同時確認三件事：

Ingress Controller 專案是否發布了針對 CVE-2026-42945 的 advisory 或修復版本。
目前叢集執行的 controller 映像 digest 是否已經更新，而不是只改了 tag。
controller 內建 Nginx 版本、建置參數和模板設定是否仍然包含高風險 rewrite 規則。

可以先看執行中的映像：

1
2

kubectl -n ingress-nginx get pods -o wide
kubectl -n ingress-nginx describe pod <pod-name> | grep -i image

如果使用雲廠商託管 Ingress 或網關，還要查對應雲服務公告。託管元件通常不是使用者自己 apt upgrade 能解決的，需要等待廠商修復或切換到已修復版本。

rewrite 設定重點排查哪些寫法

這個漏洞和 rewrite 設定有關，排查時可以先搜尋 Nginx 設定：

1
2

grep -R "rewrite" /etc/nginx -n
grep -R "\\$[0-9]" /etc/nginx -n

重點關注類似模式：

`1`	`rewrite ^/old/(.*)$ /new/$1? permanent;`

這裡的 $1、$2 這類未命名捕獲組，以及替換目標中的 ?，是官方描述裡的關鍵條件之一。排查時尤其關注下面幾類寫法：

一個 rewrite 後面緊跟另一個 rewrite、if 或 set。
正則裡使用 (.*)、(.+) 這類寬泛捕獲，並在目標裡用 $1、$2。
rewrite 目標裡帶 ?，用於拼接或丟棄查詢參數。
rewrite 輸入來自公網路徑、Host、URI、參數或上游可控值。
面板、網關、Ingress 註解或模板自動生成的 rewrite 規則。

如果短時間內無法升級，可以先做臨時緩解：

減少複雜 rewrite 規則。
把未命名捕獲組改成更清晰的命名捕獲。
避免在替換字串裡拼接不必要的 ?。
對高風險入口加 WAF 或反向代理規則。
確認系統啟用了 ASLR。
降低 Nginx worker 執行權限，確認 systemd sandbox、SELinux/AppArmor 等加固狀態。

這些只是緩解，不是替代補丁。

修復優先級

建議按暴露面排序：

公網入口 Nginx。
反向代理、API Gateway、邊緣網關。
多租戶環境裡的 Nginx。
Kubernetes Ingress Controller。
Plesk、面板工具、雲市場映像等自帶 Nginx 的元件。
內網但承載關鍵業務的 Nginx。

升級後如何驗證：nginx -t、reload、worker 狀態

更新後不要只看套件管理器提示成功，還要確認設定、程序和實際二進位都已經切換。先驗證設定：

`1`	`nginx -t`

確認沒有錯誤後再平滑載入：

`1`	`systemctl reload nginx`

如果套件升級涉及二進位替換，建議確認舊 worker 已退出：

`1`	`ps aux \| grep nginx`

也可以查看主程序啟動時間和二進位路徑，確認執行中的服務不是舊程序繼續駐留。必要時安排維護窗口重啟服務，避免舊 worker 或舊容器繼續處理請求。

容器和 Ingress 環境還要確認新映像已經真正滾動完成：

1
2

kubectl -n ingress-nginx rollout status deployment/<deployment-name>
kubectl -n ingress-nginx get pods -o wide

驗證重點不是「命令執行過」，而是「線上流量已經由包含修復的 Nginx 程序承載」。

不要忽略同批次 Nginx 修復

nginx.org 在同一天發布的 1.30.1 和 1.31.0 不只修復了 CVE-2026-42945。發布資訊還提到 HTTP/2 request injection、SCGI/uWSGI buffer overread、charset module buffer overread、HTTP/3 address spoofing、OCSP resolver use-after-free 等問題。

這意味著生產環境不應該只針對單個 CVE 做臨時規則，而是應該把 Nginx 這一輪安全更新當成一次整體升級來處理。

小結

CVE-2026-42945 的關鍵點不是「所有 Nginx 都會被秒控」，而是：一個長期存在於 rewrite 模組裡的記憶體安全漏洞，在特定設定下可被未認證請求觸發，最直接後果是 worker 崩潰重啟；在 ASLR 關閉等較弱環境下，程式碼執行風險更高。

對維運來說，處理順序很簡單：

確認 Nginx 來源和版本。
查看發行版、F5、nginx.org 或雲廠商公告。
盡快升級到包含修復的版本或發行版安全套件。
排查複雜 rewrite 設定，尤其是 $1、$2 和 ? 組合。
確認 ASLR、權限隔離和服務重載狀態。

標題可以嚇人，修復要冷靜。先確認暴露面，再升級，再回頭清理高風險 rewrite 規則。

參考連結

Copy Fail 漏洞 CVE-2026-31431：Linux 核心檔案複製路徑中的容器逃逸風險

Fri, 01 May 2026 18:42:34 +0800

Copy Fail 是一個影響 Linux 核心檔案複製路徑的漏洞，編號為 CVE-2026-31431。 Bugcrowd 的分析把它稱為一個值得關注的核心級問題：在特定條件下，非特權使用者可以利用檔案複製相關邏輯觸發越權寫入，進而造成權限提升或容器逃逸。

從風險角度看，它不是普通應用層漏洞。問題發生在核心處理檔案複製和頁面快取的路徑上，因此影響面會延伸到容器、共享主機、CI/CD Runner、PaaS 平台和多租戶 Linux 環境。如果攻擊者已經能在系統裡執行低權限程式碼，漏洞就可能成為進一步突破隔離邊界的跳板。

漏洞大致發生在哪裡

Copy Fail 關聯的是 Linux 核心中的檔案複製能力。現代 Linux 提供了多種高效複製路徑，例如 copy_file_range、splice 類路徑以及不同檔案系統之間的資料複製最佳化。這些機制的目標是減少使用者態和核心態之間的資料搬運，提高大檔案複製效能。

問題在於，高效能複製路徑通常會複用頁面快取、檔案偏移、權限檢查和檔案系統回呼。如果其中某個邊界條件處理不嚴，核心可能在錯誤的權限上下文裡執行寫入，或者把本不應該被修改的資料頁暴露給攻擊者控制。

Copy Fail 的核心風險可以概括為：

攻擊者不需要 root 權限；
攻擊入口來自常見檔案複製能力；
影響點在核心態；
在容器環境裡，漏洞可能繞過命名空間和掛載隔離；
成功利用後可能寫入宿主機上不應被容器修改的內容。

這也是它被重點討論的原因。容器安全依賴 Linux 核心提供隔離能力，一旦核心路徑本身出現越權寫入，容器邊界就會變得脆弱。

為什麼容器場景更敏感

容器並不是虛擬機。容器內行程和宿主機共享同一個 Linux 核心，只是透過 namespace、cgroup、capability、seccomp、AppArmor/SELinux 等機制做隔離。

如果漏洞發生在使用者態服務裡，通常只影響某個容器或某個行程。但如果漏洞發生在核心裡，尤其是可以被非特權使用者觸發的核心漏洞，攻擊者可能從容器內部影響宿主機。

Copy Fail 的危險點就在這裡。很多平台允許使用者提交建置任務、執行腳本、啟動容器或執行外掛。攻擊者只要能在容器裡執行程式碼，就可能嘗試利用核心檔案複製路徑突破隔離。

高風險環境包括：

Kubernetes 叢集中的不可信工作負載；
CI/CD 平台的共享 Runner；
允許使用者上傳程式碼執行的沙箱平台；
多租戶 Linux 主機；
容器化 PaaS；
執行第三方外掛或擴充的系統。

如果這些環境裡的核心版本處於受影響範圍，而且缺少額外限制，風險就會明顯升高。

受影響範圍要看核心補丁狀態

這類漏洞的判斷不能只看發行版名稱。同一個 Ubuntu、Debian、RHEL、Fedora 或 Arch 版本，是否受影響取決於目前實際執行的核心套件，以及發行版是否已經回補補丁。

排查時應優先確認三件事：

目前執行核心版本；
發行版安全公告是否提到 CVE-2026-31431；
雲端廠商或託管平台是否已經完成宿主機核心修復。

可以先在系統上確認核心版本：

`1`	`uname -a`

然後查看發行版安全公告、核心 changelog 或雲端平台公告。不要只根據主版本號判斷是否安全，因為很多企業發行版會把安全補丁回補到舊版本核心裡。

臨時緩解思路

最可靠的修復方式仍然是更新核心。但在補丁無法立刻部署的環境裡，可以先降低暴露面。

常見緩解方向包括：

禁止不可信使用者執行特權容器；
避免給容器掛載敏感宿主機路徑；
收緊容器 capability，尤其不要隨意授予 CAP_SYS_ADMIN；
使用 seccomp、AppArmor 或 SELinux 限制危險系統呼叫和檔案存取；
將不可信工作負載遷移到隔離更強的虛擬機；
對 CI/CD Runner 做按任務銷毀，避免長期複用同一宿主機；
監控異常檔案寫入、權限變更和容器逃逸跡象。

這些措施不能替代補丁。它們的作用是降低攻擊成功率和影響面，特別是在補丁發布到生產環境之前爭取緩衝時間。

修復優先級

建議按環境風險排序處理。

優先修復：

對外提供容器執行能力的平台；
執行不可信程式碼的 CI/CD 節點；
多租戶 Kubernetes 節點；
有使用者自定義外掛或腳本執行能力的系統；
共享開發機、教學機、實驗平台。

相對低優先級：

單使用者桌面；
只執行可信服務的內網主機；
已經使用虛擬機隔離不可信程式碼的環境。

即便風險較低，也建議隨發行版更新核心。核心漏洞常常會被組合進更複雜的攻擊鏈裡，拖延補丁沒有太多收益。

給維運團隊的檢查清單

可以按下面順序處理：

盤點所有 Linux 主機和容器節點；
標記會執行不可信程式碼的機器；
檢查目前核心版本和發行版安全公告；
優先更新高風險節點；
對無法立即更新的節點啟用臨時隔離策略；
檢查容器執行時設定，移除不必要的特權和宿主機掛載；
更新後重啟節點，確認新核心已經實際生效；
保留變更記錄，方便後續稽核。

核心套件安裝完成並不代表系統已經執行在新核心上。更新後必須重啟，並再次確認：

`1`	`uname -a`

小結

Copy Fail / CVE-2026-31431 的重點不是某個應用崩潰，而是 Linux 核心檔案複製路徑中的權限邊界問題。它讓非特權程式碼有機會觸碰更高權限的資料寫入路徑，因此在容器和多租戶環境裡尤其值得重視。

處理這類漏洞時，最重要的是兩件事：

盡快跟進發行版或雲端廠商提供的核心補丁；
在補丁部署前限制不可信程式碼、特權容器和敏感宿主機掛載。

對個人桌面來說，它可能不是馬上需要恐慌的問題。但對執行容器平台、CI/CD、沙箱和共享主機的團隊來說，應該把它當作高優先級核心安全更新處理。

參考來源：