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

  - iommu/tegra241-cmdqv：在拆除 VINTF 之前釋放錯誤 IRQ tegra241_cmdqv_remove（） 會先拆除每個 VINTF，然後呼叫 free_irq（）。拆除 VINTF 會釋放 vintf0 並清除 cmdqv->vintfs[0]。該視窗中的錯誤會使 tegra241_cmdqv_isr（） 讀取過時的插槽並將其交給 tegra241_vintf0_handle_error（），後者會取消參照 NULL 或釋放的指標。在拆除 VINTF 之前釋放 IRQ。free_irq（） 會等待正在進行的處理常式完成並封鎖新的處理常式，因此任何 ISR 都無法在 VINTF 被拆除時觀察它。注意：使用者擁有的 VINTF （viommu） 可能會比這次拆卸更耐用，這會取消映射 cmdqv->base 並釋放 cmdqv->vintfs，因此稍後的 viommu 關閉會觸及釋放的記憶體。這裡既沒有引入也沒有修復這一點：物理 IOMMU 不是可插拔的設備，因此 iommufd 在設計上對 viommu 後面的設備沒有參考，並且當 viommu 還活著時，預計不會進行這種拆解。（CVE-2026-90426）

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

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

  - wifi：mt76：mt7996：綁定的 TLV 步入mt7996_mcu_get_chip_config tlv->len 沒有最小值的回應 TLV 迴圈，因此包含零長度 TLV 的理論韌體回應可能會永遠旋轉，在裝置探測期間懸置 CPU。u32 有效載荷也被無邊界檢查地讀取。
    拒絕短固定欄位，停止在長度低於標頭或超出 skb 的 TLV 上。
    (CVE-2026-90370)

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

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

  - 匯流排：mhi：host：修正 EDL sysfs 失敗時的控制器清除 mhi_register_controller（） 會在建立選用的 trigger_edl sysfs 檔案之前新增控制器裝置。如果 sysfs_create_file（） 失敗，錯誤路徑只會刪除裝置參照，並讓裝置保持註冊狀態。因此，請在錯誤路徑中呼叫 put_device（） 之前的 device_del（）。（CVE-2026-90402）

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

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

  - wifi： mt76： mt7996：為 CSA 中止倒數計時 TLV 保留空間 當 CSA 倒數計時處於活動狀態時，mt7996_mcu_beacon_cntdwn（） 會發出兩個bss_bcn_cntdwn_tlv項目 （CSA 倒數計時和 CCA 中止密件抄送），但MT7996_BEACON_UPDATE_SIZE只保留一個。啟用 MBSSID 且接近最大信標範本後，額外的 8 個位元組可能會將 offload 命令推過 MT7996_MAX_BSS_OFFLOAD_SIZE 並觸發 skb_over_panic（）。為兩個倒數 TLV 預留空間。CVE-2026-90366

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

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

  - drm/panthor：使用 kbo 範圍重疊檢查新增vm_bind區域 建立虛擬機器時，呼叫端必須指定為對應核心 BO 而預留的位址空間劃出範圍。這表示 UM 公開 BO 的vm_bind對應不應該與該區域相交，但目前我們不會檢查這一點。起初，我想通過其 reserve_{offset， range} 參數將這些值提供給 drm_gpuvm_init（），但事實證明，它適用於未通過通常的 drm_gpuvm 拆分/合併電路管理的 VM 地址範圍，因此在 VM 創建時存儲用戶 VA 範圍的末端並在vm_bind ioctl 路徑中進行快速檢查是最簡單的解決方法。新的檢查還確保vm_bind範圍不會溢出 64 位元無符號整數的大小。這已經在 drm_gpuvm_sm_map -> drm_gpuvm_range_valid 內的呼叫堆疊下游完成，但最好在叫用 GPUVM 函式之前，在驅動程式中儘早失敗，這樣我們就不會浪費時間配置vm_bind內容資源。（CVE-2026-90409）

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

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

  - xfrm：修正 xfrm_dev_direct_output（） 中的 skb 雙重釋放 local_out（） 的傳回值不是 1 表示 skb 已被消耗或其所有權已轉移。儘管如此，xfrm_dev_direct_output（） 還是會釋放此路徑上的 skb，當 netfilter 丟棄封包並使任何其他所有者無效時，會導致雙重釋放。直接傳回 local_out（） 結果，與 xfrm_output_resume（） 中的所有權處理相符。（CVE-2026-92489）

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

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

  - xsk：修正 __xsk_rcv（） 中的 NULL 指標解除參照 在 __xsk_rcv（） 多緩衝區路徑中，在迴圈中呼叫 xsk_buff_alloc（），而不檢查其傳回值。xsk_buff_can_alloc（） 僅計算填充佇列項目而不驗證其位址，因此它可以成功，而 xsk_buff_alloc（） 拒絕所有剩餘項目並傳回 NULL。哎呀：一般保護錯誤，可能是非規範位址 0xdffffc0000000000 KASAN：範圍內 null-ptr-deref [0x0000000000000000-0x0000000000000007] RIP：0010：__xsk_rcv+0x426/0xc20 （net/xdp/xsk.c：350） 呼叫追蹤：xsk_generic_rcv+0x26d/0x5f0 xdp_do_generic_redirect+0x3c5/0xcf0 do_xdp_generic+0x92f/0xe70 __netif_receive_skb_core.constprop.0+0xf7e/0x2b30 使用兩階段交易來修正此問題。首先配置並暫存封包所需的所有緩衝區，如果任何分配失敗，則使用 xsk_buff_free（） 回收所有暫存緩衝區。只有在此階段成功之後，才能複製資料、保留 RX 描述元，並在無錯誤迴圈中釋放緩衝區。（CVE-2026-90115）

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

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

  - wifi： mt76：修正RXDMAD_C緩衝區回收爭用 RXDMAD_C緩衝區來自 RRO 資料佇列的頁面集區，這些頁面集區系結至不同的 NAPI，因此此處使用的直接頁面集區回收可能會爭用擁有的 NAPI;採用非直接路徑，就像對 WED RX 佇列所做的那樣。（CVE-2026-90371）

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

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

  - RDMA/core：等待 RCU 回呼後再卸載 ib_core put_gid_ndev（） 與 call_rcu（） 一起排入佇列，並在 ib_core 中實作。停止工作佇列不會排空已排入佇列的回呼，因此 RCU 可以在卸載模組程式碼之後叫用它。synchronize_rcu（） 不會等待回呼。在所有生產者停止後等待他們。（CVE-2026-93110）

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

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

  - isofs：釋放 Zisofs 區塊指標緩衝區頭 zisofs_fill_pages（） 會讀取壓縮的區塊指標表格。錯誤路徑釋放當前buffer_head，循環在前進時也會釋放舊buffer_head。不過，成功路徑會保留最後一個參照buffer_head。在返回成功之前釋放它。（CVE-2026-90434）

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

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

  - bpf：拒絕透過不受信任的 BTF 指標寫入 check_ptr_to_btf_access（） 可讓程式類型的 btf_struct_access 回呼在預設 BTF 存取路徑拒絕非讀取存取之前驗證寫入。
    這會繞過由協助程式 （例如 bpf_rdonly_cast（） 建立的不受信任 BTF 指標的唯讀原則。在回呼分支之前，透過通用進入點的 PTR_UNTRUSTED BTF 指標拒絕非讀取存取，以處理所有案例。（CVE-2026-93144）

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

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

  - blk-iolatency：釋放原則資料時清除延遲狀態 io.latency 可以節流沒有自己的延遲目標的群組。當同級錯過其目標時，check_scale_change（） 會縮減其對等體，而達到佇列深度的對等體會在每次進一步縮減時呼叫 blkcg_use_delay（），即使 min_lat_nsec == 0。iolatency_pd_offline（） 透過 iolatency_set_min_lat_nsec（） 重設目標，這只會在非零到零的轉換中清除延遲，因此它永遠不會清除這樣的對等體。然後釋放原則資料會保留 blkg->use_delay 設定，並將 blkcg->congestion_count提升，沒有任何可以刪除它的東西。然後，只要 cgroup 存在，blk_cgroup_congested（） 就會針對該 cgroup 及其後代中的每個任務傳回 true：page_cache_sync_ra（） 會將預讀切斷為單一頁面，page_cache_async_ra（） 會完全跳過它，而 __folio_throttle_swaprate（） 會接受swap_avail_lock並排程匿名對開配置的限制。清除 iolatency_pd_free（） 中的延遲。到那時，生物持有的 blkg 引用已經耗盡，或者佇列被凍結以停用策略，因此 check_scale_change（） 無法重新武裝它。免費回呼也可以看到從未附加到 blkg 的原則資料，因此會進行 pd->blkg 檢查。（CVE-2026-90183）

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

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

  - IB/isert：工作階段註冊後發布完整功能的接收緩衝區 isert_put_login_tx（） 會在 __transport_register_session（） 執行之前發布完整功能的接收緩衝區，因此不等待最終登入回應的啟動器仍然可以對se_tpg為 NULL 的se_session執行 SCSI 命令 - 與先前的修補程式相同， target_submit+0xbe。從之前的修補程式已經用來傳送回應的 isert_get_rx_pdu（） 張貼它們，並在傳送之前張貼它們：當發起者被告知它可以使用它時，接收佇列就會填滿。配置在那裡會保留現有屬性，即一旦最終登入回應在網路上，就不會發生記憶體配置失敗。最終登入要求和 isert_post_recvm（） 之間的接收佇列已經是空的;
    這在之後移動了第二個點，從中位數 92 US 增加到 172 US 超過 1200 次登錄。只有在被告知之前發送的發起方才能到達該窗口，並且在 IB 和 RoCE 上，它的發送會在那裡重試，直到緩衝區出現 - isert_rdma_accept（） 要求 rnr_retry_count = 7。iWARP 沒有 RNR 流量控制，因此相同的傳送會改為終止連線。在 rxe 上測量，每次執行 400 次登入週期，啟動器不等待：在 10 次執行中發布緩衝區之前，檢測的組建不計算 isert_recv_done（） 的條目，其中該啟動器在 10 次未修補的執行中計算了 8 次，僅使用先前的修補程式，則在 10 次未修補的執行中計算了 5 次。未經測試：iWARP、透過 iSER 的探索工作階段和真實的 HCA。
    (CVE-2026-90293)

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

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

  - RDMA/core：修正 ib_destroy_cq_user（） 中釋放後的潛在使用：透過網路連結路徑存取 CQ 時，所述 CQ 的唯一同步機制是 rdma_restrack_get（）。目前，rdma_restrack_del（） 會在 ib_destroy_cq_user（） 結尾叫用，但為時已晚，因為此時與 CQ 相關聯的廠商特定資源可能已經釋放。這可能會留下一個較短的窗口，透過重新追蹤仍可存取 CQ，從而導致潛在的釋放後使用。透過將 rdma_restrack_begin_del（） 呼叫移至 ib_destroy_cq_user（） 的開頭來修正此問題，確保在釋放其內部資源之前將 CQ 從重新追蹤中移除。這可確保沒有新使用者持有正在破壞的CQ的參照。此外，此變更會保留建立和銷毀常式之間的預期反向順序：在成功建立結束時新增資源以重新追蹤，因此在銷毀流程期間應首先從重新追蹤中移除，以維持生命週期管理的一致性和可預測性。（CVE-2026-92511）

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

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

  - smb/server：修正 ksmbd_ipc_tree_connect_request（） 中的 null-ptr-deref 請參閱以下程序：
    ksmbd_tree_conn_connect ksmbd_share_config_get share->name = kstrdup（） // 失敗 if （！test_share_config_flag（share， KSMBD_SHARE_FLAG_PIPE）） // false // 不檢查 'share->name' ksmbd_ipc_tree_connect_request strlen（share->name） // null-ptr-deref （CVE-2026-90166）

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

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

  - net/smc：在 REQ_ADD_LINK 到 ADD_LINK 轉換中覆寫之前釋放隱藏的 qentry 當 smc_llc_event_handler（） 在 ADD_LINK 請求到達時將本機 LLC 流程從 SMC_LLC_FLOW_REQ_ADD_LINK 轉換為 SMC_LLC_FLOW_ADD_LINK 時，它會無條件呼叫 smc_llc_flow_qentry_set（）：if （lgr->llc_flow_lcl.type == SMC_LLC_FLOW_REQ_ADD_LINK） { lgr->llc_flow_lcl.type = SMC_LLC_FLOW_ADD_LINK; smc_llc_flow_qentry_set（&lgr->llc_flow_lcl， qentry）;... }flow->type SMC_LLC_FLOW_REQ_ADD_LINK時到達的CONFIRM_LINK或ADD_LINK_CONT會透過 SMC_LLC_CONFIRM_LINK/SMC_LLC_ADD_LINK_CONT 處理常式 （儲存於任何非 NONE 流程類型的 flow->qentry 中） 儲存到 flow->qentry 中。當後續ADD_LINK到達時，REQ_ADD_LINK 分支會使用新指標覆寫 flow->qentry，而無需先釋放隱藏的分配，從而洩露一個 kmalloc 物件。隱藏的項目沒有消費者：smc_llc_wait（） 僅從 llc_add_link_work 呼叫，當流程類型保持REQ_ADD_LINK時，該尚未排程。此時沒有服務員睡在llc_msg_waiter上。在覆寫之前無條件釋放任何隱藏的 qentry 是安全的。在 REQ_ADD_LINK 分支中，先呼叫 smc_llc_flow_qentry_del（），然後再呼叫 smc_llc_flow_qentry_set（）。smc_llc_flow_qentry_del（） 在釋放之前已經檢查了 flow->qentry，因此沒有隱藏任何項目的正常路徑是無操作的。（CVE-2026-90108）

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

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

  - platform/x86： dell-wmi-base：修正模組載入失敗時的資源洩漏 當模組載入失敗時，我們需要正確清理 SMBIOS 要求和隱私驅動程式。（CVE-2026-93130）

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

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

  - wifi： iwlwifi： mei：在讀取 SAP 訊息之前檢查其長度 在讀取訊息之前，請驗證 SAP 訊息大小不大於本機緩衝區，以避免緩衝區溢位。（CVE-2026-93063）

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

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

  - bpf：在狀態修剪期間比較迭代器類型迭代器堆疊槽可以是MEM_RCU或PTR_UNTRUSTED。
    這些狀態不得相等，否則驗證程式可能會修剪不安全的路徑。比較STACK_ITER插槽的指標類型。（CVE-2026-90217）

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

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

  - dmaengine： xilinx_dma： 修正 AXIDMA 和 MCDMA 中斷處理常式中的通道閒置狀態管理 修正 AXIDMA 和 MCDMA irq 處理常式中的爭用情形，其中通道可能會被錯誤地標記為閒置，並在描述元仍在處理時嘗試虛假傳輸。此問題發生在以下情況： 1. 多個描述元已排入佇列且作用中。2. 完成一些描述元後會觸發中斷。3.
    xilinx_dma_complete_descriptor（） 會將已完成的描述元移至 done_list。4. 通道被標記為閒置並呼叫 start_transfer（），即使active_list仍然包含未處理的描述元。5. 這會導致過早的轉移嘗試以及潛在的描述元損毀或錯過完成。僅在活動清單實際上為空時才將通道標記為閒置並開始新的傳輸，以確保正確的通道狀態管理並避免虛假傳輸嘗試。（CVE-2026-93170）

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

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

  - vdpa_sim：當 kthread_run_worker（） 失敗時，修正背景工作角色建立失敗 vdpasim_create（） 將 vdpasim->worker 保留為ERR_PTR後的清理作業。然後，錯誤路徑會捨棄裝置參照，以釋放部分初始化的模擬器。vdpasim_free（） 無條件地將工作指標傳遞給 kthread_destroy_worker（），因此ERR_PTR被取消參照，並可能觸發一般保護錯誤。儲存背景工作錯誤、清除指標，只有在成功初始化時才清理背景工作。
    此外，透過保護 virtqueue 和 IOTLB 清理，使發行路徑能夠容忍部分初始化的物件，因為其他初始化失敗可能會連線到相同的發行路徑。我自己發現了這個錯誤，儘管該補丁是在 AI 幫助下編寫的。（CVE-2026-90130）

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

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

  - bpf：在載入 check_atomic_load（） 呼叫 check_load_mem（） 之前檢查載入獲取 src ptr 類型，然後再進行 atomic_ptr_type_ok（）。對於擷取到自己的來源暫存器 （dst_reg == src_reg） 的載入取得，check_load_mem（） 會以載入值的類型覆寫src_reg的類型，因此後續的 atomic_ptr_type_ok（） 不再看到來源指標，也無法拒絕不允許的類型 （ctx、pkt、flow_keys、sock）。由於 bpf_convert_ctx_accesses（） 不會重寫不可部分完成載入，因此對基礎核心物件的原始存取會保留在原處。目標類型取自 ctx 存取本身，因此例如，對 struct __sk_buff 的 sk 欄位進行載入獲取會將暫存器類型化為 PTR_TO_SOCK_COMMON_OR_NULL，而 type_is_sk_pointer（） 也不匹配，而它實際上保存未轉換的結構sk_buff位元組。一旦通過 NULL 檢查，這就是類型混淆，而不僅僅是核心資料的洩漏。使用 check_reg_arg（） 驗證src_reg，並在載入之前再次使用 atomic_ptr_type_ok（） 檢查來源指標類型，鏡像 check_atomic_rmw（）。超出範圍的暫存器編號已經被 check_and_resolve_insns（） 更早地拒絕（提交 503d21ef8eac （bpf：儘早進行暫存器範圍驗證）），而唯一的豁免 is_stack_arg_ldx（） 需要 BPF_LDX |BPF_MEM |BPF_DW，因此永遠不會與BPF_ATOMIC insn 相符。因此，atomic_ptr_type_ok（） 無法取消參照越界暫存器狀態，也就是說，以下修正提交所解決的越界讀取不會再次出現 （也透過自我測試證明）。（CVE-2026-90312）

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

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

  - RDMA/rxe：在索引 wqe->dma.sge[] 之前驗證 num_sge/cur_sge 對於使用者 QP，qp->sq.queue 是應用程式直接寫入的環，因此 rxe_post_send（） 採用is_user分支，並且僅排程send_task而不驗證 WQE。rxe_requester（） 會透過 req_next_wqe（） 就地取用它，並呼叫 copy_data（），後者會將 &wqe->dma.sge[cur_sge] 與攻擊者控制的 num_sge/cur_sge 建立索引。只有核心路徑邊界num_sge （validate_send_wr（））;使用者 WQE 永遠不會被檢查，因此本機非特權使用者可以張貼具有超出範圍cur_sge或過大num_sge的 WQE，並強制在 copy_data（） 中越界讀取 per-WQE sge 陣列 （vmalloc OOB 讀取，本機 DoS）。在使用前將num_sge綁定到 rxe_requester（） 中的 qp->sq.max_sge，就像 get_srq_wqe（） 已經保護 SRQ 條目一樣，並且僅在 WQE 攜帶有效負載 （dma.resid） 時才綁定cur_sge：copy_data（） 在接觸 dma->sge[] 之前提前返回零長度副本，因此零有效負載 WQE（max_sge == 0 QP 可以發布的唯一類型）保持有效。在 KASAN 下複製;copy_data（） 中的 vmalloc-out-of-bounds 已消失。（CVE-2026-92525）

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

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

  - net/sched： sfq：限制量子以避免帶正負號的溢位軟鎖定 sfq_init（） 設定 q->quantum = psched_mtu（qdisc_dev（sch）） （無正負號）。具有巨大 MTU 的裝置（例如，接受 MTU 2147483634 的 max_mtu == 0 的虛擬裝置）會使 psched_mtu（） 傳回 0x80000000，因此 slot->allot = INT_MIN 和 INT_MIN + INT_MIN 永遠在 INT_MIN 和 0 之間切換，在 qdisc 鎖定下旋轉 sfq_dequeue（）。將量子箝位為 [256， 1 << 20]，以便重新填充迴路終止。下限也涵蓋 q->量子 == 0 （psched_mtu（） 傳回 0），其旋轉方式相同 sfq_dequeue（）。sfq_change（） 已經拒絕負量子，因此只有 init 路徑被公開。重新建立錯誤的條件：其 MTU （加上 hard_header_len） 將 psched_mtu（） 包裝到符號位元中的裝置 （例如，max_mtu == 0 的虛擬裝置接受 MTU 2147483634）。
    需要在使用者命名空間中CAP_NET_ADMIN。（CVE-2026-90072）

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

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

  - 藍牙：L2CAP：修正爭用 l2cap_sock_cleanup_listen（） 與 put_chan 對於沒有 sk->sk_socket 的 L2CAP 通訊端，讀取 l2cap_pi（sk）->chan 可能會與並行的 l2cap_sock_kill（） -> l2cap_sock_put_chan（） 爭用。這不包括同時proto_ops回呼，但 l2cap_sock_cleanup_listen（） 中的存取具有不安全的無鎖定讀取。[任務 1][任務 2 （hdev->工作佇列）] l2cap_sock_release（parent） l2cap_disconn_cfm l2cap_sock_cleanup_listen l2cap_conn_del bt_accept_dequeue l2cap_chan_del lock_sock（sk） l2cap_sock_teardown_cb bt_accept_unlink bt_sk（sk）->parent = NULL release_sock（sk） ----------------> lock_sock（sk） parent = /* NULL */ lock_sock（sk） <--------------------- release_sock（sk） sock_set_flag（sk， SOCK_ZAPPED） l2cap_sock_close_cb l2cap_sock_kill（sk） l2cap_sock_put_chan chan = READ l2cap_pi（sk）->chan l2cap_pi（sk）->chan = NULL l2cap_chan_hold_unless_zero l2cap_put_chan（chan） kref_get_unless_zero（&chan->ref） 任務 1 可能會觀察到 NULL，這會導致 null-ptr-deref。
    透過採用 l2cap_sock_kill（） 中的 lock_sock（） 與 l2cap_sock_cleanup_listen（） 同步來修正爭用。
    這裡不需要 hold_unless_zero（），如果它不是 NULL，則 l2cap_pi（sk）->chan 擁有參照。釐清程式碼註解與鎖定。（CVE-2026-90091）

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

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

  - net： bridge： arp/nd proxy：修正讀取 neigh ha 目前會直接讀取 neigh ha 位址，但如果更新 neigh 位址，可能會導致讀取撕裂/部分讀取。使用 neigh_ha_snapshot 來建立位址的穩定快照。（CVE-2026-90106）

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

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

  - ip6mr：不要複製 ip6mr_cache_report（） 中的 dst IPv6 輸入會將非參照計數 （NOREF） dst 附加至 RCU 下的 skb。當輸入多點傳播封包遺漏 MFC 查詢時，ip6mr_cache_unresolved（） 會將 skb 放在未解析的佇列上，從而逸出接收端 RCU 寬限期。如果刪除並釋放基礎路由，且 MFC 佇列稍後以錯誤的父介面解析，則 ip6_mr_forward（） 會叫用 ip6mr_cache_report（...， MRT6MSG_WRONGMIF），這會在釋放的 dst 項目上執行 dst_clone（skb_dst（pkt）），從而觸發 slab 釋放後使用。排入佇列至 mroute6_sk （原始通訊端） 的報告封包，而網路連結通知不需要附加的 DST 項目。透過以下方式解決此問題： 1. 移除 ip6mr_cache_report（） 中的 dst_clone（） 並確保報告 skb 不保留 dst。2. 在 ip6mr_cache_unresolved（） 中將未解析的 skb 排入佇列之前刪除 skb_dst，與組播轉送透過 ip6_route_output（） 重新解析傳出路由的事實相符。（CVE-2026-90111）

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

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

  - RDMA/mlx5：修正 debugfs 中的堆疊越界讀取 cc_params debugfs get_param（） 會將壅塞參數讀取為 u32，但使用帶正負號的 %d 將其格式化為 11 位元組的堆疊緩衝區。設定了位元 31 的值 （例如 0x80000000） 會轉譯為全長為 12 的 -2147483648\n 。 snprintf（） 僅儲存 11 個位元組，但傳回 12，因此 simple_read_from_buffer（） 將 12 個位元組視為有效，並讀取 lbuf[] 之後的一個位元組。將緩衝區大小調整為最寬的無符號小數，以 %u 格式化以符合 u32，並使用 scnprintf（），以便傳遞給 simple_read_from_buffer（） 的長度反映實際儲存的位元組。（CVE-2026-90416）

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

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

  - fs/resctrl：移除網域時，修正背景工作執行緒中的 UAF mbm_handle_overflow（） 和 cqm_handle_limbo（） 背景工作角色會讀取事件計數器，並在讀取此時可能會休眠。它們是透過內嵌在結構rdt_l3_mon_domain中的delayed_work排程的。架構在 cpus_write_lock（） 下分配並釋放這些網域的 CPU 熱插拔回呼，而工作角色會取得 cpus_read_lock（） 以保持網域在其存取中處於活動狀態。當工作角色在等待 cpus_read_lock（） 時被封鎖，而熱插拔核心保留 cpus_write_lock（），則可能會發生釋放後使用：架構會釋放包含工作角色work_struct的rdt_l3_mon_domain。當背景工作解除封鎖時，它在內嵌工作指標上執行的 container_of（） 會解除參照釋放的記憶體。從背景工作角色中刪除 cpus_read_lock（），改為在架構釋放網域之前同步清空擱置中和進行中的工作。
    由於架構會在 cpus_write_lock（） 下的網域與 RCU 清單取消連結且寬限期過後離線，因此無法排程任何新工作。取消只需要等待現有工作結束。在 cancel_delayed_work_sync（） 附近的 CPU 離線期間丟棄 rdtgroup_mutex，以便等待互斥的工作可以在將工作重新釘選到不同的 CPU 之前完成。當 CPU 離線時，架構可能會以任何順序反覆運算資源。例如，MBA 控制網域可能會在對應的 L3 監視網域之前或之後離線。確保 resctrl fs 會取消背景工作角色，無論架構以何種順序離線網域。（CVE-2026-93099）

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

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

  - wifi： ath11k：修正 ath11k_service_ready_ext_event（） 中的洩漏 目前，在 ath11k_service_ready_ext_event（） 處理期間，可以在 TLV 剖析期間配置 svc_rdy_ext.mac_phy_caps。
    這是在成功路徑上釋放的暫時配置，但不會在錯誤路徑上釋放。如果剖析成功到足以配置mac_phy_caps，然後在稍後的 TLV 上失敗，則配置會洩漏。因此，釋放錯誤路徑上的配置。僅測試編譯檔案。(CVE-2026-90361)

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

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

  - iomap：在 iomap 回呼失敗時釋放對開本批次 對不相關修補程式的 sashiko 審查指出，用於 iomap 零範圍的對開批次機制在幾個錯誤情況下無法釋放批次。如果呼叫 ->iomap_end（） 或 ->iomap_begin（） 失敗，則直接傳回路徑會繞過批次清除。->iomap_end（） 情況目前不是一個實際問題，因為沒有從此路徑傳回錯誤的機制使用者。理論上，->iomap_begin（） 情況是可能的，因為 XFS 可以叫用填充協助程式，並在之後的不同時間點出錯。這讓事情變得微妙複雜，因為 XFS 不會將iomap_flags傳輸到錯誤路徑中的 iomap 資料結構。若要處理這兩個問題，請先確保在任一 fs 回呼的錯誤路徑中叫用清理協助程式。其次，更新協助程式以無條件清除旗標，只要填入批次即可釋放批次。這更清楚地描述了標誌控制 I/O 路徑的目的，而不一定是 fbatch 的狀態，因此也在此周圍添加註釋。（CVE-2026-90384）

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

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

  - ksmbd：繫結的 smb_check_perm_dacl（） ACE 依 DACL 大小遍歷 smb_check_perm_dacl（） 會驗證 DACL 是否符合 NT 安全性描述元內，但接著會依剩餘的 NTSD 長度 （acl_size） 來限制其兩個 ACE 遍歷，而不是 DACL 宣告的大小 （pdacl_size）。當 pdacl->size 小於尾端 NTSD 緩衝區時，宣告的 DACL 界限之後的位元組 - 仍在預存的安全性描述元內
    - 在存取檢查期間剖析為 ACE。特製的 DACL 可以將授予存取權的 ACE 置於 pdacl->size 之外，且目前的程式碼會在 SMB2_CREATE 存取驗證期間接受它，而 parse_dacl（） 和 smb_inherit_dacl（） 會在 pdacl_size 停止。依pdacl_size綁定兩個 ACE 遍歷，以符合伺服器中其他位置使用的 DACL 界限語意。驗證： - 語意 KUnit 工具顯示在修正之前選取了邊界後 ACE，並在修正之後被拒絕 （EACCES） - linux master （7.2-rc6）、x86_64 （CVE-2026-90153）

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

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

  - amt：不支援跨網路設定。當較低的裝置被取消註冊時，amt_device_event（） 會嘗試取消註冊其較高的 AMT 裝置，但它有兩個問題。1. amt_lookup_upper_dev（） 僅在下層裝置的網路中查詢上層裝置 2.amt_device_event（） 只會取消註冊單一上層裝置 如果在另一個網路中的下層裝置上建立 AMT 裝置，移除下層裝置會觸發下方的 splat，並卡住，直到移除所有上層裝置為止。[0] 考慮到 1.以及以下幾點： * amt_link_setup（） 將 dev->netns_immutable 設定為 true * 快速路徑中未呼叫 skb_scrub_packet（） * iproute2 二進位檔無法透過 link-netns 找到 cross-netns 較低的裝置： # ip -n ns1 link add amt0 link-netns ns2 type amt dev veth1 找不到裝置 veth1 而不是正確支援它並為 per-netns netdev unreg 做準備， 讓我們禁止跨 netns 設定。請注意，問題 2.需要單獨修復。[0]： 警告：net/core/dev.c：12518 at unregister_netdevice_many_notify+0x1cce/0x2250， CPU#48： ip/2031 連結的模組： CPU： 48 UID： 0 PID：
    2031 Comm： ip 未受污染 7.2.0-rc5+ #27 PREEMPT（完整） 硬體名稱：QEMU Standard PC （i440FX + PIIX， 1996）， BIOS 1.17.0-debian-1.17.0-1 04/01/2014 RIP： 0010：unregister_netdevice_many_notify （net/core/dev.c：12518） 代碼： 89 EF E8 D5 52 ae fe e9 d0 f4 ff ff 48 8d 3d f9 3b 9c 02 48 c7 c6 c0 0b 63 84 ba ab 1f 00 00 67 48 0f b9 3a e9 65 ff ff ff 90 <0f> 0b 90 eb 81 48 8d 3d f6 3b 9c 02 48 c7 c6 c0 0b 63 84 ba e2 1f RSP：0018：ffffc90004abf160 EFLAGS：00010212 RAX：ffff888104d38260 RBX：ffff88800b0911b8 RCX：
    dffffc00000000000 RDX：0000000000000000000000 RSI：0000000000000008 RDI：ffffffff85b9f880 RBP：ffffc90004abf2d0 R08：ffffffff85b9f887 R09：1ffffffff0b73f10 R10：dffffc00000000000： R11fffffbfff0b73f11 R12：
    ffff88800b091d08 R13： ffff88800b091178 R14： dffffc0000000000 R15： ffff88800b091000 FS：
    00007f555b86c600（0000） GS：ffff8881942a0000（0000） knlGS：000000000000000000 CS：0010 DS：0000 ES：0000 CR0：
    0000000080050033 CR2：0000562107d489c0 CR3：0000000109a40002 CR4：0000000000372ef0 呼叫追蹤： <TASK> rtnl_dellink （net/core/rtnetlink.） c：3632 net/core/rtnetlink.c：3674） rtnetlink_rcv_msg （net/core/rtnetlink.c：7112） netlink_rcv_skb （net/netlink/af_netlink.c：2556） netlink_unicast （net/netlink/af_netlink.c：1319） netlink_sendmsg （net/netlink/af_netlink.c：1900） ____sys_sendmsg （net/socket.c：775） __sys_sendmsg （net/socket.c：2738） do_syscall_64 （arch/x86/entry/syscall_64.c：63）entry_SYSCALL_64_after_hwframe （arch/x86/entry/entry_64.S：121） ...unregister_netdevice：等待 veth0 變為自由。使用計數 = 7 ref_tracker：netdev@ffff88800d7496d8有 3/3 的使用者
    __netdev_adjacent_dev_insert （./include/linux/netdevice.h：4525 ./include/linux/netdevice.h：4554 net/core/dev.c：8791） __netdev_upper_dev_link （net/core/dev.c：8879 net/core/dev.c：8963） netdev_upper_dev_link （net/core/dev.c：9009） amt_newlink （drivers/net/amt.c：3321） （CVE-2026-90232）

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

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

  - crypto：rk3288 - HASH 閒置逾時上的雜湊請求失敗 rk_hash_run（） 等待RK_CRYPTO_HASH_STS在最終 DMA 傳輸後變成閒置狀態，但會忽略輪詢結果。如果雜湊引擎從未變成閒置狀態，驅動程式仍會讀取摘要暫存器，並以先前的成功值完成要求。儲存輪詢結果，並在讀取摘要暫存器之前完成具有逾時錯誤的要求。（CVE-2026-93156）

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

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

  - NFSv4.2：針對配置驅動程式寫入的 layoutupdate4 內文，修正 LAYOUTSTATS 傳送緩衝區耗盡encode_layoutstats_maxsz預算 XDR_QUADLEN（PNFS_LAYOUTSTATS_MAXSIZE），即 256 位元組。flexfiles 記錄可以超過此值。ff_layout_encode_ff_layoutupdate（） 會為每個資料伺服器發出一個 netaddr4、一個 nfs_fh4、兩個ff_io_latency4、一個 nfstime4 和一個布林值。檔案控制碼長度為 NFS_MAXFHSIZE 位元組的資料伺服器已經佔了其中的 132 個位元組，而這兩個ff_io_latency4各為 64 位元組，nfstime4 和布林值又增加了 144 個位元組，因此在對 netaddr4 進行編碼之前，本文會傳遞 256 個位元組。encode_layoutstats（） 另外會寫入 deviceID4 和 layoutupdate4 lou_type字，這兩個字都不是 巨集 考慮的。檔案控制碼和位址都是由伺服器透過 LAYOUTGET 和 GETDEVICEINFO 選擇的，因此它可以驅動編碼器通過傳送緩衝區的結尾。
    一旦發生這種情況，xdr_reserve_space（） 將傳回 NULL，並且兩個 ff_layout_encode_io_latency（） 呼叫在持有 dss_info->mirror->lock 的情況下運行，因此返回 NULL 會永久保留鎖定。將PNFS_LAYOUTSTATS_MAXSIZE提高到 384，讓記錄符合保留範圍。（CVE-2026-90103）

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

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

  - cxl/mbox：在空負載上中斷毒物清單迴圈 每次反覆運算時傳回 count == 0 且設定 CXL_POISON_FLAG_MORE 的裝置永遠不會nr_records前進，因此 max_errors 防護永遠不會跳閘，並且在持有 poison.mutex 時，do/while 會永遠迴圈。這會暫停 sysfs 觸發的掃描執行緒，並封鎖裝置上所有後續的有害操作。現有的 防止未清除
    _FLAG_MORE防護旨在綁定行為不當的裝置，但未涵蓋計數 == 0 情況。停止空白承載上的迴圈，讓故障或惡意裝置無法楔入有害掃描。
    (CVE-2026-93097)

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

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

  - PCI/sysfs：將鎖定檢查新增至舊版 I/O 和記憶體處理常式 目前，舊版 I/O 和記憶體 sysfs 處理常式不會檢查 security_locked_down（LOCKDOWN_PCI_ACCESS），因此在核心鎖定時，會使 legacy_io 和 legacy_mem 檔案不受保護。提交 eb627e17727e （PCI：鎖定核心時鎖定 BAR 存取） 將檢查新增至 pci_write_config（）、pci_mmap_resource（） 和 pci_write_resource_io（），以防止使用者空間對可用來修改核心程式碼的支援 DMA 的硬體進行程式設計，但未涵蓋舊版處理常式。因此，當核心被鎖定時，root 仍然可以寫入任意 I/O 連接埠並映射舊版 I/O 和記憶體空間，這與鎖定旨在刪除的功能相同。將相同的檢查新增至 pci_write_legacy_io（）、pci_mmap_legacy_mem（） 和 pci_mmap_legacy_io（）。這些泛型處理常式涵蓋定義HAVE_PCI_LEGACY的兩種架構 （例如 Alpha 和 PowerPC）。[bhelgaas：新增連結]（CVE-2026-90315）

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

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

  - iommu/tegra241-cmdqv：只有在 LVCMDQ 完全初始化之後，才發佈 tegra241_vintf_init_lvcmdq（） 會在 tegra241_vcmdq_alloc_smmu_cmdq（） 建置 vcmdq->cmdq 之前，將新配置的 vcmdq 指標儲存到 vintf->lvcmdqs[] 陣列。錯誤 ISR 會解除參照該 cmdq，因此在此視窗中觸發的閂鎖 LVCMDQ 錯誤 （例如，透過 kexec 繼承的錯誤） 會使 tegra241_vintf0_handle_error（） 將仍然歸零的arm_smmu_cmdq傳遞給 __arm_smmu_cmdq_skip_err（），從而取消參照 NULL 佇列暫存器指標。從 tegra241_vintf_init_lvcmdq（） 刪除儲存區，並在配置結束時發佈 vcmdq，並使用 smp_store_release（） 與 ISR 中的 smp_load_acquire（） 配對，這可以看到完全建置的 LVCMDQ 或 NULL。使用者擁有的 LVCMDQ 分配會相應地移動，一旦 tegra241_vcmdq_hw_init_user（） 成功，就會使用普通儲存區發布 vcmdq，因為使用者 VINTF 的 lvcmdqs[] 沒有無鎖定讀取器 -- 錯誤 ISR 僅遍歷 VINTF0 陣列。（CVE-2026-90430）

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

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

  - iommu/vt-d：拆除別名 domain_context_clear_one（） 和 device_pasid_table_teardown（） 時，使用正確的 SID 排清內容快取，每個裝置的 DMA 別名都會叫用一次。每個函式都會使用 pci_for_each_dma_alias（） 回呼提供的匯流排/devfn 配對來尋找內容項目，然後呼叫 intel_context_flush_no_pasid（），這會從 info->bus 和 info->devfn 建構裝置選擇性內容快取無效 （也就是說，一律是裝置本身的請求者 ID）。因此，對於裝置自己的 RID 以外的每個別名，剛在記憶體中清除的內容項目永遠不會在內容快取中失效。硬體可能會繼續使用該過時的快取項目。在可擴展模式的拆卸路徑中，intel_pasid_free_table（） 可以釋放該過時項目仍引用的 PASID 目錄，從而允許 IOMMU 遍歷釋放的記憶體。透過將要拆除的項目的來源 ID 傳遞給 intel_context_flush_no_pasid（） 而不是從 @info 派生來解決此問題。（CVE-2026-90240）

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

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

  - remoteproc：修正透過 rsc_table_for_each_entry（） 中帶正負號位移的 OOB 讀取 table->offset[i] 是韌體中的 u32，但儲存在帶正負號的 int 中。像 0xFFFFFFF0 這樣特製的偏移會變成 -16，將 hdr 放在表格緩衝區之前 16 位元組。後續的 avail 檢查被略過，因為在運算式 table_sz - offset - sizeof（*hdr） 中，負 int 被提升為大size_t，產生一個大的正 avail，並讓越界 hdr->type 讀取在未被偵測到的情況下繼續進行。將位移儲存為 u32，並在進行任何指標算術之前使用無符號比較來驗證它。（CVE-2026-90314）

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

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

  - wifi：MT76：修正處理 mt76_switch_vif_chanctx（） 中不同頻段的通道上下文 在短時間內在不同的無線電上執行通道切換時，每個結構ieee80211_vif_chanctx_switch都可以攜帶不同頻段的通道上下文。重構 mt76_switch_vif_chanctx（） 以正確處理此案例。（CVE-2026-90381）

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

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

  - i3c： master：針對主要控制器裝置解除參照 master->this sysfs 屬性回呼，修正 master->this 的釋放後使用。然而，master->this 在主裝置本身被釋放之前在 i3c_master_detach_free_devs（） 中被釋放。因此，sysfs 存取可能會取消參照釋放的 master->this 指標，進而導致釋放後使用。保持 master->this 處於活動狀態，直到 i3c_masterdev_release（） 為止，該 （） 是在主要裝置及其 sysfs 狀態被拆除後呼叫的。請勿將 master->this 釋放為一般裝置分離路徑的一部分。在 i3c_master_set_info（） 中的錯誤路徑上，在釋放分配的裝置之前，將 master->this 和 bus.cur_master 重設為 NULL。（CVE-2026-93200）

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

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

  - bpf， cgroup： 修正 __cgroup_bpf_attach 失敗後的無效儲存存取 更換 cgroup bpf prog 之後，可能會發生潛在的無效儲存存取問題。這發生在下列案例中： 1. 具有儲存裝置的 prog1 以多重連接模式連接至 cgroup。2. 在多重連接模式下使用 BPF_F_REPLACE 將 prog1 替換為 prog2，但中途失敗 （例如在 bpf_trampoline_link_cgroup_shim 或 update_effective_progs 中）。3. 在多重連接模式下，將新的 prog3 附加到 cgroup。原因是
    __cgroup_bpf_attach會在附件完成之前，以新的儲存體覆寫 pl->storage。當附件中途失敗時，清理路徑會呼叫 bpf_cgroup_storages_free（new_storage） 以釋放新配置的儲存體，但無法將 pl->storage 還原回old_storage。因此，仍然作用中的 prog1 保留無效或懸置的儲存指標，導致執行 prog1 並呼叫 prog1 時記憶體存取無效bpf_get_local_storage。此外，原始的 pl->flags 和 cgrp->bpf.flags[atype] 不會還原。透過在更新之前儲存 old_pl_flags、old_storage 和 old_flags，並在錯誤時將它們正確還原在清理路徑中來修正此問題。（CVE-2026-90313）

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

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

  - dax：在 dax_holder_notify_failure（） 中讀取一次holder_ops dax_holder_notify_failure（） 讀取 dax_dev->holder_ops 兩次，而不使用 READ_ONCE（） -- 一次用於 NULL 檢查，一次用於間接 notify_failure（） 呼叫。並行 fs_put_dax（） 可以清除兩次讀取之間的holder_ops，因此檢查可以在呼叫取消參照 NULL 時觀察到非 NULL 指標。（kill_dax（） 也會清除 holder_ops，但僅在 synchronize_srcu（） 之後，因此它無法爭用 dax_read_lock（） 內的讀取器;fs_put_dax（） 不會進行此類同步。使用 READ_ONCE（） 將holder_ops擷取到本地一次，以便 NULL 檢查和間接呼叫觀察到相同的值。（CVE-2026-93073）

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

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

  - platform/x86： lg-laptop： 修正 LED 資源處理 事件通知回呼即使未成功註冊至 LED 子系統，也可能會存取 kbd_backlight。同樣的情況也發生在 acpi_remove（） 內部，其中 LED 設備被無條件取消註冊。透過追蹤 kbd_backlight LED 裝置的可用性來修正此問題，並使用 devm_led_classdev_register（） 讓開發人員在移除期間負責取消註冊 LED 裝置。為此，LED 裝置的父裝置會變更為原生平台裝置。（CVE-2026-93128）

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

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

  - 韌體： arm_scmi：在回呼之前發佈通道狀態 傳輸設定可以在設定常式傳回之前啟用回呼。mailbox_chan_setup（） 會向 mbox_request_channel（） 註冊信箱用戶端，而信箱控制器啟動路徑可以在發佈 SCMI 信箱通道狀態之前啟用中斷傳遞。同樣地，smc_chan_setup（） 會在 SMC 傳輸使其 cinfo 指標可見之前，要求可選的 A2P 完成 IRQ。如果擱置中或虛假回呼在這些視窗中觸發，傳輸 RX 回呼可以取消參照 NULL 傳輸 cinfo 指標。僅發布傳輸私有指標也不夠：在 scmi_chan_setup（） 指派 cinfo->handle 之前，早期回呼可以進入 SCMI 核心。核心從 RX 路徑中的 cinfo->handle 衍生scmi_info，因此即使傳輸專用 cinfo 有效，NULL 控制碼仍可能出錯。在叫用傳輸設定回呼之前，請指派 cinfo->handle。在要求信箱通道或 IRQ 之前，先發佈信箱和 SMC 傳輸私人通道狀態，並在安裝失敗時再次清除早期發佈的指標。此外，在失敗時還原信箱設定 devres 資源，讓核心忽略的選擇性 RX 設定錯誤不會留下過時的傳輸狀態。（CVE-2026-93093）

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

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

  - wifi：MT76：MT7915：避免 mt7915_mcu_get_sta_nss 中的 nss 下溢 如果對等體的 VHT/HE MCS 映射沒有支援的空間流（所有欄位0x3），則迴圈將以 nss == 0 退出，並且函數返回 （u8）-1 （255），然後將其寫入韌體sta_rec_bf波束成形欄位中。將結果限制為 0。
    (CVE-2026-90372)

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

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

  - arm64： process：修正內容切換 MTE 僅限儲存區標籤檢查SCTLR_EL1。當使用者選擇加入MTE僅限存放區標籤檢查模式時，會設定TCSO0。然而，它不是SCTLR_USER_MASK的一部分，這意味著在上下文切換時我們永遠不會清除SCTLR_EL1。TCSO0，因此我們將該設定洩漏到另一個任務中。透過將 SCTLR_EL1_TCSO0_MASK 包含在 SCTLR_USER_MASK （CVE-2026-90094） 中來解決這個問題

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

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

  - blk-cgroup：修正原則啟用與 blkg 損毀之間的爭用 切換區塊裝置上的 IO 排程器時，blkcg_activate_policy（） 會為連接至佇列的所有 blkg 配置 blkg_policy_data （pd）。
    但是，blkcg_activate_policy（） 可能會與並行 blkcg 刪除爭用，從而導致釋放後使用和記憶體洩漏問題。釋放後使用發生在下列爭用中： T1 （blkcg_activate_policy）： - 成功為 blkg1 配置 pd （loop0->queue， blkcgA） - 無法為 blkg2 配置 pd （loop0->queue， blkcgB） - 進入 enomem 復原路徑以釋放 blkg1 資源 T2 （blkcg 刪除）： - blkcgA 會同時刪除 - blkg1 會透過 blkg_free_workfn（） 釋放 blkg1->pd - blkg1-pd 會釋放 T1 （續）： - 釋放 pd 後，復原路徑存取 blkg1->pd->online - 觸發釋放後使用 此外，blkg_free_workfn（） 會在從 q->blkg_list 移除 blkg 之前釋放 pd。這可讓 blkcg_activate_policy（） 為正在銷毀的 blkg 配置新的 pd，讓新配置的 pd 在最終釋放 blkg 時無法存取。透過擴展 blkcg_mutex 涵蓋範圍以序列化 blkcg_activate_policy（） 復原和 blkg 銷毀來修正這些爭用，確保 pd 生命週期與 blkg 清單可見性同步。（CVE-2026-90326）

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

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

  - octeontx2-af：修正重複 rvu_mbox_init（） 的 CN20K 信箱存留期 rvu_mbox_init（） 在探測期間針對 AF-PF 信箱和啟用 SR-IOV 時針對 AF-VF 信箱分別呼叫。每個呼叫都用來配置新的ng_rvu物件，當指標在第二次呼叫上被覆寫時，會洩漏第一個配置。在兩個路徑上共用一個ng_rvu會暴露幾個拆卸錯誤：錯誤路徑釋放了所有 cn20k 信箱 DMA 和 kfree（）d ng_rvu，即使只應展開失敗的 init 類型，也會在 AF-VF init 失敗後留下即時 AF-PF 信箱記憶體。mutex_init（） 也會在 AF-VF 路徑上重新執行，而 AF-PF 信箱處理常式仍可保留 rvu->mbox_lock。探查和 SR-IOV 故障路徑也沒有釋放 cn20k 信箱 DMA，因為清理僅發生在 rvu_remove（） 中。使用 devm_kzalloc（） 配置一次 ng_rvu、在同一區塊中初始化 mbox_lock、僅為失敗的 init 類型展開信箱記憶體，以及從探查和 pci_enable_sriov（） 錯誤路徑釋放 cn20k 信箱 DMA。（CVE-2026-90079）

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

