Log for Ubuntu 台灣社群

Linux 本機權限提升漏洞「複製失敗」（Copy Fail）— CVE-2026-31431 （★ 191 分 🔥）

Copy Fail（CVE-2026-31431，通用漏洞與揭露編號）是一個 Linux 本機權限提升漏洞（LPE, Local Privilege Escalation），研究者稱其影響 2017 年以來到修補前的多數主流 Linux 核心。漏洞源自核心加密 API 中 `authencesn` 與 `AF_ALG`（讓使用者空間程式呼叫核心加密功能的通訊端介面）、`splice()` 系統呼叫之間的邏輯缺陷，可讓一般本機使用者把 4 個可控制位元組寫入可讀檔案的頁面快取（page cache，核心記憶體中的檔案副本），再藉由修改 setuid-root 程式如 `/usr/bin/su` 的快取內容取得 root 權限。研究者強調這不是競態條件，也不需要特定發行版偏移值，展示的 Python PoC（概念驗證程式）僅 732 bytes，使用標準函式庫即可在多個發行版上取得 root。

文章指出，這個漏洞對多租戶 Linux 主機、共用核心的容器叢集、CI（Continuous Integration，持續整合）runner、建置農場、可執行不受信任程式的雲端 SaaS 平台風險最高，因為一般帳號、容器內程式或惡意 PR 程式碼都可能升級為主機 root。它本身不是遠端漏洞，但若與 Web RCE（Remote Code Execution，遠端程式執行）、SSH 入侵點或外洩憑證串接，攻擊者可從低權限落點進一步控制系統。修補方式是更新到包含主線 commit `a664bf3d603d` 的核心，該修補回復 2017 年 `algif_aead` 的原地最佳化，避免頁面快取頁面進入可寫目的 scatterlist。無法立即更新時，建議暫時停用 `algif_aead` 模組，並在容器、沙箱與 CI 環境中用 seccomp（Linux 系統呼叫過濾機制）阻擋建立 `AF_ALG` 通訊端。

Hacker News 討論中，不少人實測後認為漏洞確實嚴重：有人回報全新安裝的 Ubuntu Server、Ubuntu 24.04 LTS 家用伺服器或舊測試 VM 仍可被 PoC 立即取得 root；也有人指出部分發行版安全追蹤頁面仍列為未修補，或把嚴重性標成中等，引發對廠商處理優先順序的質疑。也有使用者整理核心版本，表示上游穩定版中約從 6.18.22、6.19.12、7.0 起包含修補，但各發行版是否 backport（將修補移植回舊版核心）仍需查各自公告。另有留言確認停用 `algif_aead` 可讓某些系統上的 PoC 失效。

討論也對文章的呈現方式與部分主張提出保留。有人指出頁面稱已驗證 RHEL 14.3，但 RHEL 目前並無 14.3，可能是把 RHEL 10.1 核心版本旁的發行版名稱寫錯，這讓不少人批評頁面像 AI 產生的行銷文案；不過也有資安從業者表示 Theori/Xint 團隊本身可信，漏洞真實性不應因文案瑕疵被否定。對於「732 bytes」的強調與具名漏洞網域，也有人認為是行銷手法，但另一派認為像 Heartbleed、Log4Shell 這類名稱有助於讓管理者記住並推動修補。

在技術限制方面，留言者提醒目前 PoC 主要針對 x86_64 與特定 setuid 程式，並非在所有情境都直接成功；有人在 rootless Podman 中測試未能逃出容器，在 Alpine 或 Raspberry Pi 上也需要調整 payload。也有人指出，文章宣稱 Kubernetes 與容器逃逸仍待後續技術文章佐證，雖然頁面快取可被改寫這一點理論上可被延伸利用。Android 方面，多數討論認為成功機率較低，因為 Android 常見 SELinux 限制、nosuid 掛載、少量 root 程序，以及一般 App 可能無權開啟 `AF_ALG` 通訊端。整體來看，社群共識是漏洞本身高風險且應優先修補，但宣傳頁面的部分細節與跨容器宣稱仍需進一步技術驗證。

👥 90 則討論、評論 💬
https://news.ycombinator.com/item?id=47952181

Linux 7.0 在特定情境下讓 PostgreSQL 效能腰斬：解析搶佔式排程引發的效能退化 （★ 108 分 🔥）

