PostgreSQL 18.4 / 17.10 發布：11 個 CVE，CVSS 8.8 緩衝區溢位與任意程式碼執行
postgresql.org · 2026-05-14
PostgreSQL 全球開發組於 2026-05-14 同步發布 18.4、17.10、16.14、15.18、14.23 五個版本，修補 11 個安全漏洞並關閉逾 60 個錯誤。其中四個漏洞評級達 CVSS 8.8（High-Critical），涵蓋整數繞回引發的緩衝區溢位、pg_basebackup 符號連結追蹤、libpq 堆疊溢位，以及 refint 模組的任意程式碼執行。
漏洞機制
CVE-2026-6473（CVSS 8.8）是整數繞回（integer wraparound）導致記憶體配置過小，後續寫入時發生越界存取，可造成段錯誤甚至任意寫入。影響 PostgreSQL 14 至 18 全版本。
CVE-2026-6475（CVSS 8.8）允許持有資料庫 superuser 權限的攻擊者，透過 pg_basebackup 或 pg_rewind 的符號連結追蹤，覆寫伺服器 OS 上的任意檔案（如 ~/.bashrc），進而劫持 OS 層帳號。
CVE-2026-6477（CVSS 8.8）位於 libpq 客戶端函式庫，伺服器端 superuser 可透過 lo_* 大物件函數系列在客戶端程序的堆疊上寫入惡意資料，影響 pg_dump 與 psql。
CVE-2026-6637（CVSS 8.8）存在於 refint（Referential Integrity）貢獻模組。非特權 SQL 用戶可在觸發器執行路徑上注入惡意參數，觸發以資料庫 OS 用戶身份執行的任意程式碼，同時存在 SQL injection 向量。
受影響版本
- PostgreSQL 14.0–14.22 → 升至
14.23（EOL 2026-11-12） - PostgreSQL 15.0–15.17 → 升至
15.18 - PostgreSQL 16.0–16.13 → 升至
16.14 - PostgreSQL 17.0–17.9 → 升至
17.10 - PostgreSQL 18.0–18.3 → 升至
18.4
修補與緩解
本次更新為累積式（cumulative），升級方式是停止服務、替換二進位，不需要執行 pg_dumpall 或 pg_upgrade。對 CVE-2026-6637，短期緩解可透過收緊 refint 觸發器的角色權限，並移除不必要的 refint 安裝（DROP EXTENSION refint）。此次發布亦同步納入時區資料庫 tzdata 2026b，反映 British Columbia 省永久實施夏令時間的法規變更。
原始來源：postgresql.org
Cloudflare ClickHouse 計費管道危機：分區鍵變更引爆查詢計劃互斥鎖競爭
blog.cloudflare.com · 2026-05-14
Cloudflare 工程師記錄了一次因 ClickHouse 分區策略調整導致計費管道（billing pipeline）大幅延遲的事件。根本原因是查詢計劃器（query planner）在複製資料分片清單（parts list）時持有一把全域互斥鎖，分片數增加後多執行緒查詢在此鎖上形成嚴重的序列化瓶頸。
原本的問題
Cloudflare 將 Ready-Analytics 資料表的分區鍵從 (day) 改為 (namespace, day)，目的是實現按命名空間的資料保留期控制。分區鍵增加後，ClickHouse 將同樣的資料切割成更多細粒度的分片，資料表的分片總數因此大幅增加。
問題在於：每次查詢計劃階段，每個工作執行緒都必須以獨佔鎖（exclusive lock）取得整份分片清單的副本，再從中篩選出與查詢相關的子集。當並發查詢數量增加，所有執行緒排隊等待同一把鎖，形成事實上的序列執行。I/O、記憶體、掃描列數等指標均正常，只有查詢持續時間異常，這使得問題難以用標準監控工具定位。
採用的方法
診斷階段，工程師透過 CPU 火焰圖發現時間花費在 filterPartsByPartition，但 CPU 使用率並不高。切換到「Real Time」追蹤（包含等待中執行緒）後，才發現超過一半的 leaf 查詢時間消耗在等待互斥鎖，而非實際計算。
三個階段的修補依序推進：
- 共享鎖（shared lock）：將獨佔鎖換為
std::shared_lock，允許多個讀者並發取得分片清單副本 - 延遲複製（deferred copy）：建立一份共享的分片清單副本；各查詢計劃器僅複製篩選後的子集
- 二分搜尋（binary search）：利用
namespace分區鍵的有序特性，以O(log n)取代線性掃描定位相關分片
實際效果
修補貢獻至 ClickHouse 上游，並在 25.11 版本發布。Cloudflare 部署後，查詢延遲降低 50%，且延遲不再隨分片數增加而線性成長。此案例同時展示了 Real Time 火焰圖相較於 CPU 火焰圖在等待瓶頸診斷上的優越性——當大多數延遲來自鎖等待而非計算，CPU 火焰圖幾乎看不到問題。
原始來源：blog.cloudflare.com
C++26 的 std::simd：標準化十年後，它已不是最佳選擇
lucisqr.substack.com · 2026-05-15
C++26 標準正式納入 std::simd（提案 P1928），這是一個以程式庫形式提供的可攜式 SIMD 抽象層，目標是讓開發者「寫一次 SIMD 程式碼，編譯至所有架構」。然而從提案提出到納入標準歷時逾十年，期間自動向量化編譯器與替代函式庫的進步，使其到達時已面臨定位困境。
規格細節
std::simd<int> 的預設寬度為 128 位元（SSE），即使在 AVX2（256 位元）或 AVX-512（512 位元）的機器上編譯也是如此。開發者需明確指定 std::simd<int, std::simd_abi::avx2> 才能取得更寬的向量，此預設值導致在現代 x86-64 機器上的實際效能比純量迴圈慢約 2.4 倍（如作者實測）。
函式庫另一個結構性限制在於缺乏跨道（cross-lane）操作——洗牌（shuffle）、排列（permute）、水平歸約（horizontal reduction）等均不在 P1928 範疇內。這些操作正是影像編解碼器（如 JPEG XL）、壓縮演算法、音訊處理等場景中最常見的 SIMD 使用模式。
效能問題
作者實測一個 sin 迴圈：純量版本在 -O3 -march=native 下由編譯器自動向量化，效能優於手寫 std::simd 版本。原因是模板呼叫使 SIMD 操作對最佳化器不透明，阻止常數摺疊（constant folding）與強度削減（strength reduction）等代數化簡。引入 <simd> 標頭亦造成約 10 倍的編譯時間增加。
影響範圍
作者建議在需要 SIMD 的場景優先評估替代方案：Google Highway（被 Chromium、libjxl 使用）、xsimd（被 NumPy 後端使用）、EVE。對於架構特定最佳化，Intel ISPC 在生成最佳向量指令方面仍優於任何 C++ 程式庫。std::simd 對需要在 AVX-512、NEON、SVE 之間保持完全可攜性且效能要求不嚴苛的工具程式碼仍有其適用場景。
原始來源：lucisqr.substack.com