GHSA-vfvv-c25p-m7mm：rkyv 0.8.0–0.8.15 的 Panic 安全漏洞允許記憶體損毀
GitHub Advisories / RustSec · 2026-05-15
Rust 序列化函式庫 rkyv 版本 0.8.0 至 0.8.15 存在 panic 安全缺陷，InlineVec::clear() 與 SerVec::clear() 在迭代過程中 Drop 實作拋出 panic 時，可觸發雙重釋放（double free）或釋放後使用（use-after-free）。RustSec 編號 RUSTSEC-2026-0122，CVSS v4 評分 6.9（Moderate）。
漏洞機制
兩個函式具有相同的結構缺陷：它們逐元素呼叫 drop_in_place，但等到迭代結束後才更新長度計數器。若某個元素的 Drop 實作在執行過程中 panic，長度保持不變，後續操作將再次存取已釋放的記憶體：
- InlineVec 情境：容器被 drop 時，其解構器再次呼叫
clear()，重新處理已釋放的元素（CWE-415 Double Free） - SerVec 情境：
with_capacity()建構子在使用者代碼執行後呼叫clear()，可在 panic 後再次存取堆疊上已釋放的資料（CWE-416 Use-After-Free）
兩種利用路徑均可從 Safe Rust 觸發，利用標準 panic 處理機制即可，無需 unsafe 代碼。
受影響版本與修補
| 狀態 | 版本範圍 |
|---|---|
| 受影響 | rkyv 0.8.0 – 0.8.15 |
| 已修補 | rkyv 0.8.16（commit 5828cf5） |
修補與緩解
升級至 rkyv 0.8.16 即可修復。修補方式是在迭代過程中逐步更新長度計數器，確保 panic 發生時已釋放元素不會被再次存取。若暫時無法升級，應避免在被 rkyv 序列化的類型的 Drop 實作中使用任何可能 panic 的操作。
Linux 核心 ESP/IPSEC 模組的攻擊面縮減：以近期本地提權為例
Openwall oss-security · 2026-05-16
Openwall oss-security 郵件列表於 2026 年 5 月 16 日發布了一篇分析，以近期 Linux 核心中 ESP（Encapsulating Security Payload）模組的本地提權漏洞為例，論證預設不載入未使用的核心模組的安全價值。
攻擊面分析
ESP 是 IPSEC 協議套件的一部分，在現代網路環境中使用率極低，但在絕大多數 Linux 發行版中預設可載入。近期有多個本地提權漏洞的利用路徑依賴 ESP 模組存在。作者指出，若這些模組預設未載入，相關漏洞的利用難度將大幅提升或完全失效。
建議的緩解措施
文章建議在不需要 IPSEC 的系統上，透過核心設定停用相關選項：
CONFIG_INET_ESP=n
CONFIG_INET6_ESP=n
CONFIG_INET_AH=n
CONFIG_INET6_AH=n
CONFIG_INET_IPCOMP=n
CONFIG_INET6_IPCOMP=n長期解決方案是發行版將 IPSEC 相關模組打包為獨立的 linux-modules-ipsec 套件，不在預設安裝中納入，由需要 IPSEC 的使用者主動安裝。作者承認這增加了套件維護複雜度，但認為攻擊面縮減的安全效益值得。
原始來源：oss-security 郵件列表
Meta Labyrinth 1.1：訊息加密備份的發送端信封模型
Meta Engineering · 2026-05-11
Meta 發布 Labyrinth 加密儲存系統 1.1 版，引入新的備份子協議，將備份觸發點從裝置上線時移至訊息發送時，解決因裝置長時間離線或遺失導致備份中斷的問題。Labyrinth 用於保護 Messenger 的端對端加密訊息歷史，Meta 本身無法讀取備份內容。
核心機制
1.1 的關鍵架構改動是「訊息加密金鑰信封」模型：每則訊息被包覆在一個訊息加密金鑰中，發送端在發送時直接將這個加密的金鑰信封放入接收端的加密備份空間，如同「把密封信封投入只有接收端才能開啟的鎖箱」。這使備份在訊息發送瞬間即完成，不再依賴接收端裝置上線。
可靠性改善
- 遺失手機或長時間未登入後，訊息歷史仍可完整恢復
- 換裝置時不再出現訊息歷史中斷
- 成功備份的訊息比例顯著提升
完整的密碼學規格可參閱 Labyrinth 白皮書。Labyrinth 的治理架構與 Mozilla、Signal 類似，以協議層面的不可讀性作為對使用者的承諾基礎。