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

  - KVM：arm64：vgic：處理中斷關聯性變更與停用 LPI 之間的爭用 如果發生下列情況，Hyunwoo Kim 會報告一些非常糟糕的爭用： - LPI-I 在 vcpu-B 的 AP 清單中擱置中 - vcpu-A 寫入 vcpu-B 的 RD 以停用其 LPI - vcpu-C 將 I 從 B 移至 C 如果最後兩個爭用足夠好，vgic_prune_ap_list（） 可以刪除 irq 和 AP 清單鎖定， 重新獲得它們，並且在此間隔內 IRQ 已被釋放。UAF 緊隨其後。修復有兩個： - 在刪除 irq 和 ap_list 鎖定之前，請參考 irq - 不要嘗試處理擱置位元的遷移：根據架構，不期望保留此狀態 這樣，我們就可以確定中斷仍然存在，並且我們可以安全地將其從 AP 清單中刪除，因為它在此階段沒有目標（除非觸發另一個中斷， 但那是另一回事了）。（CVE-2026-72288）

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

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

  - can： bcm：修正 bcm_rx_handler（） 中 rx_stamp/rx_ifindex 上的資料爭用 對於在所有介面上訂閱的 rx op （ifindex == 0），相同的 op 會在共用的 per-netns 萬用字元篩選器清單中註冊一次，因此 bcm_rx_handler（） 可以在不同的 CPU 上同時執行，以處理到達不同網路裝置的框架。
    op->rx_stamp 和 op->rx_ifindex 是在 bcm_rx_update_lock 之前編寫的，允許並發寫入器相互競爭 - 包括 32 位平台上 64 位rx_stamp的撕裂儲存。除了撕裂的儲存區之外，bcm_send_to_user（） 必須報告它正在傳遞其內容的同一框架的時間戳記/ifindex。因此，作業會與內容比較放在相同的不間斷bcm_rx_update_lock區段中。作為副作用，RTR 請求框架功能（永遠不會到達 bcm_send_to_user（））不再更新 rx_stamp/rx_ifindex，因為只有通知路徑需要它們。（CVE-2026-72117）

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

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

  - f2fs：修正 f2fs_balance_fs（gc_merge） 路徑中的潛在鎖死 當我們使用gc_merge掛載選項掛載裝置時，我們可能會遇到以下潛在鎖死： Kworker GC trehad 截斷器 - f2fs_write_cache_pages - f2fs_write_single_data_page - f2fs_do_write_data_page - folio_start_writeback --- 在對開本上設定回寫旗標 - f2fs_outplace_write_data： 內部 bio 快取中快取的對開本 - f2fs_balance_fs - wake_up（gc_thread）：喚醒 gc 執行緒以執行前台 GC - finish_wait（fggc_wq）：等待等候佇列
    ---等待 GC 執行緒完成工作 - truncate_inode_pages_range - __filemap_get_folio（， FGP_LOCK）
    ---鎖定對開本 - truncate_inode_partial_folio - folio_wait_writeback ---等待清除回寫 - do_garbage_collect - move_data_page - f2fs_get_lock_data_folio - 對開本上的鎖定 ---在對開本的鎖定上被封鎖 為了避免這種鎖死，讓我們呼叫以下函式GC_MERGE在 f2fs_balance_fs（） 路徑中提交快取的 bio，就像我們在NOGC_MERGE路徑中所做的那樣。- f2fs_submit_merged_write（sbi、DATA）;- f2fs_submit_all_merged_ipu_writes（SBI）;（CVE-2026-68459）

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

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

  - RDMA/irdma：將等候佇列和旗標替換為完成 驅動程式先前曾使用等候佇列以及明確的 request_done 旗標，但request_done周圍沒有適當的屏障。Gui-Dong Han <hanguidong02@gmail.com> 的早期補丁試圖通過添加缺少的內存屏障來解決這個問題。此修補程式不會新增屏障，而是將 waitqueue+flag 取代為完成，而完成就是為此目的而設計的。（CVE-2026-72494）

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

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

  - 已解決 Linux 核心中的下列弱點：ntfs: validate index block header more strictly Modify ntfs_index_block_inconsisent() to perform stricter validation of INDEX_HEADER geometry in INDX blocks, and update ntfs_lookup_inode_by_name() to use that function to validate INDX blocks.
    (CVE-2026-72206)

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

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

  - can： bcm：擴展資料和計時器更新的 bcm_tx_lock 使用 將現有 tx 操作的新 CAN 框架內容暫存到 kmalloc（） 的緩衝區中，並在那裡進行驗證，以反映 bcm_rx_setup（） 中已經使用的方法。在持有 op->bcm_tx_lock 時，僅將已驗證的資料複製到 op->frame 中，因此 bcm_can_tx（） 和 bcm_tx_timeout_handler（） 無法再觀察部分更新或未驗證的框架。
    從使用者空間複製 CAN 框架資料時，為 memcpy_from_msg（） 新增缺少的錯誤路徑。同時將 bcm_tx_setup（） 中的 kt_ival1/kt_ival2/ival1/ival2 更新移至 op->bcm_tx_lock 下，並在 bcm_tx_set_expiry（） 和 bcm_tx_timeout_handler（） 中的相同鎖定下讀取 kt_ival1/kt_ival2/count，從而關閉 32 位元平台上撕毀的 64 位元ktime_t讀取。（CVE-2026-72119）

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

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

  - ipmi：修正 i_ipmi_request（） 中的參照計數洩漏 當調用者向 i_ipmi_request（） 提供「supplied_recv」訊息時，該函數會增加使用者的「nr_msgs」參照計數。如果稍後發生錯誤，out_err清除路徑只會在函式自行配置時釋放recv_msg （即 ！supplied_recv）。在supplied_recv情況下，會略過清理，使參照計數升高。
    呼叫端 ipmi_request_supply_msgs（） 不會在錯誤時釋放supplied_recv，因此參照會永久洩漏。當錯誤路徑中存在具有有效使用者指標的recv_msg時，明確還原參照計數作業來修正此問題：遞減nr_msgs並刪除使用者的 kref。（CVE-2026-72040）

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

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

  - nvmet-auth：拒絕過短的 AUTH_RECEIVE 緩衝區。nvmet_execute_auth_receive() 在僅檢查 AUTH_RECEIVE 配置長度為非零且與傳輸長度相符後，便信任該長度。在 SUCCESS1 與 FAILURE1/預設狀態下，這會導致遠端 NVMe-oF 啟動器能以短於回應內容的 kmalloc() 緩衝區，進入固定大小的 DH-HMAC-CHAP 回應建構器，這使得 nvmet_auth_success1() 與 nvmet_auth_failure1() 發生越界寫入；這兩個函式僅對長度不足發出 WARN_ON 警告，隨後仍會格式化訊息。影響：具備已啟用驗證目標存取權限的遠端 NVMe-oF 啟動器，可透過 1 位元組的 AUTH_RECEIVE 配置長度，觸發 16 位元組的堆積越界寫入。在 nvmet_auth_receive_data_len() 中計算目前 DH-HMAC-CHAP 步驟所需的最小回應長度。當主機提供的配置長度過短時，報告資料長度為零，以便 nvmet_execute_auth_receive() 現有的零長度檢查能在任何建構器執行前拒絕該指令。SUCCESS1 的最小值為 sizeof(struct nvmf_auth_dhchap_success1_data) 加上 HMAC 雜湊長度，因為回應雜湊會寫入 rval[] 彈性陣列末端，因此最小值取決於狀態，而非固定的 sizeof 大小。
    CHALLENGE 則保留其在 nvmet_auth_challenge() 中現有的可變長度防護。此問題僅在目標端配置了頻帶內 DH-HMAC-CHAP 驗證時才會觸發。(CVE-2026-72130)

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

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

  - wifi： ath12k：修正 ath12k_wifi7_dp_rx_h_verify_tkip_mic（） 中的記憶體洩漏 在 ath12k_wifi7_dp_rx_h_verify_tkip_mic（） 中，當 NWIFI 標頭長度無效時，對 ath12k_dp_rx_check_nwifi_hdr_len_valid（） 的呼叫可能會傳回 false，導致函數以 -EINVAL 提前中止。發生這種情況時，錯誤會傳播到 ath12k_wifi7_dp_rx_h_defrag（），後者透過將其設定為 NULL 來清除first_frag。因此，重組路徑不再參考對應的 MSDU，而且永遠不會釋放。這會導致此錯誤路徑上受影響 MSDU 的記憶體流失。需要進行適當的清理，以確保在TKIP MIC驗證期間標頭驗證失敗時釋放MSDU。測試對象： WCN7850 hw2.0 PCI WLAN。HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 （CVE-2026-74368）

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

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

  - bpf：在 zap_pages（） zap_vma_range（） 中採取 mmap_lock 需要持有所屬 mm 的mmap_lock。在競技場>鎖定下進行mmap_read_lock將使 AB-BA 對抗 arena_vm_close（） 和 arena_map_mmap（），兩者都在持有 mmap_write_lock 的情況下運行，然後獲得競技場>鎖定。相反，刪除 arena->lock，mmget_not_zero（） vma 的 mm，獲取mmap_read_lock，然後通過 find_vma（） 重新解析 vma，因為它可能在等待期間已被取消映射或替換。在 vml->zap_gen 中使用每個呼叫產生來追蹤已處理的 vml，並使用新的 arena->zap_mutex 序列化 zap_pages（） 呼叫端，以便不同 uaddr 範圍內的並行呼叫端不會在 zap 完成之前標記彼此已處理的 vml。（CVE-2026-74354）

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

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

  - mtd： maps： vmu-flash：修正未對齊修正中的錯誤 使用 kzalloc_obj（） / kzalloc_objs（） 配置 memcard 結構，而不是 kmalloc_obj（） / kmalloc_objs（） 以防止存取未初始化的資料。修正執行階段錯誤：未對齊修正中的錯誤：mtd_get_fact_prot_info處的 0000 [#1]。（CVE-2026-72168）

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

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

  - flow_dissector：讀取前檢查裝置類型 ETH_ADDRS __skb_flow_dissect（） 在要求 FLOW_DISSECTOR_KEY_ETH_ADDRS 時無條件地從 eth_hdr （skb） 讀取 12 個位元組。這假設 skb 在 mac_header 處具有有效的乙太網路標頭，但情況並非總是如此。該問題可能由以下原因觸發： 1. 在 L3 模式下建立 TUN 裝置 （IFF_TUN， hard_header_len=0） 2.在 eth_src 3 上安裝帶有花卉濾波器的 multiq qdisc。透過 AF_PACKET 傳送封包 由於 L3 模式下的 TUN 沒有鏈路層標頭，因此 mac_header 指向 L3 資料區。正如 KMSAN 所報告的那樣，流剖析器讀取 12 位元組的未初始化 skb 內存，然後通過 fl_set_masked_key（） 傳播並用作 __fl_lookup（） 中的 rhashtable 查找鍵。拒絕控制路徑中的過濾器（在 tc 過濾器添加時）是不可行的，因為 TC 過濾器塊可以在任意設備之間共享——安裝在乙太網上的過濾器稍後可能會通過共享塊對無標頭設備上的封包進行分類。裝置關聯在篩選器建立時不會固定。透過在 dev->type == ARPHRD_ETHER 上控制 memcpy 來解決此問題，這可確保只有真正的乙太網路框架封包的位址才能被讀取。這比先前的 hard_header_len >= 12 檢查更精確，後者會錯誤地通過非乙太網路鏈路類型，例如 IPoIB （ARPHRD_INFINIBAND，hard_header_len=24） 和 FDDI （hard_header_len=21），其 L2 標頭不是乙太網路格式。另外檢查 skb_mac_header_was_set（） 以防止 mac_header 是未設定的哨兵 （~0U） 的病態情況，這會導致 eth_hdr（） 傳回野生指標。對於act_mirred重新導向情況（乙太網路封包重新導向到共用 TC 區塊的非乙太網路裝置），將金鑰歸零是正確的行為：封包現在在目標裝置上進行分類，其中乙太網路位址比對在語義上沒有意義。注意：在非乙太網路裝置上，歸零金鑰將與配置為全零 MAC 位址的篩選器相符。這是先前行為的改進，其中未初始化的記憶體可以隨機比對任何篩選器。（CVE-2026-72444）

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

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

  - rxrpc：序列化核心接受具有通訊端拆卸的預先分配 rxrpc_kernel_charge_accept（） 讀取 rx->backlog，無需任何通訊端/backlog 同步，並將該原始指標傳遞至 rxrpc_service_prealloc_one（）。並行 rxrpc_discard_prealloc（） 設定 rx->backlog = NULL 並釋放待辦專案環，因此核心預先配置工作角色可以在更新時繼續使用釋放的結構rxrpc_backlog
    *_backlog_head/尾部和陣列插槽。使用通訊端鎖定序列化狀態檢查和待辦專案查詢，並在拆卸停用接聽或捨棄服務待辦專案後拒絕核心預先配置。
    (CVE-2026-74436)

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

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

  - ALSA： seq： midi：使用 event_input event_process_midi（） 序列化輸出拆卸 借用 msynth->output_rfile.output，然後將子流傳遞給 dump_midi（） 和 snd_rawmidi_kernel_write（），而不與輸出開啟/關閉轉換同步。midisynth_use（） 也會在 snd_rawmidi_output_params（） 完成之前發布output_rfile。因此，最後一個 midisynth_unuse（） 可以在 snd_rawmidi_kernel_write1（） 獲取其運行時緩衝區引用之前釋放相同的 rawmidi 文件並釋放 substream->runtime。這會讓event_input路徑使用過時的子資料流或執行階段，並可能以 NULL 解除參照或釋放後使用結尾。使用兩個同步處理來修正此問題。保留簡短的 IRQ 安全微調鎖定，僅用於發佈或清除output_rfile，以及將輸出快照與snd_use_lock_t參照配對。
    一旦 event_process_midi（） 取得該進行中的參照，它會在呼叫 snd_seq_dump_var_event（） 、dump_midi（） 或 snd_rawmidi_kernel_write（） 之前刪除微調鎖定。midisynth_unuse（） 現在會在相同的微調鎖定下分離可見的 rawmidi 檔案，等候進行中的寫入器排空，然後才排空並釋放已儲存的檔案。midisynth_use（） 同樣會開啟到本機snd_rawmidi_file，只有在 snd_rawmidi_output_params（） 成功後才發布它。有錯誤的案例涉及兩條路徑，每欄顯示該路徑內的順序： event_input 路徑：上次未使用的路徑： 1. event_process_midi（） 快照 1.midisynth_unuse（） 啟動 output_rfile.output。拆output_rfile。2. dump_midi（） 達到 2.snd_rawmidi_kernel_release（） snd_rawmidi_kernel_write（） 關閉輸出檔案。在固定執行階段之前。3. close_substream（） 釋放 3.回呼會繼續使用 substream->runtime。借用的子流。驗證重現了以下核心報告：snd_rawmidi_kernel_write1+0x56/0x360 中的 KASAN null-ptr-deref RIP：0033：0x7fde7dd0837f RIP：
    0010：snd_rawmidi_kernel_write1+0x56/0x360 （CVE-2026-74387）

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

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

  - afs：修正 afs_break_some_callbacks（） 中缺少的 NULL 指標檢查 修正 afs_break_some_callbacks（） 以檢查 afs_lookup_volume_rcu（） 是否傳回 NULL （例如，指定的磁碟區未知）。（CVE-2026-72373）

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

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

  - md/raid1，raid10：使用 md_cloned_bio（） 修正錯誤路徑偵測 使用 md_cloned_bio（） 來偵測錯誤路徑，而不是依賴 raid1 中的 r1_bio 或 raid10 中的 r10_bio->read_slot，在分割並重新提交失敗的 bio 後，錯誤路徑可能為 NULL 或 -1。因此，可能無法識別錯誤路徑，並且記憶體配置可能會錯誤地使用 GFP_NOIO 而不是 （GFP_NOIO | __GFP_HIGH），從而導致記憶體壓力下發生鎖死。（CVE-2026-74374）

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

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

  - 輸入：ims-pcu - 修正 reset_device sysfs 回呼中的爭用情形 ims_pcu_reset_device（） sysfs 回呼呼叫 ims_pcu_execute_command（），而不取得 pcu->cmd_mutex。如果與其他命令同時觸發，可能會導致資料爭用和共用命令緩衝區損毀。在呼叫 ims_pcu_execute_command（） 之前取得 pcu->cmd_mutex。（CVE-2026-72075）

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

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

  - RDMA/rxe：修正 get_srq_wqe get_srq_wqe（） 從共用接收佇列緩衝區讀取 wqe->dma.num_sge 中的 TOCTOU 堆積溢位，該緩衝區已對應至使用者空間。它會根據max_sge驗證num_sge，但然後重新讀取相同的欄位以計算 memcpy 大小。並行使用者空間執行緒可能會修改驗證與使用之間的num_sge，從而在將 WQE 複製到 qp->resp.srq_wqe 時造成堆積緩衝區溢位。
    將num_sge讀取到局部變數中，並將其用於邊界檢查和大小計算。
    (CVE-2026-74378)

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

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

  - wifi： libertas_tf：修正 lbtf_free_adapter（） lbtf_free_adapter（） 呼叫 timer_delete（&priv->command_timer） 中的釋放後使用，它不會等待執行中的 command_timer_fn（） 回呼。
    lbtf_free_adapter（） 在 ieee80211_free_hw（） 釋放 priv 之前的拆卸路徑上執行，無論是在 lbtf_remove_card（） 中還是在探查錯誤路徑中。每當傳送韌體命令時，command_timer都會由 lbtf_cmd（） 中的 mod_timer（） 武裝。 command_timer_fn（） 解除參照 priv。如果命令在移除裝置時逾時，則 command_timer_fn（） 會在釋放裝置後與拆卸和解除參照 priv 同時執行。這與在同級 libertas 驅動程式中修正的提交 03cc8f90d053 （wifi： libertas：修正 lbs_free_adapter（） 中的釋放後使用） 相同。libertas_tf變體具有相同的模式，並且保持不變。使用 timer_delete_sync（），以便在釋放 priv 之前完成任何進行中的回呼。（CVE-2026-72070）

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

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

  - ASoC：編解碼器：hdac_hdmi：驗證寫入的列舉值 hdac_hdmi_set_pin_port_mux（） 會在呼叫 snd_soc_dapm_put_enum_double（） 之前，使用寫入的列舉值來編製文字陣列的索引，以驗證值是否在列舉項目範圍內。因此，超出範圍的值可讓驅動程式在協助程式拒絕寫入之前讀取文字陣列。在協助程式接受值之後移動查閱。
    (CVE-2026-74295)

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

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

  - 已解決 Linux 核心中的下列弱點：ntfs: not change 0-byte $DATA attribute to non-resident When ntfs_resident_attr_resize() cannot grow a resident attribute in place, it retries after converting other resident attributes to non-resident to free space in the MFT recrord. Do not select zero-length resident $DATA attributes for this conversion. fsck treats 0-byte non-resident $DATA attribute as corruptions. (CVE-2026-72207)

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

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

  - power： supply： core：修正 supplied_from 分配 如果 dts 屬性 power-supplies 有多個值，則存取 __power_supply_populate_supplied_from 中的 psy->supplied_from[i-1] 將使陣列supplied_from溢位。（CVE-2026-74271）

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

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

  - sockmap：修正 udp_bpf_recvmsg（） 中的釋放後使用，syzbot 報告 sk_msg_recvmsg（） 中結構sk_msg的釋放後使用。[0] sk_msg_recvmsg（） 從鎖定下的 psock->ingress_msg 中窺視sk_msg，但其處理是無鎖定的。因此，sk_msg_recvmsg（） 必須由調用方序列化，否則多個執行緒可能會接觸相同的sk_msg。例如，TCP 使用 lock_sock（），而 AF_UNIX 使用 unix_sk（sk）->iolock。
    最初，udp_bpf_recvmsg（） 使用 lock_sock（），但引用的提交將其刪除。讓我們使用 udp_bpf_recvmsg（） 中的 lock_sock（） 序列化 sk_msg_recvmsg（）。請注意，由於 sk_msg_recvmsg（） 中的 copy_page_to_iter（），因此不允許保留 spin_lock_bh（&sk->sk_receive_queue.lock）。
    [0]：錯誤：KASAN：sk_msg_recvmsg+0xb54/0xc30 net/core/skmsg.c：428 在 addr ffff88814cdcf000 由任務 syz.0.24/6020 讀取大小 4 CPU：1 UID：0 PID：6020 通訊：syz.0.24 未受污染的 syzkaller #0 PREEMPT（完整） 硬體名稱：Google Compute Engine/Google Compute Engine、BIOS Google 2026 年 1 月 13 日 呼叫追蹤： <TASK> dump_stack_lvl+0xe8/0x150 lib/dump_stack.c：120 print_address_description mm/kasan/report.c：378 [內嵌] print_report+0xba/0x230 mm/kasan/report.c：482 kasan_report+0x117/0x150 mm/kasan/report.c：595 sk_msg_recvmsg+0xb54/0xc30 net/core/skmsg.c：428 udp_bpf_recvmsg+0x4bd/0xe00 net/ipv4/udp_bpf.c：84 inet_recvmsg+0x260/0x270 net/ipv4/af_inet.c：891 sock_recvmsg_nosec net/socket.c：1078 [內嵌] sock_recvmsg+0x1a8/0x270 net/socket.c：1100 ____sys_recvmsg+0x1e6/0x4a0 net/socket.c：2812
    ___sys_recvmsg+0x215/0x590 net/socket.c：2854 do_recvmmsg+0x334/0x800 net/socket.c：2949 __sys_recvmmsg net/socket.c：3023 [內聯] __do_sys_recvmmsg net/socket.c：3046 [內聯] __se_sys_recvmmsg net/socket.c：3039 [內聯] __x64_sys_recvmmsg+0x198/0x250 net/socket.c：3039 do_syscall_x64 arch/x86/entry/syscall_64.c：63 [內聯] do_syscall_64+0xe2/0xf80 arch/x86/entry/syscall_64.c：94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP： 0033：0x7fb319f9aeb9 代碼：ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48 RSP： 002b：00007fb31ad97028 EFLAGS：00000246 ORIG_RAX：000000000000012b RAX：ffffffffffffffda RBX：00007fb31a216090 RCX：00007fb319f9aeb9 RDX：
    0000000000000001 RSI：0000200000000400 RDI：0000000000000004 RBP：00007fb31a008c1f R08：000000000000000000 R09：0000000000000000 R10：0000000040000021 R11：0000000000000246：0000000000000000：000000000000000000：0000000000000000：0000000000000：00000000000000：000000000000000：0000000000000000000000 R12：00000000000000000000：00000000000000000：00000000000000000000：000000000000000000000 R13：0000000000000000
    00007fb31a216128 R14： 00007fb31a216090 R15： 00007ffe21dd0a98 </TASK> 由任務 6019 分配：
    kasan_save_stack mm/kasan/common.c：57 [內嵌] kasan_save_track+0x3e/0x80 mm/kasan/common.c：78 poison_kmalloc_redzone mm/kasan/common.c：398 [內嵌] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c：415 kasan_kmalloc include/linux/kasan.h：263 [內嵌] __kmalloc_cache_noprof+0x3d1/0x6e0 mm/slub.c：5780 kmalloc_noprof include/linux/slab.h：957 [內嵌] kzalloc_noprof include/linux/slab.h：1094 [內嵌] alloc_sk_msg net/core/skmsg.c：510 [內嵌] sk_psock_skb_ingress_self+0x60/0x350 net/core/skmsg.c：612 sk_psock_verdict_apply net/core/skmsg.c：1038 [內嵌] sk_psock_verdict_recv+0x7d9/0x8d0 net/core/skmsg.c：1236 udp_read_skb+0x73e/0x7e0 net/ipv4/udp.c：2045 sk_psock_verdict_data_ready+0x12d/0x550 net/core/skmsg.c：1257 __udp_enqueue_schedule_skb+0xc54/0x10b0 net/ipv4/udp.c：1789 __udp_queue_rcv_skb net/ipv4/udp.c：2346 [內嵌] udp_queue_rcv_one_skb+0xac5/0x19c0 net/ipv4/udp.c：2475
    __udp4_lib_mcast_deliver+0xc06/0xcf0 net/ipv4/udp.c：2585 __udp4_lib_rcv+0x10f6/0x2620 net/ipv4/udp.c：2724 ip_protocol_deliver_rcu+0x282/0x440 net/ipv4/ip_input.c：207 ip_local_deliver_finish+0x3bb/0x6f0 net/ipv4/ip_input.c：241 NF_HOOK+0x336/0x3c0 include/linux/netfilter.h：318 dst_input include/net/dst.h：474 [內嵌] ip_sublist_rcv_finish+0x221/0x2a0 net/ipv4/ip_input.c：584 ip_list_rcv_finish net/ipv4/ip_inp
    ---truncated--- (CVE-2026-74257)

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

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

  - netfilter： nft_lookup：透過反向查詢修正 catchall 元素處理 nft_lookup_eval（） 決定查詢是否符合 （'found'） 來自直接集查詢和 priv->invert，然後再回退到開放式預設範圍的間隔集 （例如 nft_set_rbtree） 所使用的 catchall 元素。由於在 'ext' 被 catchall 查詢取代後，永遠不會重新計算 'found'，因此反向查詢 （NFT_LOOKUP_F_INV， ！= @set） 可能會錯誤地匹配或錯誤地跳過 catchall 元素，從而產生錯誤的判決。在計算 'found' 之前，將 catchall 查詢折疊成 'ext'，以符合 nft_objref_map_eval（） 已經使用的順序。（CVE-2026-72320）

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

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

  - netfilter： cttimeout：分離資料平面逾時原則並重新利用參照計數 新增 CT 延伸模組用來設定自訂 CT 逾時原則的結構nf_ct_timeout的參照計數，這會告訴我們 conntrack 項目正在使用 CT 逾時。當最後一個 conntrack 項目丟棄 ct 逾時的參照計數時，會釋放 ct 逾時。移除控制平面的參照計數，以控制規則集是否參照逾時原則。完成此更新後，可以立即從 nfnetlink_cttimeout 移除 ct 逾時原則。這是為了簡單起見，不要在單一物件上處理兩個參照計數。
    移除 nf_queue_nf_hook_drop（）：位於 nfqueue 中的封包將僅保留對 nf_ct_timeout 物件的引用，直到封包被重新插入，因為這是 ct 延伸模組的一部分，因此將在釋放 conntrack 時釋放。仍會呼叫 nf_ct_untimeout（） 以盡最大努力進行清理：當 CT 逾時消失時，現有項目上的 CT 逾時會被移除，但只要 iptables 規則集仍然透過範本參照 CT 逾時，新的 conntracks 可能會繼續附加它並延長其生命週期，直到規則被移除為止。不再從模組移除路徑呼叫 nf_ct_untimeout（），這不太可能發現逾時，因為模組參照計數被撞擊，並且新的參照計數已經追蹤了 CT 逾時策略的使用，因此在未使用時將其釋放。（CVE-2026-74347）

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

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

  - wifi： ath11k：在 PCI 關機期間取消 SSR 工作項目 如果重新開機與 WLAN 韌體損毀復原 （SSR） 重疊，則核心可能會當機。損毀是 MHI 拆卸路徑中的 NULL 指標解除參照，同時釋放 DMA 支援的 MHI 內容。簡化追蹤：dma_free_attrs mhi_deinit_dev_ctxt [mhi] ath11k_pci_power_down [ath11k_pci] ath11k_pci_shutdown [ath11k_pci] device_shutdown kernel_restart 在主機端，SSR 由 MHI RDDM 回呼驅動，該回呼將reset_work排入佇列以執行裝置復原。
    reset_work呼叫 ath11k_hif_power_down（） 後接 ath11k_hif_power_up（） 來重新啟動裝置。
    斷電階段會取消初始化 MHI 並釋放 DMA 資源。關機/重新開機會使用此 RDDM 驅動的 SSR 復原流程完全非同步執行。因此，關機路徑 （ath11k_pci_shutdown（） -> ath11k_pci_power_down（）） 可能會與 SSR 復原序列爭用。藉由在 PCI 關機期間取消 SSR 相關的工作項目、將裝置標示為取消註冊，以及序列化檢查和排入佇列reset_work的 RDDM 回呼路徑來修正此問題。如此可確保一旦拆卸開始，就不會將新的 SSR 復原工作排入佇列，而且任何進行中的復原工作都會在裝置斷電之前完全同步，從而防止 MHI 拆卸和 DMA 資源釋放多次執行。注意：此問題僅影響 PCI/MHI 型裝置。AHB 型 ath11k 裝置不會在正常 SSR 流量中將reset_work排入佇列。
    測試對象： WCN6855 hw2.1 PCI WLAN。HSP.1.1-04866.5-QCAHSPSWPL_V1_V2_SILICONZ_IOE-1 （CVE-2026-74407）

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

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

  - can： isotp：修正釋放後使用爭用，並行 NETDEV_UNREGISTER isotp_release（） 使用儲存的 ifindex 透過 dev_get_by_index（） 查詢綁定的網路裝置。在裝置取消註冊期間，在 NETDEV_UNREGISTER 通知程式鏈結執行之前，裝置會從 ifindex 雜湊中取消列出，因此並行 isotp_release（） 找不到任何裝置、完全跳過 can_rx_unregister（），但仍繼續釋放通訊端。由於 isotp_release（） 此時已經從 isotp 通知程式清單中移除了自己，因此 isotp_notify（） 也永遠沒有機會清理，留下一個過時的 CAN 過濾器，該過濾器一直指向釋放的通訊端。以與 raw.c 相同的方式修正此問題：從 bind（） 開始，在通訊端 （so->dev/so->dev_tracker） 中保留對綁定net_device的追蹤參照，而不是從 ifindex 重新解析它，並使用 rtnl_lock（） 序列化 bind（）/release（），以便 so->dev 始終與NETDEV_UNREGISTER通知程式看到的內容一致。無論 ifindex-hash 是否取消列出，so->dev 都保持有效，並且只有 isotp_release（）/isotp_notify（） 中哪個先到達那裡才能清除，因此過濾器總是被刪除一次。isotp_bind（） 現在拒絕與 -EAGAIN 的（重新）綁定，而 so->[tx|rx].state 尚未ISOTP_IDLE，因此先前NETDEV_UNREGISTER繼續運行的計時器無法對新綁定的 so->ifindex 採取行動。這兩項檢查共用相同的 lock_sock（） 區段，因此不會遺漏並行 isotp_notify（） 清除 so->bound 的視窗。（CVE-2026-72125）

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

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

  - EVM：終止並綁定 evm_xattrs 讀取緩衝區 evm_read_xattrs（） 分配大小 + 1 位元組，從已啟用的 xattr 清單中填充它們，然後將 strlen（temp） 傳遞給 simple_read_from_buffer（）。當未啟用任何已設定的 xattr 時，fill 迴圈不會儲存任何內容，且 temp[0] 會保持未初始化狀態，因此 strlen（） 會讀取超出初始化記憶體的記憶體。分配後明確終止緩衝區，對每個格式化行使用 snprintf（），並將累積長度傳遞給 simple_read_from_buffer（），而不會有截斷的風險。
    (CVE-2026-74399)

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

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

  - can： bcm：將 rx_op 解除分配推遲到工作佇列以修正 thrtimer UAF 提交 f1b4e32aca08 （can： bcm：使用 call_rcu（） 而不是昂貴的 synchronize_rcu（）） 用 call_rcu（） 取代 bcm_delete_rx_op（） 中的 synchronize_rcu（），並引入了 RX_NO_AUTOTIMER 標誌。但是，對於資料包 rx 快速路徑中的 thrtimer 省略了此旗標檢查。在 BCM RX 操作拆卸期間，並行 RCU 讀取器 （bcm_rx_handler） 可以在排程 call_rcu（） 後通過 bcm_rx_update_and_send（） 爭用和重新布防 thtimer。一旦 RCU 寬限期過後，bcm_op就會被釋放。隨後觸發的 thrtimer 接著取消參照解除配置的操作，導致 UAF。將旗標檢查新增至 rx 快速路徑 （bcm_rx_update_and_send） 並不會完全關閉 TOCTOU 爭用，並會為每個 CAN 幀引入延遲。相反，直接在 RCU 回調（softirq 上下文）內調用 hrtimer_cancel（） 是致命的，因為 hrtimer_cancel（） 可以休眠，從而在原子錯誤時觸發調度。藉由將計時器取消和記憶體釋放延遲至專用的未繫結工作佇列 （bcm_wq） 來解決此問題。RCU 回呼現在會將工作專案排入佇列以bcm_wq，這會安全地取消計時器，並在可休眠的進程內容中解除配置記憶體。專用的工作佇列用於防止全系統的 WQ 飽和，並在模組卸載時徹底排清/銷毀，以避免 rmmod 頁面錯誤。
    由於延遲的工作現在可以比呼叫上下文的壽命無限量，因此在分配 op->sk 時也獲取參照，並且僅在延遲工作取消了兩個計時器後才刪除它，因此通訊端無法再從仍然武裝的計時器下釋放，其回調 （bcm_send_to_user（）） 取消參照 op->sk。CVE-2026-72123

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

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

  - iomap：保護 EOF 修剪io_size防止並行截斷反向溢位 iomap：修正並行附加寫入中的零填充資料問題，變更了 ioend 帳戶，以便 io_size 僅追蹤 EOF 內的有效資料。當回寫範圍延伸超過end_pos時，這會io_size修剪：ioend->io_size += map_len;如果 （ioend->io_offset + ioend->io_size > end_pos） ioend->io_size = end_pos - ioend->io_offset;但是，如果end_pos最終低於 ioend->io_offset，則減法會變為負數並儲存在 size_t io_size 中，從而導致無符號包裝變成巨大的值。當回寫繼續超過位元組層級 EOF 直至區塊對齊範圍時，或在 iomap_writeback_handle_eof（） 中取樣end_pos之後，並行截斷縮小檔案時，可能會發生這種情況。包裝的 io_size 可能會誤導附加偵測並損毀完成時間大小處理，因為檔案系統end_io路徑會耗用io_size來做出磁碟上 EOF 更新和未寫入/COW 完成範圍等決策。當 EOF 移動到或之前移動到 ioend 起始偏移量時，將 io_size 限制為零來解決此問題。這保留了將io_size修剪為有效 EOF 內資料的原始意圖，同時避免了反向溢位。（CVE-2026-72367）

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

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

  - 藍牙：hci_core：修正 hci_unregister_dev（） 中的 UAF hci_unregister_dev（） 不會在釋放 hci_dev 結構之前停用 cmd_timer 和 ncmd_timer。如果在裝置拆卸期間觸發逾時，回呼會解除參照釋放的記憶體 （包括 hdev->reset 函式指標），導致釋放後使用。在現有的 disable_work_sync（） 呼叫旁邊新增 disable_delayed_work_sync（） 呼叫，以確保在拆卸繼續之前，兩個計時器都完全靜止。（CVE-2026-74302）

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

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

  - octeontx2-af： cn10k：將 VF LMTLINE 共用限制為自己的 PF rvu_mbox_handler_lmtst_tbl_setup（） 使用 req->base_pcifunc 作為 LMT 對映表的直接索引，以讀取另一個函式的 LMTLINE 實體基底位址，並將它複製到呼叫端自己的 LMT 對映表項目中。信箱分派器會驗證來自 IRQ 來源的 req->hdr.pcifunc，但 req->base_pcifunc 是個別的承載欄位，且未清理。當 VF 呼叫端的 base_pcifunc 不是其自己的 PF 下的有效函式時，使用 -EPERM 拒絕要求。 is_pf_func_valid（） 將 FUNC 欄位繫結至 PF 已設定的 VF 計數，將計算的索引保留在呼叫端自己的插槽區塊內。（CVE-2026-72045）

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

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

  - net： ip6_tunnel：需要在裝置 netns 中CAP_NET_ADMIN，以便 changelink ip6_tnl_changelink（） 最多在兩個 netn 上運作，即 dev_net（dev） 和通道連結 netns t->net。一旦裝置在執行要求的 netns 中建立或移動至 netns 以外的 netns，它們就會有所不同。rtnl changelink 路徑僅針對 dev_net（dev） 檢查CAP_NET_ADMIN，因此在 t->net 中具有權限但不在 t-net 中的呼叫者可以重寫位於 t->net 中的隧道。在剖析任何屬性之前，在其頂端的 rtnl_dev_link_net_capable（） 上閘道 ip6_tnl_changelink（）。（CVE-2026-72051）

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

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

  - bnxt：修正 XDP head-grow 上的磁頭反向溢位 xdp.py 測試test_xdp_native_adjst_head_grow_data在 bnxt 機器上執行時當機 （在 NIPA 中也會當機）。似乎該錯誤是 bnxt_rx_multi_page_skb 中的下溢，它構建了 skb 頭：napi_build_skb（data_ptr - bp->rx_offset、rxr->rx_page_size）;這個運算式的問題在於，在頁面模式下，rx_offset為：bp->rx_offset = NET_IP_ALIGN + XDP_PACKET_HEADROOM;評估（至少在 x86_64 上）為 258。測試test_xdp_native_adjst_head_grow_data測試頭部調整 -256 的情況。執行此測試時，data_ptr會移位至 frag_start + 2 （其中 frag_start = page_address（頁面） + 位移）。然後，叫用 bnxt_rx_multi_page_skb 並減去 napi_build_skb 運算式 258，在 frag_start 之前到達位址。當位移量< 256 時，這可以是上一個片段或上一個實體頁面 （例如，如果片段從位移 0 開始）。釋放 skb 時，頁面集區片段參照會卸除在正確頁面的錯誤頁面或錯誤片段上。無論哪種情況，損毀的參照計數都可能導致頁面在仍在使用時過早回收。一旦（錯誤地）回收，它可以再次分發，在驅動程序拆卸時，這將導致雙重釋放。修正中的提交更新了此程式碼，以處理原生頁面大小為 >= 64k 的情況，但它無意中破壞了頭部成長案例。若要修正此問題，請將偏移欄位新增至結構bnxt_sw_rx_bd，鏡像結構bnxt_sw_rx_agg_bd中現有的偏移欄位。在分配時填入它，並在重複使用時保留它。在bnxt_rx_multi_page_skb中，使用新新增的偏移欄位來計算片段起始點，並將其傳遞給napi_build_skb。使用skb_reserve調整版面配置。有兩種情況，非調整情況和調整情況。在這兩種情況下，skb 都是以 page_address（page） + offset 建置，以說明原生頁面大小 >= 64K，而 skb_reserve 是以 data_ptr - （page_address（page） + offset） 呼叫的情況。該差異等於未移動data_ptr時的 bp->rx_offset，或 XDP 調整頭部時的 bp->rx_offset + xdp_adjust。套用此認可後重新執行失敗的測試會導致測試成功執行並完成。其他rx_skb_func實作沒有此問題。（CVE-2026-74269）

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

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

  - RDMA/bnxt_re：避免重複要求配置 WC 頁面 應用程式可以針對相同的 ucontext 要求多個 WC 頁面。截至目前，每個 ucontext 僅支援 1 個 WC 頁面。新增鎖定以避免並行存取，並新增檢查以失敗重複的要求。此外，如果 WC 的 mmap 項目插入失敗，請釋放針對 WC 頁面對應的 Doorbell 頁面索引。（CVE-2026-72495）

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

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

  - net： macb：關閉時掉落飛行中的 Tx SKB MACB 驅動程式從那時起就永遠洩漏了尚未標記為完成的傳出 SKB。他們生活在排隊>tx_skb中，毫無悔意或檢查地被釋放。macb_free_consistent（） 會在幾個程式碼路徑中呼叫，但只有 close 才會觸發新增的運算式。在 macb_open（） 和 macb_alloc_consistent（） 失敗的情況下，佇列的tx_skb剛剛分配並且是空的。（CVE-2026-72017）

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

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

  - irqchip/ts4800：修正移除時缺少的鏈結處理常式清除 驅動程式會在使用 irq_set_chained_handler_and_data（） 探查期間為父中斷安裝鏈結處理常式，但 remove 函式不會清除此處理常式。這會留下一個懸空處理常式，當父中斷在移除驅動程式之後觸發時，可能會呼叫該處理常式，可能會存取釋放的記憶體並導致核心損毀。
    此外，透過 irq_of_parse_and_map（） 取得的parent_irq不會被儲存，因此無法在 remove 函式中存取。此外，在探測期間建立的中斷對應未正確處置。透過以下方式解決此問題： - 在探測中儲存parent_irq - 清除 ts4800_ic_remove（） 中帶有 NULL 的鏈結處理常式 - 在移除網域之前處置所有 IRQ 對應以防止資源洩漏 （CVE-2026-72384）

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

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

  - remoteproc：qcom：在將區域新增到 'dump_segments' 之前，修正自訂dump_segments新增失敗時在 qcom_add_minidump_segments（） 中釋放分配minidump_region 'name' 時的洩漏。否則，「名稱」不會被追蹤，並且永遠不會被 qcom_minidump_cleanup（） 釋放。新增到 'dump_segments' 時傳回錯誤失敗。（CVE-2026-72216）

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

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

  - ata：libata-core：拒絕無效的並行定位範圍計數 ata_dev_config_cpr（） 從並行定位範圍日誌的 buf[0] 中獲取範圍描述符的數量（最多 255 個），設備報告這些描述符與 GPL 目錄中的日誌大小無關。然後，計數在兩個無邊界的地方以固定的 32 位元組步幅行走：此處讀取的日誌，以及 INQUIRY VPD 頁面 B9h 發射器，它將每個範圍一個描述元寫入固定的 2048 位元組ata_scsi_rbuf中。報告計數大於其自身記錄的裝置會使讀取緩衝區溢位 （超過 512 位元組的 slab 最多 7704 位元組），而超過 62 的計數會使發射端的回應緩衝區溢位。在探測時，針對裝置傳回的日誌和 VPD B9h 回應緩衝區可以保留的描述元數量（ATA_DEV_MAX_CPR，衍生自 rbuf 大小）綁定計數一次。拒絕超出範圍的計數並顯示警告;這會將發射器保持在邊界內，沒有單獨的變更。（CVE-2026-72030）

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

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

  - cxl/region：在區域建立期間封鎖區域刪除 展開範圍鎖定，將其重新命名為 regions_lock，以在 construct_region（） 和 attach_target（） 之間的關鍵期間，以及 device_add（） 和註冊移除動作之間的期間內停用區域刪除。否則，使用者空間可能會混淆核心。這可能會違反區域在完成 cxl_add_to_region（） 後仍保持註冊狀態的假設。這可能會違反 devm_add_action_or_reset（） 正在使用即時「結構cxl_region」的假設。該區域消失在這些窗口之外是可以的，因為它反映了保持適當鎖的設備熱插拔流。（CVE-2026-74273）

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

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

  - md/raid5：中斷等量批次時避免R5_Overlap爭用 KCSAN 在 sh->dev[i].flags 上報告 break_stripe_batch_list（） 與 raid5_make_request（） 中的爭用 （純文字寫入與原子位元 op）。和 ..一種可能的情況是： CPU1 CPU2 break_stripe_batch_list（sh1） -> handle sh2 -> lock（sh2）
    -> sh2->batch_head = NULL -> unlock（sh2） -> test_and_clear_bit（R5_Overlap， sh2->dev[i].flags） -> wake_up_bit（sh2->dev[i].flags） raid5_make_request（） -> add_all_stripe_bios（sh2） -> lock（sh2） -> stripe_bio_overlaps（sh2） 傳回 true batch_head為 NULL，因此 sh2 上存在新的 bio 重疊 bio -> true -> set_bit（R5_Overlap， sh2->dev[i].flags） -> unlock（sh2） -> wait_on_bit（sh2->dev[i].flags） -> sh2->dev[i].flags = sh1->dev[i].flags &; ~R5_Overlap 沒有 wait_up_bit（），CPU2 可以永遠wait_on_bit（）... 修正方式： - 擴大保護區域。- 未保留 head_sh->stripe_lock 時，使用 batch_head 裝置旗標的 snaphot。- 將 sh/head_sh->batch_head = NULL 移至受保護區域的末尾，並且 現在任何並發的 add_all_stripe_bios（） 都會抓取 sh->stripe_lock： - 參見 batch_head ！= null，並且 被鎖定下的 stripe_bio_overlaps（） 拒絕 （無R5_Overlap等待） ，或 ， - 只有在 dev[i].flags 已經設定並且先前的 R5_Overlap 等候程式工作之後，才會看到 batch_head == NULL。KCSAN 報告：
    ================================================錯誤：KCSAN：CPU 0 上的任務 4042 對 break_stripe_batch_list / raid5_make_request 寫入 （標記） 到 8 位元組0xffff8e89c8117548的資料爭用：
    raid5_make_request+0xea0/0x2930 md_handle_request+0x4a2/0xa40 md_submit_bio+0x109/0x1a0
    __submit_bio+0x2ec/0x390 submit_bio_noacct_nocheck+0x457/0x710 submit_bio_noacct+0x2a7/0xc20 submit_bio+0x56/0x250 blkdev_direct_IO+0x54c/0xda0 blkdev_write_iter+0x38f/0x570 aio_write+0x22b/0x490 io_submit_one+0xa51/0xf70 __x64_sys_io_submit+0xf7/0x220 x64_sys_call+0x1907/0x1c60 do_syscall_64+0x130/0x570 entry_SYSCALL_64_after_hwframe+0x76/0x7e CPU 5 上的任務 4010 讀取到 8 位元組0xffff8e89c8117548： break_stripe_batch_list+0x249/0x480 handle_stripe_clean_event+0x720/0x9b0 handle_stripe+0x32fb/0x4500 handle_active_stripes.isra.0+0x6e0/0xa50 raid5d+0x7e0/0xba0 md_thread+0x15a/0x2d0 kthread+0x1e3/0x220 ret_from_fork+0x37a/0x410 ret_from_fork_asm+0x1a/0x30 值已變更： 0x0000000000000019 -> 0x0000000000000099 --> R5_Overlap （CVE-2026-72420）

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

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

  - ocfs2：修正 ocfs2_sum_rightmost_rec 中的 UBSAN array-index-out-of-bounds [錯誤] 磁碟損毀設定在 inode 的內嵌範圍清單中l_next_free_rec為 0，會在下次寫入該檔案時觸發 UBSAN 錯誤。[CAUSE] ocfs2_sum_rightmost_rec（） 計算 i = le16_to_cpu（el->l_next_free_rec） - 1 並存取 el->l_recs[i]，而不驗證 i。當 l_next_free_rec 為 0 時，i 變為 -1;當 l_next_free_rec 超過 l_count 時，I 會越過數組的末尾。任一情況都會違反 __counted_by_le（l_count） 註 l_recs[] 解，並觸發 UBSAN。[修復]在 ocfs2_validate_inode_block（） 中讀取 inode 時驗證 inode 的內嵌範圍清單：l_count 必須為非零且不大於 inode 區塊可以容納的範圍，並且l_next_free_rec不得超過 l_count。損毀的清單會在讀取時被拒絕，然後 b-tree 程式碼才能越界索引 l_recs[] 。（CVE-2026-72162）

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

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

  - ksmbd：在剖析 ACE 之前拒絕大小過小的 DACL parse_dacl（） 會將攻擊者控制的 ACE 計數與符合 DACL 大小的最小 ACE 數目進行比較，以限制攻擊者控制的 ACE 計數。DACL 大小欄位為 16 位，但運算式會減去 sizeof（struct smb_acl）。因為 sizeof（） 是未簽署的，所以小於 ACL 標頭的 DACL 大小會反向溢位至大型size_t。惡意用戶端可以透過以下方式達到此目的： SMB2_SET_INFO （InfoType=SMB2_O_INFO_SECURITY） -> smb2_set_info_sec（） -> set_info_sec（） -> parse_sec_desc（） -> parse_dacl（） -> init_acl_state（...， 0xffff） -> init_acl_state（...， 0xffff） -> kmalloc_objs（...， 0xffff） 因此，格式錯誤的安全描述元可能會使num_aces通過防護並驅動大型臨時 ACL 狀態和指標陣列配置。在執行減法之前，請拒絕小於結構smb_acl的 DACL，因此反向溢位無法繞過 ACE 計數檢查。（CVE-2026-72382）

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

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

  - macsec：不要讀取 macsec_encrypt（） 中未設定的 MAC 標頭 macsec_encrypt（） 透過 eth_hdr（skb） （skb->head + skb->mac_header） 讀取乙太網路標頭，以 memmove（） 轉發 12 個來源/目標 MAC 位元組，並為 SecTAG 騰出空間。在 AF_PACKET SOCK_RAW + PACKET_QDISC_BYPASS 傳輸路徑上，skb 在未設定 MAC 標頭的情況下到達 macsec ndo_start_xmit（），因此 eth_hdr（skb） 解析為 skb->head + （u16）~0，並且讀取越界：一個 12 位元組的堆積過度讀取，也作為幀的外部來源/目標 MAC 在網路上發出。KASAN 在 macsec_start_xmit（） 上 6.0報告 slab-out-of-bounds 讀取;在當前主線上，CONFIG_DEBUG_NET 組建在 skb_mac_header（） 中將其標記為未設定的 mac 標頭。在 TX 路徑上，L2 標頭位於 skb->data，因此請使用由提交 96cc4b69581d 新增的 skb_eth_hdr（） （macvlan：不要假設在 macvlan_broadcast（）） 中設定了 mac_header 來達到此目的。（CVE-2026-72019）

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

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

  - ASoC：mediatek：mt8192：在探測 MT8192 期間檢查執行階段回復 AFE 探查在從硬體重新起始設定 regmap 快取時，暫時啟用執行時期 PM，但它使用 pm_runtime_get_sync（） 而不檢查回覆值。如果執行階段繼續失敗，探測會繼續進行，而裝置不一定可存取，而且 pm_runtime_get_sync（） 可能會讓 PM 使用計數遞增。regmap_reinit_cache（） 失敗路徑也會在捨棄暫時 PM 參照之前和清除pm_runtime_bypass_reg_ctl之前傳回。請使用 pm_runtime_resume_and_get（） ，以便還原失敗不會洩漏使用計數，並在卸除所有 regmap_reinit_cache （） 結果上的探查 PM 參照之後，清除暫時繞過旗標。（CVE-2026-72260）

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

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

  - sctp：修正 sctp_free_addr_wq（） sctp_free_addr_wq（） 中的爭用addr_wq_timer先前在按住 addr_wq_lock 時使用 timer_delete（） addr_wq_timer移除的爭用。不過，timer_delete（） 並不能保證目前執行中的計時器處理常式已完成。這允許與 sctp_addr_wq_timeout_handler（） 爭用，其中處理常式在釋放addr_waitq後仍可能運行，獲取addr_wq_lock並存取釋放的內存，從而導致釋放後使用。在進行addr_wq_lock之前呼叫 timer_shutdown_sync（） 來解決此問題。
    這可確保任何進行中的計時器處理程序都已完成，並防止計時器在拆卸期間重新武裝，從而確保後續清理安全。（CVE-2026-72383）

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

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

  - fs/resctrl：修正將虛擬鎖定區域的 RMID 雙重新增至釋放清單虛擬鎖定群組的 RMID 在建立時被釋放。卸載時，rmdir_all_sub（） 會無條件釋放所有群組的所有 RMID，導致虛擬鎖定群組的 RMID 雙重釋放。這樣做的結果是，原始釋放會導致虛擬鎖定群組的 RMID 新增至rmid_free_lru鏈結清單，然後第二個釋放會再次嘗試將相同的 RMID 項目新增至rmid_free_lru。不要雙重釋放虛擬鎖定群組的 RMID。（CVE-2026-72015）

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

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

  - KVM：x86：如果 vCPU 已停用 PV EOI，則忽略擱置中的 PV EOI 如果 vCPU 自提出要求以來已停用 PV EOI，則略過 KVM 的內部服務擱置 PV EOI 要求。如果讀取 pv_eoi_get_user（） 中的客體記憶體失敗，即如果 pv_eoi_test_and_clr_pending（） 提前結束，*並且* vCPU 也會停用 PV EOI，則宣告啟用 PV EOI 可能會失敗。位於 arch/x86/kvm/lapic.c：3338 的核心錯誤！哎呀：無效的操作碼：0000 [#1] SMP CPU：4 UID：1000 PID：890 通訊：pv_eoi_test 未受污染 7.0.0-d585aa5894d8-vm #337 搶佔 硬體名稱：QEMU 標準 PC （Q35 + ICH9， 2009），BIOS 0.0.0 02/06/2015 RIP：0010：kvm_lapic_sync_from_vapic+0x12b/0x140 [kvm] 呼叫追蹤： <TASK> kvm_arch_vcpu_ioctl_run+0x1075/0x1c30 [kvm] kvm_vcpu_ioctl+0x2d5/0x980 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0xb5/0xb40 entry_SYSCALL_64_after_hwframe+0x4b/0x53 </TASK> 連結於：kvm_intel kvm irqbypass ---[ end trace 000000000000000000 ]--- （CVE-2026-72284）

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

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

  - OPP： 修正 OPP 新增和查詢之間的爭用 dev_pm_opp_add_dynamic（） 和 dev_pm_opp_find_freq_exact（） 之間存在爭用： CPU0 （新增） CPU1 （查詢） -------------------------------
    ------------------------------ _opp_add（） mutex_lock（） list_add（&new_opp->node， head） mutex_unlock（）
    _opp_table_find_key（） mutex_lock（） dev_pm_opp_get（opp） kref_get（） mutex_unlock（） kref_init（&new_opp->kref） dev_pm_opp_put（） kref_put_mutex（） 新加入的 OPP 會在初始化其 kref 之前插入清單中。並行查詢可以找到此 OPP 並在其尚未初始化時增加其參照計數，從而導致參照計數損毀和潛在的過早釋放。透過初始化來修正此問題
    ->kref 和 ->opp_table，然後再透過 list_add（） 使 OPP 可見。這可確保任何並行查詢都會觀察到完全初始化的物件。[ Viresh：更新提交日誌 ]（CVE-2026-74405）

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

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

  - gpio：tegra：不要針對 GPIO 方向呼叫 pinctrl tegra_gpio_direction_input（） 和 tegra_gpio_direction_output（） 已經直接對 GPIO 控制器方向暫存器進行程式設計。額外的 pinctrl_gpio_direction_input/output（） 呼叫不會新增 Tegra pinctrl 操作，因為 Tegra pinmux 操作提供 GPIO 請求/自由處理，但沒有gpio_set_direction鉤子。額外的呼叫仍會進入 pinctrl 核心並採用 pctldev->mutex。共用 GPIO 使用者可以在保留其每行微調鎖定時呼叫方向路徑，因此此備援 pinctrl 方向呼叫可以在不可部分完成內容中休眠。這是由我們的靜態分析工具發現的，然後通過手動審查 tegra_gpio_probe（）、Tegra GPIO 方向回調和 Tegra pinctrl 操作來確認。檢閱的路徑具有預設的非休眠結構gpio_chip，而方向回呼仍會進入 pinctrl 互斥路徑。定向運行時間驗證保持相同的非休眠芯片註冊並驅動：
    gpio_shared_proxy_direction_output（） gpiod_direction_output_raw_commit（） tegra_gpio_direction_output（） pinctrl_gpio_direction_output（） Lockdep 在保留共用 GPIO 微調鎖定且堆疊上 pinctrl_get_device_gpio_range（） 加上 tegra_gpio_direction_output（） 的情況下，報告原子睡眠警告。不要將整個晶片標記為can_sleep以覆蓋這一點：can_sleep描述 get（）/set（） 是否可以休眠，並且 Tegra 值存取是 MMIO。移除多餘的 pinctrl 方向呼叫，並將 pinctrl 參與現有要求/自由路徑中。（CVE-2026-72063）

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

ID	名稱	嚴重性
335686	Linux Distros 未修補弱點：CVE-2026-72288	critical
335685	Linux Distros 未修補弱點：CVE-2026-72117	medium
335684	Linux Distros 未修補弱點：CVE-2026-68459	medium
335683	Linux Distros 未修補弱點：CVE-2026-72494	critical
335682	Linux Distros 未修補弱點：CVE-2026-72206	critical
335681	Linux Distros 未修補弱點：CVE-2026-72119	high
335680	Linux Distros 未修補弱點：CVE-2026-72040	high
335679	Linux Distros 未修補弱點：CVE-2026-72130	critical
335678	Linux Distros 未修補弱點：CVE-2026-74368	medium
335677	Linux Distros 未修補弱點：CVE-2026-74354	high
335676	Linux Distros 未修補弱點：CVE-2026-72168	medium
335675	Linux Distros 未修補弱點：CVE-2026-72444	high
335674	Linux Distros 未修補弱點：CVE-2026-74436	critical
335673	Linux Distros 未修補弱點：CVE-2026-74387	high
335672	Linux Distros 未修補弱點：CVE-2026-72373	high
335671	Linux Distros 未修補弱點：CVE-2026-74374	high
335670	Linux Distros 未修補弱點：CVE-2026-72075	high
335669	Linux Distros 未修補弱點：CVE-2026-74378	high
335668	Linux Distros 未修補弱點：CVE-2026-72070	high
335667	Linux Distros 未修補弱點：CVE-2026-74295	high
335666	Linux Distros 未修補弱點：CVE-2026-72207	critical
335665	Linux Distros 未修補弱點：CVE-2026-74271	high
335664	Linux Distros 未修補弱點：CVE-2026-74257	high
335663	Linux Distros 未修補弱點：CVE-2026-72320	critical
335662	Linux Distros 未修補弱點：CVE-2026-74347	high
335661	Linux Distros 未修補弱點：CVE-2026-74407	high
335660	Linux Distros 未修補弱點：CVE-2026-72125	high
335659	Linux Distros 未修補弱點：CVE-2026-74399	high
335658	Linux Distros 未修補弱點：CVE-2026-72123	high
335657	Linux Distros 未修補弱點：CVE-2026-72367	high
335656	Linux Distros 未修補弱點：CVE-2026-74302	high
335655	Linux Distros 未修補弱點：CVE-2026-72045	high
335654	Linux Distros 未修補弱點：CVE-2026-72051	high
335653	Linux Distros 未修補弱點：CVE-2026-74269	critical
335652	Linux Distros 未修補弱點：CVE-2026-72495	critical
335651	Linux Distros 未修補弱點：CVE-2026-72017	medium
335650	Linux Distros 未修補弱點：CVE-2026-72384	medium
335649	Linux Distros 未修補弱點：CVE-2026-72216	high
335648	Linux Distros 未修補弱點：CVE-2026-72030	high
335647	Linux Distros 未修補弱點：CVE-2026-74273	high
335646	Linux Distros 未修補弱點：CVE-2026-72420	high
335645	Linux Distros 未修補弱點：CVE-2026-72162	high
335644	Linux Distros 未修補弱點：CVE-2026-72382	high
335643	Linux Distros 未修補弱點：CVE-2026-72019	high
335642	Linux Distros 未修補弱點：CVE-2026-72260	medium
335641	Linux Distros 未修補弱點：CVE-2026-72383	high
335640	Linux Distros 未修補弱點：CVE-2026-72015	high
335639	Linux Distros 未修補弱點：CVE-2026-72284	high
335638	Linux Distros 未修補弱點：CVE-2026-74405	high
335637	Linux Distros 未修補弱點：CVE-2026-72063	high

偵測

Nessus 的 Misc. 系列

critical

medium

medium

critical

critical

high

high

critical

medium

high

medium

high

critical

high

high

high

high

high

high

high

critical

high

high

critical

high

high

high

high

high

high

high

high

high

critical

critical

medium

medium

high

high

high

high

high

high

high

medium

high

high

high

high

high