Fragnesia（CVE-2026-46300）是 Linux 核心網路子系統的本地提權漏洞：已經能在主機上執行程式的低權限使用者，可能藉此改寫唯讀檔案在記憶體中的快取內容，進一步取得 root。CISA 在 2026 年 10 月 28 日把它列入已知遭利用漏洞目錄（KEV），修補期限是 10 月 31 日。
如果你管理的是 Linux 伺服器、NAS 或開發主機，這篇整理的是三件事：怎麼確認自己有沒有受影響、怎麼更新，以及暫時不能重開機時可以先做什麼。
想先了解 Dirty Frag 與「寫入唯讀檔案 page cache」這類漏洞的背景，可以前往 〈2026 年 10 月「趨勢科技 ZDI 提前公開 Linux 內核未修補漏洞」事件查核〉 觀看，本文不重複說明。
事件重點
這個漏洞不是 10 月才出現的新問題，時間軸拉長來看比較清楚：
| 日期 | 事件 | 來源 |
|---|---|---|
| 2026-05-13 | oss-security 郵件列表出現 Fragnesia 的公開說明，揭露者為 V12 security 團隊，列名 William Bowling | oss-security 貼文 |
| 2026-05-13 | V12 security 在 GitHub 的 pocs 倉庫公開 Fragnesia 的概念驗證程式（PoC） | V12 pocs 倉庫、AlmaLinux 公告 |
| 2026-05-16 | AlmaLinux 修補核心進入正式倉庫 | AlmaLinux 公告 |
| 2026-05-20 | Red Hat 發布 RHEL 8、9、10 的核心勘誤（RHSA） | Red Hat CVE 頁面 |
| 2026-05-23 | NVD 收錄 CVE-2026-46300 | NVD |
| 2026-10-28 | CISA 列入 KEV | CISA KEV |
| 2026-10-31 | KEV 設定的修補期限 | CISA KEV |
CISA 的 KEV 條目另外標示三件事：
- 是否被勒索軟體活動利用：Unknown（未知）。
- 需要依 BOD 26-04 的「Forensics Triage Requirements」做鑑識分流（Forensic Triage 欄位為 Yes）。
- NVD 記錄裡 CISA 的 SSVC 評估為「Exploitation: active」。
KEV 的說明文字還寫到，這個漏洞可以和 CVE-2026-109618、CVE-2026-109619 串接，用來植入 PHP webshell 並以 root 執行指令。這兩個編號在 NVD 都查得到，都是 PHP 本身的漏洞，並且同樣在 2026 年 10 月 26 日列入 KEV：
| 編號 | NVD 上的漏洞名稱 | 簡述 |
|---|---|---|
| CVE-2026-109618 | PHP Memory Corruption Vulnerability | 記憶體不足（OOM）處理後，請求記憶體處於未初始化狀態，可能導致遠端程式碼執行 |
| CVE-2026-109619 | PHP Stale Internal Request-State Vulnerability | 全域狀態指向已釋放的請求記憶體，可能導致遠端程式碼執行 |
換句話說，KEV 描述的情境是：網站程式先被 PHP 漏洞打進來，再用核心漏洞往 root 提權。至於實際的攻擊活動細節，CISA 條目沒有進一步說明，本文也不推測。
漏洞是怎麼發生的
NVD 收錄的核心修補說明（commit message）寫得很具體，可以拆成三個環節：
- 核心的
skb_try_coalesce()會把一個封包緩衝區（skb）裡的分頁片段（paged frags）接到另一個 skb。 - 如果來源 skb 帶有
SKBFL_SHARED_FRAG標記，代表這些片段是外部擁有的，或是由 page cache 支撐的；合併後目標 skb 卻沒有保留這個標記。 - ESP 輸入處理會用
skb_has_shared_frag()判斷能否省略skb_cow_data()（先複製資料）。標記遺失時，ESP 會直接在原地解密，也就是改寫到 page cache 支撐的片段上。
修補的做法是在 skb_try_coalesce() 轉移分頁片段時一併帶過去這個標記。
補充說明：oss-security 貼文提到，觸發條件與
espintcp（ESP-in-TCP）模式有關：從檔案 splice 進 TCP 接收佇列的資料，在該 socket 切換到 espintcp 之前就已存在。貼文同時指出，被改寫的是 page cache，不會寫回磁碟。
各來源對漏洞類型的說法
同一個漏洞，不同單位用了不同的弱點分類與評分，以下並列，不做取捨：
| 來源 | 弱點分類（CWE） | CVSS v3.1 |
|---|---|---|
| NVD（主要） | CWE-787（越界寫入） | 7.8 |
| CISA（KEV 條目） | CWE-456（變數缺少初始化） | — |
| Red Hat | CWE-123（Write-what-where） | 7.8（Important） |
| SUSE | — | 8.8（Scope: Changed），CNA 與 NVD 為 7.8 |
NVD 與 Red Hat 的向量字串同為 AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H，意思是必須先有本機的低權限帳號、不需要使用者互動。這也是為什麼 Red Hat 把它評為 Important 而不是 Critical。
和 Dirty Frag 是同一個漏洞嗎
兩邊的說法不完全一致：
- Red Hat 的資安公告 RHSB-2026-003 把 Dirty Frag（CVE-2026-43284、CVE-2026-43500）與 Fragnesia（CVE-2026-46300）放在同一份公告裡處理。
- AlmaLinux 的公告寫明 Fragnesia 與 Dirty Frag 是不同的漏洞，只是影響同一塊程式區域與模組。
- Ubuntu 的條目寫 Fragnesia 的緩解方式與 Dirty Frag 相同。
實務上的重點有兩點：
- AlmaLinux 公告寫，已套用 Dirty Frag 模組封鎖設定的系統，Fragnesia 也一併被擋住。
- Tenable 的部落格（廠商文章，僅供參考）提到，只套用 Dirty Frag 核心修補的系統不受保護。所以更新後請照上一節的方式，確認核心版本已達到你的發行版對 CVE-2026-46300 公告的修補版本。
受影響範圍
上游核心版本（NVD）
NVD 的組態列出以下核心版本範圍屬於受影響：
| 核心分支 | NVD 標示的受影響範圍 |
|---|---|
| 3.9 至 5.10 | 3.9 起，到 5.10.257（含） |
| 5.11 至 5.15 | 5.11 起，5.15.208 以前 |
| 5.16 至 6.1 | 5.16 起，6.1.174 以前 |
| 6.2 至 6.6 | 6.2 起，6.6.141 以前 |
| 6.7 至 6.12 | 6.7 起，6.12.91 以前 |
| 6.13 至 6.18 | 6.13 起，6.18.33 以前 |
| 6.19 至 7.0 | 6.19 起，7.0.10 以前 |
| 7.1 | 7.1 rc1 到 rc4 |
發行版核心常常把修補移植到舊版號，不能只看上游版號就判斷。例如 Debian bullseye 的條目把 5.10.257-1（DLA-4606-1）列為已修補版本，和 NVD 對 5.10 分支「到 5.10.257（含）」的寫法邊界不同。實際判斷時，請以自己使用的發行版公告為準。
發行版公告
| 發行版 | 公告內容 | 來源 |
|---|---|---|
| Red Hat | RHEL 8、9、10 與依賴 RHEL 核心的產品（CoreOS、OpenShift、OpenStack、Virtualization）受影響；CVE 頁面的修補狀態為 Fixed，RHEL 8 kernel 為 RHSA-2026:19666、RHEL 9 為 RHSA-2026:19568、RHEL 10 為 RHSA-2026:19569（2026-05-20 發布） | RHSB-2026-003、Red Hat CVE 頁面 |
| Ubuntu | 22.04 LTS 修補於 5.15.0-181.191；24.04 LTS 於 6.8.0-124.124；25.10 於 6.17.0-35.35；26.04 LTS 於 7.0.0-22.22；26.10 不受影響 | Ubuntu 安全條目 |
| Debian | 首批修補版本：bookworm 6.1.174-1（DSA-6306-1）、trixie 6.12.90-1（DSA-6295-1）、bullseye 5.10.257-1（DLA-4606-1）。追蹤頁目前列 bookworm security 6.1.190-1、trixie security 6.12.116-1、forky 7.2.15-1、sid 7.3.4-1 為已修補 | Debian Security Tracker |
| SUSE | SLES 15 SP7 為 6.4.0-150700.53.55.1、SLES 16.0 為 6.12.0-160000.31.1 等，其他產品見條目 | SUSE CVE 頁面 |
| AlmaLinux | 8：4.18.0-553.124.3.el8_10、9：5.14.0-611.54.5.el9_7、10：6.12.0-124.56.3.el10_1 以上 | AlmaLinux 公告 |
Ubuntu 較舊的 20.04、18.04、16.04、14.04 也有對應的修補版本，其中 20.04 以前需要 Ubuntu Pro（16.04、14.04 另需 Legacy Support 附加項目），完整清單請看 Ubuntu 條目。SUSE 的條目列出超過一百筆勘誤，其中 Live Patching 與各子產品的版本也請直接查原頁。
怎麼檢查自己有沒有受影響
以下指令都是各家公告或發行版文件中出現的做法。貼上前請先確認自己的環境與權限。
- 先看目前執行的核心版本。把輸出和上一節你使用的發行版修補版本比對。版本等於或高於修補版本，並且已經重開機載入，就代表核心已經包含修補。
uname -r - Debian、Ubuntu 另外確認已安裝的核心套件（Ubuntu 公告的做法）。
dpkg -l 'linux-image*' | grep ^ii - 確認 ESP 與 rxrpc 相關模組有沒有被載入（Red Hat 公告用 esp4、esp6，Ubuntu 與 AlmaLinux 公告另外加上 rxrpc）。沒有輸出，代表目前這些模組沒有載入；有輸出，代表它們正在記憶體裡。
lsmod | grep -E 'esp4|esp6|rxrpc'
補充說明：模組沒有載入不等於安全。核心在需要時可能自動載入模組，所以「沒載入」只能說明現況，不能取代更新核心或封鎖模組。是否使用 IPsec VPN（例如 StrongSwan）也請一併確認，下面的緩解做法會影響這類服務。
修補：更新核心並重開機
官方公告一致建議的做法是更新核心。Ubuntu 公告說明核心更新與緩解設定是二選一，更新核心是優先做法；套用後都要重開機才會載入新核心。
Debian、Ubuntu
- 更新套件清單並升級。
sudo apt update && sudo apt upgrade - 重開機載入新核心。
sudo reboot - 重開機後再檢查一次版本。
uname -r
Ubuntu 公告提到預設啟用的 unattended-upgrades 會在 24 小時內自動套用安全更新，但仍需要自己重開機。
AlmaLinux、RHEL 系列
AlmaLinux 公告給的更新流程如下，鏡像站同步可能需要數小時，看不到新版本時稍後再試。
- 重新抓取中繼資料並升級。
sudo dnf clean metadata && sudo dnf upgrade - 重開機。
sudo reboot
RHEL 本身的修補版本，請到 Red Hat 客戶入口網站的 CVE-2026-46300 頁面與 RHSA 勘誤查詢；NVD 引用的勘誤超過三十筆，依版本與產品線各自對應。
暫時緩解：無法立刻重開機時
這是在不能馬上更新時的暫時做法，不是修補。Red Hat、Ubuntu、AlmaLinux 的公告都提到，核心更新完成後應移除這些設定。
做法一：封鎖 esp4、esp6（與 rxrpc）模組
Red Hat 公告的做法封鎖 esp4、esp6；Ubuntu 與 AlmaLinux 公告多封鎖了 rxrpc。Red Hat 公告指出 rxrpc 是 CVE-2026-43500 的範圍，並寫明該 CVE 不影響 Red Hat 產品，所以是否一併封鎖，取決於你使用的發行版公告與是否用到 AFS。
- 寫入模組封鎖設定（以下沿用 AlmaLinux 公告的檔名與寫法）。
sudo sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/fragnesia.conf" - 如果模組已經載入，嘗試卸載。使用中的模組會卸載失敗，這是正常的。
sudo rmmod esp4 esp6 rxrpc 2>/dev/null; true - Debian、Ubuntu 另外依 Ubuntu 公告重建 initramfs，讓開機早期階段也被封鎖。
sudo update-initramfs -u -k all - 確認模組現在是否仍在載入（Ubuntu 公告提供的檢查方式）。如果仍顯示已載入，Ubuntu 公告的說法是需要重開機才能讓封鎖生效。
grep -qE '^(esp4|esp6|rxrpc) ' /proc/modules && echo "Affected modules are loaded" || echo "Affected modules are NOT loaded"
補充說明：這個做法有代價。Red Hat、Ubuntu、AlmaLinux 公告都警告：封鎖 esp4、esp6 會讓 IPsec ESP 的 VPN 失效，封鎖 rxrpc 會讓 AFS 等 RxRPC 應用失效。有使用 IPsec 的主機，請優先更新核心，不要套用這個做法。
做法二：停用非特權的 user namespace
Red Hat 公告把它列為「保留 IPsec 的針對性做法」，適用於不能封鎖 esp4、esp6 的環境。
- 寫入 sysctl 設定並套用。
echo "user.max_user_namespaces=0" | sudo tee /etc/sysctl.d/dirtyfrag.conf sudo sysctl --system
補充說明：Red Hat 公告指出，停用非特權 user namespace 可能影響 rootless 容器、沙箱瀏覽器與 Flatpak。公告也提醒，關掉其中一種本機存取方式，不代表使用者沒有其他取得本機權限的途徑。
懷疑已被利用時
AlmaLinux 公告寫到，如果系統可能已經被針對性攻擊，可以清掉 page cache，讓被改寫的頁面重新從磁碟載入。
- 清空 page cache。
sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'
這個動作只處理記憶體中的快取，不等於入侵調查。KEV 條目要求適用單位依 CISA 的鑑識分流要求處理，若你的主機曾經暴露在網路上並執行 PHP 應用程式，也請一併確認 PHP 是否已更新。
移除緩解設定
核心更新並重開機後，Red Hat 與 Ubuntu 的公告都建議移除暫時設定。
- 刪除先前建立的設定檔（檔名依你實際建立的為準）。
sudo rm /etc/modprobe.d/fragnesia.conf - Debian、Ubuntu 再重建 initramfs。
sudo update-initramfs -u -k all
PHP 端要不要一起更新
KEV 提到的 CVE-2026-109618 與 CVE-2026-109619，NVD 記載的 PHP 受影響範圍相同：8.2.35 以前（CVE-2026-109618 從 7.3.0 起算，CVE-2026-109619 從 5.4.0 起算）、8.3.36 以前、8.4.27 以前與 8.5.12 以前。
CISA 的 PHP 警示列出的修補版本是 8.2.35、8.3.36、8.4.27 與 8.5.12，並寫明 PHP 8.1 以下的系統在修補或升級前應該下線。
這兩個漏洞的修補與 Fragnesia 無關，各自獨立，需要另外更新 PHP。
本文不寫實際的串接方式。如果你的主機同時跑 PHP 網站與可被本機登入的帳號，兩邊都更新是比較完整的處理。
目前能確認與不能確認的事
- 能確認：漏洞編號、NVD 與 CISA 的記錄、各發行版的修補版本與緩解做法，都來自上列公告原文。
- 公開資訊：Fragnesia 的概念驗證程式已由 V12 公開在 GitHub，AlmaLinux 公告也提到攻擊程式碼已公開。
- 尚未看到官方說明：實際被利用的攻擊活動規模與對象。KEV 只寫了串接 PHP 漏洞的情境，勒索軟體利用欄位為 Unknown。
- 各單位對弱點分類與評分不同（見前面的對照表），這不影響修補方式。
參考資料與延伸閱讀
- 站內延伸閱讀：2026 年 10 月「趨勢科技 ZDI 提前公開 Linux 內核未修補漏洞」事件查核
- NVD：CVE-2026-46300
- CISA 已知遭利用漏洞目錄（CVE-2026-46300）
- CISA BOD 26-04：Prioritizing Security Updates Based on Risk
- Red Hat：CVE-2026-46300
- Red Hat：RHSB-2026-003（Dirty Frag 與 Fragnesia）
- Ubuntu：CVE-2026-46300
- Ubuntu 部落格：Dirty Frag 修補與緩解
- Debian Security Tracker：CVE-2026-46300
- SUSE：CVE-2026-46300
- AlmaLinux：Fragnesia 公告
- oss-security：Linux kernel LPE（fragnesia）
- NVD：CVE-2026-109618
- NVD：CVE-2026-109619
- CISA：Critical Vulnerabilities in PHP Require Immediate Patching
- V12 security：Fragnesia PoC 倉庫
- Tenable：Fragnesia 常見問題（廠商部落格，僅作線索參考）
發佈留言