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

  - 使用者可以提供字串長度長於 CEL 環境中設定的 ParserExpressionSizeLimit（） 的運算式，且在檢查/強制執行限制之前，記憶體配置會與輸入大小成正比。（CVE-2026-83530）

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

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

  - dm-io：複製來源 bio 而不是複製其 biovec 對於DM_IO_BIO請求，do_region（） 透過遍歷來源 bio 的 biovec 並一次重新新增一個頁面來建立每個目標 bio，以磁區為單位追蹤剩餘的傳輸。向量長度是位元組粒度的，不需要扇區對齊（例如，跨頁面分割的未對齊O_DIRECT緩衝區），因此基於扇區的帳戶可能會丟失子扇區片段：to_sector（） 截斷了其餘部分，外部循環永遠旋轉，提交空 bios，懸掛 I/O。根本沒有必要重建生物維克。目的地讀取 （或寫入） 與來源 bio 完全相同的頁面，因此 bio 可以簡單地使用 bio_alloc_clone（） 複製來源的 biovec 並將其重新映射到目標裝置。克隆繼承源的迭代器和對齊方式，區塊層將其拆分為目標提交時的限制，因此整個區域映射到單個克隆的生物，無需手動頁面複製或扇區統計。這會移除生物支援 I/O 的每頁複製路徑 （及其開放編碼的 bvec dpages 協助程式），並修正未對齊的直接 I/O 至 dm 鏡像裝置的掛起。頁面清單、vma 和 kmem 來源會保留現有的複製路徑。（CVE-2026-89578）

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

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

  - ntfs：拒絕無效的空白對應配對 如果具有不一致的最高 VCN 和大小，則拒絕具有空白對應配對的屬性。（CVE-2026-89613）

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

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

  - PCI：plda：修正 plda_init_interrupts（） 錯誤路徑中的 IRQ 網域洩漏 plda_init_interrupts（） 初始化 IRQ 網域並建立 IRQ 對應，但不會在後續步驟失敗時將其展開。如果 plda_init_interrupts（） 中的 platform_get_irq（） 或任一 irq_create_mapping（） 失敗，則永遠不會取消初始化網域。如果 irq_create_mapping（） 失敗，port->intx_irq 會保持初始化狀態。因此，請呼叫 plda_pcie_irq_domain_deinit（） 來移除錯誤路徑中的 IRQ 網域。由於 plda_pcie_irq_domain_deinit（） 現在會在移除其網域之前自行處置 intx_irq 和 msi_irq 對應，因此msi_irq對應失敗路徑可以直接移至 err_irq_domain_deinit，而不是先個別處置 port->intx_irq。此問題是透過自動審查 sashiko-bot 發現的 [mani： commit log] （CVE-2026-89454）

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

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

  - sched/core：處理 pick_task（） 釋放 rq 鎖定 Core 排程的 pick_next_task（） 在
    ->pick_task（） 實作可以釋放 rq 鎖定。進入時衍生的選取狀態只有在鎖定持續持有時才有效。一旦選擇可以刪除鎖定，交錯選擇可能會使所有鎖定無效：單 CPU 快速路徑可以提交未 cookie 的選擇，儘管核心在發布期間發生了 cookie，並且交錯選擇的強制閒置會扭曲重新啟動的通道的帳戶。當選擇在釋放鎖定後返回RETRY_TASK時重新啟動整個選擇來修復它：狀態推導上方的單個重新啟動點會替換每個循環的重新啟動標籤，因此重試會選擇通過交錯選擇和帳戶提交的狀態，並像新選擇一樣重置強制閒置。need_sync和fi_before在重試中閂鎖。時鐘有效性無法重新推導 - 沒有程式排序的方法來判斷釋放鎖定後，自己的和核心 rq 時鐘是否仍會更新，因為其他儲物櫃的 pin 週期可能會或可能不會使它們失效。重新啟動時，請清除core_clock_updated，以便同級迴圈重新更新核心 rq，並在無效時更新自己的 rq 時鐘。（CVE-2026-89521）

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

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

  - dm array：在讀取時驗證陣列區塊標頭 array_block_check（） 驗證 blocknr 和 csum，僅此而已，而旁邊的 node_check（） 自從兩者都被寫入以來，已經限制了結構欄位。
    dm_array_cursor_next（） 從磁碟上的nr_entries中獲取其迴圈，而 element_at（） 是無人保護的指標算術，因此大於區塊所包含的計數會將游標保留在一個區塊中，而索引會增長到該區塊之後，讀取會離開 dm-bufio 緩衝區 -- dm_cache_load_mappings（） 會在啟動時每個快取區塊驅動它一次。檢查標頭本身：拒絕零value_size，要求 max_entries 等於該value_size和區塊大小的 calc_max_entries（），並要求 nr_entries 適合。相等而不是上限，因為低於實際容量的計數會在 fill_ablock（） 和 trim_ablock（） 中跳閘 BUG_ON（）。中繼資料 dm-array 寫入滿足這三個條件。（CVE-2026-89574）

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

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

  - ntfs：拒絕開機磁區中無效的 MFT LCN NTFS 開機磁區會將 MFT 和 MFTMirr 位置儲存為未簽署的 64 位 LCN，但 parse_ntfs_boot_sector（） 會將它們解碼成 s64。因此，特製的高位值可能會變成負數，並通過現有的上界檢查。然後，無效值會傳播至 MFT 區域配置器，並可能導致越界存取 lcn_empty_bits_per_page。
    (CVE-2026-89612)

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

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

  - platform/x86： hp-bioscfg：將已驗證的元素計數傳遞至套件剖析器 每個類型的套件剖析器都會收到錯誤的元素計數。hp_init_bios_package_attribute（） 驗證 obj->package.count，然後呼叫五個 hp_populate_*_package_data（） 包裝函式 （字串、整數、列舉、有序列表、密碼） 之一。每個包裝器都會將計數轉發到其 hp_populate_*_elements_from_package（） 剖析器，但它不是轉送經過驗證的 obj->package.count，而是從 elements[0] 派生計數。elements[0] 是 NAME 欄位，而且一律是 ACPI_TYPE_STRING，因此從中讀取 ->package.count 實際上會讀取
    ->string.length 透過聯集acpi_object。因此，剖析器會根據名稱字串的長度來綁定自己，而不是套件中的實際元素數。這在今天是安全的，因為 hp_init_bios_package_attribute（） 拒絕任何小於類型元素計數的包，因此解析器只會在完整包上運行，並且無論虛假邊界如何，都不會讀取它。即將進行的變更會放寬檢查以接受較短的套件。一旦解析器可以接收的元素少於其每個類型的計數，從名稱長度中獲取的邊界就不再反映陣列大小，並且 elem <計數迴圈條件和 elem + n >= 計數子迴圈保護讀取超過 elements[] 的末尾 - 越界堆讀取。將經過驗證的 obj->package.count 轉發到每個 *_package_data（） 包裝器，以便剖析器根據實際套件大小綁定自己。這不會改變今天正確列舉的套件的行為，而且是安全接受較短套件的先決條件。
    (CVE-2026-81011)

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

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

  - acpi/apei/ghes： 將 raw_spinlock_t 用於 CXL CPER 工作鎖定 CXL CPER 工作登錄及取消註冊協助程式會取得 cxl_cper_work_lock，並使用微調鎖定保護程式 （） cxl_cper_prot_err_work_lock，這會讓本機中斷保持啟用狀態。對應的 POST 路徑 （cxl_cper_post_event（）、cxl_cper_post_prot_err（）） 在硬式 IRQ 內容中執行 （它們是從 GHES 錯誤通知路徑呼叫的），並使用 irqsave guard（） 取得相同的鎖定。如果當 GHES 中斷到達相同的 CPU 時，CPU 透過微調鎖定 guard（） 持有其中一個鎖定，則 IRQ 處理常式會在保留的鎖定上旋轉，等待其釋放，而鎖定持有者會被 IRQ 搶佔。結果是僵局。
    將兩個鎖定從 spinlock_t 轉換為 raw_spinlock_t，並在所有呼叫站點使用 guard（）。在PREEMPT_RT核心上，spinlock_t由 rt_mutex 支援，不允許從硬 IRQ 上下文休眠;
    raw_spinlock_t在這兩種情況下都是安全的。將WARN_ONCE新增至這兩個暫存器函式，以在執行階段顯示雙重註冊錯誤。在呼叫 cancel_work_sync （） 之前，重組這兩個取消註冊函式，以清除鎖定下的全域工作指標，關閉 CPER 中斷可以排程即將釋放指標上工作的視窗。在 cancel_work_sync（） 之後新增 kfifo_reset（），以便在下次模組載入時不會重播過時的項目。這兩個 kfifo 都是單一消費者：一次只能註冊一個 work_struct，由暫存器函式中的WARN_ONCE防護強制執行。kfifo_reset（） 在鎖定之外是安全的，因為 cancel_work_sync（） 已靜止消費者，且在目前模組結束完成且執行新的模組 init 之前，沒有新的消費者可以註冊。移除 cxl_ras_exit（） 和 cxl_pci_driver_exit（） 中的冗餘 cancel_work_sync（） 呼叫。CPER 取消登錄功能現在會在內部靜止工作。（CVE-2026-89589）

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

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

  - fs/ntfs3：由日誌記錄綁定 page_lcns[] 的索引 copy_lcns 迴圈和重做會在 j + i 處縮短迴圈索引 page_lcns[] ，其中 i 一直運行到日誌記錄的lcns_follow。該計數僅針對記錄自己的長度進行檢查，而不是目標項目，因此 check_dp_table（） （驗證項目的lcns_follow） 不會涵蓋它：copy_lcns 項目甚至可能在該檢查之後被新分配，並且 find_dp（） 邊界 j 而不是 i。因此 page_lcns[] ，特製的記錄會溢出原本有效的項目。新增 dp_range_ok（） 並在每個迴圈之前拒絕其執行不符合項目的任何記錄。這是僅有的兩個 page_lcns[] 由記錄而不是項目索引的存取，因此現在每個存取都與項目驗證一起受到限制。[almaz.alexandrovich@paragon-software.com：原始修補程式包含對已處理問題的更改，部分應用]（CVE-2026-89615）

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

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

  - 加速/火箭：修正 rocket_job_run（） 中的錯誤路徑處理 在 rocket_job_run（） 中，透過 dma_fence_get（） 為 job->done_fence 取得額外的柵欄參照後，錯誤路徑有三個錯誤： - job->done_fence 持有的dma_fence參照永遠不會釋放，導致參照洩漏。- 即使在失敗時，pm_runtime_get_sync（） 也會遞增使用計數器，但錯誤路徑不會遞減它，從而洩漏執行階段 PM 參照並防止 NPU 暫停。- 有效但無信號的柵欄會傳回 DRM 排程器，這會觸發 WARN（柵欄 ...釋放時有待定的信號！當排程器捨棄其參照時。透過將 pm_runtime_get_sync（） 替換為 pm_runtime_resume_and_get（） 來修正，該 （） 會在失敗時自動平衡使用計數器，在錯誤時釋放兩個柵欄參照，並傳回 ERR_PTR（ret） 而不是無信號柵欄。[tomeu：重構錯誤路徑以使用合併的 goto 標籤]（CVE-2026-89590）

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

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

  - ecryptfs：拒絕太小的標籤 70 封包 ecryptfs_parse_tag_70_packet（） 會從剖析的封包內文大小中減去固定的中繼資料欄位，以衍生出加密的檔案名稱大小。主體小於這些固定欄位的格式錯誤的封包可能會反向溢位該大小計算。拒絕減去前標記 70 封包，除非本文包含簽名、加密碼和至少一個位元組的加密檔案名稱資料。（CVE-2026-89606）

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

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

  - NFSD：檢查 inode 鎖定下的截斷權限 nfsd_setattr（） 會檢查大小更新是否需要在採用 inode_lock（） 之前NFSD_MAY_TRUNC。比較會使用該未鎖定讀取所取樣的檔案大小，但實際的ATTR_SIZE更新稍後會透過 notify_change（） 在 inode_lock（） 下套用。這會為僅附加檔案留下一個 TOCTOU 視窗。如果用戶端傳送的 SETATTR 不會在解鎖範例時壓縮檔案，則並行附加可以在 nfsd_setattr（） 採用 inode_lock（） 之前擴充檔案。然後，notify_change（） 會套用實際截斷，而不進行拒絕 IS_APPEND（inode） 的NFSD_MAY_TRUNC檢查。VFS 截斷系統呼叫路徑會在呼叫 notify_change（） 之前執行自己的僅附加檢查，因此 NFSD 必須針對即將變更的鎖定大小做出此決策。從截斷權限檢查中分割寫入計數取得。在鎖定的 setattr 工作之前保留 get_write_access（），然後在取得 inode_lock（） 之後和 notify_change（ATTR_SIZE） 之前重新檢查請求的大小是否低於 i_size_read（inode）。這也避免了普通解鎖的 inode >i_size負載。
    (CVE-2026-89713)

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

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

  - net/smc：修正 smc_llc_srv_add_link（） 中 LLC qentry 的釋放後使用 smc_llc_srv_add_link（） 保持add_llc指向佇列項目：add_llc = &qentry->msg.add_link;smc_llc.c：1482 ...
    smc_llc_save_add_link_info（link_new，add_llc）;smc_llc.c：1494 smc_llc_flow_qentry_del（&lgr->llc_flow_lcl）;
    smc_llc.c：1495 ...u8 *llc_msg = smc_link_shared_v2_rxbuf（連結） ？（u8 *）lgr->wr_rx_buf_v2 ： （u8 *）add_llc;
    smc_llc.c：1504 smc_llc_save_add_link_rkeys（連結，link_new，llc_msg）;smc_llc.c：1506 smc_llc_flow_qentry_del（） kfree（）s 項目，因此在沒有共用 v2 接收緩衝區的連結上，交給 smc_llc_save_add_link_rkeys（） 的指標已經釋放。在修正之前：提交該分支始終使用 lgr->wr_rx_buf_v2，並且在釋放後未使用add_llc。透過 rxe 在未修補的樹狀結構上重現，使用 KASAN、kasan_multi_shot 和連結強制max_recv_sge == 1：該條目被釋放並由同一調用讀取，並且釋放框架是 smc_llc_srv_add_link（） 本身。[ 2.523161] 錯誤：KASAN：smc_llc_save_add_link_rkeys+0x333/0x350 中的 slab-use-after-free [ 2.523499] 由任務 kworker/0:1/11 在 addr ffff8880052194de 讀取大小 2 [ 2.523789] [ 2.523862] CPU：0 UID：0 PID：11 Comm：kworker/0:1 未受污染 7.2.0-rc5-p0-g2c9dd296545d #35 搶佔（延遲） [ 2.523865] 硬體名稱：QEMU Ubuntu 24.04 PC v2 （i440FX + PIIX，arch_caps fix，1996），BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 2.523866] 工作佇列：smc_hs_wq smc_listen_work [ 2.523869] 呼叫追蹤： [ ] [ ] dump_stack_lvl+0x53/0x70 [2.523872] print_report+0xd0/0x630 [ 2.523874] ？ __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 2.523876] smc_llc_save_add_link_rkeys+0x333/0x350 [ 2.523878] kasan_report+0xce/0x100 [ 2.523879] ？ smc_llc_save_add_link_rkeys+0x333/0x350 [ 2.523881] smc_llc_save_add_link_rkeys+0x333/0x350 [ 2.523883] ？ smcr_buf_reg_lgr+0x2a4/0x660 [ 2.523885] smc_llc_srv_add_link+0xaa2/0x1e50 [ 2.523888] ？ _printk+0xba/0xf0 [ 2.523897] ？ __pfx_smc_llc_srv_add_link+0x10/0x10 [ 2.5238992.523871<TASK>2.523870] ?down_write+0xb0/0x130 [ 2.523903] ？
    __pfx_down_write+0x10/0x10 [ 2.523905] smc_listen_work+0x489e/0x4d00 [ 2.523907] ？ kmem_cache_free+0x1c6/0x3a0 [ 2.523911] ？ __pfx_smc_listen_work+0x10/0x10 [ 2.523913] ？ release_sock+0x148/0x1d0 [ 2.523915] ？ smc_tcp_listen_work+0xb4f/0xfc0 [ 2.523917] ？
    _raw_spin_lock_irq+0x80/0xe0 [ 2.523918] ？ __pfx__raw_spin_lock_irq+0x10/0x10 [ 2.523920] process_one_work+0x633/0x1030 [ 2.523922] ？ assign_work+0x11d/0x370 [ 2.523924] worker_thread+0x45b/0xd10 [ 2.523926] ？ __pfx_worker_thread+0x10/0x10 [ 2.523928] ？ __pfx_worker_thread+0x10/0x10 [ 2.523929] kthread+0x2c6/0x3b0 [ 2.523931] ？ recalc_sigpending+0x15c/0x1e0 [ 2.523934] ？ __pfx_kthread+0x10/0x10 [2.523935] ret_from_fork+0x36e/0x5a0 [ 2.523937] ？ __pfx_ret_from_fork+0x10/0x10 [ 2.523938] ？
    __switch_to+0x572/0xdd0 [ 2.523943] ？ __pfx_kthread+0x10/0x10 [ 2.523944] ret_from_fork_asm+0x1a/0x30 [2.523947] </TASK> [ 2.523948] 2.531253[ ] 任務 48 分配： [ 2.531399] kasan_save_stack+0x33/0x60 [2.531570] kasan_save_track+0x14/0x30 [ 2.531737] __kasan_kmalloc+0x8f/0xa0 [ 2.531905]
    __kmalloc_cache_noprof+0x158/0x370 [ 2.532100] smc_llc_enqueue+0x72/0x560 [ 2.532268] smc_wr_rx_tasklet_fn+0x474/0xa80 [ 2.532491] tasklet_action_common+0x20f/0x8a0 [ 2.532714] handle_softirqs+0x18e/0x590 [ 2.532886] do_softirq+0x3b/0x60 [ 2.533036] __local_bh_enable_ip+0x61/0x70 [2.533221 ] __alloc_skb+0x732/0x890 [ 2.533384] rxe_init_packet+0x16b/0x4f0 [ 2.533567] prepare_ack_packet+0xb8/0x830 [ 2.533760] rxe_receiver+0x495/0x96e0 [ 2.533933] do_work+0x144/0x470 [ 2
    ---truncated--- (CVE-2026-80981)

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

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

  - fs/ntfs3：修正 ni_read_frame（） 中部分 LZNT 解壓縮的資訊洩露 ni_read_frame（） 將 LZNT $DATA 框架解壓縮到 vmap 的目標頁面中，然後信任 decompress_lznt（） 的傳回值：unc_size = decompress_lznt（frame_ondisk， ondisk_size， frame_mem， frame_size）; if （（ssize_t）unc_size < 0） err = unc_size;否則 if （！unc_size || unc_size > frame_size） err = -EINVAL; decompress_lznt（） 會在壓縮資料流耗盡後立即停止 （例如零區塊標頭）並傳回它實際寫入的位元組數，該位元組數可能遠小於frame_size。unc_size 和 frame_size 之間的位元組永遠不會寫入。
    後面唯一的 memset（） 將 i_valid 以外的區域歸零;當框架完全位於檔案的有效大小內時，memset（） 不會運行，因此間隙會保留剛剛 vmapped 頁面中的任何內容。
    然後，所有頁面都會被標記為最新狀態並返回使用者空間，從而洩露未初始化（最近釋放）的核心頁面記憶體。一個精心製作的壓縮文件，其流解壓縮到只有幾個位元組，會在普通讀取 （2） 上洩露每一幀的剩餘部分，這足以恢復核心指標並擊敗 KASLR。
    在成功的 LZNT 解壓縮後立即將 [unc_size， frame_size） 尾部歸零，以便其餘部分讀回零。（CVE-2026-89616）

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

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

  - scsi： fnic：在微調鎖定下使用 GFP_ATOMIC 進行 VLAN 分配 fnic_fcoe_process_vlan_resp（） 會以 kzalloc_obj（） （預設GFP_KERNEL） 配置 VLAN 描述元，同時透過 spin_lock_irqsave（） 保留vlans_lock。
    GFP_KERNEL可能會休眠，這在此不可部分完成內容中是不允許的，而且可能會觸發無效內容休眠警告或鎖死。傳遞GFP_ATOMIC，以便在 IRQ 安全微調鎖定下安全地進行配置。
    (CVE-2026-89514)

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

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

  - ksmbd：修正 oplock 中斷通知中的釋放後使用 smb2_oplock_break_noti（） 在沒有任何鎖定的情況下讀取 opinfo->conn，並在兩次可能休眠的分配後對其進行取消參照。當擁有 oplock 的持久控制碼中斷連線時，session_fd_check（） 會清除 opinfo->conn 並刪除其 ci->m_lock 下的 conn 參照，而最後一個 ksmbd_conn_put（） 會釋放連線。然後，由另一個與拆卸爭用的連接觸發的中斷可以復活釋放的連接：ksmbd_conn_get（） 是一個普通atomic_inc，排隊的中斷工作稍後會通過 ksmbd_conn_write（） 解除參照過時的 conn，這是任何持有持久批次 oplock 的經過身份驗證的客戶端都可以訪問的釋放後使用。將呼叫端的 inode 串連到通知路徑中，而不是在上面進行新的參照。oplock_break（） 的每個呼叫者都已經在擁有中斷目標 oplock 清單的 inode 上保留一個即時ksmbd_file （或父租約中斷路徑中的明確 ksmbd_inode_lookup_lock（） 引用），因此無法在調用期間釋放 ci，並且可以在不取消引用 opinfo->o_fp 的情況下獲取其鎖定，並行關閉可能會釋放。選取並釘選 ci->m_lock 下的連線，這是更新 opinfo->conn 所用的相同鎖定 session_fd_check（） 和 ksmbd_reopen_durable_fd（），因此並行分離會失去與清除的爭用，或會讓連線保持活動狀態，直到通知工作釋放它為止。將參考傳輸至工作專案，並在配置失敗時釋放它。（CVE-2026-80926）

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

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

  - nfsd：取消 copy-notify stateid 時檢查用戶端擁有權 在OFFLOAD_CANCEL路徑 （clp ！= NULL） 上，manage_cpntf_state（） 釋放了目標 cpntf 狀態，但沒有檢查擁有權。查詢金鑰 st->si_opaque.so_id 會循環配置 （可猜測），而內嵌的 clientid 是固定的每網 nn->s2s_cp_cl_id，因此任何經過驗證的 NFSv4.2 用戶端都可以取消並釋放另一個用戶端的 copy-notify stateid。將 state->cp_p_clid 中記錄的建立用戶端識別碼與要求用戶端的cl_clientid進行比較，並在不相符時傳回nfserr_bad_stateid，而不是釋放項目。（CVE-2026-89694）

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

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

  - platform/x86： hp-bioscfg：修正 hp_get_string_from_buffer（） 中的差一寫入 hp_get_string_from_buffer（） 會將轉換後的字串長度限制在大小為 > dst_size 的目標緩衝區大小上，因此當轉換後的長度完全等於 dst_size 時，conv_dst_size 會保留在 dst_size，並且無條件的 NUL 終止符會寫入 dst[conv_dst_size] = 0;落在目的地緩衝區之後一個位元組。這與之前在 hp_convert_hexstr_to_str（） 中修正的 off-by-one 的錯誤形狀相同：緩衝區的大小針對內容正確調整，但絕不會根據該大小檢查終止符寫入。透過將比較變更為 >= 來修正conv_dst_size以便始終為終止符留出空間。所有到達此功能的固定大小目的地 （path[512]、current_value[512]、current_password/current_value[64] 以及 encodings[][512] 和 prerequisites[][512] 中的每個項目緩衝區）都會受到影響。（CVE-2026-81012）

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

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

  - KVM：arm64：GICv2：不要在超出範圍的 GICV_DIR INTID vgic_v2_deactivate（） 將客體寫入給 GICV_DIR 的 INTID 直接傳遞給 vgic_get_vcpu_irq（），並使用 WARN_ON_ONCE（） 將失敗的查詢視為不可能發生的條件。不過，客體可以隨意實現：對於實作的 SGI、PPI 和 SPI 範圍之外的任何 INTID，查詢都會傳回 NULL，因為 GICv2 沒有 LPI。以 EOImode==1 執行的客體將此類 INTID 寫入GICV_DIR會觸發 WARN，並使使用 panic_on_warn 執行的主機發生錯誤。捨棄 WARN 並忽略失敗的查詢。（CVE-2026-89727）

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

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

  - phy：rockchip-samsung-dcphy：修正超出範圍的max_register PHY 暫存器區塊為 64KB，因此當暫存器步幅為 4 時，最後一個可存取的暫存器位於偏移0xfffc。max_register名稱0x10000，一個暫存器超過映射末尾：透過 regmap debugfs 介面轉儲暫存器會讀取超出 ioremapped 區域，並在未映射頁面上出現 oops。哎呀，在保持 regmap 鎖定的情況下觸發，因此稍後的 PHY 操作鎖死。（CVE-2026-89721）

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

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

  - net：thunderbolt：啟動失敗時將連接標記為關閉 tbnet_connected_work（） 中的每個失敗路徑都會撤銷自己的工作，並在不清除login_sent的情況下返回，因此連接看起來仍然已建立。因此，下一個 tbnet_tear_down（） 採用其主分支並重複已經發生的拆解：它停止已經停止的環，這是一個 dev_WARN（），在panic_on_warn下是致命的，並且即使在 HopID 不匹配路徑上，它也會釋放網絡>remote_transmit_path，其中此連接從未擁有該 ID，靜默地釋放其他人仍在使用的 ID。清除這些路徑上的login_sent。這足以讓 tbnet_tear_down（） 不理會未展開狀態，並且login_received必須保持設定狀態：它記錄對等體已登入並攜帶它提供給我們的傳輸路徑，這端的任何內容都無法讓對等體再次發送。除了避免拆卸之外，還有兩件事發生了變化：不再發送該區塊中的登出請求，並且對等體的下一個登入請求現在會將我們的登入工作重新排入佇列，而不是connected_work，從而為連線提供全新登入，而不是在過時狀態下重試。（CVE-2026-80989）

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

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

  - ceph：如果沒有可能的進度，則不要重複 ceph_trim_dentries（） ceph_cap_reclaim_work（） 只要 ceph_trim_dentries（） 傳回 -EAGAIN，就會重新排入佇列，每當租約遍歷耗盡其「nr_to_scan」預算時，就會發生這種情況。這會造成忙碌迴圈，當沒有任何可回收的內容時，會消耗 CPU 而沒有任何進展：在沒有上限壓力 （'count==0'） 且每個掃描的租約仍然有效的情況下，每次傳遞都會將完整掃描預算降至零並傳回「-EAGAIN」，然後立即再次排入佇列。dir-lease 走使情況變得更糟。當 'expire_dir_lease' 為 'false' 時 （亦即我們無意收回目錄租約），__dir_lease_check（） 會針對每個有效租約傳回 'TOUCH'。'TOUCH' 將 dentry 移動到清單的尾部，並透過 __dentry_dir_lease_touch（） 重設 'di->time'，因此遍歷 N 個有效租約會毫無意義地重寫清單、重新整理時間戳記 （防止它們過期） 並始終排空 'nr_to_scan'，保證 '-EAGAIN' 重新排隊。分三個步驟修正此問題： - 當 'expire_dir_lease' 為 'false' 時，傳回 'KEEP' 而不是 'TOUCH'。如果我們不打算收回租約，請將其保留在原處，而不是攪動列表並重置其時間戳記;然後步行自然終止（或在第一次新租約時通過“停止”）。- 僅在實際釋放某些內容時，才從第一次 （dentry-lease） 遍歷返回 '-EAGAIN'。不釋放任何內容的完整批次意味著立即重試相同的清單是徒勞的;轉而進入 dir-lease 步道。- 兩次保送後，當沒有釋放任何東西並且沒有上限壓力 （'count==0'） 時，成功救援 （0）。當我們沒有超過上限並且沒有取得任何進展時，沒有理由繼續重試。在實際上限壓力 （'count>0'） 下，回收路徑不會改變，但仍會透過「-EAGAIN」重試。如果沒有這個補丁，我在我們的 Web 伺服器上每秒看到 500 次 ceph_trim_dentries（） 呼叫。這在 '/proc/lock_stat' （5 分鐘擷取） 中非常明顯： 類別名稱 con-bounces 爭用 waittime-min waittime-max waittime-total waittime-avg acq-bounces acquisitions holdtime-min holdtime-max holdtime-total holdtime-avg &mdsc->dentry_list_lock： 126180 128218 0.04 8063.44 15986965.20 124.69 1573354 5296812 0.04 8291.28 74164526.48 14.00 ----------------------- &mdsc->dentry_list_lock 111736 [<000000007b11e319>] __ceph_dentry_dir_lease_touch+0x7c/0xa8 &mdsc->dentry_list_lock 2631 [<0000000050597999>] __dentry_leases_walk+0x64/0x2c8 &mdsc->dentry_list_lock 3878 [<00000000c0022f62>] __ceph_dentry_lease_touch+0x5c/0xa8 &mdsc->dentry_list_lock 9973 [<000000002f27cb6f>] __dentry_lease_unlist+0x50/0xa0 ----------------------- &mdsc->dentry_list_lock 123621 [<0000000050597999>] __dentry_leases_walk+0x64/0x2c8 &mdsc->dentry_list_lock 1822 [<000000007b11e319>] __ceph_dentry_dir_lease_touch+0x7c/0xa8 &mdsc->dentry_list_lock 2720 [<000000002f27cb6f>] __dentry_lease_unlist+0x50/0xa0 &mdsc->dentry_list_lock 55 [<00000000c0022f62>]
    __ceph_dentry_lease_touch+0x5c/0xa8 使用此修補程式： 類別名稱 con-bounces 爭用 waittime-min waittime-max waittime-total waittime-avg acq-bounces acquisitions holdtime-min holdtime-max holdtime-total holdtime-avg &mdsc->dentry_list_lock： 1203 1215 0.16 408.88 33082.88 27.23 4320501 7357389 0.04 500.64 1961578.00 0.27 ----------------------- &mdsc->dentry_list_lock 1029 [<000000003c9aea8a>]
    __ceph_dentry_dir_lease_touch+0x7c/0xa8 &mdsc->dentry_list_lock 1 ---truncated--- （CVE-2026-89647）

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

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

  - nfsd：修正 cpntf 發佈爭用 nfs4_init_cp_state nfs4_alloc_init_cpntf_state（） 將新的 cpntf 項目發佈到一個 s2s_cp_lock 區段中的 s2s_cp_stateids IDR （已設定cs_type），然後再次鎖定以將其list_add （） 到 p_stid->sc_cp_list。在間隙中，so_id 可以存取項目，但cp_list仍然是來自 kzalloc 的 {NULL，NULL}。爭用OFFLOAD_CANCEL （so_id 會以 cnr_stateid 的形式回應到用戶端，因此任何 NFSv4.2 用戶端都可以驅動它） 到達 manage_cpntf_state（） -> _free_cpntf_state_locked（） 並在歸零list_head上執行 list_del（），從而使伺服器癱瘓。將 cs_type 指派和 list_add（） 與 idr_alloc_cyclic（） 合併到相同的關鍵區段中，以便並行查詢會遺漏項目或看到完全連結的cp_list。INIT_LIST_HEAD（） 分配和切換後的條目
    _free_cpntf_state_locked（） 轉換為 list_del_init（），因此過時的取消連結是無操作的。nfs4_init_copy_state（） 傳遞 NULL p_stid並跳過list_add，保留NFS4_COPY_STID語義。（CVE-2026-89684）

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

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

  - mptcp：修正 syncookie 中未初始化的local_id MP_JOIN重建 mptcp_token_join_cookie_init_state（） 會在重建 SYN Cookie 下處理的 MP_JOIN 4th-ACK 的要求通訊端時，從已儲存的 cookie 項目還原 remote_nonce、local_nonce、備份、join_id、權杖和 MSK，但不會還原 local_id，即使 SYN 路徑儲存了它。然後，subflow_ulp_clone（） 會讀取該未初始化的欄位，並將其儲存為聯結子流程的位址 ID。因為 request-sock slab 是SLAB_TYPESAFE_BY_RCU的，而且不會在配置時歸零，所以值是先前釋放要求通訊端的過時位元組，路徑外對等節點可以透過傳送並行 MP_JOIN SYN 來影響該位元組。這會損毀路徑管理員針對連線的 ID 型子流程簿記。從 cookie 項目還原 subflow_req->local_id，就像對其他欄位所做的那樣。（CVE-2026-89554）

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

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

  - opennlp.tools.namefind.RegexNameFinderFactory - DEFAULT_REGEX_NAME_FINDER公開的兩個內建名稱搜尋器模式。電子郵件和DEFAULT_REGEX_NAME_FINDER。URL - 包含模棱兩可的巢狀量詞。
    透過 RegexNameFinderFactory.getDefaultRegexNameFinders（...） 取得這些搜尋器，然後透過 RegexNameFinder.find（String[]） 或 RegexNameFinder.find（String） 將它們套用至不受信任的文字的應用程式，可以透過小型特製輸入驅動至超線性回溯或無限比對器遞迴。對於 EMAIL 模式，從不跟著 @ 的長篇本機部分字元會強制比對器從每個起始位移重新掃描到輸入結尾。成本隨著輸入長度呈二次方增長：大約 32 KB 的輸入在單個 find（） 調用中消耗幾秒鐘的 CPU，並且不返回任何匹配項，並且輸入每加倍，成本就會增加大約四倍。針對 URL 模式，查詢字串子運算式會在外部重複內巢狀擷取重複。JDK 比對器會為每個查詢權杖遞迴一次，因此包含許多 & 分隔權杖的大約 4 KB 的輸入會耗盡執行緒堆疊，並導致 java.lang.StackOverflowError 從 find（） 傳播出去，從而終止呼叫執行緒。在使用較小堆疊建立的執行緒上 （例如 -Xss512k，典型的伺服器背景工作集區），大約 1 KB 就足夠了。在這兩種情況下，能夠提供文字進行分析的攻擊者都可以將單一要求轉換為幾秒鐘到幾分鐘的固定 CPU，或轉換成突然的執行緒終止，從而拒絕對內嵌應用程式的服務。除了選擇兩個內建搜尋器之一的應用程式之外，不需要驗證、特殊配置或模型檔案。此問題影響 Apache OpenNLP：從 2.0.02.5.113.0.0-M1 到 3.0.0-M5。建議使用者升級至版本 2.5.12，或針對追蹤 3.0.0 里程碑行的使用者升級至 3.0.0-M6，以修正此問題。（CVE-2026-82617）

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

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

  - nfsd：修正 clients_still_reclaiming（） 中的時鐘網域不相符 clients_still_reclaiming（） 會從 nn->boot_time （CLOCK_REALTIME，~1.7 十億） 計算截止時間，但會將其與 ktime_get_boottime_seconds（） （CLOCK_BOOTTIME，啟動後的秒數） 進行比較。比較總是錯誤的，BOOTTIME 需要 ~54 年的正常運行時間才能超過 REALTIME 衍生的截止日期。這表示任何用戶端都可以透過傳送CLAIM_PREVIOUS OPEN 要求來無限期地保留伺服器，並封鎖所有其他用戶端的所有非回收作業。在現有boot_time旁邊新增boot_time_bt （CLOCK_BOOTTIME），並將其用於截止日期計算。boot_time （CLOCK_REALTIME） 會保留其cl_boot clientid-nonce 角色。（CVE-2026-89685）

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

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

  - orangefs：剖析用戶端除錯遮罩之前跳過前導空格 orangefs_prepare_cdm_array（） 會使用 strcspn（cds_head，） 調整每個用戶端除錯關鍵字緩衝區的大小，但然後使用 %s 剖析關鍵字。%s 轉換會略過前導空格，而 strcspn（） 則不會。如果用戶端除錯項目以空格開頭，則可以在 sscanf（） 複製下列非空記號時，針對空關鍵字調整配置大小。這可以寫入已配置關鍵字緩衝區的結尾。在計算關鍵字長度之前跳過前導空格，以便分配符合 sscanf（） 剖析的字串。（CVE-2026-89497）

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

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

  - ocfs2：驗證 dlm_mig_lockres_handler 的長度 接收DLM_MIG_LOCKRES訊息的節點信任對等提供的dlm_migratable_lockres的數個欄位，而不進行驗證。num_locks和lockname_len僅在傳送端受界，而且永遠不會檢查訊息是否實際攜帶num_locks migratable_lock項目。因此，dlm_process_recovery_data（） 會遍歷 mres->ml[0..num_locks） 經過訊息的 kmalloc（data_len） 副本 （以BUG_ON錯誤結束的越界讀取），而 dlm_init_lockres（） 會將 lockname_len 位元組複製到固定的 32 位元組 o2dlm_lockname slab 物件中 （堆積越界寫入）。網域中的任何節點都可以連線到這兩者。在 dlm_grab（） 之後立即驗證這些欄位，然後再使用它們 -- 包括未聯結的錯誤路徑，該錯誤路徑已將帶有無限lockname_len的 mres->lockname 列印為 %.*s 精確度。除非 lockname_len <= DLM_LOCKID_NAME_MAX、num_locks <= DLM_MAX_MIGRATABLE_LOCKS （寄件者已宣告的繫結） ，且承載足夠大以保留宣告的鎖定，否則拒絕訊息。符合規範的回復和移轉訊息不受影響。（CVE-2026-89494）

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

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

  - mmc：透過 SDMMC：探查失敗時停止卡片偵測處理 request_irq（） 會註冊 SD 卡偵測中斷，並在 mmc_add_host（） 執行之前探查啟用它。如果 mmc_add_host（） 失敗，錯誤路徑只會取消映射暫存器並傳回：中斷保持註冊狀態，因此處理常式在釋放後會繼續針對主機執行。via_sdc_isr（） 解除參照 sdhost 及其 MMIO 基底並排程 carddet_work，而 via_sdc_card_detect（） 也會透過其 container_of（） 解除參照針對釋放的記憶體執行。新增探查錯誤路徑，以停用和釋放中斷，並在取消對應之前取消carddet_work。carddet_work可以透過 via_reset_pcictrl（） 重新啟用裝置中斷，從而恢復 PCIINTCTRL，因此在取消工作後再次遮罩它。此問題由內部靜態分析工具發現，並透過手動程式碼審查確認。（CVE-2026-89440）

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

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

  - sunrpc：在發佈 proc 項目之前初始化 create_use_gss_proxy_proc_entry gssp_lock 在 init_gssp_clnt（） 在 sn->gssp_lock 上執行 mutex_init（） 之前，會透過 proc_create_data（） 發佈 /proc/net/rpc/use-gss-proxy。一旦 dentry 在 proc_subdir_lock 下連結，就可以立即從使用者空間存取它，因此落在視窗中的寫入會將 set_gssp_clnt（） 驅動到零初始化結構互斥體上的 mutex_lock（） 中。create_use_gss_proxy_proc_entry（net） proc_create_data（use-gss-proxy， ...） /* dentry live */ init_gssp_clnt（sn） mutex_init（&sn->gssp_lock） /* 太晚 */ write_gssp（） set_gssp_clnt（net） mutex_lock（&sn->gssp_lock） /* 未初始化 */ gssp_rpc_create（...） sn->gssp_clnt = clnt mutex_unlock（&sn->gssp_lock） 此視窗僅跨越 proc_create_data（） 傳回和 init_gssp_clnt（） 之間的兩個陳述式， 因此，只有在另一個工作已經開啟新發佈的檔案時，註冊執行緒被搶佔時，寫入器才會到達它。register_pernet_subsys（） 在 pernet_ops_rwsem 下的搶佔式上下文中運行，因此可以搶佔，並且當為任務已執行auth_rpcgss每個即時網路命名空間建立 proc 項目時，視窗會在模組載入時加寬。贏得爭用的寫入器會鎖定一個填滿零的結構互斥。在CONFIG_DEBUG_MUTEXES缺少的魔術值會跳閘沒有 init splat 的鎖;在生產核心上，捷徑會透過 CMPXCHG（owner， 0， current） 取得鎖定。在後一種情況下，在 init_gssp_clnt（） 重新歸零所有者之前到達的第二個寫入器可以同時輸入 set_gssp_clnt（），在第一個寫入器的 clnt 仍在使用時關閉它，並洩漏失敗者的 clnt。透過在 sunrpc_init_net（） 中初始化 sn->gssp_lock 來修正，使其存留期與它所在的sunrpc_net相符。sn->gssp_clnt 已經是 NULL，來自支援 net_generic 儲存體的 kzalloc，因此不再需要延遲協助程式;刪除 init_gssp_clnt（）、其原型以及來自 create_use_gss_proxy_proc_entry（） 的呼叫。sunrpc.ko 是 auth_rpcgss.ko 的建置時相依性，因此 sunrpc_init_net（） 一律會在每個 netns 上執行，然後任何auth_gss pernet init 才能發佈 proc 項目。（CVE-2026-89540）

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

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

  - cxl/mce：使 MCE 通知程式每個區域 Flavien Solt 報告 CXL MCE 通知程式的存留期問題，這可能會導致 MCE 處理常式中出現 NULL 取消參照和釋放後使用。通知程式會依每個記憶體裝置註冊，並儲存在「struct cxl_memdev_state」中，即使它只需要區域狀態 （區域的 SPA 範圍及其擴充的線性快取大小）。正確的修復方法是將通知程式移至「struct cxl_region」並從 cxl_region_probe（） 註冊，因為它應該是每個區域的通知程式，而不是讓記憶體裝置和端點保持活動狀態。將註冊設定為僅針對具有擴充線性快取的區域進行，因為這是目前唯一的使用方式。刪除 cxl_port_get_spa_cache_alias（），因為它現在是死代碼。[ dj： 當通知程式因 kconfig 而失敗時，更新 dev_warn（）。（本） ]（CVE-2026-89570）

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

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

  - net/smc：不要在 SMC-D 拆卸路徑上取消參照未設定的傳送緩衝區 smc_close_stream_wait（） 從其 sk_wait_event（） 條件內部呼叫 smc_tx_prepared_sends（），並且 sk_wait_event（） 會在釋放通訊端鎖定的情況下評估該條件一次。smcd_buf_detach（） 清除 lock_sock（） 下 smc_conn_kill（） 中的 conn->sndbuf_desc，因此當通訊端在那裡等待時終止的連結群組會留下協助程式解除參照 NULL，從而出錯 close（）。SIOCOUTQ 會手動讀取欄位，而 smc_close_cancel_work（） 會在兩個 cancel_*_sync（） 呼叫之間捨棄鎖定。在協助程式中對指標進行一次取樣，在未設定時報告未準備好的任何內容，並以相同的方式繫結 ioctl。接收工作集直接在 smc_cdc_msg_recv_action（） 中取消參照欄位，而不是透過此協助程式;1/2 是它不會運行那麼晚的原因。（CVE-2026-80984）

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

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

  - power： supply： cros_usbpd-charger： bound EC 報告的連接埠計數 cros_usbpd_charger_probe（） 從 EC 讀取兩個連接埠計數，並在填入固定大小陣列時使用其中一個 num_charger_ports 作為迴圈綁定： struct port_data *ports[EC_USB_PD_MAX_PORTS];/* 8 個條目 */ ...對於 （i = 0; i < charger->num_charger_ports; i++） charger->ports[charger->num_registered_psy++] = port;num_usbpd_ports（來自 EC_CMD_USB_PD_PORTS）和 num_charger_ports（來自 EC_CMD_CHARGE_PORT_COUNT）都是 EC 報告的 u8 值。唯一的驗證是將兩個 EC 報告的值相互比較的健全性檢查：if （num_charger_ports < num_usbpd_ports || num_charger_ports > num_usbpd_ports + 1） return -EPROTO;它從不檢查 EC_USB_PD_MAX_PORTS 的計數，即 ports[] 陣列的大小。對於任何 N > 8 （例如，兩個 255） 報告 num_usbpd_ports == num_charger_ports == N 的故障、惡意或受損的 EC 通過此檢查，然後循環將 N 個指標寫入嵌入在 devm_kzalloc（） charger_data中的 8 個條目 ports[] 陣列中，使其溢位最多 255 - 8 = 247 個條目（~1976 個字節）： Slab 越界寫入。拒絕大於 ports[] 陣列可容納的連接埠計數。
    (CVE-2026-89471)

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

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

  - x86/tdx：修正 arch/x86/coco/tdx/tdx.c 中連接埠 I/O 處理 handle_in（） 和 handle_out（） 中的差一錯誤：
    u64 mask = GENMASK（BITS_PER_BYTE * size， 0）;GENMASK（h， l） 包括位元 h。對於 size=1 （INB），這會產生 GENMASK（8， 0） = 0x1FF （9 位元），而不是 GENMASK（7， 0） = 0xFF （8 位元）。遮罩對於所有 I/O 尺寸來說有點太寬了。修正遮罩計算。（CVE-2026-89751）

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

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

  - nfsd：透過 op_release nfsd4_decode_createhow4（） 呼叫 nfsd4_decode_fattr4（） 釋放 OPEN 解碼的 posix ACL，該 ACL 透過 posix_acl_alloc（） 配置參照計數的結構posix_acl物件，並將它們儲存在 open->op_pacl 和 open->op_dpacl 中。一旦 OPEN 化合物完成，就必須釋放這些指標。當 nfsd4_decode_open_claim4（） 傳回 non-seqid-mutating 錯誤時，分派器會在 op_func 執行之前短路： nfsd4_proc_compound（） if （op->status &; op->opnum == OP_OPEN） op->status = nfsd4_open_omfg（...） if （！seqid_mutating_err（ntohl（op->status））） return op->status;/* nfsd4_open（） 永遠不會執行 */ ...opdesc->op_release（&op->u） /* 仍必須發行 op_pacl/op_dpacl */ 在此變更之前，OP_OPEN 中 nfsd4_ops[]沒有 .op_release，且發行對位於 nfsd4_open（） out_err時位於 （） 內：
    標籤。在短路路徑上，永遠不會叫用 nfsd4_open（），因此兩個posix_acl參照都會在每個帶有有效 POSIX ACL createhow4 屬性的格式錯誤的 OPEN 化合物上洩漏。新增 nfsd4_open_release（） 並將其連線為OP_OPEN.op_release。posix_acl_release（） 是 NULL 安全的，因此單一發布站點涵蓋正常路徑和nfsd4_open_omfg短路。從 nfsd4_open（） 的 out_err： 標籤中移除相符的 posix_acl_release（） 對，以避免重複釋放。複合迴圈有兩個編碼分支：
    nfsd4_encode_operation（） 用於一般操作，nfsd4_encode_replay（） 用於 v4.0 重播操作。op_release 僅從 nfsd4_encode_operation（） 呼叫，因此附加到 op->u 的資源會在重播路徑上洩漏。將 op_release（） 呼叫移出 nfsd4_encode_operation（） 和重播分支，將其放在 nfsd4_proc_compound（） 中的 if-else 之後。這會在相當明顯正確的位置提供單一呼叫站點，涵蓋正常編碼和重播路徑。（CVE-2026-89664）

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

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

  - ring-buffer：頁面交換失敗時停止遠端讀取器更新 當寫入器在遠端捕獲磁頭之前移動磁頭時，遠端swap_reader_page回呼可以傳回 -EBUSY，特別是在小型緩衝區上的事件風暴期間。__rb_get_reader_page_from_remote（） 目前會警告該失敗，但會繼續使用未變更的讀取器識別碼，並重新排列本機頁面清單，就像交換成功一樣。
    將回呼失敗當作可復原的錯誤處理。使用 pr_warn_ratelimited（） 報告並傳回 NULL。
    呼叫端已將 NULL 讀取器頁面處理為失敗的嘗試。這可避免與先前和新的讀取器拼接相同的頁面，而不會淹沒爭用中的記錄。（CVE-2026-89499）

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

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

  - NTB：ntb_transport：拒絕過大的 TX 緩衝區 ntb_process_tx（） 會呼叫具有 NULL 資料指標的 tx_handler（） 並傳回成功來處理過大的緩衝區。因此，ntb_netdev既不會釋放其完成回呼中的 skb，也不會採用其佇列錯誤路徑，從而洩漏它。在取得佇列項目之前，拒絕 ntb_transport_tx_enqueue（） 中的過大緩衝區，並傳回 -EMSGSIZE。呼叫端會保留緩衝區的擁有權，而當佇列傳回此永久錯誤時，上述 netdev 修補程式會釋放 skb。（CVE-2026-80987）

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

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

  - nfsd：修正 V4ROOT 上的 dentry 參照洩漏 當 NFS3_FHSIZE 或 NFS_FHSIZE 切換案例偵測到 NFSEXP_V4ROOT 並轉出時，匯出檔案控點查詢 nfsd_set_fh_dentry（） 會洩漏來自 exportfs_decode_fh_raw（） 的 dentry 參照。out： 標籤調用 exp_put（），但從不調用 dput（dentry），並且從未分配過 fhp->fh_dentry，因此 fh_put（） 無法補償。針對 V4ROOT 匯出的 fsid 的特製 NFSv3 檔案控點會在每個要求時觸發洩漏。（CVE-2026-89683）

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

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

  - tpm： tpm_i2c_nuvoton：在等待逾時停用 IRQ i2c_nuvoton_wait_for_stat（） 會在等待中斷處理常式報告狀態變更之前啟用 IRQ。如果等待逾時，或在處理常式執行之前中斷，則函式會傳回而不平衡 enable_irq（） 呼叫。在離開失敗的等待路徑之前，請停用 IRQ。也保留中斷等候的原始錯誤碼，而不是在協助程式內將其轉換為 -ETIMEDOUT。（CVE-2026-80930）

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

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

  - params：修正分配失敗時的 charp 損毀 param_set_charp（） 會在 slab 可用後將 charp 參數儲存在配置的記憶體中，並在參數更新時釋放先前的值。在取代配置成功之前，會釋放先前的值。如果 kmalloc_parameter（） 失敗，則 setter 會傳回 -ENOMEM，並將參數保留為 NULL。在 zswap 初始化之前，zswap 的壓縮器更新失敗，稍後可能會觸發： 錯誤：核心 NULL 指標解除參照，位址：00000000000000000 RIP：
    0010：strcmp+0x10/0x30 呼叫追蹤：zswap_setup+0x3b1/0x490 zswap_enabled_param_set+0x5b/0xa0 param_attr_store+0x93/0xe0 module_attr_store+0x1c/0x30 kernfs_fop_write_iter+0x116/0x1f0 先分配並複製替換，只有在分配成功後才替換參數值。（CVE-2026-89552）

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

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

  - lockd：修正 lockowner 配置失敗時的 NULL 解除參照 nlmclnt_locks_init_private（） 會安裝 NLM 檔案鎖定作業，即使 nlmclnt_find_lockowner（） 無法配置 lockowner。然後 nlmclnt_proc（） 傳回 -ENOMEM，但 VFS 仍會拆除部分初始化的file_lock並呼叫 locks_release_private（）。這會叫用 nlmclnt_locks_release_private（），它取消參照 fl->fl_u.nfs_fl.owner 並因從未安裝所有者而當機。在嘗試起始設定 NLM 專用狀態之前，請先清除fl_ops，並只有在成功配置鎖定擁有者之後，才安裝 NLM 鎖定作業。（CVE-2026-89484）

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

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

  - 裝置屬性：修正 fwnode_for_each_child_node（） 中的無限迴圈 當迭代具有輔助 fwnode 的 fwnode 的子節點時，如果輔助 fwnode 有多個子節點，則 fwnode_get_next_child_node（） 可以進入無限迴圈。父子項 （主要 fwnode） FWa： {FWa1， FWa2， FWa3} （次要 fwnode） FWb： {FWb1， FWb2} 在此情況下： > fwnode_get_next_child_node（FWa， FWa1） - fwnode_call_ptr_op（FWa， get_next_child_node， FWa1） 傳回 FWa2 ...fwnode_get_next_child_node（FWa， FWa3） - fwnode_call_ptr_op（FWa， get_next_child_node， FWa3） 傳回 NULL - fwnode_call_ptr_op（FWb， get_next_child_node， FWa3） 傳回 FWb1 fwnode_get_next_child_node（FWa， FWb1） - fwnode_call_ptr_op（FWa， get_next_child_node， FWb1） 傳回 FWa1 這會導致 fwnode_for_each_child_node（） 無限迴圈， 重新輸出 {FWa1， FWa2， FWa3， FWb1， FWa1， ...}。
    根本原因是當目前的子系 （FWb1） 屬於次要 fwnode 時，在基系 fwnode 上呼叫 get_next_child_node （） 會再次正確地傳回第一個子系 （FWa1） ，而不是 NULL。在呼叫 get_next_child_node（） 之前，透過動態檢查目前子項的父 fwnode 來修正此問題。此方法遵循提交 b5b41ab6b0c1 中建立的模式 （裝置屬性：檢查 fwnode_graph_get_next_endpoint（） 中的 fwnode->secondary）。（CVE-2026-89744）

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

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

  - ALSA： virmidi：在探測時檢查卡片索引有效性 virmidi 驅動程式盲目地相信指定的 devptr->id 值在探測時的正確卡片索引範圍內。驅動程式本身在模組探查時建立的裝置沒問題，但如果裝置是透過 sysfs 介面手動繫結，則可能是 -1 為無，這會導致 index[] 和其他參數的 OOB 存取。新增卡片索引的健全性檢查，並在值超出範圍時警告/更正。（CVE-2026-80964）

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

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

  - wifi：ath6kl：在減去 IE 偏移量之前限制 assoc 請求/回應長度 ath6kl_cfg80211_connect_event（） 從 assoc_req_len （-= 4） 和 assoc_resp_len （-= 6） 減去固定的 IE 偏移量，兩者都是 u8，沒有下限。最近添加到 ath6kl_wmi_connect_event_rx（） 的聚合檢查從上面限制了聲明的長度（它們的總和必須符合收到的事件），但短於其固定偏移量的 assoc 請求/響應仍然在這裡下溢：u8 換行為 ~250，然後 cfg80211_connect_result（） / cfg80211_roamed（） 將該包裝值視為 IE 長度，並通過 nl80211 將該位元組從小assoc_info緩衝區複製到用戶空間， 揭露相鄰的 slab 記憶體。
    在減去之前，將兩個長度夾緊到它們的偏移量。使用自動來源分析在 0sec （https://0sec.ai） 之前找到;從來源可以明顯看到缺少的下限。經過編譯測試。（CVE-2026-89524）

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

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

  - dm-pcache：驗證 kset key_num和區段內邊界 從快取裝置解碼的另外兩個欄位將不受限制。kset key_num驅動 cache_kset_crc（） 和 cache_replay（） 中的重放迴圈、回寫工作程式和 GC 工作程式，但只有 magic 和固定種子 CRC 會先檢查，因此 key_num 超過 PCACHE_KSET_KEYS_MAX 緩衝區的非最後一個 kset 會在 CRC 比較之前讀取過其末尾。金鑰的區段內偏移量和 cache_key_decode（） 中的長度是逐字記錄的，因此經過其區段的金鑰會重播到快取樹狀結構中，資料 CRC 檢查和隨後的每次讀取命中，然後將相鄰的持久記憶體複製到呼叫者的 bio 中 - 這是洩漏到使用者空間的越界讀取。這兩個欄位都由提供快取裝置 （CAP_SYS_ADMIN） 的人員控制;CRC 種子是公開的。在任何 kset 讀取之前將 kset_onmedia_valid（） 新增至綁定key_num，並拒絕以 64 位元計算的偏移加上長度超過區段data_size的索引鍵。有效的中繼資料不受影響。（CVE-2026-80961）

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

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

  - RDMA/ucma：鎖定 ucma_write_cm_event（） 中的處理常式 ctx->file 只能在處理常式鎖定和 xa_lock 下變更，這會阻止 uevents 在 ucma_migrate_id（） 將 ctx 移至另一個檔案時排入 ctx 佇列。CM 核心在叫用 ucma_event_handler（） 之前會取得該鎖定，但將事件本身排入佇列的 write（） 路徑則不會。ucma_write_cm_event（） 會重新讀取 ctx->file 的四個取消參照，因此 ucma_migrate_id（） 可以在序列中交換它：mutex_lock（&ctx->file->mut）;/* 檔案 A */ list_add_tail（&uevent->list， &ctx->file->event_list）;/* 檔案 B */ mutex_unlock（&ctx->file->mut）;/* 檔案 B */ wake_up_interruptible（&ctx->file->poll_wait）;/* 檔案 B */ 視窗是 mutex_lock（） 本身：當移轉重新指派 ctx->file 時，寫入器在其中休眠。然後，list_add_tail（） 在檔案 B 的event_list上運行，僅保留檔案 A 的互斥：list_add損毀。prev->next 應該是下一個 （ffff888101320f30），但原來是 ffff88814a08c418。(prev=ffff88814a075c18).lib/list_debug.c：32 的核心錯誤！呼叫追踪：
    ucma_write_cm_event+0x36e/0x5e0，檔案 A 的靜音將永遠保留，將其下一個寫入器楔入 D 狀態。
    uevent 也滯留在清單中 ucma_cleanup_ctx_events（） 不會走，因此它會超過其上下文的壽命。
    /dev/infiniband/rdma_cm 是 0666，並且不涉及 RDMA 設備，因此無權限的使用者可以存取所有這些。取處理常式鎖，就像 ucma_cleanup_mc_events（） 所做的那樣;ctx->cm_id 由 ucma_get_ctx（） 參照固定。（CVE-2026-89507）

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

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

  - USB： 小工具： u_audio：修正音效卡中斷連線的釋放後使用 g_audio_cleanup（） 叫用 snd_card_free_when_closed（） 以啟動音效卡拆卸，並立即釋放上下文snd_uac_chip基礎結構。但是，當 ALSA 控制元素 （kctls） 在使用者空間中保持開啟狀態時，snd_card_free_when_closed（） 會以非同步方式傳回。當使用者空間控制應用程式存取或關閉這些開啟的檔案描述元時，kctl 回呼會嘗試取消參照 kctl->private_data，指向釋放的 UAC 結構內的 &uac->c_prm 或 &uac->p_prm，從而導致釋放後使用 （UAF） 記憶體損毀。藉由將結構snd_uac_chip的損毀推遲到釋放所有對 ALSA 聲卡的參照為止，來修正此問題。在 g_audio_setup（） 期間註冊自訂卡片>private_free回呼 （u_audio_card_free），僅在音效卡參照計數降至零時，才釋放 UAC 及其相關聯的播放/擷取要求和環形緩衝區。（CVE-2026-89736）

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

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

  - bnx2x：修正 bnx2x_init_firmware（） 錯誤路徑中的雙重釋放 bnx2x_init_firmware（） 釋放錯誤路徑中的 bp->init_ops、bp->init_data 和 bp->init_ops_offsets，而不將它們設定為 NULL。清理函數 bnx2x_release_firmware（） 無條件地釋放相同的三個指標，因此如果init_firmware失敗並且稍後調用release_firmware（例如從__bnx2x_remove或透過函數狀態機），則所有三個指標都會被第二次釋放。在錯誤路徑中的 kfree（） 之後將每個指標設定為 NULL，以便 bnx2x_release_firmware（） 中的後續 kfree（NULL） 是安全的無操作。（CVE-2026-89582）

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

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

  - ACPI： pfr_update：修正 query_capability（） 中的堆疊緩衝區溢位 query_capability（） 使用 memcpy 和韌體提供的長度，將韌體_DSM傳回的四個 ACPI 緩衝區物件複製到結構pfru_update_cap_info中的固定大小 u8[16] 欄位中：memcpy（&cap_hdr->code_type， elements[CAP_CODE_TYPE_IDX].buffer.pointer， elements[CAP_CODE_TYPE_IDX].buffer.length）;drv_type、platform_id和oem_id重複相同的模式。如果韌體針對任何這些欄位傳回 buffer.length > 16，則 memcpy 會寫入目的地陣列。結構pfru_update_cap_info在 pfru_ioctl（） 中進行堆疊分配。在 7.2-rc6 上與 KASAN 確認：當 DSM 傳回 64 位元組緩衝區時，會產生三個堆疊越界報告，寫入在 cap_hdr 的 [64， 156） 框架視窗結束後達到 44 位元組到相鄰堆疊紅區。引入 out_obj->package.elements 的協助程式指標，並在複製之前使用它根據其目的地欄位大小驗證每個緩衝區長度，如果韌體提供過大的緩衝區，則傳回 -EINVAL。（CVE-2026-89587）

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

ID	名稱	嚴重性
345347	Linux Distros 未修補弱點：CVE-2026-83530	medium
345346	Linux Distros 未修補弱點：CVE-2026-89578	medium
345345	Linux Distros 未修補弱點：CVE-2026-89613	critical
345344	Linux Distros 未修補弱點：CVE-2026-89454	medium
345343	Linux Distros 未修補弱點：CVE-2026-89521	high
345342	Linux Distros 未修補弱點：CVE-2026-89574	high
345341	Linux Distros 未修補弱點：CVE-2026-89612	critical
345340	Linux Distros 未修補弱點：CVE-2026-81011	high
345339	Linux Distros 未修補弱點：CVE-2026-89589	medium
345338	Linux Distros 未修補弱點：CVE-2026-89615	high
345337	Linux Distros 未修補弱點：CVE-2026-89590	medium
345336	Linux Distros 未修補弱點：CVE-2026-89606	high
345335	Linux Distros 未修補弱點：CVE-2026-89713	critical
345334	Linux Distros 未修補弱點：CVE-2026-80981	critical
345333	Linux Distros 未修補弱點：CVE-2026-89616	high
345332	Linux Distros 未修補弱點：CVE-2026-89514	medium
345331	Linux Distros 未修補弱點：CVE-2026-80926	critical
345330	Linux Distros 未修補弱點：CVE-2026-89694	medium
345329	Linux Distros 未修補弱點：CVE-2026-81012	high
345328	Linux Distros 未修補弱點：CVE-2026-89727	medium
345327	Linux Distros 未修補弱點：CVE-2026-89721	medium
345326	Linux Distros 未修補弱點：CVE-2026-80989	high
345325	Linux Distros 未修補弱點：CVE-2026-89647	high
345324	Linux Distros 未修補弱點：CVE-2026-89684	high
345323	Linux Distros 未修補弱點：CVE-2026-89554	high
345322	Linux Distros 未修補弱點：CVE-2026-82617	critical
345321	Linux Distros 未修補弱點：CVE-2026-89685	high
345320	Linux Distros 未修補弱點：CVE-2026-89497	high
345319	Linux Distros 未修補弱點：CVE-2026-89494	critical
345318	Linux Distros 未修補弱點：CVE-2026-89440	high
345317	Linux Distros 未修補弱點：CVE-2026-89540	high
345316	Linux Distros 未修補弱點：CVE-2026-89570	high
345315	Linux Distros 未修補弱點：CVE-2026-80984	medium
345314	Linux Distros 未修補弱點：CVE-2026-89471	high
345313	Linux Distros 未修補弱點：CVE-2026-89751	high
345312	Linux Distros 未修補弱點：CVE-2026-89664	high
345311	Linux Distros 未修補弱點：CVE-2026-89499	high
345310	Linux Distros 未修補弱點：CVE-2026-80987	high
345309	Linux Distros 未修補弱點：CVE-2026-89683	high
345308	Linux Distros 未修補弱點：CVE-2026-80930	medium
345307	Linux Distros 未修補弱點：CVE-2026-89552	medium
345306	Linux Distros 未修補弱點：CVE-2026-89484	medium
345305	Linux Distros 未修補弱點：CVE-2026-89744	high
345304	Linux Distros 未修補弱點：CVE-2026-80964	high
345303	Linux Distros 未修補弱點：CVE-2026-89524	high
345302	Linux Distros 未修補弱點：CVE-2026-80961	high
345301	Linux Distros 未修補弱點：CVE-2026-89507	high
345300	Linux Distros 未修補弱點：CVE-2026-89736	high
345299	Linux Distros 未修補弱點：CVE-2026-89582	medium
345298	Linux Distros 未修補弱點：CVE-2026-89587	high

偵測

Nessus 的 Misc. 系列

medium

medium

critical

medium

high

high

critical

high

medium

high

medium

high

critical

critical

high

medium

critical

medium

high

medium

medium

high

high

high

high

critical

high

high

critical

high

high

high

medium

high

high

high

high

high

high

medium

medium

medium

high

high

high

high

high

high

medium

high