Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且廠商未提供可用的修補程式。

  - KVM： nVMX：確保在 VM-Exit 上清除 KVM_REQ_GET_NESTED_STATE_PAGES 模擬巢狀 VM-Exit 時，請務必檢查並清除KVM_REQ_GET_NESTED_STATE_PAGES以確保要求遭到清除，即使 KVM 是使用 CONFIG_KVM_HYPERV=n 建置的，因為 KVM 巧妙地依賴檢查來清除旗標，從而避免重複對應 vmcs12 頁面， 例如，如果 KVM 設法在不處理請求的情況下從 VM-Enter 保釋，然後模擬 VMLAUNCH 或 VMRESUME。（CVE-2026-89931）

請注意，Nessus 的判定取決於廠商所報告的套件是否存在。

Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且廠商未提供可用的修補程式。

  - 跟蹤：讓 show_event_filters/觸發程式檔案採用追蹤陣列參照 顯示追蹤陣列內設定的所有過濾器或觸發程式的新新增檔案show_event_filters和show_event_triggers不會參照它所顯示的追蹤陣列。在不獲取參考的情況下，當任務讀取其中一個文件時，可以通過 rmdir 釋放trace_array。這些檔案會逐一查看執行個體 （trace_array） 內的所有事件，並且沒有任何內容可以阻止在讀取其資料時釋放該執行個體。這會導致釋放後使用損毀。讓這兩個檔案的開啟透過 trace_array_get（） 進行trace_array參照，以防止在檔案開啟時釋放trace_array。（CVE-2026-90014）

請注意，Nessus 的判定取決於廠商所報告的套件是否存在。

Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且廠商未提供可用的修補程式。

  - perf/x86/intel：修正 LBR 堆疊中的核心位址洩漏 在 Arch LBR 獲得 CPL 篩選支援之前，僅限使用者的分支堆疊仍然可以包含核心位址。因此，即使要求PERF_SAMPLE_BRANCH_USER，核心分支記錄仍可能公開給使用者空間。例如，在 Intel Tiger Lake 上，下列命令仍可從位址報告具有核心空間的 SYSRET/ERET 項目： $ ./perf record -e cycles：p -o - --branch-filter any，save_type，u -- \ ./perf bench syscall basic --loop 1000 | \ ./perf script -i - --fields brstack|tr ' ' '\n'| \ grep -E '0x[89a-f][0-9a-f]{15}' 總時間： 0.000 [sec] 0.219000 usecs/op 4,566,210 ops/sec [ perf record： 喚醒 1 次以寫入資料 ] [ perf record：
    擷取並寫入 0.551 MB - ] 0xffffffff93c001c8/0x7f12a2b1d647/P/-/-/16959/SYSRET/- 0xffffffff93c001c8/0x7f12a2b1d5c2/P/-/-/17535/SYSRET/- 0xffffffff93c01928/0x7f12a2861000/P/-/-/6719/ERET/- 0xffffffff93c01928/0x7f12a297a000/P/-/-/8575/ERET/- 問題在於 intel_pmu_lbr_filter（） 無法完全驗證取樣項目的權限等級。它會根據分支類型和收件人位址篩選一些不相符的項目，但不會拒絕其寄件者位址違反所要求分支權限篩選器的項目。藉由擴充軟體篩選以針對br_sel驗證來源和到位址來修正此問題。任何包含核心位址不符合要求的使用者篩選器的 LBR 項目都會遭到刪除。這可防止核心位址出現在僅限使用者的分支堆疊中。（CVE-2026-89984）

請注意，Nessus 的判定取決於廠商所報告的套件是否存在。

Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且廠商未提供可用的修補程式。

  - media： v4l2-ctrls：驗證 HEVC EXT SPS RPS 計數 HEVC SPS 控制項會攜帶解碼器驅動程式用來遍歷相符的 EXT SPS 動態陣列的短期和長期 RPS 計數。拒絕超過 64 個短期集和 32 個長期參照的 HEVC 限制的 SPS 值，讓驅動程式稍後無法編製超出這些控制項的索引。也拒絕負或正影像計數超過 16 個項目陣列，或合併的 delta-POC 計數超過 HEVC DPB 上限的 EXT SPS ST RPS 項目。
    (CVE-2026-89873)

請注意，Nessus 依賴供應商報告的套件存在。

Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且廠商未提供可用的修補程式。

  - KVM： nVMX：服務本機 TLB 在失敗的巢狀 VM-Enter 上進行排清 KVM 服務會在完整巢狀 VM-Enter 上排清本機 TLB （透過 __nested_vmx_vmexit（）），但如果巢狀 VM-Enter 失敗 （例如，由於 nested_vmx_enter_non_root_mode（） 中的 VMCS 檢查失敗），則不會。不過，即使巢狀 VM-Enter 未成功，KVM 也可能已將需要執行的 TLB 排清排入佇列。例如，如果透過 nested_vmx_transition_tlb_flush（） 停用 L2 的 VPID，或透過 MSR 載入清單，如 SDM 所說：如果以架構上需要 TLB 排清的方式載入任何 MSR，則會更新 TLB，以便在 VM 進入之後，邏輯處理器不會使用轉換前快取的任何轉譯。SDM 不清楚何時應該進行 TLB 排清，以及失敗的虛擬機器項目是否會排清 TLB，因此在此情況下一律執行 TLB 排清會比較安全。更具體地說，KVM 也會更新 nested_vmx_transition_tlb_flush（） 中用於 L2 的最後一個 VPID L1 （即 last_vpid），即使 VM 項目最終失敗也是如此。使用目前的程式碼時，如果 L1 變更 L2 的 VPID，然後執行失敗的 VM 項目，然後執行成功的 VM 項目，因為失敗的 VM 項目會更新last_vpid，但實際上不會排清 TLB。在失敗的 VM 項目上服務本機 TLB 排清，可確保在更新 last_vpid 時一律排清 TLB。（CVE-2026-89930）