文章指出，AWS 工程師 Salvatore Dipietro 在 96 個 vCPU（虛擬 CPU）的 Graviton4 機器上，以 pgbench（PostgreSQL 標準效能測試工具）測試 PostgreSQL，發現 Linux 7.0 相較 Linux 6.x 吞吐量幾乎腰斬：每秒交易數從約 98,565 筆降到 50,751 筆。透過 perf（Linux 效能剖析工具）追蹤後，CPU 有約 55% 時間耗在 PostgreSQL 的 s_lock，也就是 StrategyGetBuffer 路徑中的自旋鎖（spinlock）。這個函式負責在共享緩衝池中尋找可用緩衝區；在高並行情境下，大量後端行程會同時競爭同一把鎖。

文章將問題追溯到 Linux 7.0 移除現代 CPU 架構上的 PREEMPT_NONE，改以 PREEMPT_LAZY 或 PREEMPT_FULL 為主。PREEMPT_NONE 過去較常用於伺服器，核心較少在工作進行中介入；PREEMPT_LAZY 則試圖兼顧回應性與吞吐量。PostgreSQL 的共享緩衝池若使用預設 4 KB Linux 記憶體頁，在 120 GB shared_buffers 下會對應到約 3,100 萬個記憶體頁；當某個後端行程持有自旋鎖時觸發 minor page fault（次要分頁錯誤，代表首次存取時需要建立實體記憶體映射），其他行程就會在鎖外空轉等待。PREEMPT_LAZY 可能讓持鎖行程在處理 page fault 期間被排程器暫停，使鎖持有時間從「處理 page fault 的時間」延長為「page fault 加上等待重新排程的時間」，並由所有等待中的後端行程共同放大 CPU 浪費。

文章提出的主要緩解方式是啟用 huge pages（巨頁），例如 2 MB 或 1 GB 記憶體頁。以 120 GB shared_buffers 來看，4 KB 頁可能產生約 3,100 萬個首次存取映射點，2 MB 巨頁可降到約 61,440 個，1 GB 巨頁則約 120 個；同時也能降低 TLB（Translation Lookaside Buffer，位址轉譯快取）的壓力。文章建議 PostgreSQL 的 huge_pages 設為 on，而不是預設 try，避免系統沒有配置好巨頁時悄悄退回 4 KB 頁。不過巨頁需要預先保留記憶體，可能造成其他行程可用記憶體減少，也可能因配置粒度過大而浪費部分空間。文中也提到 Intel 核心工程師 Peter Zijlstra 提出可重新啟動序列（rseq, Restartable Sequences）相關方向，但 PostgreSQL 社群對「為了恢復升級核心前原本就有的效能而修改資料庫」反應並不熱烈，並牽涉 Linux 長期強調的不破壞 userspace（使用者空間程式相容性）原則。

Hacker News 討論普遍認為標題有誇大之嫌，因為這不是 PostgreSQL 在 Linux 7.0 上全面故障，而是在大型 shared_buffers、4 KB 記憶體頁、巨頁未啟用、高並行壓力等條件下暴露的效能退化。有留言者直指這比較像是「120 GB PostgreSQL 卻關閉 huge pages」導致鎖競爭從糟糕變成災難，並質疑 AWS 為何用這種配置測試，也有人希望 RDS 或 Aurora 生產環境不是如此設定。另一些人補充，巨頁過去名聲不穩多半與 transparent huge pages（THP，透明巨頁）混淆；對大型 PostgreSQL 或 VM 這類單一大型記憶體區塊，明確配置 huge pages 已經是常見效能調校，甚至有人分享曾在 pgbench 看到 10% 到 20% 左右提升。

討論中也有重要技術修正：有留言指出，PREEMPT_NONE、PREEMPT_LAZY、PREEMPT_FULL 指的是核心可被搶佔的程度，不是使用者空間行程是否能被搶佔；Linux 的使用者空間程式本來就會被排程器切換。另有留言修正文章對 rseq 方案的描述，實際提案較接近 time-slice extension（時間片延長）：當行程持有 s_lock 時設定請求位元，若核心準備在此時搶佔該行程，就延長一次時間片讓它先釋放鎖，而不是單純偵測被搶佔後重試臨界區。整體而言，社群共識較接近「這是提醒大型 PostgreSQL 部署應正確配置 huge pages 的警訊」，同時也反映核心排程變更即使在少數配置下造成重大效能回歸，仍會引發對相容性與預設值的爭論。

