RefluXFS 可升至 root：真正受影響嘅 Linux server 同修補清單
先查 XFS reflink 同 kernel，裝完更新記得完整重啟
先講清楚：唔係一連網就會俾人入侵
Linux kernel 嘅 XFS 檔案系統爆出 RefluXFS 漏洞（CVE-2026-64600），CVSS 評分 7.8，公開 PoC 亦已經出現。攻擊者成功利用後，可以改寫受保護檔案，再攞到 root 權限。不過佢屬於本機權限提升漏洞：對方要先有普通本機帳戶，或者已經經另一個漏洞、惡意程式、失守服務或容器喺主機執行程式。單靠由網上連到一部 Linux server，並唔會直接觸發 RefluXFS。
GovCERT.HK 已經將事件列作高威脅警報 A26-07-38，中大 ITSC 亦發出修補通知。呢個級別合理，因為 PoC 已公開，而且成功後改動會留喺磁碟，重新開機都唔會自動還原。公司、學校、雲端平台同託管環境如果容許客戶、開發者或服務帳戶執行程式，風險自然高過單一用途、冇非信任帳戶嘅主機。
圖片：Wikimedia Commons — https://www.flickr.com/photos/jm3（CC BY-SA 2.0）
四個條件要一齊睇
真正需要優先處理嘅主機，要同時撞中幾個條件：運行 Linux kernel 4.11 或之後嘅未修補版本、磁碟用 XFS、XFS superblock 開咗 reflink=1，同一個檔案系統內仲要有攻擊者讀得到嘅高價值檔案，同埋普通用戶或程式寫得到嘅目錄。XFS reflink 會用 copy-on-write 快速複製檔案；漏洞出喺核心處理並行 direct I/O 時用咗過時嘅磁碟區塊映射，結果寫入可能落到原本共享嘅區塊。
RHEL 8 或之後建立嘅 XFS 一般預設開 reflink，Oracle Linux、Rocky Linux、AlmaLinux、Amazon Linux 同 Fedora Server 呢類環境值得先查。Ubuntu、Debian 同 SUSE 一般安裝預設冇用 XFS，普通桌面用戶相關度低好多；不過管理員如果安裝時自己揀過 XFS，或者另外掛載咗 XFS data volume，就仍然要檢查。
「1,640 萬部」只係潛在範圍
iThome 報道引述 Qualys，指佢哋按自家資產資料分析，估算全球可能有超過 1,640 萬部系統落入影響範圍。呢個數字唔代表已確認有咁多部主機齊備全部利用條件，亦唔代表全部已經遇到攻擊。盤點時應該按檔案系統設定、實際運行緊嘅 kernel，同主機有冇非信任程式執行入口排序，唔好淨係見到「Linux」就當成最高優先級。
SELinux Enforcing 亦唔可以當保證。Qualys 話佢哋喺開住 SELinux 嘅環境仍然成功利用，因為問題發生喺 XFS 磁碟區塊配置層。容器同樣要逐個 workload 睇：容器內程序如果接觸到受影響嘅 XFS 路徑，隔離設定未必截得到呢條攻擊路徑；冇掛載相關 XFS volume 嘅容器，風險就唔可以一概而論。
管理員可以跟住做
先找出 XFS 掛載點。 執行
findmnt -t xfs -o TARGET,SOURCE,FSTYPE,OPTIONS，記低系統碟、應用資料碟、容器 storage 同共享 volume。冇任何 XFS 掛載點，RefluXFS 呢條路就唔成立；有 XFS 就對每個掛載點執行xfs_info /掛載點 | grep -w reflink，輸出見到reflink=1先進入下一輪檢查。核對正在運行嘅 kernel。
uname -r只係起點，唔好單靠上游版本號落結論。RHEL、Ubuntu、Debian 同 SUSE 會將修補 backport 落舊 kernel，表面版本可能仍然細過上游已修補版。應該用 CVE-2026-64600 對照自己發行版、版本、訂閱分支同 kernel 套件公告。截稿時 Debian 已標示 Trixie6.12.96-1修好，但 Bookworm 同 Bullseye 部分套件仍列作受影響；狀態隨時會更新。安裝發行版提供嘅修補 kernel。 RHEL 系可經受支援 repository 更新 kernel，Debian、Ubuntu 同 SUSE 就用各自正常保安更新渠道。唔建議自行換上游 kernel 版本去估修補狀態，尤其係雲端 image、即時 kernel、長期支援分支同廠商特製 kernel；直接跟 vendor CVE 頁列出嘅已修補套件最穩陣。
安排完整重啟，再驗證一次。 淨係下載同安裝新 kernel，正在運行嗰個核心仍然係舊版本。重啟後再跑
uname -r，同 vendor 公告嘅修補套件核對。懷疑主機已經俾人利用，就要另外檢查 root 擁有嘅設定檔、SUID 程式、本機及服務帳戶、排程工作同憑證；更新 kernel 只會堵住漏洞，唔會清走已經寫入磁碟嘅改動。
修補優先次序要跟實際入口
最先處理多租戶主機、CI runner、容器 host、學生或開發者可以登入嘅 server，同埋已經俾外來程式取得執行能力嘅系統。只供單一服務、冇普通帳戶、又冇非信任 workload 嘅主機，仍然要修補，但可以排喺齊備利用條件嘅 XFS 主機後面。呢次最實際嘅做法係先用十幾分鐘盤點儲存設定，再按 vendor 公告修補同重啟。
參考來源
- iThome — Qualys揭露潛伏9年的Linux核心漏洞RefluXFS，可能影響全球超過1,640萬臺主機 — original report
- Qualys：RefluXFS 技術分析 — 漏洞發現者公布嘅先決條件、技術成因、測試結果同潛在影響資料。
- GovCERT.HK 高威脅保安警報 A26-07-38 — 香港官方風險級別、受影響上游版本範圍同修補建議。
- 中大 ITSC RefluXFS 保安通知 — 本地修補通知，確認 PoC 已公開、完整重啟要求同事後檢查重點。
- Linux kernel 上游修補 commit — Linux kernel 官方修補記錄，解釋點樣重新讀取過時嘅 XFS data fork mapping。
- Debian CVE-2026-64600 Security Tracker — 核對 Debian 各版本即時修補狀態，亦顯示點解唔應該只睇上游 kernel 版本。
- Red Hat CVE-2026-64600 — 確認 RHEL 受影響條件、已發佈套件同官方緩解資料。
本文根據原文及公開資料整理；資料有出入時，以原文及官方資料為準。