ID	名稱	嚴重性
347774	Linux Distros 未修補弱點：CVE-2026-90426	medium
347773	Linux Distros 未修補弱點：CVE-2026-90370	medium
347772	Linux Distros 未修補弱點：CVE-2026-90402	high
347771	Linux Distros 未修補弱點：CVE-2026-90366	medium
347770	Linux Distros 未修補弱點：CVE-2026-90409	high
347769	Linux Distros 未修補弱點：CVE-2026-92489	critical
347768	Linux Distros 未修補弱點：CVE-2026-90115	medium
347767	Linux Distros 未修補弱點：CVE-2026-90371	high
347766	Linux Distros 未修補弱點：CVE-2026-93110	high
347765	Linux Distros 未修補弱點：CVE-2026-90434	medium
347764	Linux Distros 未修補弱點：CVE-2026-93144	high
347763	Linux Distros 未修補弱點：CVE-2026-90183	medium
347762	Linux Distros 未修補弱點：CVE-2026-90293	high
347761	Linux Distros 未修補弱點：CVE-2026-92511	high
347760	Linux Distros 未修補弱點：CVE-2026-90166	medium
347759	Linux Distros 未修補弱點：CVE-2026-90108	high
347758	Linux Distros 未修補弱點：CVE-2026-93130	medium
347757	Linux Distros 未修補弱點：CVE-2026-93063	high
347756	Linux Distros 未修補弱點：CVE-2026-90217	high
347755	Linux Distros 未修補弱點：CVE-2026-93170	high
347754	Linux Distros 未修補弱點：CVE-2026-90130	medium
347753	Linux Distros 未修補弱點：CVE-2026-90312	high
347752	Linux Distros 未修補弱點：CVE-2026-92525	high
347751	Linux Distros 未修補弱點：CVE-2026-90072	medium
347750	Linux Distros 未修補弱點：CVE-2026-90091	high
347749	Linux Distros 未修補弱點：CVE-2026-90106	high
347748	Linux Distros 未修補弱點：CVE-2026-90111	high
347747	Linux Distros 未修補弱點：CVE-2026-90416	high
347746	Linux Distros 未修補弱點：CVE-2026-93099	medium
347745	Linux Distros 未修補弱點：CVE-2026-90361	medium
347744	Linux Distros 未修補弱點：CVE-2026-90384	medium
347743	Linux Distros 未修補弱點：CVE-2026-90153	high
347742	Linux Distros 未修補弱點：CVE-2026-90232	medium
347741	Linux Distros 未修補弱點：CVE-2026-93156	medium
347740	Linux Distros 未修補弱點：CVE-2026-90103	high
347739	Linux Distros 未修補弱點：CVE-2026-93097	medium
347738	Linux Distros 未修補弱點：CVE-2026-90315	high
347737	Linux Distros 未修補弱點：CVE-2026-90430	medium
347736	Linux Distros 未修補弱點：CVE-2026-90240	high
347735	Linux Distros 未修補弱點：CVE-2026-90314	medium
347734	Linux Distros 未修補弱點：CVE-2026-90381	high
347733	Linux Distros 未修補弱點：CVE-2026-93200	high
347732	Linux Distros 未修補弱點：CVE-2026-90313	high
347731	Linux Distros 未修補弱點：CVE-2026-93073	medium
347730	Linux Distros 未修補弱點：CVE-2026-93128	high
347729	Linux Distros 未修補弱點：CVE-2026-93093	medium
347728	Linux Distros 未修補弱點：CVE-2026-90372	high
347727	Linux Distros 未修補弱點：CVE-2026-90094	medium
347726	Linux Distros 未修補弱點：CVE-2026-90326	high
347725	Linux Distros 未修補弱點：CVE-2026-90079	medium

偵測

Nessus 的 Misc. 系列

medium

medium

high

medium

high

critical

medium

high

high

medium

high

medium

high

high

medium

high

medium

high

high

high

medium

high

high

medium

high

high

high

high

medium

medium

medium

high

medium

medium

high

medium

high

medium

high

medium

high

high

high

medium

high

medium

high

medium

high

medium