Open Source · Audits
系統性正確性稽核
找到一個錯誤之後，我會把它的成因整理成一條檢查，再拿去看別的專案有沒有同樣的問題。這一頁是四條稽核線：跨專案的資源會計錯誤、多家廠商的 DRA driver、OCUDU 的 NTN 更新路徑、Kueue 的配額會計。每一項都附回報、修正與回歸測試的連結。精選的代表工作在 Overview，所有合併紀錄在 Ledger。
Variant Analysis
資源會計錯誤的跨專案追查
12 個缺陷變體 · 6 個獨立維護的上游專案 · 11 項修正已合併
從第一個資源會計錯誤開始，我把它的成因歸納成幾條檢查：配額與用量在相加、相乘、換算型別、共用與生命週期變動時，數字要放得下、狀態要一致，不能因為溢位、截斷、漏算或重複計算而失真。
接著我拿這幾條檢查去看其他排程器與 Kubernetes 的動態資源配置（DRA）。其中一條是「已經分配出去的資源，不能因為庫存資料更新就看起來像空的」，我另外寫成預印本 《No Capacity Resurrection》（SSRN），附可重現的實驗，見 Publications。
下表十二個問題都是我找到的，其中十一個開了 issue；Kueue 型別邊界那一項是前一項的後續，直接送了修正。十一個已經修好合併：十個是我送的修正，每一支都附回歸測試；KAI-Scheduler 的不限量配額那一項由 eladb 修好。剩下一個是 KEDA 的，我找到原因也備好修正，但那個 scaler 即將淘汰，維護者以 wontfix 關閉。
-
kubernetes/kubernetes int64 溢位 merged
一個實際上無法滿足的裝置請求，被判成可以配置。
-
kubernetes/kubernetes 型別邊界 merged
一個刻意構造的刻度值能通過檢查，接著讓配置器除以零而當掉。
檢查用的是精確的數值，計算用的卻是超出 int64 就截斷的版本，同一個值在兩邊得到不同答案。回報 #140472，修正 #140666（已合併）。
-
kai-scheduler/KAI-Scheduler int64 溢位 merged
佇列的需求被低估，本來該成立的資源回收被擋下，受害的是同一個佇列裡正常的工作。
-
kai-scheduler/KAI-Scheduler 哨兵 merged
一個設成不限量的子佇列，反而把子佇列配額的加總拉低，父佇列真的被分配過頭時也不會警告。
檢查把子佇列的配額直接相加，沒有把
-1當成「不限」：父佇列 10，子佇列 -1 與 5，算出來是 4。回報 #1881，修正由 eladb 送出的 #2167（已合併，不是我送的）。 -
volcano-sh/volcano int64 溢位 merged
使用者自己填的裝置數量，可以拿來繞過配額限制。
配額會計把裝置數量直接相加，沒有任何上限。回報 #5620，修正 #5621（已合併）；另一條漏掉的累加路徑由 #5625 補上，已合併並回移到 1.15。
-
volcano-sh/volcano 無上界迴圈 merged
只要一個 Pod 填上超大的裝置數量，排程器就卡住不回來、記憶體一直長，整個叢集的排程停擺。
它算容量總和的方式是照請求的數量一次一次加，數量多少就跑多少圈；這個數字直接來自使用者，API server 只擋掉非正數。回報 #5627，修正改成一次相乘，先在私下的 advisory 分支修好，再以 #5869 回移到 1.15；發佈為 GHSA-j38h-7pfq-cxmw，我列名為發現者。
-
kubernetes-sigs/kueue int64 溢位 merged
超過配額的工作被放行，佇列記下的已用配額也跟著錯。
-
kubernetes-sigs/kueue 乘法溢位 merged
同一條計算路徑上還有第二個地方：扣除共享計數器時仍會溢位。
-
kubernetes-sigs/kueue 型別邊界 merged
driver 自己發布的計數器數值不經 API server 驗證，負數或超出範圍的值會直接讓配額算錯。
超出 int64 的數值在相乘之前就已經被截斷成錯的值（例如 1e19 變成 0），後面的防溢位乘法救不回來；那道保護還只在數量大於 1 時才生效。這是前一項的後續，沒有另開 issue，直接以 #12945 修好並合併。
-
kubernetes-sigs/kueue 哨兵碰撞 merged
用量加到頂之後，會和代表「不限量」的特殊值撞在一起：之後加入的工作不再計入，離開時卻照樣扣掉，帳面上的用量一路往下漂，直到重啟。
Kueue 用 int64 的最大值代表「不限量」，用量加到頂時也停在同一個值，兩者從此分不開。回報 #14105，修正 #15026：int64 放不下時改用精確的大整數，已合併。每個工作自己的請求量仍會停在上限，這樣的總量一拿去除，又變回偏少的數字（#14371）；尚未入場的工作已由 #14520 改從每個 Pod 的請求重算，已合併。把請求量整個改成精確表示的工作開在 #16405，由 HarshithaMS005 的 #16479 完成並合併，這則隨之關閉；#14371 還開著。
-
cncf-tags/container-device-interface slice 邊界 merged
只有一個字元的廠商或類別名稱，就能讓解析程式當掉。
名稱只有一個字元時，程式切出的字串起點比終點還大；隔壁做同樣事情的函式本來就有這道檢查。回報 #320，修正 #321（已合併）。
-
kedacore/keda off-by-one wontfix
累積的訊息延遲剛好落在分區數的邊界時，副本數上限失效，多開了一個副本。
判斷上限時用的是無條件捨去，HPA 算副本數時卻無條件進位，兩邊在邊界上對不起來。回報 #7930。我備好了修正與回歸測試，但這個 liiklus scaler 即將淘汰，維護者以 wontfix 關閉，並沒有否認這是錯誤。同一個 scaler 在門檻設為 0 時會除以零而當掉，那則回報 #7917 與修正 #7918 也因同樣理由關閉。
同一子系統的縱深：Kubernetes DRA structured allocator
除了跨專案比對，我也在 Kubernetes 本身的 DRA 配置器裡往下查同一類問題，修好五個並已合併：數值溢位與表示範圍（#140666、#140442）、不同 driver 的計數器快取互相撞名（#140435）、候選裝置被拒或回溯時留下的殘餘狀態（#140431），以及共享裝置的計數器被重複計算（#140437）。
這五支修正都已合併並列入 v1.37，每支都關閉一個我回報的 issue，也都附針對原本失效路徑的回歸測試。這部分程式碼會由 Kubernetes 的同步機器人複製到唯讀的 k8s.io/dynamic-resource-allocation 與 k8s.io/apimachinery 模組，下一節各家廠商的 driver 引用的正是這一份。鏡像 repo 只接受機器人同步，不另計為合併，Merged 只算 kubernetes/kubernetes 這一邊。
上游制度化：SIG API Machinery 的 Quantity int64 burndown
這類 int64 溢位後來被上游整理成正式的工作項目。SIG API Machinery 的維護者 jpbetz 開了 #141166，系統性追蹤 Kubernetes 數量型別在 int64 邊界的各種錯誤，並點名請我參與。我先送了第一項 #141170：把每個取值函式今天實際回傳什麼記成測試基準，之後的修正都能對著它比對。接著 #141305 讓這些取值函式溢位時停在上下限，不再悄悄繞成錯的數字，並新增能告訴呼叫端「放不下」的版本；同一天 #141349 修好驗證那一端：像 10P、1E 這樣的整數，原本會被誤判成「必須是整數」而拒絕。隔天再合併三支：#142013 修好數量比較本身的溢位；#141348 讓 LimitRanger 的上下限與比例改用這個比較，審查時發現得先修比較函式，所以順序是先修它；#141618 讓 PVC 指定 PV 時的容量檢查也用同一個比較。用錯取值函式的呼叫端與取值函式本身，到這裡都已合併。
不變量的最新延伸（回報中）
同一組檢查後來也在排程器以外找到問題。opencontainers/cgroups #73：把很大的 CPU 配額換算成 cgroup 設定時會溢位，寫進去的是一個極小的值，程式被悄悄限速；kolyshkin 10/2 送了修正 #79，審查中；Kubernetes 這一側的修正 #141327 也還在審查。kubernetes #141323：DRA 配置器檢查每個請求的裝置數上限時，用一般整數相加而溢位；修正 #141307 已合併，也回移到 1.34 到 1.37 四個版本，這則 issue 已列入 Found & Fixed。兩者都是我回報的，因為是同一條檢查延伸到新的專案，沒有算進上表的變體。
Kubernetes DRA
跨廠商 DRA driver 正確性稽核
9 個 driver · 8 個組織 · 其中 5 家同一個「多-driver claim」缺陷（★）
Kubernetes 的動態資源配置（DRA，1.34 起正式可用）讓每家廠商用自己的 driver 把硬體交給排程器。我逐一檢查多家 driver，發現它們常帶著同一個假設：一個請求的配置結果裡，每一筆都屬於自己這個 driver。但同一個請求可以由好幾個 driver 一起滿足，所以這個假設在五家廠商的 driver 上各自出錯（★ 標記）。已合併的修正見 Ledger 合併清單。
-
dra-driver-google-tpu · Google ★ multi-drivermerged
它把配置結果裡的每一筆都拿去做 TPU 專屬的檢查，所以同一個請求若也要了別家的裝置，完整的 TPU 配置反而被拒，錯誤訊息還答非所問。改成只檢查屬於自己的那幾筆。回報 #26，修正 #25（已合併）。
-
power-dra-driver · IBM ★ multi-drivermerged
準備裝置時，它在自己的可用清單裡找每一筆結果，別家的裝置當然找不到，整個請求就失敗，同時用到兩家 driver 的 Pod 起不來；讀設定的那段程式早就會跳過別家，偏偏這個迴圈漏了。回報 #322，修正 #323（已合併）。同一次我還回報了更深一層的 #324：比對結果時只看 driver 與裝置名稱、不看所屬的資源池，同一個 driver 但別的池的結果仍可能套到本機的加速器上。維護者以這顆晶片只有單一協同處理器、用途是測試為由關閉，沒有修正。
-
dra-driver-spyre · IBM（Spyre AI） ★ multi-driver + nil panic已修 · #65、#82 merged
#59：拿別家 driver 的結果去查 Spyre 的裝置表，同時用到多家 driver 的請求整個失敗。#58：釋放裝置時若設定檔已經不見，會對空指標取值而當掉。#59 已修：這個 repo 目前只收協作者的 PR，所以由維護者依我的報告自己寫了 #65，已合併。#58 也由 sunya-ch 依我的報告寫了 #82，10/15 合併。
-
dra-driver-sriov · Network Plumbing WG ★ multi-drivermerged
#136：狀態更新撞到衝突要重試時，它把整份裝置狀態換回第一次嘗試前的樣子，別的 driver 在這段時間寫進去的內容就被蓋掉。修這個問題時又找到 #138：重新讀取時只比對名稱、不比對 UID，請求被刪掉重建後，狀態會寫到同名但不同的物件上。我的 #137 一起修好兩者，已合併。同一個 repo 另外兩個問題（#140、#143）由 #168 一併處理，審查中；#169 處理有多個請求的 Pod 只清掉第一個、其餘 VF 從沒釋放的問題。
-
dra-driver-nvidia-gpu · NVIDIA ★ multi-driver部分已修 · #1328 merged
MIG 配置部分失敗要回滾時，它把配置結果裡每一筆的名字都交去拆除，連別家 driver 的也算在內；同一個函式的另一半與另外三個迴圈都先檢查 driver，只有這裡漏了。別家的結果會出現在這裡，是因為準備時整份請求狀態都存進了檢查點。目前主線剛好因為另一個回歸（#1452）拆不到東西，那個回歸修好後這條路就會通。回報 #1327，回滾的檢查由 #1328 修好並合併，也手動回移到 release-0.5（#1477）；檢查點那一半的 #1371 還在審查，#1327 等兩半都落地再關。
-
dra-driver-cpu · Kubernetes SIG 設定/生命週期7 merged
這是上游的參考實作。我已合併的修正 #215/#257/#259/#272/#273：設定鍵換個大小寫就能繞過排除清單、kubelet 根目錄改成可設定且設錯時拒絕啟動、收到終止訊號時正常收尾等，見 Ledger。kubelet 根目錄的收尾 #274 與 #282（拒絕只在參數裡改寫的路徑，並接進 CI 與 e2e 測試）也已合併，我回報的 #231 同日關閉。
-
k8s-gpu-dra-driver · AMD 非決定性/衛生2 merged
已合併 #74/#76：driver 發布裝置清單的順序每次重啟都不同，會左右排程器挑到哪一張卡，改成依名稱排序；另外
.gitignore的規則沒有限定位置，連cmd/底下的原始碼也被忽略了。 -
composite-dra-driver · Red Hat shadow/pairing 生命週期進行中
一組和影子請求（shadow claim）的身分與生命週期有關的問題，都是我回報的，修正還在審查：影子請求的名字沒帶上原請求的 UID，同名重建時會認領到舊的那個（#65 → #66）；釋放時在底層真的釋放成功前就丟掉復原資訊，資源洩漏被重試蓋住（#64 → #67）；準備時不理會啟動時還原的狀態，改從會變動的裝置清單重建（#68）；自動配對讓兩個組合裝置共用同一個實體裝置（#69）；建立或更新狀態部分失敗後，留下沒有配置的影子請求卡住（#70）。另外補上 Kubernetes 1.36 新增的權限要求，否則影子請求的狀態更新在 1.36 會被拒（#71，10/9 合併，是這個 repo 第一筆外部貢獻）。
-
HAMi-DRA · Project-HAMi CEL 注入/webhook社群修復 · #91 merged
#73：webhook 把使用者填的註記值直接拼進 CEL 運算式，沒加引號也沒去空白。值裡有引號或反斜線時，API server 驗證運算式失敗，Pod 被拒，錯誤訊息卻只說 CEL 解析失敗，看不出問題在註記；沒去空白的那一面比較安靜：「GPU-1, GPU-2」的第二個值帶著空格，比對不到任何裝置。moezdil 以 #91 加上引號與去空白修好，不是我送的。
O-RAN / NTN
OCUDU NTN SIB19 路徑正確性稽核
12 個缺陷 · 分屬 5 種類別 · 同一 NTN SIB19 更新路徑
OCUDU（Open Centralized Unit Distributed Unit）是 srsRAN Project 的下一代，沿用它的 5G 基地台（CU/DU）程式碼，搬到 GitLab，授權也從 AGPLv3 改成較寬鬆的 BSD 類授權。初始軟體由美國政府出資，交給 DeepSig 與 Software Radio Systems（SRS）建置。
2026 年 3 月，Linux Foundation 成立 OCUDU Ecosystem Foundation，讓專案在中立的開源治理下發展，創始成員包括 AMD、AT&T、Ericsson、Nokia、NVIDIA、SoftBank 與 Verizon 等。SRS 是主要的程式碼貢獻者之一。
OCUDU 的前身 srsRAN Project 從 24.4 版就支援同步軌道衛星的非地面網路（NTN），OCUDU 的第一個版本也保留了這項功能。2026 年 7 月，開發分支密集合併了一批 NTN 擴充：衛星資訊廣播（SIB19）、地面與衛星的鄰區資訊、衛星切換、饋電鏈路的時間提前量，以及動態更新衛星資訊。
我用同樣的方法，把這條剛落地的衛星資訊更新路徑從頭看到尾（從 DU 的管理流程到 MAC 排程與軌道計算），找到 12 個問題，分成五類：記憶體生命週期、時間與編號的邊界、數值退化、錯誤處理與交易性、狀態不同步。
8 月中有了實質進展。!1153 在審查時縮小成只修一個 use-after-free，已合併並關閉 #643（見下方縱深一）；原本一起修的另外六項（#652、#653、#654、#655、#656、#657）被移出範圍，issue 仍開。!1242 修好 #695 的 SI 視窗計算，已合併。!1162 處理 #658 的全 0 廣播，也已合併。!1096 裡衛星資訊時間基準的部分已合併，但和本次稽核的 issue 無關；它原本也修 #649，因為和開發分支重複而撤回，issue 仍開。#659 的修正沒有合併，issue 已由維護者關閉；#660 也由維護者關閉。#643、#695 是我回報並修好的，!1153、!1242、!1162、!1096 都已合併。
-
du_high · SIB19 use-after-free 已修 · !1153 merged
衛星資訊更新把指向暫存資料的參照交給稍後才執行的工作，原本的函式一返回，那些參照就指向已釋放的記憶體。
之後的 DU 更新與 MAC 重新設定，讀的都是已釋放的記憶體。回報 #643，修正 !1153（已合併，見下方縱深一）。
-
MAC · SI-message 環狀歧義 回報中
時間點剛好相差半圈時，比較的結果沒有定義，排隊中的衛星資訊更新可能提早約 512 個 frame 生效。
廣播週期設成 512 個 frame，剛好是 1024 個 frame 一圈的一半，正好踩在比較的邊界上。回報 #649；修正原本放在 !1096，因為和開發分支既有的檢查重複，我撤回了這部分，issue 仍開。
-
ntn · config off-by-one 已關閉
衛星資訊的時間基準，比 3GPP 規格（TS 38.331）定義的晚了一個 slot（15 kHz 時是 1 毫秒）。
推算衛星位置與共同時間提前量都以這個時間基準為準，晚一個 slot，衛星的位置就算不準。回報 #659；修正 !1163 因為上游 !1216 拿掉了它依賴的參數而撤回，在新的開發分支上重送為 !1241，兩者都沒有合併，#659 已由維護者關閉。
-
ntn · orbital 退化 NaN 已關閉
赤道軌道或圓形軌道都是合法的設定，卻會讓計算出現 0 除以 0，得到的無效數值（NaN）一路流進軌道參數、衛星資訊廣播與位置推算。
問題出在把座標換算成軌道參數的那一步。回報 #660，維護者已關閉，沒有對應的修正。
-
du_manager 窄化截斷 回報中
系統資訊的編號被轉成最多只能存 255 的型別，又沒有檢查範圍，超過 255 的編號會被悄悄截斷後才交給 MAC。
回報 #656，修正隨 !1153 送出，但那個 MR 後來只修 use-after-free，這一項沒有落地，issue 仍開。
-
MAC · SI 組裝 界限失守 回報中
系統資訊緩衝區的 2048 位元組上限只在除錯版檢查，正式版沒有防護，可能讀到緩衝區之外。
組裝時把固定 2048 位元組的緩衝區，照排程給的長度交給下一層，執行時不檢查長度。回報 #652，修正隨 !1153 送出，但那個 MR 後來只修 use-after-free，這一項沒有落地，issue 仍開。
-
du_manager 背壓丟棄 回報中
主控迴圈的佇列（上限 128）滿了，NTN 參數更新就被直接丟掉，不記錄、不重試，也不回報錯誤。
回報 #653，修正隨 !1153 送出，但那個 MR 後來只修 use-after-free，這一項沒有落地，issue 仍開。
-
du_manager 非交易 回報中
更新沒有「全部成功或全部不做」的保證，中途失敗會留下改到一半的狀態；有多個 cell 時，已經套用的 cell 也不會通知 CU。
輔助資訊在衛星資訊重新設定之前就寫進了正在運作的 cell 設定，而那次重新設定是可能失敗的。回報 #654，修正隨 !1153 送出，但那個 MR 後來只修 use-after-free，這一項沒有落地，issue 仍開。
-
du_manager 忽略錯誤 回報中
更新函式回報失敗時沒有人檢查，失敗的 cell 照樣走完流程，最後還可能回報成功。
回報 #655，修正隨 !1153 送出，但那個 MR 後來只修 use-after-free，這一項沒有落地，issue 仍開。
-
MAC · SI-message 無 rollback 回報中
多個封包逐一放進佇列，中途有一個失敗就返回，已經放進去的不會撤回，結果只套用了一部分。
回報 #657，修正隨 !1153 送出，但那個 MR 後來只修 use-after-free，這一項沒有落地，issue 仍開。
-
MAC · assembler 狀態失同步 已修 · !1162 merged
編碼器清單每次重新設定時會跟著縮放，內容快取卻只增不減；經過某種先移除再加回的順序之後，內容沒變的系統資訊會被廣播成全 0。
-
du · SI-window 規範時間邊界 部分已修 · !1242 merged
設得過高或過於分散的廣播視窗位置能通過現有檢查，但照 3GPP 規格（TS 38.331）的公式根本排不進去，那則系統資訊永遠不會送出；判斷視窗重疊的程式又混用兩種單位，真正重疊時反而沒發現。
設定檢查少了「視窗位置不能超出週期」這個上限，重疊判斷又拿以視窗為單位的差，去對以 frame 為單位的數取餘數。回報 #695，修正 !1242 已合併，但只修好下一個視窗起點的計算；設定檢查的上限與重疊判斷的單位沒有一起落地，維護者在 !1242 合併後就關閉了 #695。
縱深一：非同步生命週期安全（#643 → !1153）
衛星資訊的更新流程，把指向函式內暫存資料的參照，交給一個稍後才執行的協程。原本的處理函式一返回，那些資料就已經釋放，之後的 DU 更新與 MAC 重新設定讀到的都是已釋放的記憶體。
已合併的 !1153 讓請求自己持有這些資料，一路以值傳遞到協程與後續流程。新加的端到端回歸測試用 ASan 驗證過：修正前會報錯，修正後通過；我也把兩個成因分別放回去（mutation testing），確認測試各自抓得到。合併後關閉 #643。
縱深二：整條 NTN 更新程序的錯誤處理缺口
#653、#654、#655 與 #657 都在同一個 NTN 參數更新流程上，合起來看，是這個流程從頭到尾沒有處理失敗：佇列滿了就悄悄丟掉、中途失敗留下改到一半的狀態、忽略失敗還回報成功、多個封包中途失敗不撤回。這四項不在已合併的 !1153 範圍裡，仍在回報中，等之後的修正。
Kueue · Resource transformation
Kueue 配額會計正確性稽核
7 個缺陷 · Kueue 配額會計與資源轉換驗證
Kueue 會依設定把資源換算成別的資源，再連同工作本身的請求一起計入配額。我用三條標準檢查這條路徑：設定要先驗證、計費不能悄悄算錯、同一份設定每次要算出一樣的結果。目前找到七個問題：負的係數變成在做減法、保留名稱沒有擋、名稱相撞時結果不固定、「保留原量」寫回的是乘過的值、Pod 的額外開銷沒有驗證、大數相乘被截斷、替換延伸資源時連帶刪掉別的計費。
以下七項都是我回報的。六項已由我的修正合併：#13986 一次修好三項，另有 #13989、#14042 與 #14154；第七項的修正（#13995）為了不超過 Kueue 開著 PR 數量的上限，10/11 先關掉；隔天 nareshpatel1015 另開 #17090 修這一項，我審了三輪後給 lgtm，10/14 合併，七項都已修好。
-
config · transformation 數值/負值 已修 · #13986 merged
換算係數設成負數時，等於在扣掉別的請求，最後又被歸零蓋過去，配額就這樣被悄悄少算。
-
config · deviceClassMappings 保留名未擋 已修 · #13989 merged
pods是 Kueue 內部用來計算 Pod 數量的保留名稱。工作的驗證有擋，設定檔卻沒擋；叫這個名字的裝置對應一旦載入，裝置的計費就混進 Pod 數量，配額跟著算錯。裝置對應的驗證只看名稱格式、長度與是否重複，沒有像工作驗證那樣拒絕保留名稱。回報 #13988，修正 #13989（已合併，並回移到 release-0.18：#14758）。
-
config · transformation 非決定性 已修 · #13986 merged
換算出來的資源和工作直接請求的資源同名時，留下哪一個由雜湊表的走訪順序決定，同一份設定每次算出的配額可能不同。
換算時輸出用累加，保留或沒換算的輸入用覆寫，兩者寫進同一張表。回報 #13990，修正 #13986（已合併，同一支修好三項）。
-
config · transformation 狀態污染 已修 · #13986 merged
「保留原量」的策略應該留下原本的請求量，但乘上係數時原值先被改掉了，寫回去的是乘過的數字，配額因此被放大。
乘係數的那一段直接改寫了原本的變數，保留原量時又拿同一個變數寫回。回報 #13992，修正 #13986（已合併，同一支修好三項）。
-
quota · ResourceValue int64 截斷 已修 · #14042 merged
換算乘出很大的數值時，CPU 以外的資源一超出 int64 就被悄悄截斷，甚至變成負的請求，最後再被歸零蓋過去。
取值時只有 CPU 走安全的版本，其他資源用的取值在超界時結果未定義；專門為此寫好的安全函式沒有被用上。回報 #13998，修正 #14042（已合併）。
-
webhook · validatePodSet 驗證漏網 社群修復 · #17090 merged
Pod 的額外開銷（
spec.overhead）也算進配額，但「不能是負數」的驗證漏了它，負的開銷因此能進到配額計算。驗證只檢查容器與 Pod 層級的資源，漏了額外開銷。回報 #13991。我的修正 #13995 為了不超過 Kueue 開著 PR 數量的上限，10/11 先關掉；nareshpatel1015 另開 #17090 修這一項。我審了三輪，第一輪指出更新路徑會讓已經帶著負值的 Workload 連移除 finalizer 都被拒，補上測試後我給了 lgtm，mimowo 核准，10/14 合併，也排了 0.20 與 0.19 的回移。
-
workload · extended-resource 連坐刪除 已修 · #14154 merged
延伸資源由裝置類別提供時，建立工作的程式會刪掉這項資源的整筆計費，只補回從容器算出來的那部分；同一筆裡其他來源（額外開銷、換算結果）就一起不見，配額少算。
重建計費時只看容器，但原本的請求量已經加上額外開銷，換算也在刪除之前就做完了。回報 #14004，修正 #14154（已合併）：只拿掉實際被替換的那一部分，並回移到 0.19 與 0.18。
Audits in flight
進行中的系統性稽核
5 條稽核線 · 橫跨可觀測性、批次排程、嵌入式驅動、宣告式基礎設施與節點執行期
上方四區是已經告一段落的稽核；這裡是還在進行的，多數已經回報，部分修正已合併或還在上游審查。
-
kubernetes · kubelet 靜態連結 build 模式／執行期語意 10 落點、3 個專案 · 4 已修
kubelet 改成靜態編譯之後，查詢使用者帳號時只讀
/etc/passwd，不再經過系統的帳號服務（NSS），race 偵測也開不起來。我用「改變編譯方式，不該改變執行時的行為」這條標準，追這個改動影響到哪些地方。起點是 dims 的 #135870。找到的問題包括：同一台機器上，kubelet 是不是用 cgo 編譯，會決定它拿到哪一段使用者 ID 範圍（#141940，dims 在 #135870 一併修掉）；kubelet 改成靜態編譯後，race 測試 job 其實在測一個沒開 race 偵測的 kubelet（#141942，dims 請我拆成獨立的 issue，後來以 test-infra#37840 修好）。我另外補上 kubeadm 在系統沒有 getent 時的預檢警告（#141968，已合併），並讓 getent 不能用時改用 Go 內建的查詢（#141971，審查中）；#141970 與 #141941 仍開。9/12 我再往下追到作業系統：shadow-maint/shadow#1738，getsubids 把「沒有設定範圍」「帳號不存在」「檔案讀不到」印成同一句、同一個結束碼。共同維護者 alejandro-colomar 同意之後，請我把修正拆成兩支：#1740 讓沒有範圍的使用者拿到長度為零的結果，而不是空指標，已合併；#1739 讓 getsubids 用不同的結束碼區分這幾種情況，審查中。同一天我也私下向 Kubernetes 安全回應委員會回報：帳號服務斷線時，kubelet 會退回預設的 ID 範圍，而不是管理員設定的範圍，見 Issues 頁。
-
opentelemetry-cpp · curl HTTP client 併發/生命週期 16 回報 · 5 已修
OpenTelemetry C++ 內建的 curl HTTP client，在多執行緒下取消連線、重試、事件回呼與釋放資源時，出現一整組競態、死鎖、使用已釋放記憶體與資源洩漏的問題。
幾個例子：取消連線時用到已釋放的連線物件（#4375，已修）、重設時自己鎖死自己（#4389，已修）、在事件回呼裡結束連線會死鎖（#4402）、重試期限每次呼叫都重新起算（#4403，shixi-li 以 #4452 修好）、初始化失敗時連線物件沒有釋放（#4397）；10/3 再回報一則：送出請求時正好碰上背景執行緒結束，會多起一個背景執行緒，關閉時兩者競態（#4665）。標題提到 curl 的完整清單見 GitHub。
-
kueue · DRA extended-resource/配額會計 配額正確性 承上 · 30+ 回報 · 15+ 已修
延續上方的 Kueue 配額稽核：延伸資源的對應、計費、額外開銷與換算，在漏算、重複計算、負值與溢位時的一整組配額錯誤。
幾個例子：某一類裝置完全沒有計費（#14249）、額外開銷沒有核對配額（#14274）、Pod 層級的請求沒有核對（#14255，Dasmat13 以 #16047 修好）、負的裝置請求抵銷掉別的請求（#14216，pujitha24 以 #14367 修好）。同一個「共用請求怎麼記帳」的問題也出現在 Volcano：上層佇列對共用的請求兩個方向都漏記（#5847，Anirudh0465 的 #5851 審查中）。完整清單見 GitHub。
-
zephyr · ESP32 GDMA/I2S driver 邊界/狀態機 14 回報 · 10 已修
Zephyr 的 ESP32 DMA 與 I2S 音訊驅動，在描述符用完、狀態切換、零長度資料與停止時的一組邊界錯誤，以及誤讀硬體狀態的問題。
幾個例子：描述符用完時讀到清單尾端之外（#115502）、停止時同一個方向被停兩次（#115503）、I2S 傳送啟動失敗沒有歸還記憶體區塊（#115504）、停止後延遲傳送的計時器沒有取消（#115505）、對不支援的方向下指令會碰到空指標（#115719，後來發佈為 GHSA-5g9q-h8wq-rrf3，CVE-2026-19737）、零長度的區塊被交給 DMA（#115720）、兩種電源管理鎖共用一個旗標（#115722，raffarost 以 #117706 修好）、停止時沒清掉鎖存的中斷，下一次啟動先送出上一筆的回呼（#115726）、AXI 通道略過中止的交握（#116336）、同時收發時一邊出錯另一邊仍繼續跑（#115499，harshitnub077 以 #117645 修好），以上都已修好。仍開的四則：#113310、#115717、#115801、#116337。完整清單見 GitHub。
-
crossplane · ControllerEngine 生命週期競態 3 缺陷 · 修正在飛
Crossplane 的動態控制器交接時的啟停競態：失敗後的清理誤停了剛接手的新控制器、已經停止的事件來源仍被掛上處理函式、監看被加到已停止的控制器上。