👥 52 則討論、評論 💬
https://news.ycombinator.com/item?id=47949585

GCC 16 已釋出 （★ 120 分）

GCC 16（GNU Compiler Collection，GNU 編譯器套件）帶來大量編譯器、語言前端、診斷工具與平台支援更新。整體最佳化方面，LTO（Link-Time Optimization，連結時最佳化）改善了頂層組合語言敘述的處理；推測式去虛擬化可處理更一般的間接函式呼叫；向量化器也更能辨識迴圈中的平行歸約、處理迭代次數不明的迴圈、改善對齊剝離與早期中斷迴圈的程式碼產生。需要注意的相容性變更包括 Solaris 上 int8_t 等型別改為 signed char、-pthread 不再預先定義 _REENTRANT，以及原本稱為 json 的診斷輸出格式已移除，機器可讀診斷建議改用 SARIF（Static Analysis Results Interchange Format，靜態分析結果交換格式）。

語言層面最受矚目的是 C++ 預設標準從 gnu++17 改為 gnu++20；若既有程式依賴舊標準，需明確指定 -std= 或進行移植。GCC 16 也實作多項 C++26 功能，包括 reflection（反射）、contracts（契約）、constexpr 例外、擴充 structured bindings 等；C++23 則新增 explicit lifetime management（明確生命週期管理）等功能。libstdc++ 方面，C++20 實作不再標示為實驗性，但多個 C++20 元件有 ABI（Application Binary Interface，應用程式二進位介面）變更；std::regex 改用堆積式堆疊以避免大型字串比對時造成系統堆疊溢位，C++23 與 C++26 標準函式庫功能也持續擴充。

其他語言與平台更新也相當廣。OpenMP（共享記憶體平行程式介面）與 OpenACC（加速器平行程式標準）強化 GPU 記憶體配置與資料搬移能力，特別是 Nvidia GPU 與 AMD GPU offloading；Fortran 改善 Fortran 2018、2023 功能，Ada、Modula-2 也有語言與函式庫更新，並新增實驗性的 Algol 68 編譯器 ga68。硬體目標方面，x86 新增 AMD Zen6、Intel Wildcat Lake 與 Nova Lake 支援，AMD GCN 加入 MI300 相關支援，LoongArch 新增 32 位元架構與函式多版本化，Windows 則支援原生 TLS（Thread-Local Storage，執行緒區域儲存）。診斷系統可輸出實驗性 HTML、擴充 SARIF、呈現有向圖，靜態分析器開始能處理簡單 C++ 範例與例外處理，但仍不適合大型生產環境 C++ 程式碼。

Hacker News 討論主要聚焦在 GCC 發行節奏、C++ 新功能與相容性風險。有留言指出 GCC 近年採取規律發行週期，類似 Fedora 春季版本，這種做法讓大型專案不必等待所有功能完成才釋出，也迫使尚未穩定的功能以開關方式關閉；有人拿 OpenJDK 作為對照，認為較頻繁的小版本讓企業更習慣更新。也有老使用者回顧 GCC 2.95 時代的 C++ 問題，並提到 Cygnus、Red Hat 與 IBM 對 GCC 專案組織化的歷史影響。

技術討論中，有使用者特別強調 C++23 的 std::start_lifetime_as<T>，認為這是處理 zero-copy（零拷貝）I/O buffer 時值得採用的功能，可避免用 reinterpret_cast 將 char buffer 視為結構型別時落入 UB（undefined behavior，未定義行為）。也有人補充 char buffer 的型別雙關本來就有部分允許情境，另有留言批評 C++ strict aliasing（嚴格別名規則）過於複雜，建議實務上使用 -fno-strict-aliasing。另有使用者表示已在 Debian sid 使用 GCC trunk 版本並嘗試 C++26 reflection，但希望 GCC 生態系能有 LSP（Language Server Protocol，語言伺服器通訊協定）支援；也有人回報使用 GCC 16 產生的二進位檔在 Debian 12、13 上遇到 libstdc++ 相容性問題，顯示這次標準函式庫與 ABI 變更仍需謹慎評估。

👥 15 則討論、評論 💬
https://news.ycombinator.com/item?id=47961004