GhostLock 現形:Linux rtmutex 堆疊生命週期錯亂長達 15 年,CVE-2026-43499 橫跨 2.6.39 到 7.1 全系列核心
oss-security 郵件列表 · 2026-07-08
德國研究者 Thomas Orgis 於 7 月 8 日在 oss-security 揭露一個被命名為 GhostLock 的 Linux 核心漏洞,編號 CVE-2026-43499。問題出在即時互斥鎖(rtmutex)的 remove_waiter() 函式,影響範圍從 2011 年的 2.6.39 一路延伸到最新的 7.1 分支。漏洞屬於堆疊層級的 use-after-free(UAF),可導致本地權限提升或系統當機。
漏洞機制
rtmutex 是核心用來實作優先權繼承(priority inheritance)鎖的機制,當一個執行緒等待鎖時,核心會建立一個 rt_mutex_waiter 結構,這個結構通常直接配置在等待者自己的核心堆疊上,而不是堆積(heap),因為它只在阻塞期間存活。問題在於 remove_waiter() 原本假設呼叫時的「當下執行緒」(current)就是要移除的等待者本人,但在優先權繼承鏈的特定情境下,函式其實是代表另一個 task 被呼叫,此時 waiter::task 並不等於 current。
當程式碼誤用 current 而非 waiter->task 去做紅黑樹(rbtree)的 dequeue 動作,會同時產生三個後果:一是移除節點時沒有取得正確的鎖保護;二是原本應該被清空的 task 狀態沒有清乾淨,留下一個指向已經返回、堆疊可能被重用的懸空指標;三是優先權調整動作套用到錯誤的等待者身上。第二點正是堆疊 UAF 的核心——等待者的堆疊框架一旦函式返回就可能被其他呼叫覆寫,而 rtmutex 內部仍握著指向該區域的參照,攻擊者只要能控制競爭時機與後續堆疊內容,就有機會把這個懸空參照導向自己布置好的資料,進而竄改核心記憶體並提權。
受影響版本
由於 rtmutex 的優先權繼承邏輯自 2.6.39 引入後幾乎沒有大改,這個錯誤在核心樹中潛伏了將近十五年。NVD 記錄列出的受影響區間包括:
2.6.39至6.1.1746.2至6.6.1396.7至6.12.856.13至6.18.266.19至7.0.3
Orgis 在信件中提到,實際觸發結果依發行版與組態不同而有差異:在 Ubuntu 使用 7.0.0-14 LTS 核心的機器上,PoC 會造成系統當機或掛起;但在 Debian 13(6.12.95+deb13-amd64)與原生 vanilla 6.6.144 上,同一份 PoC 卻沒有觸發問題,顯示實際可利用性與特定的鎖競爭時機、CPU 排程行為高度相關,並非每台機器都能穩定重現。
修補與緩解
官方修補程式為 3bfdc63936dd,提交訊息為「rtmutex: Use waiter::task instead of current in remove_waiter()」,已於 2026 年 4 月 21 日合併進主線,隨後回溯到多個穩定分支。修法很直觀:把函式內所有原本引用 current 的地方,改成明確使用傳入的 waiter->task,確保 dequeue 與狀態清除動作永遠作用在正確的等待者身上。
由於這是核心層級的競爭條件,沒有使用者空間可設定的緩解手段,唯一作法是升級到已包含該修補的核心版本。CVSS 3.1 評分為 7.8(HIGH),向量為 AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H,代表攻擊者需要本地低權限帳號存取,但無需使用者互動即可達成高衝擊的權限提升。
「Bad Epoll」:六道指令的競爭窗口,讓 Linux 與 Android 核心雙雙淪陷
oss-security 郵件列表 · 2026-07-08
首爾大學 CompSec Lab 研究者 Jaeyoung Chung 在 7 月 8 日發布代號 Bad Epoll 的本地提權漏洞,編號 CVE-2026-46242,存在於 Linux 核心 epoll 子系統的 ep_remove() 函式中。這是一個競爭條件引發的 use-after-free,漏洞早在 2023 年就被引入,直到今年才被完整揭露並證實可在 kernelCTF 目標與 Android 上達到 98% 以上的穩定提權成功率。
漏洞機制
epoll 允許一個檔案描述符同時監看多個其他描述符,甚至可以監看另一個 epoll 實例(俗稱 epoll 疊 epoll)。每個被監看的檔案會透過 file->f_ep 欄位串接進監看清單。ep_remove() 在把某個檔案從清單移除時,會先清空 file->f_ep,但接下來仍繼續在同一個臨界區間內使用該檔案指標,而沒有先確保沒有其他路徑正在動同一份物件。
問題就出在「同一個 epoll 檔案的兩條關閉路徑同時執行」的情境:一條路徑透過正常關閉呼叫 ep_remove(),另一條透過 __fput() 的併發釋放路徑,兩者對同一物件的存取只錯開大約六道組合語言指令的時間差,卻足以讓其中一條路徑把物件釋放,另一條路徑接著寫入一塊已經被釋放、甚至已被重新配置給別的用途的記憶體。
受影響版本
造成漏洞的程式碼變動於 2023 年 4 月 8 日以提交 58c9b016e128 引入,直到 2026 年 4 月 24 日才由 a6dc643c6931 修復。NVD 列出的受影響版本區間為:
5.15.209至5.166.1.175至6.26.4至6.18.326.19至7.0.9
換句話說,不只桌機與伺服器版核心中鏢,主線為 6.6 系列的 Android 通用核心(GKI)一樣受影響,研究者證實可在搭載 6.6+ 核心的 Pixel 10 上取得 root,而且攻擊起點可以是 Chrome 瀏覽器的 renderer 沙箱行程,不需要額外的沙箱逃逸漏洞去接觸到這段核心程式碼。
修補與緩解
公開的攻擊手法會準備四個 epoll 物件,分成兩組:一組專門用來觸發競爭、騰出一塊被釋放的記憶體洞,另一組則扮演受害者,被布局進同一塊剛釋放的記憶體。研究者接著利用 cross-cache 攻擊手法,把這次僅有 8 位元組的 UAF 寫入,轉換成對檔案物件內容的完整控制:
- 透過
/proc/self/fdinfo洩漏檔案物件內容,達成任意核心記憶體讀取 - 利用讀出的資訊建構 ROP 鏈,劫持核心控制流
- 最終取得 root 權限,在測試的 kernelCTF 目標(
lts-6.12.67、cos-121-18867.294.100)上達到 98%–99% 的成功率
修補程式 a6dc643c6931 調整了 ep_remove() 的加鎖順序與物件生命週期管理,確保清空 f_ep 與後續使用檔案指標之間不再存在可被利用的競爭窗口。CVSS 3.1 評為 7.8(HIGH),向量 AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H,由於觸發不需要特殊權限、只需要本地程式碼執行能力,對容器逃逸與瀏覽器沙箱逃逸場景尤其危險,使用者應盡快更新到含修補的核心或已回溯此修正的發行版套件。
Serena 儀表板零驗證曝險:DNS 重綁定接力 Shell 注入,讓 AI 代理工具變成遠端程式碼執行跳板
GitHub Security Advisory GHSA-37h2-6p4f-mp3q · 2026-07-08
AI 編碼代理工具 Serena(pip 套件 serena-agent)被揭露內建的 Web 儀表板存在完全無驗證的漏洞,編號 CVE-2026-49471。攻擊者只要誘騙受害者瀏覽一個惡意網頁,就能透過 DNS 重綁定跨越瀏覽器的同源限制,寫入被下毒的「記憶」內容,最終在受害者下次啟動代理工作階段時觸發任意 Shell 指令執行。受影響版本為 < 1.5.2,已於 1.5.2 修補。
漏洞機制
Serena 執行時會自動在本機啟動一個 Flask 儀表板,監聽固定的 24282 連接埠——這個數字其實是 constants.py 裡寫死的 0x5EDA(唸起來像 "Serena/SEDA")。這個伺服器沒有任何身分驗證、沒有 CSRF token,也沒有檢查請求的 Host 標頭,像 /save_memory、/shutdown 這類路由任何人送出請求都會被受理。
因為瀏覽器的同源政策是以「網域」而非「IP」判斷,攻擊者可以架設一個 TTL 只有 1 秒的網域,讓受害者瀏覽器先解析到一個正常的公開 IP 完成頁面載入,接著在頁面內的 JavaScript 發出第二次請求時,DNS 已經重新解析指向 127.0.0.1——這就是所謂的 DNS 重綁定攻擊。由於 Serena 端完全不檢查請求來源的 Host 是不是預期的 localhost,這個偽裝成同源請求的呼叫可以直接打到本機儀表板的 API。
第二個環節在於 src/serena/util/shell.py 的 execute_shell_command 函式,它用 subprocess.Popen(shell=True) 執行指令,對特殊字元沒有過濾,而且這個工具在所有情境設定檔中都是預設啟用的。攻擊者把夾帶指令注入字元的內容寫進「記憶」檔案,之後只要受害者的 AI 代理照常讀取記憶並執行其中建議的指令,惡意內容就會被當成 Shell 指令跑起來。
受影響版本
- 受影響:
serena-agent < 1.5.2 - 已修補:
serena-agent 1.5.2
完整攻擊鏈可以拆成以下步驟:
- 攻擊者架設 DNS TTL 為 1 秒的惡意網頁
- 受害者在本機執行 Serena 時瀏覽該網頁
- DNS 重新解析到
127.0.0.1,繞過 Host 檢查缺失的儀表板 - 頁面 JavaScript 對
localhost:24282/save_memory送出 POST,寫入夾帶惡意指令的記憶內容 - 下一次代理工作階段讀取被下毒的記憶,經由
shell=True執行任意指令
修補與緩解
官方在提交 oraios/serena@016ccbe 中補上了請求層級的 Host 驗證,概念上等同於在每個請求進來前檢查來源:
from flask import abort
@self._app.before_request
def check_host():
allowed = {f"127.0.0.1:{port}", f"localhost:{port}"}
if request.host not in allowed:
abort(403)只要請求的 Host 標頭不在允許清單內就直接回傳 403,從根本上阻斷 DNS 重綁定路徑,但這個修法沒有處理 shell.py 裡 shell=True 的注入面,使用者仍應留意 execute_shell_command 這類工具的使用情境。此漏洞 CVSS v3 評分為 8.3(HIGH),向量為 AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H,對應 CWE-306(缺少身分驗證)與 CWE-352(CSRF),由 GitHub 使用者 @Goh3st 回報。