請注意，Nessus 的判定取決於廠商所報告的套件是否存在。

Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且廠商未提供可用的修補程式。

  - media：v4l2-fwnode：修正 v4l2_fwnode_parse_link 中的 fwnode 洩漏 在 v4l2_fwnode_parse_link（） 中，使用 fwnode_graph_get_remote_endpoint（） 取得遠端端點 fwnode 參照。此參照會在錯誤路徑中正確釋放，但在成功路徑上會洩漏。在傳回 0 之前新增缺少的 fwnode_handle_put（），以防止參照洩露。[Sakari Ailus：稍微修正主語前綴和編碼風格。（CVE-2026-89872）

請注意，Nessus 的判定取決於廠商所報告的套件是否存在。

Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且廠商未提供可用的修補程式。

  - drm/amdkfd：在 MES 佇列驅逐/暫停後新增 TLB 排清 MES （微引擎排程器） 不會在取消對應佇列後執行大量 TLB 無效，這與自動執行此動作的 HWS 不同。
    這會導致爭用情形、即進行中的DMA描述元可以存取已取消對應的記憶體、進而導致頁面錯誤、以及SVM頁面移轉期間GPU佇列懸置。此問題表現為在啟用 XNACK 模式 1 的情況下，gfx1151 （Strix Point） 上的 KFDSVMRangeTest.MultiThreadMigrationTest 失敗 - GPU 計算佇列因已提交但從未使用的封包而懸置。在兩個位置移除 MES 佇列後新增 kfd_flush_tlb（） 呼叫： - evict_process_queues_cpsch（）：在驅逐期間移除所有佇列之後 - suspend_queues（）：偵錯/CRIU 佇列暫停之後 （使用mem_fence屏障） 這可確保在釋放或移轉記憶體之前，排清來自未對應佇列的所有進行中記憶體存取。（從提交 f5c4f88e0f9c45a8fb9dfac0c1df726c95e41b77 中挑選）（CVE-2026-89811）

請注意，Nessus 的判定取決於廠商所報告的套件是否存在。

Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且廠商未提供可用的修補程式。

  - iio： 緩衝區：將 IIO dma 柵欄鎖定存留期繫結至柵欄 「iio_dma_fence」實作目前使用內嵌在「iio_dmabuf_priv」中的鎖。但「iio_dma_fence」可能比「iio_dmabuf_priv」更長，這可能會導致釋放後使用。將鎖的存留期與柵欄的存留期繫結，方法是將它們內嵌在相同的結構中。我們不能只保留對 'iio_dma_fence' 的 'iio_dmabuf_priv' 的引用，因為 'iio_buffer_dmabuf_release（）' 可能會休眠，而不允許柵欄釋放回呼休眠。
    請注意，'dma_fence' 框架現在有一個內部鎖，當在 'dma_fence_init（）' 中為 'lock' 傳遞 'NULL' 時會使用該鎖，但為了允許此修補程式反向移植，請使用外部鎖。
    (CVE-2026-89940)

請注意，Nessus 依賴供應商報告的套件存在。

Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且廠商未提供可用的修補程式。

  - f2fs：只有 redirty_blocks redirty_blocks（） 中重新髒的釘選對開本會用 read_cache_folio（） 釘選對開本，然後使用 filemap_lock_folio（） 再次遍歷相同的範圍，以重新髒污它們並刪除它所取得的參照。提交 5951fee46bef （f2fs：在 redirty_blocks（）） 中使用對開本） 將第二遍更改為 do/while 迴圈。如果 read_cache_folio（） 在釘選任何內容之前失敗，則page_idx不會前進，但清理迴圈仍會執行一次。如果預讀已在頁面快取中填入失敗的對開本，則該額外的反覆運算會找到它，並folio_put_refs（對開本，2） 捨棄一個參照太多。稍後的drop_caches或回收可以報告 BUG： Bad page state。僅重新弄髒已成功固定的範圍。
    (CVE-2026-89841)

請注意，Nessus 依賴供應商報告的套件存在。

Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且廠商未提供可用的修補程式。

  - USB：typec：hd3ss3220：追蹤每個消費者的 VBUS 啟用狀態 regulator_is_enabled（） 報告彙總調節器狀態，而不是此消費者是否持有啟用參照。如果另一個取用者先啟用 VBUS，驅動程式可以略過自己的 regulator_enable（） 呼叫，然後嘗試卸除從未取得的參考，從而觸發不平衡的調節器停用警告。在本機追蹤成功的啟用和停用呼叫。當作業失敗時，狀態保持不變，以便稍後的角色或識別碼通知重試作業，同時此取用者會保留平衡的參照。（CVE-2026-90028）

請注意，Nessus 的判定取決於廠商所報告的套件是否存在。

Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且廠商未提供可用的修補程式。

  - drm/nouveau/uvmm：展開 OP_UNMAP_SPARSE 時清除已變更的旗標 成功的OP_UNMAP_SPARSE會使用 nouveau_uvma_region_dirty（） 標記其區域已變更，並將拆卸推遲到 nouveau_uvmm_bind_job_cleanup（）;它不會從 UVMM->region_mt中移除該區域。如果作業中稍後的作業失敗，回溯路徑永遠不會清除 reg->dirty （設定在一個地方，但未在任何地方清除） 並設定 op->reg = NULL，因此清除會略過拆卸。此區域會以 dirty set 留在樹狀結構中，且從未發出完成訊號。之後超過該範圍的綁定會永久失敗 -- -ENOENT 或來自髒檢查的 -EINVAL，或 bind_validate_region（） 中無法終止的 wait_for_completion（） -- 在 uvmm 的生命週期內。
    當展開還原疏鬆取消映射時，清除 reg->dirty，將區域還原為找到它的狀態。（CVE-2026-89800）

請注意，Nessus 的判定取決於廠商所報告的套件是否存在。

Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且廠商未提供可用的修補程式。

  - media：cx23885：在拆卸之前取消 NetUP CI 工作 netup_ci_exit（） 釋放netup_ci_state，而其工作項目 netup_read_ci_status（） 可能仍在系統工作佇列上擱置或執行。工作者使用 container_of（） 取得狀態並取消參照它，因此它不能超過狀態。netup_ci_init（） 將初始狀態讀取排入佇列，CI GPIO 中斷隨後將來自 netup_ci_slot_status（） 的相同工作排入佇列。在移除期間，cx23885_finidev（） 會在 CI 裝置取消註冊之前呼叫 free_irq（）。free_irq（） 可防止進一步的 IRQ 處理常式執行，但不會清空先前排入佇列的工作，因此背景工作程式可以在 netup_ci_exit（） 釋放狀態後執行。在呼叫 dvb_ca_en50221_release（） 和 kfree（） 之前呼叫 cancel_work_sync（）。此問題是由內部靜態分析工具發現的。
    (CVE-2026-89893)

請注意，Nessus 依賴供應商報告的套件存在。

Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且廠商未提供可用的修補程式。

  - LoongArch： BPF：將競技場暫存器插槽移至 TCC 內容下方 目前，堆疊配置會將選用的競技場暫存器插槽放置在尾部呼叫計數器內容上方。動態啟用arena_vm_start時，它會移動堆疊框架內tcc_ptr槽的相對位移，導致硬式編碼追蹤巨集不相符，並可能導致記憶體未對齊或損毀。若要修正此問題，請將 arena 暫存器儲存和還原序列移至 build_prologue（） 和尾聲中的尾部呼叫計數器上下文插槽下方。更新 __build_epilogue（） 以插入適當的偏移遞減，以安全地跳過不需要的tcc_ptr讀取區塊，同時與最底部重新定位的競技場插槽準確對齊。使用此修補程式時，tcc_ptr位置一律會位於基底被呼叫者儲存暫存器正下方的固定距離，與競技場功能是否開啟無關。（CVE-2026-89905）

請注意，Nessus 的判定取決於廠商所報告的套件是否存在。

Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且廠商未提供可用的修補程式。

  - media：em28xx：修正中斷連線時 dev_next->devlist 的釋放後使用 當探測具有 has_dual_ts=1 的裝置並採用is_audio_only路徑時，dev 和 dev->dev_next 都會透過 em28xx_init_extension（） 新增至全域em28xx_devlist。但是，在中斷連線期間，em28xx_close_extension（dev） 只會呼叫 list_del（&dev->devlist），而 dev->dev_next->devlist 仍會連結在全域清單中。當dev_next隨後透過 kref_put（） 釋放時，其 devlist 項目會變成 em28xx_devlist 中的懸空指標。下一個呼叫 em28xx_init_extension（） 的裝置探查在偵測到已釋放的節點時觸發清單損毀錯誤list_add_tail。此錯誤是由提交 a368ecde8a50 （USB： core：透過清除描述元中的保留位元來修正重複端點錯誤） 暴露的，該錯誤會在端點剖析期間清除 bEndpointAddress 中的保留位元。這會導致模糊端點位址 （例如 0xf3） 被標準化為 0x83，em28xx 將其解譯為供應商音訊端點，從而啟用以前使用此類描述元無法連線的 is_audio_only + has_dual_ts 程式碼路徑。在釋放裝置之前，從 em28xx_close_extension（） 中的全域清單中移除 dev->dev_next->devlist 來修正此問題。（CVE-2026-89891）

請注意，Nessus 的判定取決於廠商所報告的套件是否存在。

Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且廠商未提供可用的修補程式。

  - nvme-tcp：檢查 C2HData PDU 的資料方向 nvme_tcp_handle_c2h_data（） 會依命令識別碼尋找要求，並檢查它是否具有承載，但不會檢查命令是否要求讀取資料。因此，使用 C2HData 回應寫入命令的控制器會到達 nvme_tcp_recv_data（），其中
    _copy_to_iter（） 命中 WARN_ON_ONCE（i->data_source） 並傳回 0。接收路徑會將其轉換為 -EFAULT 並重設控制器。不會複製任何資料，因此這不是記憶體損毀。控制器收到的是它可以隨意發出的核心警告，這對於使用 panic_on_warn 啟動的主機來說是致命的。傳送路徑已經知道方向 - 它在構建命令時會查閱 rq_data_dir（） - 並且 nvme_tcp_handle_r2t（） 檢查它命名的請求的長度和偏移。C2HData 路徑完全不檢查方向。拒絕命令不是讀取的 C2HData PDU。拒絕它會使命令失敗並重置控制器，就像此函式中的相鄰檢查所做的那樣;消失的是警告。[ 6.885580] ------------[ 切到這裡 ]------------ [ 6.886457] 警告：lib/iov_iter.c：193
    _copy_to_iter+0x289/0x1330， CPU#0： kworker/0：1H/71 [ 6.888137] CPU： 0 UID： 0 PID： 71 通訊： kworker/0：1H 未受污染 7.2.0-rc5-NVMETCP-gf5098b6bae76 #1 搶佔（延遲） [ 6.891165] 工作佇列： nvme_tcp_wq nvme_tcp_io_work [ 6.891875] RIP： 0010：_copy_to_iter+0x289/0x1330 [ 6.903739] 呼叫追蹤： [ 6.904085] 6.909254<TASK> [ ] __skb_datagram_iter+0x433/0x820 [ 6.911026] skb_copy_datagram_iter+0x37/0x120 [6.911622] nvme_tcp_recv_skb+0xa07/0x4320 [ 6.913378] __tcp_read_sock+0x1ab/0x810 [ 6.915788] nvme_tcp_try_recv+0x152/0x1e0[ 6.918222] nvme_tcp_io_work+0x1e4/0x6c0 [ 6.926906] </TASK> [ 6.927226]
    ---[ 結束追蹤 00000000000000000000 ]--- [ 6.927878] nvme nvme0：佇列 1 無法複製要求0x71資料 [6.928709] nvme nvme0：接收失敗：-14 （CVE-2026-89973）

請注意，Nessus 的判定取決於廠商所報告的套件是否存在。

Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且廠商未提供可用的修補程式。

  - USB：gadget：midi2：修正 f_midi2_free_ep_reqs 中的空指標解除參照 當嘗試清理從未初始化的端點時，f_midi2_free_ep_reqs（） 中會發生空指標解除參照。透過 configfs 設定 MIDI 2.0 小工具並將區塊方向設定為 SNDRV_UMP_DIR_INPUT 時，在小工具綁定階段 （f_midi2_bind（）） 期間會明確跳過 midi1_ep_out 端點的初始化。因此，usb_ep>卡片欄位會維持為 NULL。稍後，當主機設定替代設定時，f_midi2_set_alt（） 會呼叫 f_midi2_stop_eps（） 來無條件地停止 IN 和 OUT 端點，而 （） 又會呼叫兩個端點的 f_midi2_free_ep_reqs（）。當針對未初始化的midi1_ep_out呼叫 f_midi2_free_ep_reqs（） 時，它會嘗試取消參照 usb_ep->card 以確定要釋放的請求數，從而導致損毀。在 f_midi2_free_ep_reqs（） 中使用 usb_ep->num_reqs 而不是 usb_ep->card->info.num_reqs 來修正此問題。usb_ep->num_reqs 在 f_midi2_init_ep（） 期間正確設定，如果端點從未初始化，則保持 0，從而安全地避免迴圈。為了保持一致性，請將相同的變更套用至 f_midi2_alloc_ep_reqs（）。哎呀：一般保護錯誤，可能是非規範位址 0xdffffc00000000ee：0000 [#1] SMP KASAN NOPTI KASAN：
    null-ptr-deref in range [0x0000000000000770-0x0000000000000777] ... RIP：0010：f_midi2_free_ep_reqs drivers/usb/gadget/function/f_midi2.c：1166 [內聯] RIP：0010：f_midi2_stop_eps+0x28e/0x4d0 drivers/usb/gadget/function/f_midi2.c：1246 ... 呼叫追蹤： <TASK> f_midi2_set_alt+0x11c/0xf00 drivers/usb/gadget/function/f_midi2.c：1296 composite_setup+0x1ffd/0x3480 drivers/usb/gadget/composite.c：1933 configfs_composite_setup+0xbd/0x100 drivers/usb/gadget/configfs.c：1877 （CVE-2026-90024）

請注意，Nessus 的判定取決於廠商所報告的套件是否存在。

Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且廠商未提供可用的修補程式。

  - 惡意建構的郵件標頭可能會導致多個欄位被剖析為一個欄位，或潛在的記憶體安全違規。此漏洞已在 Thunderbird 156、Thunderbird 140.16和 Thunderbird 153.3中修復。（CVE-2026-92238）

請注意，Nessus 的判定取決於廠商所報告的套件是否存在。

Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且廠商未提供可用的修補程式。

  - media： cec： extron-da-hd-4k-plus：新增健全性檢查 新增檢查以防止溢位 msg.msg[]，以防傳入資料格式錯誤。（CVE-2026-89898）

請注意，Nessus 的判定取決於廠商所報告的套件是否存在。

Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且廠商未提供可用的修補程式。

  - USB： gadget： f_midi：初始化 f_midi_alloc（） 中的工作f_midi_alloc將 free_ref 初始化為 1，並且只有在透過 f_midi_register_card（） 註冊音效卡時才能遞增。f_midi_register_card（） 僅在實際執行INIT_WORK的 f_midi_bind（） 中調用。如果從未執行 f_midi_bind（），則不會初始化工作，且 f_midi_free 中的 if 條件變為 true，這會導致稍後在
    __flush_work為 work->func = 0。透過將INIT_WORK從 f_midi_bind（） 移至 f_midi_alloc（） 來修正此問題。
    (CVE-2026-90021)

請注意，Nessus 依賴供應商報告的套件存在。

Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且廠商未提供可用的修補程式。

  - ALSA： pcm：修正非原子操作和觸發啟動之間的爭用 我們保護不可部分完成 PCM 操作之間並發狀態轉換的爭用，但非不可部分完成操作 （hw_params、hw_free 和 prepare） 與不可部分完成操作之間的檢查並不完美;在 hw_params &; co 的開頭會檢查衝突的 PCM 狀態，但在非原子 PCM 作業期間仍可發出不可部分完成的 PCM 操作。範例這類案例是執行緒 A 針對已準備好的資料流程重新發出 PREPARE 或 HW_PARAMS，而另一個執行緒 B 會在準備作業中間觸發 PCM 啟動。雖然這通常不會導致太多嚴重的問題，但可能會造成一些不一致，如 syzkaller 所報告 （例如 ODEBUG 警告）。有各種原子 PCM 操作，基本上唯一的問題是 PCM 啟動，因為它從 PREPARED 狀態運行。其他觸發命令（停止等）適用於正在運行或其他特殊狀態，因此它們被過濾為先決條件。此修補程式用於防止在非原子作業期間觸發啟動，以解決上述問題。幸運的是，hw_params、hw_free和準備操作會呼叫 snd_pcm_buffer_access_lock（），這可用於檢查 PCM 觸發器的並發操作 -- 它將運行時>buffer_accessing設定為負數（如果可能），因此 PCM 觸發器只需要檢查運行時>buffer_accessing值;如果為負數，則表示並行的非原子 PCM 操作正在執行。（CVE-2026-89979）

請注意，Nessus 的判定取決於廠商所報告的套件是否存在。

Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且廠商未提供可用的修補程式。

  - mm/page_alloc：請勿在 UP 修補程式系列的 NMI 中spin_trylock（） mm/page_alloc：修正 RT/UP 上的 free_pages_nolock（）。Sashiko 在審查其他系列時發現的預先存在的錯誤：
    https://lore.kernel.org/all/20260703-alloc-trylock-v5-0-c87b714e19d3@google.com/ 我沒有重現這些錯誤，我懷疑沒有現實世界的用戶受到它們的影響。此修補程式 （共 2 個）：如 can_spin_trylock（） 中所述，在此上下文中使用它是不安全的。提交 620b46ed6ae17 （mm/page_alloc：
    從 UP 的 NMI 中的 alloc_frozen_pages_nolock（） 提前返回 NULL）在分配端修正了此問題，但遺漏了空閒端。影響：如果非 SMP 組建上存在使用 NMI 中這些功能 （可能追蹤） 的 BPF 程式，這可能會使核心當機，並可能被本機攻擊者惡意利用來提升權限。（CVE-2026-90046）

請注意，Nessus 的判定取決於廠商所報告的套件是否存在。

Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且廠商未提供可用的修補程式。

  - media： rtl2832_sdr：在 start_streaming（） 失敗 rtl2832_sdr_start_streaming（） 呼叫 rtl2832_sdr_alloc_stream_bufs（） 、rtl2832_sdr_alloc_urbs（） 和 rtl2832_sdr_submit_urbs（） 依序釋放 URB 和資料流緩衝區，並共用一個 ERR： 標籤，只會解除鎖定互斥並傳回。當 alloc_urbs（） 成功但 submit_urbs（） 失敗時，或當 alloc_urbs（） 本身在 alloc_stream_bufs（） 已經成功之後傳回 -ENOMEM 時，URB 和/或一致的 DMA 資料流緩衝區會保持配置狀態，同時串流向 vb2 報告失敗。接下來VIDIOC_STREAMON有兩個潛在缺陷：
    1） rtl2832_sdr_alloc_stream_bufs（） 無條件地將 dev->buf_num 重設為 0 並覆蓋 dev->buf_list[]/dev->dma_addr[]，永久洩漏上次嘗試配置的相干 DMA 記憶體。2） rtl2832_sdr_alloc_urbs（） 從不重設 dev->urbs_initialized，只會遞增它。第二次成功傳遞後，urbs_initialized 可能會超過 MAX_BULK_BUFS，因此後續的 rtl2832_sdr_free_urbs（） 會從 urbs_initialized - 1 向下遍歷到 0，並讀取 dev->urb_list[] 結尾，將垃圾指標傳遞給 usb_free_urb（）。鏡像 stop_streaming（） 已經執行的拆卸：在錯誤路徑上，在解鎖之前呼叫 rtl2832_sdr_free_urbs（） 和 rtl2832_sdr_free_stream_bufs（）。這兩個協助程式都是冪等的 （free_urbs終止和零urbs_initialized;free_stream_bufs在URB_BUF上受閘控並清除buf_num計數器），因此部分故障路徑和無分配路徑保持安全。透過自動審查 INV-003 系列 https://sashiko.dev/(CVE-2026-89880發現的問題，網址為 ）

請注意，Nessus 的判定取決於廠商所報告的套件是否存在。

Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且廠商未提供可用的修補程式。

  - media：cx231xx：在 VBI 佇列忙碌時拒絕幾何圖形變更 vidioc_s_fmt_vid_cap（） 和 vidioc_s_std（） 變更裝置範圍的 dev->width / dev->norm，但僅在 *video* 佇列 （dev->vidq） 忙碌時拒絕變更。VBI 佇列 （dev->vbiq） 共用相同的幾何圖形：cx231xx_init_vbi_isoc（） 從 dev->norm 閂鎖 dma_q->lines_per_field，VBI videobuf2 平面在 vbi_queue_setup（） 和 vbi_buf_prepare（） 中根據 dev->width / dev->norm 調整大小，然後 cx231xx_do_vbi_copy（） 在每次 URB 完成時重新計算 *live* dev->width 和閂鎖lines_per_field的目的地偏移量：
    偏移 = lines_completed * （dev->寬度 << 1） + ...;if （dma_q->current_field == 2） 偏移量 += dev->width * 2 * dma_q->lines_per_field;memcpy（plane + offset， p_buffer， lencopy）;由於 VBI 節點與視訊節點共用video_ioctl_ops，因此應用程式可以調整小型 VBI 平面 （具有較小寬度或 NTSC 標準的 REQBUFS/QBUF） ，然後在 VBI 資料流程執行時透過視訊節點擴大 dev->width （或將 dev->norm 切換為 PAL） -- 允許變更，因為只會檢查 dev->vidq -- 並讓裝置傳遞欄位 2 VBI 承載。cx231xx_do_vbi_copy（） 現在會計算具有較大幾何圖形的偏移量，並且 memcpy（） 超出已配置的較小平面的末端，這是一個堆積越界寫入，其偏移量由攻擊者選擇，其內容來自裝置。cx231xx_copy_vbi_line（） 中的 per-field guard 無濟於事：它將副本限制在閂鎖的lines_per_field上，而不是平面的實際容量，並且 vb2 不會對已經準備好的緩衝區重新執行 buf_prepare（）。當 VBI 佇列忙碌時，也拒絕格式/標準變更，因此幾何圖形無法在已配置的 VBI 緩衝區下方變更。（CVE-2026-89894）

請注意，Nessus 的判定取決於廠商所報告的套件是否存在。

Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且廠商未提供可用的修補程式。

  - iio： pressure： dps310：修正 ACPI 探查上的 NULL 指標解除參照 當裝置透過其 ACPI HID （）IFX3100 列舉裝置時，i2c_client_get_device_id（） 傳回 NULL：ACPI 衍生的用戶端名稱不符合驅動程式的i2c_device_id表。 然後，dps310_probe（） 會取消參照 iio->name = id->name 中的 NULL 指標，並在探查期間使核心損毀。IIO 裝置名稱一律為 dps310，因此請直接設定並刪除現在未使用的裝置識別碼查詢。（CVE-2026-89933）

請注意，Nessus 的判定取決於廠商所報告的套件是否存在。

Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且廠商未提供可用的修補程式。

  - USB：小工具：修正 usb_put_function_instance（） 中的 NULL 指標解除參照 usb_put_function_instance（） 嘗試在 FI 結構中取消參照 fd 以在 uvc_alloc_inst（） 錯誤路徑中獲取 mod。但是，在 uvc_alloc_inst（） 中配置 fi 後，直到稍後在 try_get_usb_function_instance（） 中才會分配 fd，因此保證在錯誤路徑中為 null。透過新增 fi->fd 的 null 檢查來修正此問題，如果 fd 為 null，則傳回該檢查。
    (CVE-2026-90019)

請注意，Nessus 依賴供應商報告的套件存在。

Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且廠商未提供可用的修補程式。

  - samples/damon/mtier：處理 damon_stop（） 失敗 damon_sample_mtier_stop（） 假設其 damon_stop（） 呼叫一律會成功停止兩個 DAMON 內容。因此，它會在 damon_stop（） 呼叫之後解除配置兩個 DAMON 內容。但是，如果給定的上下文已經停止，damon_stop（） 會失敗並傳回錯誤，同時讓尚未停止的 DAMON 上下文繼續運行。由於 kdamond_fn（） 中的記憶體配置失敗，可能會發生這種意外的早期 DAMON 上下文停止。因為 damon_sample_mtier_stop（） 只是將所有 DAMON 上下文與連結到上下文的damon_target和damon_region物件解除配置，所以未停止的 DAMON 上下文 （kdamond） 的執行最終會使用釋放的記憶體 （釋放後使用）。透過將要叫用的 damon_stop（） 分隔到每個內容來修正此問題。請注意，DAMON_SYSFS也允許多個 DAMON 上下文執行。但是，它會逐一呼叫每個上下文的 damon_stop（）。因此，此問題僅在 mtier 中。從長遠來看，最好重構 damon_stop（），以始終確保停止所有上下文，無論中間是否發生故障。
    不過，請以目前的方式進行此修復，以保持簡單且易於反向移植。我稍後會進行重構。這個問題是由 Sashiko 發現的 [1]。（CVE-2026-90006）

請注意，Nessus 的判定取決於廠商所報告的套件是否存在。

Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且廠商未提供可用的修補程式。

  - KVM：arm64：正確地將 TLBI 範圍限制為架構限制 TLB 依範圍無效有一種相當強大的方法，可以在少量位元中對相當大的範圍進行編碼。此範圍可以基於任意 VA，這意味著如果虛擬管理程式足夠天真，將範圍新增至基底，客體很容易產生溢位... 請確定範圍上限為決定 VA 範圍的位址位元所規定的限制。對於 IPA 無效，這將進一步糾正以忽略上限範圍。（CVE-2026-89911）

請注意，Nessus 的判定取決於廠商所報告的套件是否存在。

Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且廠商未提供可用的修補程式。

  - scsi：qla2xxx：序列化在重設處理常式中讀取的快閃記憶體版本 未重設 sysfs 重設作業 （0x20261） 的更新快取版本會呼叫 get_flash_version（），其讀取硬體快閃記憶體暫存器，而不保留 ha->optrom_mutex。VPD 更新路徑會序列化 optrom_mutex 下的相同呼叫，因此此重設路徑可能會將其快閃記憶體暫存器存取與並行 VPD 或 optrom 快閃記憶體作業交錯，並損毀讀取。在 get_flash_version（） 呼叫中保留 ha->optrom_mutex 以符合 VPD 更新路徑。
    (CVE-2026-89855)

請注意，Nessus 依賴供應商報告的套件存在。

Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且廠商未提供可用的修補程式。

  - drm/amdgpu：在重設時強制完成 KIQ 環圍欄 與 MES 排程器環一樣，KIQ 環設定 no_scheduler = true 並使用輪詢柵欄，因此 amdgpu_device_pre_asic_reset（） 中的強制完成迴圈會略過它。其 hw fence 值位於 wb （GTT） 記憶體中，並在 fence_drv.sync_seq 繼續前進時在 MODE1 重設後倖存下來，因此在重設之後，第一個 KIQ 提交可以永遠輪詢永遠不會回寫的 seq。強制完成 KIQ 環形圍欄，以便將其硬體圍欄重新對齊為 sync_seq。 （CVE-2026-89813）

請注意，Nessus 的判定取決於廠商所報告的套件是否存在。

Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且廠商未提供可用的修補程式。

  - scsi：qla2xxx：在 qla24xx_report_id_acquisition（） 中保留 vport 參照 在格式 1 路徑中，虛擬連接埠位於 ha->vp_list 上，同時保留 vport_slock，但在使用 vp 之前會刪除鎖定：
    qla_update_host_map（） 被調用，並在 vp 上設置 VP_IDX_ACQUIRED/REGISTER_FC4_NEEDED/ REGISTER_FDMI_NEEDED。該視窗不會進行任何參照，因此並行 qla24xx_deallocate_vp_id（） 可以拆除 vport 並將其釋放，從而導致釋放後使用。找到匹配的vp時，在vport_slock下獲取vport參照（vref_count），並在上次使用vp後將其刪除。qla24xx_deallocate_vp_id（） 會等待 vref_count 達到零，然後再取消連結並釋放 vport，因此指標會保持有效。這與其他 ha->vp_list 遊歷已經使用的參照習用法相符。（CVE-2026-89861）

請注意，Nessus 的判定取決於廠商所報告的套件是否存在。

Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且廠商未提供可用的修補程式。

  - NFSD：在close_lru收割期間防止用戶端釋放後使用 在最終 CLOSE 之後留在 nn->close_lru 上的nfs4_openowner會將其最後關閉的 stateid 保留在 oo_last_closed_stid，僅保留指向其nfs4_client的原始指標。自助洗衣店收穫逾時項目、丟棄 nn->client_lock，並呼叫 nfs4_put_stid（），後者會透過 cl_lock 解除參照用戶端。沒有任何內容會將用戶端固定在該視窗中，因此並行 force_expire_client（） 可以釋放它，而 nfs4_put_stid（） 讀取釋放的記憶體。__destroy_client（） 也參加了同樣的比賽，在沒有cl_lock的情況下走了 clp->cl_openowners。在丟棄client_lock用戶端之前，先使用 cl_rpc_users 釘選用戶端，並略過已過期的用戶端。然後，__destroy_client（） 會透過 release_last_closed_stateid（） 清理自己的close_lru項目，因此 teardown 不再與自助洗衣店競爭。
    (CVE-2026-90037)

請注意，Nessus 的判定取決於廠商所報告的套件是否存在。

Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且廠商未提供可用的修補程式。

  - fs/ntfs3：修正 ni_create_attr_list（） 中的 slab-out-of-bounds 寫入 ni_create_attr_list（） 配置一個 al_aligned（record_size） （== record_size） 位元組的固定緩衝區，然後遍歷主要 MFT 記錄的每個屬性，每個屬性寫入一個ATTR_LIST_ENTRY，並按 le_size（name_len） 前進游標，而不檢查緩衝區的末端;總大小只會在迴圈之後計算。最小大小的常駐屬性會佔用磁碟上的 SIZEOF_RESIDENT （0x18 = 24） 位元組，但未命名的屬性會在清單中展開為 le_size （0） （0x20 = 32） 位元組。因為記錄中的屬性數目沒有界限 （mi_enum_attr（） 接受任意多個相同類型、無名稱的最小大小屬性），所以包含這類屬性的特製記錄會產生大於record_size的清單，並溢位堆積緩衝區。這可從特製的迴圈掛載 NTFS 映像檔中實現：開啟檔案並新增屬性 （例如透過 setxattr） 驅動 ntfs_set_ea（） -> ni_insert_resident（） -> ni_insert_attr（） -> ni_ins_attr_ext（） -> ni_create_attr_list（）。錯誤：KASAN：ni_create_attr_list+0xc48/0x1058 中的 slab-out-of-bounds by task setfattr/345 ni_create_attr_list+0xc48/0x1058 ni_ins_attr_ext+0x510/0x7c0 ni_insert_attr+0x3f8/0x70c ni_insert_resident+0xc8/0x3b0 ntfs_set_ea+0x66c/0xd28 ntfs_setxattr+0x4d8/0x5b0 在 addr ffff000008984c00 寫入大小 4
    __arm64_sys_setxattr+0xa4/0x124 由作業 345 分配：ni_create_attr_list+0x188/0x1058 有錯誤的位址屬於大小為 1024 的快取 kmalloc-1k （寫入位於 object+1024）。根據實際屬性調整緩衝區大小，而不是假設單一record_size一律就足夠了。（CVE-2026-90048）

請注意，Nessus 的判定取決於廠商所報告的套件是否存在。

Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且廠商未提供可用的修補程式。

  - s390/vfio-ap：修正取消參照 matrix_mdev->kvm，而不檢查 NULL ap_driver結構有兩個欄位，它們是回呼的函數指標： * .on_config_changed：在 AP 匯流排掃描功能開始時調用，以通知裝置驅動程式主機 AP 配置已變更，相關聯的 AP 裝置將相應地新增或移除。這讓實作者有機會評估設定變更，並在新增或移除相關聯裝置之前回應這些變更。* .on_scan_complete：在 AP 匯流排掃描功能結束時調用，以通知設備驅動程式主機 AP 配置已變更，並相應地新增或刪除 AP 設備。這讓實作者有機會在新增或移除相關聯裝置之後回應變更。
    這兩個回呼分別透過 vfio_ap_on_cfg_changed 和 vfio_ap_on_scan_complete 函式在 vfio_ap 裝置驅動程式中實作。在這兩個回呼函式的呼叫堆疊中，採用 matrix_mdev->kvm->lock 互斥，而不檢查 matrix_mdev->kvm 是否為 NULL。如果從未設定過 matrix_mdev->kvm，則嘗試取得鎖定將觸發 NULL 指標解除參照。此修補程式在採用 matrix_mdev->kvm->lock 互斥之前，新增了對 matrix_mdev->kvm == NULL 的檢查。請注意，vfio_ap_mdev_hot_plug_config函式中取得的 matrix_mdev->kvm->lock 互斥會與存取matrix_mdev欄位所需的 matrix_dev->mdevs_lock 一起移至呼叫函式。在獲取 kvm->lock 互斥之前更改對 matrix_mdev->kvm 的檢查只是必須通過另一個補丁將其移出是沒有意義的，因此在此補丁中完成。請務必注意下列事項： 1. matrix_dev >guests_lock是在兩個回呼函式的開頭取得。這可確保不會透過 vfio_ap_mdev_remove 函式移除matrix_mdev，因為移除物件之前也需要matrix_dev_guests_lock;因此，matrix_mdev將在回呼函式期間可用。2. 必須採用 matrix_dev >mdevs_lock互斥才能存取matrix_mdev結構 3 中的欄位。matrix_mdev->kvm->lock 互斥必須在 matrix_dev->mdevs_lock 之前使用，以防止 lockdep splat。4：透過vfio_ap_mdev_update_guest_apcb函式將客體的 AP 組態插入其 SIE 狀態描述時，必須保持 kvm->lock。
    5.在執行客體AP配置的熱插拔之前，vfio_ap_mdev_update_guest_apcb會檢查matrix_mdev->kvm以驗證它不是NULL。（CVE-2026-89958）

請注意，Nessus 的判定取決於廠商所報告的套件是否存在。

Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且廠商未提供可用的修補程式。

  - s390/vfio-ap：修正存取ap_matrix_mdev物件清單所需的遺失鎖定 若要周遊或新增/移除 matrix_dev >mdev_list中的ap_matrix_mdev物件，必須保留 matrix_dev >guests_lock互斥。有兩個函數可以在不保留互斥的情況下存取清單： vfio_ap_mdev_probe 函數 ~~~~~~~~~~~~~~~~~~~~~~~~~~~ vfio_ap_mdev_probe 函數使用 matrix_dev >mdevs_lock互斥來保護將新建立的 ap_matrix_mdev 物件新增至 matrix_dev >mdev_list。此互斥不保護清單存取;其目的是防止並行存取ap_matrix_mdev物件中包含的欄位。如果同時建立或移除另一個 mdev，可能會導致核心記憶體損毀或釋放後使用。現在，將 ap_matrix_mdev 物件新增至 matrix_dev->mdev_list 會受到 matrix_dev->guests_lock 的保護，這是防止並行 mdev_list 存取的正確方法。也移除了以下兩行程式碼，因為 matrix_mdev 是透過使用 kzalloc 的vfio_alloc_device巨集配置的，因此在呼叫 vfio_register_emulated_iommu_dev 之前配置結構時，req_trigger 和 cfg_chg_trigger 已經初始化為零。這可防止在裝置公開給使用者空間後，將這些觸發程式設為 NULL 的視窗。matrix_mdev->req_trigger = 空;
    matrix_mdev->cfg_chg_trigger = 空;vfio_ap_mdev_for_queue函式 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 支援顯示 /sys/bus/ap/devices 中裝置狀態屬性的 status_show 函式會呼叫 vfio_ap_mdev_for_queue 函式，該函式會反覆運算 matrix_dev->mdev_list，以尋找代表佇列裝置的物件，其狀態要顯示。若要周遊此清單，必須保留 matrix_dev >guests_lock互斥。為了解決此問題，在 status_show 函式中採用 matrix_dev >mdevs_lock互斥之前，先採用guests_lock互斥。它被帶到那裡而不是 vfio_ap_mdev_for_queue 函數 - 在需要的地方 - 因為它必須在mdevs_lock互斥器之前取，以遵守正確的鎖定順序並防止 lockdep splat;也因為需要mdevs_lock才能存取該函式中matrix_mdev物件內的欄位。請參閱 Linux 核心樹狀結構中的 vfio-ap-locking.rst。（CVE-2026-89956）

請注意，Nessus 的判定取決於廠商所報告的套件是否存在。

Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且廠商未提供可用的修補程式。

  - bpf：在bpf_get_stackid中停用搶佔 get_perf_callchain呼叫需要停用搶佔，而且只要我們存取其傳回的追蹤項目緩衝區，我們就需要停用它。請注意，bpf_get_stackid_pe函式已在停用搶佔的情況下執行。（CVE-2026-89799）

請注意，Nessus 的判定取決於廠商所報告的套件是否存在。

Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且廠商未提供可用的修補程式。

  - KVM：arm64：vgic-v3：在 vgic_v3_save_pending_tables vgic_v3_save_pending_tables（） 中獲取 LPI 參照，使用 xa_for_each（） 迭代 dist->lpi_xa，並在迴圈主體中取消參照傳回的結構vgic_irq，而無需在 LPI 上保留參照。xarray 迭代器僅在查詢目前項目時提供暫時的 RCU 涵蓋範圍。這對於此迴圈主體來說是不夠的，它會從結構vgic_irq讀取欄位，並在反覆專案完成之前執行客體記憶體存取。並行路徑可能會觸發此爭用：irqfd 快取注入路徑 （vgic_its_inject_cached_translation） 透過 vgic_its_check_cache（） 取得暫時性 LPI 參照，而不保留 kvm->lock、vcpu->mutex、config_lock 或 its_lock。如果客體 ITS DISCARD 然後刪除 its_lock 下的快取和 ITE 參照，則暫時性注入參照可能會成為最終參照。當 vgic_put_irq（） 刪除它時，LPI 會從lpi_xa中刪除並透過 kfree_rcu（） 釋放。同時，vgic_v3_save_pending_tables（） 可能仍保留從 xarray 迭代器取得的過時指標，並在 RCU 寬限期結束後取消參照它。透過 vgic_get_irq（） 重新擷取每個反覆運算的 LPI 來解決此問題，該 LPI 採用穩定的參照，並在所有路徑上使用 vgic_put_irq（） 將其刪除。這符合 vgic ITS 程式碼中其他 lpi_xa 迭代器已使用的模式。
    (CVE-2026-89913)

請注意，Nessus 依賴供應商報告的套件存在。

Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且廠商未提供可用的修補程式。

  - drm/amdgpu：限制分割區外環的隔離索引 adev->isolation[] 每個分割區有一個插槽，但未指派給一個環的環會保持AMDGPU_XCP_NO_PARTITION，即 ~0，因此用它為陣列編製索引是越界的。SDMA 提交在隔離強制執行和 VM 排清路徑和跳閘 UBSAN 上都遇到此問題。以更乾淨的著色器路徑已執行的方式回復至第一個插槽，並在環形類型檢查之前停止取得位址，使其相關。（CVE-2026-89814）

請注意，Nessus 的判定取決於廠商所報告的套件是否存在。

Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且廠商未提供可用的修補程式。

  - 如果 BIND 剖析器遇到參照 14 個以上 SVCB/HTTPS ServiceMode 記錄的 SVCB/HTTPS AliasMode 記錄，可能無法正確解除配置內部資源。如果這種情況反覆發生，資源耗盡最終會阻止解析器執行新的遞迴查詢。此問題會影響 BIND 9 版本 9.18.09.18.50（至 、 至 9.20.09.20.27、 9.21.09.21.25至 、 9.18.11-S1 至 9.18.50-S1 和 9.20.9-S1 至 9.20.27-S1）。（CVE-2026-81563）

請注意，Nessus 的判定取決於廠商所報告的套件是否存在。

Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且廠商未提供可用的修補程式。

  - drm/nouveau/dmem：修正大型對開本不相符的 DMA 取消對應大小 裝置私有 THP 移轉會使用 page_size（） 對應移轉緩衝區，並以 dma_info->size 記錄該長度。對於複合對開本，page_size（） 是PAGE_SIZE <<順序，但兩個拆卸網站仍會將文字PAGE_SIZE傳遞給 dma_unmap_page（）：- 成功路徑上的 nouveau_dmem_migrate_to_ram（），以及複製錯誤路徑上的 - nouveau_dmem_migrate_copy_one（）。對於 0 對開本>訂單，此取消映射的數量少於映射的，從而洩露了 IOMMU/IOVA 映射的其餘部分。nouveau_dmem_migrate_chunk（） 和 nouveau_dmem_evict_chunk（） 中的其他取消映射站點已經使用了保存的大小;在這裡也使用它。
    (CVE-2026-89804)

請注意，Nessus 依賴供應商報告的套件存在。

Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且廠商未提供可用的修補程式。

  - drm/panel-edp：修正探查失敗時的 I2C 轉接器洩漏 如果裝置樹狀結構冗餘地使用「ddc-i2c-bus」屬性指向輔助 ddc 匯流排，請務必在探查失敗 （例如探查延遲） 和驅動程式解除綁定時刪除 i2c 配接器參照。CVE-2026-89824

請注意，Nessus 的判定取決於廠商所報告的套件是否存在。

Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且廠商未提供可用的修補程式。

  - spi：修正部分對應失敗時的 DMA 對應擁有權 如果 TX 對應成功後 RX 對應失敗，
    __spi_map_msg（） 取消映射 TX，但保留tx_sg_mapped設定。如果 TX 對應在稍後的傳輸中失敗，則為先前的傳輸建立的對應會保持作用中狀態。在這兩種情況下，cur_{tx，rx}_dma_dev 尚未更新，因為只有在每次傳輸都對應之後才會指派它們。因此，後續的 spi_unmap_msg（） 可能會再次取消對應 TX 對應，或使用 NULL 或過時裝置釋放先前的對應。使用 NULL 裝置可能會觸發 oops。空白 SG 表格不會防止 NULL 解除參照，因為 dma_unmap_sg_attrs（） 會在檢查項目計數之前存取裝置。在對應開始之前發佈這兩個對應裝置，並透過 __spi_unmap_msg（） 解除所有失敗。這會清除對應旗標，並使用建立對應的裝置釋放每個對應一次。在迴圈之前發佈裝置也會在不需要對應傳輸時重新整理裝置。在此情況下，不會設定對應旗標，因此目前的使用者不會使用指標作為對應擁有者。（CVE-2026-90012）

請注意，Nessus 的判定取決於廠商所報告的套件是否存在。

Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且廠商未提供可用的修補程式。

  - accel/ethosu：修正工作完成柵欄清理 ethosu_ioctl_submit_job（） 在驗證緩衝區控制碼之前配置done_fence。配置呼叫 ethosu_job_err_cleanup（） 之後發生錯誤，這會釋放作業，但會洩漏未初始化的柵欄。排程器相依性錯誤也會讓 ethosu_job_run（） 在 dma_fence_init（） 之前返回。然後，正常清理會將歸零的參照計數傳遞給 dma_fence_put（）。在通用清理路徑中釋放done_fence，並使用 dma_fence_was_initialized（） 將初始化的柵欄與原始配置區分開來。[robh：也修正 goto]（CVE-2026-89976）

請注意，Nessus 的判定取決於廠商所報告的套件是否存在。

Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且廠商未提供可用的修補程式。

  - nvme-fc：當 nvme_add_ctrl（） 失敗時，修正雙重釋放光纖選項 nvmf_create_ctrl（） 擁有光纖選項，並在 ->create_ctrl（） 傳回錯誤時釋放它們，因此傳輸不得在自己的錯誤路徑上釋放它們。nvme-fc 透過在 nvme_fc_ctrl_free（） 中測試 ctrl->ctrl.opts 來追蹤這一點，這需要 nvme_fc_init_ctrl（） 在每次錯誤退出時清除該指標。耦合是隱含的，提交 1a9e218195a5 （nvme：從初始化開始分割裝置新增） 透過新增第二個錯誤退出來破壞它。當 nvme_add_ctrl（） 失敗時，nvme_fc_init_ctrl（） 會跳轉到 out_put_ctrl：，經過僅位於 fail_ctrl： 路徑上的 ctrl->ctrl.opts = NULL，因此 nvme_fc_ctrl_free（） 釋放選項並nvmf_create_ctrl（） 第二次釋放它們： 錯誤：KASAN：nvmf_free_options+0x30/0x190 nvmf_free_options+0x30/0x190 drivers/nvme/host/fabrics.c：1284 中的 slab-use-after-free nvmf_create_ctrl drivers/nvme/host/fabrics.c：1374 [內聯] 由任務釋放5534：nvme_fc_ctrl_free drivers/nvme/host/fc.c：2374 [內嵌] nvme_fc_init_ctrl+0xe17/0x1450 drivers/nvme/host/fc.c：3605 當 dev_set_name（） 無法配置時，drivers/nvme/host/fc.c：3605 nvme_add_ctrl（） 會失敗，因此在記憶體壓力或錯誤插入下可以實現此操作。如果沒有 KASAN，期權會被釋放兩次。與其清除第二個出口上的指標，不如像 nvme-tcp、nvme-rdma 和 nvme-loop 一樣從清單成員資格衍生所有權：除非控制器進入傳輸清單，否則它們的free_ctrl會保留選項。清單不能簡單地填入成功路徑上，因為它就在那裡。nvme-fc 透過 flush_delayed_work（） 同步執行初始連接，並且整個控制器必須在 rport->ctrl_list 上可連線：
    nvme_fc_unregister_remoteport（） 需要找到它來發出連接遺失的訊號，nvme_fc_match_disconn_ls（） 將傳入的中斷連接關聯 LS 與 ctrl->association_id 進行匹配，該 LS 僅在該窗口期間分配，nvme_fc_resume_controller（） 在遠端連接埠重新註冊時需要它，並且 nvme_fc_existing_controller（） 使用它來拒絕與正在進行的重複連接競爭。將插入保留在原處，並針對其後執行的錯誤路徑新增 fail_unlist： 標籤，落入 fail_ctrl：。較早的錯誤路徑永遠不會到達插入，並繼續直接使用 fail_ctrl：，因此只有控制器實際所在的位置才會觸及清單。nvme_fc_ctrl_free（） 不能使用其他傳輸free_ctrl使用的普通 goto，因為它仍然必須put_device（），釋放 rport 參照，並為插入之前獲取的資源釋放 ida 項目。改為在 rport->lock 下取樣 list_empty（）。ctrl->ctrl.opts 現在在整個拆卸過程中也保持有效。這不是要修正的錯誤，但它消除了舊慣用語的一些脆弱性：nvme_free_ctrl（） 在 ->free_ctrl（） 之前呼叫 nvme_auth_free（），並且當設定 ctrl->dhchap_ctxs 時，ctrl_max_dhchaps（） 在沒有 NULL 檢查的情況下取消參照 ctrl->opts，這是 nvme-fc 允許的，因為 NVMF_ALLOWED_OPTS 允許 dhchap 選項。取消參照 ctrl->opts 的 nvme sysfs 屬性 （例如 hostnqn 和 address） 會在 device_add（） 時間評估一次其 is_visible（） 測試，並在 cdev_device_del（） 之前保持可讀性。（CVE-2026-89974）

請注意，Nessus 的判定取決於廠商所報告的套件是否存在。

Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且廠商未提供可用的修補程式。

  - zram：修正 big-endian 64 位元上的插槽鎖定位元位置 插槽鎖定是對整個__lock字的位元操作，它標記並ac_time別名為兩個 u32。在 little-endian 上，鎖定位落在旗標中的保留位置ZRAM_ENTRY_LOCK，因此混疊會起作用。在 64 位元 big-endian 上，它降落在ac_time中：啟用 ZRAM_TRACK_ENTRY_ACTIME 後，儲存來自 mark_slot_accessed（） 或 slot_free（） 的存取時間會清除持有的鎖定位元，讓另一個 CPU 採用相同的插槽鎖定;設定該位元的存取時間值會讓插槽看起來永遠鎖定。將鎖定位移至大端 64 位元字的旗標一半。（CVE-2026-90043）

請注意，Nessus 的判定取決於廠商所報告的套件是否存在。

Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且廠商未提供可用的修補程式。

  - media：cobalt：避免兩次釋放 ALSA 私有資料 snd_cobalt_card_create（） 將 cobsc 儲存在 sc->private_data 中，並將 snd_cobalt_card_private_free（） 安裝為 sc->private_free。從那時起，snd_card_free（sc） 會透過 ALSA 卡片清除路徑釋放 cobsc。如果 cobalt_alsa_init（） 在 snd_cobalt_card_create（） 之後失敗，則err_exit_free路徑會呼叫 snd_card_free（sc），然後呼叫 kfree（cobsc）。第二個釋放會再次釋放相同的物件。移除明確的 kfree（cobsc），並將擁有權留給 ALSA 卡。此問題由靜態分析檢查程式發現，並經手動來源檢閱確認。
    (CVE-2026-89895)

請注意，Nessus 依賴供應商報告的套件存在。

Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且廠商未提供可用的修補程式。

  - drm/amd/display：避免 __is_lut_linear（） 中的除以零 __is_lut_linear（） 計算每個項目的預期值，預期值為 = i * MAX_DRM_LUT_VALUE / （大小 - 1）;如果曾經使用單一輸入 LUT 呼叫它，則大小 - 1 為零，核心會發生除法錯誤 （#DE）。項目少於兩個的 LUT 無論如何都無法描述線性映射，因此請儘早傳回 false，而不是除以零。（CVE-2026-89821）

請注意，Nessus 的判定取決於廠商所報告的套件是否存在。

Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且廠商未提供可用的修補程式。

  - drm/ttm：還原成功後刪除 tt->restore ttm_pool_restore_and_alloc（） 可以透過 ttm_pool_restore_commit（） 成功完成還原過程，但之後不會刪除 tt->restore。因此，後續的備份/還原流程會觀察看似已完成的還原，但實際上 shmem 控制碼仍安裝在 tt->pages 中，從而導致下面的堆疊追蹤。成功完成還原後，釋放並刪除 ttm_pool_restore_and_alloc（） 中的 tt->restore 來修正此問題。20545 [309.784531] RIP： 0010：sg_alloc_append_table_from_pages+0x38c/0x490 20547 [ 309.809570] RSP：
    0018：ffffc9000623b838 EFLAGS：00010206 20548 [ 309.814827] RAX：0000000000001000 RBX：ffff88816e42a160 RCX：000000000000000000 20549 [ 309.821986] RDX：0000000000002000 RSI：0000000000000003 RDI：
    0000000000001000 20550 [ 309.829147] RBP： ffff88816e42a168 R08： 0000000000000002 R09： 000000007ffff000 20551 [ 309.836310] R10： ffffc9000623b928 R11： 0000000000000000 R12： 0000000007ffff000 20552 [ 309.843471] R13： ffff88815ba5a100 R14： 0000000000000000 R15： 0000000000000001 20553 [ 309.850634] FS：
    00007f9ff305e700（0000） GS：ffff888276c94000（0000） knlGS：0000000000000000 20554 [ 309.858749] CS：0010 DS：
    0000 ES： 0000 CR0： 0000000080050033 20555 [ 309.864519] CR2： 00007f9fca701000 CR3： 00000001565e2005 CR4：
    0000000008f70ef0 20556 [ 309.871678] PKRU：55555558 20557 [ 309.874403] 呼叫追蹤：20558 [ 309.876866] <TASK> 20559 [ 309.878988] sg_alloc_table_from_pages_segment+0x60/0x100 20560 [ 309.884415] ？ ttm_resource_manager_usage+0x36/0x60 [TTM] 20561 [ 309.889845] ？ xe_tt_map_sg+0x7d/0xd0 [xe] 20562 [309.894045] xe_tt_map_sg+0x7d/0xd0 [xe] 20563 [ 309.898037] xe_bo_move+0x927/0xaa0 [xe] 20564 [309.902029] ttm_bo_handle_move_mem+0xba/0x170 [ttm] 20565 [ 309.907022] ttm_bo_validate+0xbe/0x190 [ttm] 20566 [ 309.911405] xe_bo_validate+0x9a/0x120 [xe] 20567 [ 309.915663] xe_gpuvm_validate+0xd9/0x140 [xe] 20568 [ 309.920206] drm_gpuvm_validate+0x2f0/0x5b0 [drm_gpuvm] 20569 [ 309.925459] ？ drm_exec_lock_obj+0x63/0x210 [drm_exec] 20570 [ 309.930627] xe_vm_validate_rebind+0x46 0xb0/ [xe] 20571 [309.935428] xe_exec_fn+0x20/0x40 [xe] 20572 [ 309.939249] drm_gpuvm_exec_lock+0x78/0xc0 [drm_gpuvm] 20573 [ 309.944410] xe_validation_exec_lock+0x5a/0xa0 [xe] 20574 [ 309.949385] xe_exec_ioctl+0x806/0xc30 [xe] 20575 [ 309.953639] ?ttwu_queue_wakelist+0xd9/0xf0 20576 [ 309.957935] ？ __pfx_xe_exec_fn+0x10/0x10 [xe] 20577 [ 309.962449] ？ __wake_up_common+0x73/0xa0 20578 [ 309.966482] ？ __pfx_xe_exec_ioctl+0x10/0x10 [xe] 20579 [ 309.971263] drm_ioctl_kernel+0xa3/0x100 20580 [ 309.975209] drm_ioctl+0x213/0x440 20581 [309.978637] ？ __pfx_xe_exec_ioctl+0x10/0x10 [xe] 20582 [ 309.983415] xe_drm_ioctl+0x67/0xd0 [xe] 20583 [309.987408] __x64_sys_ioctl+0x7f/0xd0 （CVE-2026-89815）

請注意，Nessus 的判定取決於廠商所報告的套件是否存在。

Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且廠商未提供可用的修補程式。

  - 在查詢回應中，攻擊者可能會傳送應該只存在一次的記錄的「具名」多個複本 （例如 SOA 記錄）。如果所有副本上的 RDATA 都相同，則記錄會附加至記憶體內 RDATA 集，這可能會導致負快取的記憶體使用量增加，並可能導致其他記憶體攻擊媒介。此問題影響 BIND 9 版本 9.11.09.18.50（至 、 至 9.20.09.20.27、 9.21.09.21.25至 、 9.11.3-S1 至 9.18.50-S1 和 9.20.9-S1 至 9.20.27-S1）。（CVE-2026-75029）

請注意，Nessus 的判定取決於廠商所報告的套件是否存在。

Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且廠商未提供可用的修補程式。

  - USB： storage： realtek_cr：在釋放包含計時器的晶片之前，修正中斷連接 realtek_cr_destructor（） 呼叫 timer_delete（） 的釋放後使用。計時器回呼可能仍在執行中，並且可以自行重新武裝，從而導致釋放後使用。使用 timer_shutdown_sync（） 等待回呼並防止進一步重新布防。無條件地執行此操作ss_en因為計時器布防後可能會更改。將 timer_setup（） 移至 init_realtek_cr（），以便在任何故障路徑叫用析構函式之前初始化計時器。透過靜態分析找到。（CVE-2026-90029）

請注意，Nessus 的判定取決於廠商所報告的套件是否存在。

Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且廠商未提供可用的修補程式。

  - xhci：修正跨多個環段的 TD 上遺失的反彈緩衝區 當 TD 到達資料未與端點的 wMaxPacketSize 對齊的鏈路 TRB 時，xhci_align_td（） 會透過持有該鏈路 TRB 的環段的反彈緩衝區暫存無法對齊的尾部。xhci_unmap_td_bounce_buffer（） 稍後會取消對應它，並針對 IN 傳輸，將資料複製回 URB 的緩衝區。佇列路徑會記錄在 td->bounce_seg 中退回的區段，假設 TD 永遠不會跨越超過兩個環形區段。該假設不成立：足夠大的 TD 可以跨越三個或更多段，並且可以在每個鏈路 TRB 上反彈。只有最後一個在 td->bounce_seg 中存留，因此每個較早的退信緩衝區既不會複製回來，也不會取消對應 DMA。URB 仍會以等於要求長度的actual_length完成，而且沒有錯誤，因此傳輸看起來成功，而目的地緩衝區中的 wMaxPacketSize 大小空洞會以無訊息方式保留其先前的內容。它還會洩漏每個丟棄的退信的 DMA 映射。任何足夠大且分散的批量傳輸都可能達到此問題。它被發現在 xHCI 後面有一個 USB 大容量存儲設備，該設備支持具有 512 位元組哈希塊的 dm-verity 目標，其中檢測到過時的數據，而不是靜默地使用。裝置列舉為 SuperSpeed，因此 wMaxPacketSize 為 1024，而 dm-bufio 為每個雜湊區塊發出一個 512 位元組的 bio。verity_prefetch_io（） 使區塊層將數百個合併為最多 512 個散點清單條目（每個 512 位元組）的單一請求。在每個環段 256 個 TRB 的情況下，這樣的 TD 跨越三個段，並且每個段邊界落在 512 的奇數倍上，即與 wMaxPacketSize 未對齊。然後，dm-bufio 會快取一個包含過時資料的雜湊區塊，dm-verity 會宣告中繼資料區塊已損毀： device-mapper： verity： 8:2： 中繼資料區塊 10850 已損毀 在 qemu https://github.com/baloo/xhci-verity 下執行此動作的再生程式可在 反彈狀態 （bounce_buf、bounce_dma、bounce_len、bounce_offs） 已位於環段上，因此沒有額外內容可追蹤。繼續在 td->bounce_seg 中記錄最後一個跳出的區段，完成後，將區段從 td->start_seg 向上遍歷，取消映射仍然有擱置的區段的每個區段。停止在 td->bounce_seg 而不是 td->end_seg 很重要：反彈意味著 TD 繼續經過該區段的鏈路 TRB，因此bounce_seg始終嚴格在end_seg之前，而較晚的 TD 可能已經在 end_seg 中啟動並在那裡被反彈。走那麼遠會將外部反彈緩衝區複製到此 URB 中，並將其取消映射兩次。如果 TD 纏繞整個環，它也會保持正確的行走，以便 end_seg == start_seg。[mn：
    新增 ring->num_segs 檢查以防止不太可能的無限 for 迴圈。（CVE-2026-90015）

請注意，Nessus 的判定取決於廠商所報告的套件是否存在。

ID	名稱	嚴重性
346682	Linux Distros 未修補弱點：CVE-2026-89931	medium
346681	Linux Distros 未修補弱點：CVE-2026-90014	high
346680	Linux Distros 未修補弱點：CVE-2026-89984	high
346679	Linux Distros 未修補弱點：CVE-2026-89873	high
346678	Linux Distros 未修補弱點：CVE-2026-89930	critical
346677	Linux Distros 未修補弱點：CVE-2026-89872	high
346676	Linux Distros 未修補弱點：CVE-2026-89811	high
346675	Linux Distros 未修補弱點：CVE-2026-89940	high
346674	Linux Distros 未修補弱點：CVE-2026-89841	high
346673	Linux Distros 未修補弱點：CVE-2026-90028	medium
346672	Linux Distros 未修補弱點：CVE-2026-89800	medium
346671	Linux Distros 未修補弱點：CVE-2026-89893	high
346670	Linux Distros 未修補弱點：CVE-2026-89905	medium
346669	Linux Distros 未修補弱點：CVE-2026-89891	high
346668	Linux Distros 未修補弱點：CVE-2026-89973	high
346667	Linux Distros 未修補弱點：CVE-2026-90024	medium
346666	Linux Distros 未修補弱點：CVE-2026-92238	critical
346665	Linux Distros 未修補弱點：CVE-2026-89898	high
346664	Linux Distros 未修補弱點：CVE-2026-90021	medium
346663	Linux Distros 未修補弱點：CVE-2026-89979	high
346662	Linux Distros 未修補弱點：CVE-2026-90046	high
346661	Linux Distros 未修補弱點：CVE-2026-89880	high
346660	Linux Distros 未修補弱點：CVE-2026-89894	high
346659	Linux Distros 未修補弱點：CVE-2026-89933	medium
346658	Linux Distros 未修補弱點：CVE-2026-90019	medium
346657	Linux Distros 未修補弱點：CVE-2026-90006	medium
346656	Linux Distros 未修補弱點：CVE-2026-89911	high
346655	Linux Distros 未修補弱點：CVE-2026-89855	high
346654	Linux Distros 未修補弱點：CVE-2026-89813	medium
346653	Linux Distros 未修補弱點：CVE-2026-89861	high
346652	Linux Distros 未修補弱點：CVE-2026-90037	critical
346651	Linux Distros 未修補弱點：CVE-2026-90048	critical
346650	Linux Distros 未修補弱點：CVE-2026-89958	high
346649	Linux Distros 未修補弱點：CVE-2026-89956	high
346648	Linux Distros 未修補弱點：CVE-2026-89799	high
346647	Linux Distros 未修補弱點：CVE-2026-89913	high
346646	Linux Distros 未修補弱點：CVE-2026-89814	high
346645	Linux Distros 未修補弱點：CVE-2026-81563	high
346644	Linux Distros 未修補弱點：CVE-2026-89804	high
346643	Linux Distros 未修補弱點：CVE-2026-89824	medium
346642	Linux Distros 未修補弱點：CVE-2026-90012	critical
346641	Linux Distros 未修補弱點：CVE-2026-89976	medium
346640	Linux Distros 未修補弱點：CVE-2026-89974	high
346639	Linux Distros 未修補弱點：CVE-2026-90043	high
346638	Linux Distros 未修補弱點：CVE-2026-89895	medium
346637	Linux Distros 未修補弱點：CVE-2026-89821	medium
346636	Linux Distros 未修補弱點：CVE-2026-89815	high
346635	Linux Distros 未修補弱點：CVE-2026-75029	medium
346634	Linux Distros 未修補弱點：CVE-2026-90029	high
346633	Linux Distros 未修補弱點：CVE-2026-90015	medium

偵測

Nessus 的 Misc. 系列

medium

high

high

high

critical

high

high

high

high

medium

medium

high

medium

high

high

medium

critical

high

medium

high

high

high

high

medium

medium

medium

high

high

medium

high

critical

critical

high

high

high

high

high

high

high

medium

critical

medium

high

high

medium

medium

high

medium

high

medium