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

  - can： isotp：序列化 so->rx_lock 下的 TX 狀態轉換 TX 狀態機器 （so->tx.state） 由三個上下文驅動：sendmsg（） 宣告並進行傳輸、使用 Flow Control/echo 幀的 RX 路徑，以及兩個超時停止傳輸的 hrtimers。將 sendmsg（） 中的無鎖定 cmpxchg（） 聲明與在其他地方的>rx_lock下進行的 hrtimer_cancel（） 呼叫混合在一起，留下了框架或計時器回呼可能作用於已經繼續的狀態的窗口，從而損壞不相關的傳輸。so->rx_lock 現在涵蓋了 TX 聲明的整個生命週期：sendmsg（） 使用它來檢查 so->tx.state 是否ISOTP_IDLE，將其切換為 ISOTP_SENDING，使 so->tx_gen 增加並耗盡先前傳輸的計時器 - 所有這些都作為一個關鍵部分。
    isotp_rcv_fc（）/isotp_rcv_cf（） 已經透過 isotp_rcv（） 在此鎖定下運行，並且 isotp_rcv_echo（） 現在會自行獲取它，因此它們都無法在聲明中觀察到傳輸。這也意味著當另一個執行線同時聲明或完成傳輸時，無法再將傳輸傳遞到 sendmsg（） 的清理路徑（信號或發送錯誤），因此這些路徑可以取消計時器並無條件重置狀態。
    isotp_release（） 以相同的方式宣告通訊端，因此爭用 sendmsg（） 會看到一致的ISOTP_SHUTDOWN，並跳過布防其計時器或傳送。只有 hrtimer 回調留在 so->rx_lock 之外，因為它們在其他地方的 so->rx_lock 取消下運行，並且自己獲取它會陷入僵局。So->tx_gen 可讓他們識別逾時的傳輸是否仍是目前作用中的傳輸，因此他們不會針對已完成或已被取代的傳輸報告錯誤。（CVE-2026-72124）

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

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

  - ipmi：修正事件傳遞中的使用者參照計數反向溢位 ipmi_alloc_recv_msg（user） 取得接收訊息所擁有的臨時使用者參照，然後 ipmi_free_recv_msg（） 再次刪除它。如果在為較早的使用者配置接收訊息後事件傳遞失敗，handle_read_event_rsp（） 會使用 ipmi_free_recv_msg（） 復原這些訊息。在釋放每則訊息之後，該復原路徑仍會明確刪除 user->refcount。額外的 put 可以釋放在 intf->users 上保持連結的使用者，因此當 ipmi_alloc_recv_msg（） 嘗試取得另一個參照時，稍後的事件傳遞可能會取消參照已釋放的使用者或觸發 refcount_t 的零加法警告。移除過時的明確放置和現已失效的使用者指派。保留 list_del（） 和 ipmi_free_recv_msg（） 呼叫;它們是必要的復原作業。（CVE-2026-72042）

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

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

  - fs/ntfs3：採用磁碟上頁面大小時調整 log->one_page_buf 大小 log_replay（） 會使用從主機PAGE_SIZE中選擇的頁面大小配置 log->one_page_buf： log->one_page_buf = kmalloc（log->page_size， GFP_NOFS）;後來，當找到重啟區域時，採用磁碟上記錄的日誌頁面大小：t32 = le32_to_cpu（log->rst_info.r_page->sys_page_size）;if （log->page_size ！= t32） {log->l_size = log->orig_file_size; log->page_size = norm_file_page（t32， &log->l_size， t32 == DefaultLogPageSize）; }如果磁碟上的頁面大小大於用於初始配置的大小，則 log->page_size 會增加，但one_page_buf會保留其原始的較小大小。然後，後續未對齊的 read_log_page（） 將 log->page_size 位元組讀取到尺寸過小的暫存緩衝區中：page_buf = page_off ？log->one_page_buf ： *buffer;錯誤 = ntfs_read_run_nb_ra（ni->mi.sbi， &ni->file.run， page_vbo， page_buf， log->page_size， NULL， &log->read_ahead）;使分配溢位。裝載已變更的 NTFS 磁碟區時，可以連線此問題，其記錄的格式化頁面大小大於裝載主機上最初配置的緩衝區 （例如，裝載在配置 4K 暫存緩衝區的主機上的 64K 記錄磁碟區）。
    當採用的磁碟頁面大小超過用於初始配置的大小時，one_page_buf增長。在 krealloc（） 失敗時，原始緩衝區會保持不變，並由現有錯誤路徑釋放。
    (CVE-2026-72470)

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

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

  - octeontx2-pf：修正 init 失敗時的 SQB 指標洩漏 otx2_init_hw_resources（） 會在後續的幾個設定步驟之前初始化 SQ aura 和集區資源。失敗時，err_free_sq_ptrs只會釋放 SQB 頁面，而留下 per-SQ sqb_ptrs陣列。將 otx2_free_sq_res（） 用於 SQ 展開路徑，即使尚未配置 sq->sqe 也讓它釋放sqb_ptrs。該錯誤首先是由我們在分析 v6.13-rc1 時針對核心記憶體管理錯誤開發的實驗性分析工具標記的。該工具仍在開發中，尚未公開。手動檢查確認該錯誤在 v7.1.1 中仍然存在。x86_64 allyesconfig 組建沒有顯示新的警告。由於我們沒有 OcteonTX2 PF 設備和相應的 AF 郵箱設置來進行測試，因此無法執行運行時測試。
    (CVE-2026-72023)

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

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

  - ntfs：偵測對應配對 LCN 累加器溢位 NTFS 對應配對剖析器會以帶正負號的整數累積相對 LCN 差異。損毀的屬性可能會使該新增超出可表示範圍。
    一個損毀的執行清單圖形會將累積的 LCN 設定為 S64_MAX，然後在下一個對應配對項目中新增增量 1。帶正負號的溢位未定義，可能會將無效的執行清單變成一組不同的實體叢集。在儲存下一次執行之前，檢查 LCN 新增是否有溢位。（CVE-2026-72200）

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

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

  - nvmet-tcp：修正錯誤路徑中的頁面片段快取洩漏 在 nvmet_tcp_alloc_queue（） 中，當在分配過程中關閉連線時（例如，nvmet_tcp_set_queue_sock（） 傳回 -ENOTCONN），錯誤處理會跳到out_destroy_sq，然後跳到out_ida_remove，而不會耗盡頁面片段快取。
    雖然在某些錯誤路徑中呼叫 nvmet_tcp_free_cmd （） 以釋放個別頁面片段，但永遠不會釋放佇列>pf_cache所保留的基礎頁面快取參照。使用 pf_cache 的第一個分配是調用 nvmet_tcp_alloc_cmd（） 進行佇列>連接，這會在 ida_alloc（） 成功傳回之後發生。這會導致每次在配置期間連線失敗時出現頁面洩漏，如果重複開啟和關閉連線，可能會導致記憶體耗盡。在釋放 out_ida_remove 標籤中的佇列結構之前呼叫 page_frag_cache_drain（） 來修正此問題。（CVE-2026-74386）

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

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

  - btrfs：修正使用 flushoncommit 時的鎖死複製內嵌範圍 在提交 b48c980b6a7e 中 （btrfs：使用 flushoncommit 時修正 reflink 和交易提交之間的鎖死） 使用 flushoncommit 選項掛載 fs 時，reflink 和交易提交之間的鎖死已修正。當我們必須將內嵌範圍的資料複製到目的地檔案時，就會發生這種情況。不過，此問題僅針對目的地位移為 0 的情況修正，而忽略了位移大於零的情況。透過確保我們在將內嵌範圍的資料複製到目的地檔案時獲得i_size更新來修正此問題。
    Syzbot 報告了此問題並帶有以下痕跡： INFO：任務 kworker/u8：3：57 被阻止超過 143 秒。未受污染的 syzkaller #0 echo 0 > /proc/sys/kernel/hung_task_timeout_secs 會停用此訊息。 task：kworker/u8：3 state：D stack：21600 pid：57 tgid：57 ppid：2 task_flags：0x4208160 flags：0x00080000 工作佇列：回寫wb_workfn （flush-btrfs-129） 呼叫追蹤： <TASK> context_switch kernel/sched/core.c：5402 [內嵌] __schedule+0x16f9/0x5500 kernel/sched/core.c：7204 __schedule_loop kernel/sched/core.c：7283 [inline] schedule+0x164/0x360 kernel/sched/core.c：7298 wait_extent_bit fs/btrfs/extent-io-tree。 c：905 [內嵌] btrfs_lock_extent_bits+0x59c/0x700 fs/btrfs/extent-io-tree.c：2008 btrfs_lock_extent fs/btrfs/extent-io-tree.h：152 [內嵌] btrfs_invalidate_folio+0x440/0xc00 fs/btrfs/inode.c：7718 extent_writepage fs/btrfs/extent_io.c：1848 [內嵌] extent_write_cache_pages fs/btrfs/extent_io.c：2552 [內嵌] btrfs_writepages+0x12f3/0x2410 fs/btrfs/extent_io.c：2684 do_writepages+0x32e/0x550 mm/page-writeback.c：2571 __writeback_single_inode+0x133/0x10e0 fs/fs-writeback.c：1764 writeback_sb_inodes+0x97f/0x1980 fs/fs-writeback.c：2056 wb_writeback+0x445/0xb00 fs/fs-writeback.c：2241 wb_do_writeback fs/fs-writeback.c：2388 [內嵌] wb_workfn+0x3fd/0xf20 fs/fs-writeback.c：2428 process_one_work+0x98b/0x1630 kernel/workqueue.c：3318 process_scheduled_works kernel/workqueue.c：3401 [內嵌] worker_thread+0xb49/0x1140 kernel/workqueue.c：3482 kthread+0x388/0x470 kernel/kthread.c：436 ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c：158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S：245 </TASK> INFO： 任務 syz.0.145:8523 被封鎖超過 143 秒。未受污染的 syzkaller #0 echo 0 > /proc/sys/kernel/hung_task_timeout_secs 會停用此訊息。
    task：syz.0.145 state：D stack：22752 pid：8523 tgid：8522 ppid：5850 task_flags：0x400140 flags：0x00080002 呼叫追蹤： <TASK> context_switch kernel/sched/core.c：5402 [inline] __schedule+0x16f9/0x5500 kernel/sched/core.c：7204 __schedule_loop kernel/sched/core.c：7283 [inline] schedule+0x164/0x360 kernel/sched/core.c：7298 wb_wait_for_completion+0x3e8/0x790 fs/fs-writeback.c：227
    __writeback_inodes_sb_nr+0x24c/0x2d0 fs/fs-writeback.c：2847 try_to_writeback_inodes_sb+0x9a/0xc0 fs/fs-writeback.c：2895 btrfs_start_delalloc_flush fs/btrfs/transaction.c：2182 [內嵌] btrfs_commit_transaction+0x813/0x2fc0 fs/btrfs/transaction.c：2371 btrfs_sync_file+0xdf4/0x1230 fs/btrfs/file.c：1822 generic_write_sync include/linux/fs.h：2663 [內嵌] btrfs_do_write_iter+0x6a9/0x840 fs/btrfs/file.c：1473 new_sync_write fs/read_write.c：595 [內嵌] vfs_write+0x629/0xba0 fs/read_write.c：688 ksys_write+0x156/0x270 fs/read_write.c：740 do_syscall_x64 arch/x86/entry/syscall_64.c：63 [內嵌] do_syscall_64+0x15f/0x560 arch/x86/entry/syscall_64.c：94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP：
    0033：0x7f5a0bdece59 RSP：002b：00007f5a0b446028 EFLAGS：00000246 ORIG_RAX：0000000000000001 RAX：
    ffffffffffffffda RBX：00007f5a0c065fa0 RCX：00007f5a0bdece59 RDX：000000000000029f RSI：0000200000
    ---truncated--- (CVE-2026-74318)

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

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

  - net： thunderbolt：透過邊界 frame_count tbnet_poll（） 將多幀 ThunderboltIP 封包組合成一個 skb 來修正 frags[] 溢位。第一幀進入 skb 線性區域，並且每增加一幀都會添加為頁面片段。skb_add_rx_frag（skb， skb_shinfo（skb）->nr_frags， page， hdr_size， frame_size， TBNET_RX_PAGE_SIZE - hdr_size）;因此，一個包含 frame_count 幀的資料包最終會包含 frame_count - 1 個片段。tbnet_check_frame（） 僅將frame_count提供的對等體限制為 TBNET_RING_SIZE / 4 （64），這遠高於 MAX_SKB_FRAGS （預設為 17）。傳送 19 個或更多小框架封包的對等體會推送nr_frags過去的MAX_SKB_FRAGS，因此 skb_add_rx_frag（） 會寫入過去的 skb_shinfo（）->frags[]，並在共用資訊之後損毀記憶體。收緊綁定到 MAX_SKB_FRAGS + 1 的封包的開頭，這樣封包就永遠不會產生超過frags[]可以容納的片段。這與其他接收路徑中最近修正的 skb 片段溢位相符，例如 f0813bcd2d9d （net： wwan： t7xx：修正 RX 路徑中潛在的 skb->frags 溢位） 和 600dc40554dc （net： usb： cdc-phonet：修正 rx_complete（） 中的 skb frags[] 溢位）。（CVE-2026-72157）

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

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

  - net： ipip：需要在裝置 netns 中CAP_NET_ADMIN，以便 changelink ipip_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（） 上閘道 ipip_changelink（）。（CVE-2026-72053）

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

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

  - ipv4： igmp：修正 igmp_gq_start_timer（） 中潛在的 UAF 裝置拆卸 （inetdev_destroy） 和傳入的 IGMP 查詢處理 （igmp_rcv） 之間存在爭用情形，導致 IGMP 計時器回呼中出現釋放後使用。在裝置銷毀期間，inetdev_destroy（） 會刪除對 in_device 的主要參照，這可能會將其參照計數降至 0。in_device記憶體的實際釋放是透過 RCU 延遲的 （使用 call_rcu（））。同時，igmp_rcv（） 在 RCU 讀取鎖定下運行並取得in_device指標。由於記憶體受 RCU 保護，因此 CPU-0 可以安全地取消參照 in_device，即使其參照計數已達到 0。
    但是，如果 CPU-0 調用 igmp_gq_start_timer（） 並重新布防計時器，它會嘗試使用 in_dev_hold（） 取得參照。這會將參照計數從 0 增加至 1，觸發 refcount_t: addition on 0 警告。由於in_device記憶體仍排定在 RCU 寬限期之後釋放 （因為釋放回呼不會再次檢查參照計數），因此會在計時器仍處於布防狀態時釋放裝置。當計時器到期時，它會存取釋放的內存，從而導致核心錯誤。使用 refcount_inc_not_zero（） （透過新的協助程式 in_dev_hold_safe（）） 來修正此問題，以防止在裝置已被銷毀時取得參照。如果參照計數為 0，則我們不會布防計時器。IPv6 MLD 中的類似問題已在後續修補程式中修正。（CVE-2026-72323）

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

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

  - ALSA： seq：讀取時清除變數事件指標 snd_seq_read（） 會在展開承載之前，將佇列的可變長度事件標頭複製到使用者空間。佇列的可變長度事件會在內部使用 SNDRV_SEQ_EXT_CHAINED，而 data.ext.ptr 會指向第一個擴充儲存格。讀取端會在複製之前從 data.ext.len 中剝離 SNDRV_SEQ_EXT_* 位元，但保留 data.ext.ptr 不變。因此，使用者空間排序器用戶端可以將直接變數事件寫入自己，並從傳回的標頭中讀回擴充單元核心位址。清除 copy_to_user（） 之前的暫存標頭指標。原始佇列事件保持不變，仍會傳遞給 snd_seq_expand_var_event（），因此負載擴充會繼續使用內部鏈。（CVE-2026-74339）

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

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

  - ASoC： 拓蹼：使用前檢查 PCM 及 DAI 名稱字串 拓撲物件會將數個 PCM 及 DAI 名稱儲存在固定大小的 UAPI 陣列中。其他拓撲剖析器路徑會在將這些欄位用作 C 字串之前，先使用有界的 strnlen（） 檢查來驗證這些欄位，但 PCM 和 DAI 路徑仍會將一些固定大小的陣列直接傳遞給 strlen（）、devm_kstrdup（）、DAI 查詢和診斷列印。因此，具有非 NUL 終止 PCM、DAI 或資料流程功能名稱的格式錯誤的拓撲 blob 可能會讓剖析器讀取過固定大小欄位的結尾。拒絕未終止的 PCM 和 DAI 名稱欄位，然後再將其作為 C 字串使用。
    (CVE-2026-74291)

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

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

  - RDMA/bnxt_re：新增 SQ 的最大插槽檢查 必須根據硬體支援的插槽上限來驗證變數 WQE 模式。支援的最大值為 64K。新增 max 和 min 檢查，如果使用者提供的值大於支援的最大值和零，則會失敗。（CVE-2026-72497）

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

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

  - ntfs：避免空閒叢集預先讀取狀態的堆積配置 get_nr_free_clusters（） 會在發佈預先計算的可用叢集計數、設定 NVolFreeClusterKnown（） 並喚醒 vol->free_waitq 之前，先配置暫時file_ra_state。如果該配置失敗，背景工作角色會在不設定旗標或喚醒等候程式的情況下返回，因此等候可用計數的呼叫端可能會無限期封鎖。預讀狀態只會在掃描點陣圖時同步使用。將其保留在堆疊上，並依位址將其傳遞給 readahead 協助程式。這可消除早期配置失敗路徑，而不是新增發佈保守計數並喚醒等候佇列的特殊案例。零初始化堆疊上狀態，因為 file_ra_state_init（） 只設定 ra_pages 和 prev_pos。將相同的處理方式應用於
    __get_nr_free_mft_records （） ，會掃描具有相同短期預讀狀態的 MFT 點陣圖。
    (CVE-2026-72202)

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

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

  - ASoC： SOF： ipc3-control： 修正 put/get bytes_ext中的堆積溢位 ipc_control_data 緩衝區會配置為 kzalloc（max_size），其中max_size涵蓋整個結構sof_ipc_ctrl_data，包括其彈性陣列有效負載。不過，bytes_ext_put _bytes_ext_get中的邊界檢查會直接將使用者資料長度與max_size進行比較，忽略 cdata->data 位於 sizeof（struct sof_ipc_ctrl_data） 位元組的位移位置。這允許透過 ALSA TLV kcontrol 介面從無權限的使用者空間寫入堆緩衝區末尾的 sizeof（struct sof_ipc_ctrl_data） 位元組，並且同樣允許過度讀取獲取路徑上的相鄰堆積資料。修正所有邊界檢查以從max_size減去 sizeof（*cdata），以便它們反映 cdata->data 位移處的實際可用空間。還要修正 bytes_ext_put 中的錯誤路徑還原，該還原寫入 cdata->data 而不是 cdata，導致相同的溢位。
    (CVE-2026-72262)

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

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

  - can： bcm：更新篩選器和計時器值時新增鎖定 當 bcm_rx_handler（）、bcm_rx_timeout_handler（） 或 bcm_rx_thr_handler（） 在傳入的 CAN 流量上同時執行時，更新計時器和篩選器內容時，KCSAN 偵測到同時存取可在 bcm_rx_setup（） 中覆寫的計時器值。使用新的 per-op bcm_rx_update_lock保護 bcm_rx_setup（） 中的計時器 （ival1/ival2/kt_ival1/kt_ival2/kt_lastmsg） 和篩選 （nframes/flags/frames/last_frames） 更新，以 RX 處理常式中的相符範圍進行。在取得鎖定之前，memcpy_from_msg（） 會暫存到暫存緩衝區中，因為它可以休眠，而且不得在微調鎖定下執行。hrtimer_cancel（） 總是在沒有保留bcm_rx_update_lock的情況下調用，因為 bcm_rx_timeout_handler（）/bcm_rx_thr_handler（） 採用相同的鎖，否則正在運行的回呼會與取消器鎖死。同時關閉相關爭用：
    bcm_rx_setup（） 在已安裝框架內容之後，將已儲存回覆框架can_id中的 RTR 旗標清除為單獨的、未受保護的步驟，因此並行 bcm_rx_handler（） 可以傳輸仍設定CAN_RTR_FLAG過時回覆。改為將該正規化折疊到初始框架準備中（在更新的暫存緩衝區上，直接在新操作的 op->frame 預先註冊上），因此安裝的框架始終在原子上自洽。bcm_rx_handler（） 的RX_RTR_FRAME檢查現在會在決定是否調用 bcm_can_tx（） 之前，先拍攝受鎖定保護的 op->flags 快照，但不會在該調用中保留鎖定。另外，在 bcm_can_tx（） 中製作受鎖定保護的 currframe 快照，以避免 bcm_tx_setup（） 中的內容更新部分覆寫。最後檢查 TX_RESET_MULTI_IDX/SETTIMER 是否可能在 bcm_can_tx（） 中的兩個鎖定區段之間重設了 op->currframe。省略調用 bcm_rx_thr_handler（） 中間隔為零的 hrtimer_forward（）。bcm_rx_setup（） 在取消此計時器之前可能已同時清除kt_ival2，因此請在bcm_rx_update_lock中檢查kt_ival2。（CVE-2026-72121）

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

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

  - xprtrdma：重新張貼格式錯誤回覆的接收緩衝區 rpcrdma_wc_receive（） 會在將成功的接收分派至 rpcrdma_reply_handler（） 之前，遞減每次完成的傳輸接收計數。
    處理常式必須在傳回之前張貼取代的接收 WR，除非代表的擁有權已移至其他地方，如在反向通道路徑上。提交 2ae50ad68cd7 （xprtrdma：喚醒 RPC 寄件者與張貼接收之間的關閉視窗） 將接收重新填充從 rpcrdma_wc_receive（） 移至 rpcrdma_reply_handler（），以便在重新張貼之前剖析回應者的信用授予。bad-version 和 short-reply 退出永遠不會達到該補充：它們回收代表並在不調用 rpcrdma_post_recvs（） 的情況下返回。因此，遠端對等可以傳送比固定傳輸標頭短或攜帶無法辨識的 RPC/RDMA 版本的持續回覆資料流，以清空用戶端張貼的接收佇列。每個此類回覆都會消耗一個已張貼的接收，而不取代它。
    佇列清空後，對等的下一次傳送找不到已張貼的接收，傳輸會停止，直到重新連線為止。在回收代表後，透過共用重新張貼尾部路由兩個格式錯誤的回覆退出，根據 buf->rb_credits （最近接受的學分授予） 重新填充。這兩個結束都不會更新壅塞視窗，因此根據先前授權接納的 RPC 仍會持續執行，等待回覆。較小的重新填充目標會讓格式錯誤的回覆資料流將張貼的接收倒數計時到批次樓層，而擁塞視窗仍允許rb_credits RPC;然後，對這些 RPC 的有效回覆突發可能會溢出張貼的接收，而且由於用戶端以零rnr_retry_count連線，因此單一 RNR NAK 會終止連線。當 rpcrdma_post_recvs（） 從內部rb_credits計算時，對 rb_credits 重新填入也會還原在提交 2ae50ad68cd7 （xprtrdma：喚醒RPC寄件者和張貼接收之間的關閉視窗） 之前套用至格式錯誤回覆的目標。
    從連線建立開始，rb_credits至少是一個，因此重新張貼路徑一律會保持「接收」張貼。（CVE-2026-72464）

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

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

  - net：序列化 netif_running（） 檢查 enqueue_to_backlog（） Syzbot 在 fib_rules_lookup（） 中報告了 KASAN slab-use-after-free。根本原因是爭用情形，其中封包可以在裝置取消註冊期間 （例如，在 netns 結束期間） 逃脫積壓排清。提交 e9e4dd3267d0 （net：取消註冊期間不處理裝置積壓） 在 enqueue_to_backlog（） 中引入了無鎖定 netif_running（） 檢查，以防止將封包排入佇列到取消註冊的裝置。然而，這會創建一個 TOCTOU 比賽窗口。無鎖傳送器 （如 veth_xmit） 可以在 dev_close（） 清除IFF_UP之前通過檢查。如果傳送器隨後延遲，則 flush_all_backlogs（） 可以在傳送器取得積壓鎖定並將封包排入佇列之前執行並完成。然後，封包會逸出排清，並在稍後處理時觸發 UAF。透過將 netif_running（） 檢查移動到待辦專案鎖定內來修正此問題。這會將檢查與排清工作序列化 （也會抓取鎖定）。然後，我們要麼在排清執行之前將封包排入佇列（以便排清），或在排清/關閉完成後檢查netif_running（），以便丟棄。（CVE-2026-72493）

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

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

  - ASoC：介子：aiu： 驗證寫入的列舉值 AIU HDMI 及內部編解碼器多路復用器放置回呼會在檢查值對列舉是否有效之前，先使用寫入的列舉值和 snd_soc_enum_item_to_val（）。在轉換列舉項目之前，拒絕超出範圍的值，以符合 G12A HDMI 和內部編解碼器多用器控制項已完成的驗證。（CVE-2026-74294）

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

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

  - bpf：取消映射值上的特殊欄位 回收映射更新和刪除路徑目前在值被替換或回收時呼叫 bpf_obj_free_fields（）。這使得欄位銷毀取決於更新/刪除作業的內容。對於追蹤程式，這可以包括 NMI 內容，其中參照的 kptr 析構函式、uptr 取消釘選和圖形根銷毀通常不安全。為可重複使用的值路徑引入 bpf_obj_cancel_fields（）。它只會對計時器、工作佇列和task_work欄位執行 NMI 安全清除。需要完全銷毀的欄位會保留附加到回收的值，並由最終清除路徑改為銷毀。將陣列和雜湊索引標籤更新/刪除/回收路徑切換至此取消協助程式。保留 bpf_obj_free_fields（） 以進行最終地圖破壞和bpf_mem_alloc析構器。預先分配的雜湊索引標籤沒有配置器析構子，因此 teardown 會繼續遍歷一般和額外元素，並完全銷毀其欄位。這刻意放寬了特殊欄位的地圖更新/刪除的無急切語意。依賴回收的映射槽在更新/刪除後立即變空的程式所依賴的行為無法在不卸載任意析構函數的情況下從每個 BPF 執行上下文安全地實現。這項變更有可能打破程式對急切釋放欄位的假設。如果是這樣，我們只能在將來 irqs_disabled（） 為真時才放寬語意以取消。然而，從理論上講，急切重複使用的映射值已經具有較弱的保證，因為並行用戶可以在新元素再次可見之前重新創建釋放的字段。（CVE-2026-74314）

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

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

  - 已解決 Linux 核心中的下列弱點：ntfs: validate resident index root values on lookup Resident $INDEX_ROOT values carry index header fields that callers consume after lookup.
    Some callers already validate parts of the layout before walking entries, but those checks are scattered and do not cover all root header invariants, such as entries_offset alignment and lower bound, index_length, and allocated_size consistency. The resident root resize paths now keep these header fields consistent while the value size changes: ntfs_ir_truncate() lowers index.allocated_size before shrinking the resident value, and ntfs_ir_reparent() grows the resident value before publishing a larger root header. Lookup-time validation can therefore cover these invariants without tripping over the driver's own resize paths. Add $INDEX_ROOT to the minimum resident value size table and validate the resident index header fields before returning the attribute from lookup. Require 8-byte aligned index header fields, a sane entries_offset, an index_length within allocated_size, allocated_size within the resident value, and enough entry space for at least an index entry header. The shared validator already rejects non-resident records for resident-only attribute types, including $INDEX_ROOT. (CVE-2026-72199)

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

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

  - vhost/net：只有在 vhost-net 為每個未完成的 zerocopy TX 描述元初始化一個ubuf_info並將其交給後端通訊端時，才能完成 zerocopy ubufs。然後，網路堆疊可以在釋放所有 skb 參照之前複製零複製 skb。例如，batman-adv 片段到達 skb_split（），它調用 skb_zerocopy_clone（） 並遞增相同的ubuf_info參照計數。vhost_zerocopy_complete（） 目前會將每個 ubuf 回呼視為已完成的虛擬主機描述元。它會取消參照 ubuf->ctx，寫入描述元完成狀態，並刪除vhost_net_ubuf_ref，即使回呼僅釋放複製的 skb 參照也是如此。因此，後端重設可以等待並釋放vhost_net_ubuf_ref，而另一個複製的 skb 仍具有相同的ubuf_info。稍後的完成會取消參照釋放的 ubufs 指標。
    KASAN 將過時完成報告為： 錯誤： KASAN：vhost_zerocopy_complete+0x1d7/0x1f0 中的 slab-use-after-free 錯誤：KASAN：vhost_zerocopy_complete+0x101/0x1f0 vhost_zerocopy_complete skb_copy_ubufs __dev_forward_skb2 veth_xmit 中的 slab-use-after-free 釋放物件是在設定後端時從 vhost_net_ioctl（） 配置的，並在移除後端後透過 kfree_rcu（）/kvfree_rcu_bulk 釋放， 而延遲的 skb 完成仍達到 vhost_zerocopy_complete（）。在接觸虛擬主機狀態之前，請遵循通用ubuf_info參照計數，並僅針對最終的 ubuf 參照執行虛擬主機描述元完成。這符合複製的 zerocopy skb 的 msg_zerocopy_complete（） 擁有權規則。
    (CVE-2026-74310)

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

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

  - hwmon：（pmbus/core） 遵守 pmbus_data2reg_vid（） 中的vrm_version pmbus_data2reg_vid（） 硬式編碼 VR11 ，而不論驅動程式設定的vrm_version為何，而 pmbus_reg2data_vid（） 已開啟該編碼。任何選擇非VR11 VID 模式並公開穩壓器（或 hwmon vout setter）的驅動程式都會向 PMBUS_VOUT_COMMAND 發送危險的錯誤代碼——例如，要求 200 mV 的 nvidia195mv 部件將 VR11 箝位編碼為 500 mV，編碼為 0xB2，晶片將其解釋為 1080 mV。鏡像 pmbus_reg2data_vid（），因此會以讀取進行來回寫入。（CVE-2026-72397）

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

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

  - fs：拒絕使用未對應的 fsuid 或 fsgid 建立O_TMPFILE vfs_tmpfile（） 從未檢查調用方的 fsuid 和 fsgid 是否對應至檔案系統。在 idmapping 未涵蓋呼叫端的 fs{u，g}id 的 idmapped 掛載上，->tmpfile（） 實例會透過 inode_init_owner（） 初始化新的 inode，其中 mapped_fsuid（）/mapped_fsgid（） 傳回 INVALID_UID/INVALID_GID，而 tmpfile 最終歸 （uid_t）-1 所有。
    所有其他建立路徑都已經拒絕了這一點：may_o_create（） （O_CREAT） 和 may_create_dentry（） （mkdir， mknod， symlink， link） 透過 fsuidgid_has_mapping（） 以 -EOVERFLOW 救助，正好是為了讓物件無法使用檔案系統無法代表的所有者來建立物件。O_TMPFILE也不例外：它是I_LINKABLE創建的，之後 linkat（2） 可以將其拼接到命名空間中，因此必須保持相同的保證。將遺漏的 fsuidgid_has_mapping（） 檢查新增至 vfs_tmpfile（）。在非 idmaped 掛載上，調用方的 fs{u，g}id 一律對應在超級區塊的使用者命名空間中，因此這是無操作，而且只會在未對應調用方的 idmaped 掛載上生效。它適用於設定FS_ALLOW_IDMAP並實作 ->tmpfile（） 的每個檔案系統（tmpfs、ext4、btrfs、xfs、f2fs 等），以及 overlayfs，其上層 tmpfile 建立透過 vfs_tmpfile（） 透過 backing_tmpfile_open（） 漏斗。（CVE-2026-72379）

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

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

  - can： bcm：在 bcm_rx_setup（） 中驗證 RTR 回覆的框架長度 bcm_tx_setup（） 在安裝 TX_SETUP 的框架之前，會根據 CAN/CAN FD DLC 限制驗證 cf->len，但 bcm_rx_setup（） 從未對透過 RX_SETUP 配置的 RTR 回覆框架與 RX_RTR_FRAME 執行相同的操作。（CVE-2026-72114）

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

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

  - scsi：lpfc：修正 lpfc_sli4_driver_resource_setup（） 中的記憶體洩漏 在某些早期退出錯誤路徑中，未釋放使用 mempool_alloc（） 配置給 mboxq 的記憶體。透過將 mempool_free（） 呼叫移動到上次使用後的較早點來解決此問題。（CVE-2026-72087）

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

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

  - bpf：在縮小 check_mem_access（） 中的 retval 範圍之前重設暫存器邊界 當 BPF 驗證程式處理 LSM 勾點傳回值的上下文載入時，它會呼叫 __mark_reg_s32_range（） 將暫存器縮小到勾點的有效範圍。但是，__mark_reg_s32_range（） 使用 max_t（）/min_t（） 將新範圍與暫存器的現有邊界相交，而不是替換它們。如果目標暫存器帶有先前指令（例如 BPF_MOV64_IMM）的過時邊界，則交集可能會產生比實際更窄的範圍。然後，驗證者認為它知道暫存器的確切值，而在運行時載入實際的鉤子傳回值，從而創建可用於繞過 BPF 記憶體安全檢查的驗證者/運行時不匹配。else 分支已呼叫 mark_reg_unknown（） 以在任何縮小之前重設暫存器狀態。在is_retval路徑中套用相同的重設，以便在之前清除過時的邊界
    __mark_reg_s32_range（） 相交。（CVE-2026-72111）

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

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

  - net/liquidio：刪除快取的 VF pci_dev LUT PF SR-IOV 啟用路徑透過使用 pci_get_device（） 反覆運算來快取 VF pci_dev指標 dpiring_to_vfpcidev_lut[] 。這些項目不擁有參照，因為迭代器會在每個步驟上捨棄先前的裝置參照。稍後在處理OCTEON_VF_FLR_REQUEST時，會取消參照快取的指標。將快取的 VF 對應替換為信箱 DPI 環上的運行時間查詢：從 q_no 衍生 VF 索引，透過匯出的 PCI IOV 協助程式解析 VF，使用 PF 指標和 VF ID 進行驗證，然後發出 pcie_flr（） 並使用 pci_dev_put（） 刪除參考。移除未使用的 VF 查詢表初始化和清理。（CVE-2026-72329）

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

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

  - can： bcm：新增缺少的裝置參照計數以移除 CAN 篩選器 sashiko-bot 指出 isotp.c 中並發裝置取消註冊的問題，該問題也存在於 bcm.c 程式碼中。raw.c 提交 c275a176e4b6 的先前修正 （can：raw：為記憶體洩漏修正新增缺少的參照計數） 引入了一個netdevice_tracker，也解決了 bcm.c 的問題。bcm_release（）、bcm_delete_rx_op（） 和 bcm_notifier（） 依靠 dev_get_by_index（ifindex） 重新尋找rx_op裝置，然後再取消註冊其篩選器。如果並行NETDEV_UNREGISTER已從 ifindex 表中取消列出裝置，則該查詢將失敗，並且 can_rx_unregister（） 會以無訊息方式跳過，留下指向即將釋放的 bcm_op/通訊端的過時 CAN 篩選器。從 rx 過濾器在 bcm_rx_setup（） 中註冊的那一刻起，直到在 bcm_rx_unreg（） 中取消註冊，在 op->rx_reg_dev 上保留 netdev_hold（）/netdev_put（） 追蹤的參照，並直接在 bcm_release（） 和 bcm_delete_rx_op（） 中使用該參照，而不是透過 ifindex 重新查詢裝置。（CVE-2026-72113）

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

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

  - bpf：用uprobe_multi資料的access_ok保護__get_user存取 正如 sashiko [1] 所報告的那樣，我們需要先使用 access_ok 來檢查使用者空間資料邊界，然後再使用 __get-user 來獲取它。[1] https://lore.kernel.org/bpf/20260610145235.CB1441F00893@smtp.kernel.org/ （CVE-2026-74258）

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

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

  - dm-verity：將錯誤計數器設為不可部分完成 錯誤計數器 v->corrupted_errs 不是不可部分完成的，因此可能會受到爭用情形的影響。由於爭用，可能會跳過對 dm_audit_log_target（max-corrupted-errors） 的呼叫。（CVE-2026-72096）

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

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

  - Bluetooth： ISO：修正格式錯誤的 ISO_END/CONT 處理核心規格 （Part C vol 4 sec 5.4.5） 不排除空ISO_CONT、ISO_END封包。如果它們是最後的，我們目前會拒絕它們。如果控制器發送格式錯誤的序列ISO_START -> rx_len = 4，ISO_CONT skb->len 4，ISO_START以 ISO_CONT 結束有效負載，我們就會洩露 conn->rx_skb。如果控制器發送的ISO_END太長，我們會在 skb_put 上感到恐慌。如果控制器發送太短ISO_END我們接受。透過 conn->rx_skb ！= NULL 標記未完成的ISO_START來修正。skb_put前請正確檢查 skb->len。結合 ISO_CONT/END 程式碼路徑，因為它們需要相同的初始檢查。
    拒絕太短的ISO_END封包。（CVE-2026-72334）

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

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

  - net/sched： sch_taprio：將直接出列呼叫替換為 peek 和 qdisc_dequeue_peeked 當 taprio 的軟體路徑窺視非工作保存子 qdisc 時，子項會將窺視的 skb 隱藏在其 gso_skb;
    然後，taprio_dequeue_from_txq（） 透過直接子 ->dequeue（） 呼叫來獲取封包，該呼叫會忽略該隱藏，孤立被窺視的 skb 並取消子級的 qlen/backlog 同步。對於 qfq 子項，這會在清空清單中重新輸入子項並取消參照 NULL，從而在普通出口時使核心從 softirq 中出現恐慌。通過 qdisc_dequeue_peeked（） 獲取數據包，就像 sch_red 和 sch_sfb 現在所做的那樣。協助程式會先歸還孩子隱藏的 skb，當沒有 skb 時，則為無操作，因此節省工作的孩子不會受到影響，而且門控路徑現在會消耗其長度計入預算的 skb。（CVE-2026-72035）

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

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

  - ocfs2：在 inode 讀取期間驗證快速符號連結目標 ocfs2_validate_inode_block（） 在數個不一致的獨立雙節點公開給檔案系統的其餘部分之前，已經拒絕了它們。快速符號連結需要相同的處理。零叢集符號連結會被視為快速符號連結，稍後會讀取 page_get_link（） 和 ocfs2_fast_symlink_read_folio（）。該路徑在內嵌負載上使用 strnlen（），然後將 len + 1 位元組複製到對開本中。如果損毀的 dinode 儲存不符合內嵌區域的 i_size，或在i_size省略終止 NUL，則該副本會讀取超過 inode 區塊緩衝區的結尾。拒絕零叢集符號連結雙節點，其i_size超過內嵌快速符號連結容量，或其內嵌承載未在驗證 inode 區塊時完全在 i_size 時以 NUL 終止。這可防止格式錯誤的快速符號連結到達讀取路徑。驗證重現了此核心報告： ocfs2_fast_symlink_read_folio+0x12c/0x1f0 中的 KASAN 釋放後使用 RIP：0033：0x7f5c6d859aa7 讀取大小為 3905 呼叫追蹤：dump_stack_lvl+0x66/0xa0 （？：？） print_report+0xce/0x630 （？：？） ocfs2_fast_symlink_read_folio+0x12c/0x1f0 （fs/ocfs2/inode.c：？） srso_alias_return_thunk+0x5/0xfbef5 （？：？）
    __virt_addr_valid+0x19f/0x330 （？：？） kasan_report+0xe0/0x110 （？：？） kasan_check_range+0x105/0x1b0 （？：？）
    __asan_memcpy+0x23/0x60 (?:?) filemap_read_folio+0x27/0xe0 (?:?) filemap_read_folio+0x35/0xe0 (?:?) do_read_cache_folio+0x138/0x230 (?:?) __page_get_link+0x26/0x110 (?:?) page_get_link+0x2e/0x70 (?:?) vfs_readlink+0x15e/0x250 (?:?) touch_atime+0x4d/0x370 (?:?) do_readlinkat+0x186/0x200 (?:?) do_user_addr_fault+0x65a/0x890 (?:?) __x64_sys_readlink+0x46/0x60 (?:?) do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f (?:?)（CVE-2026-74350）

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

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

  - pmdomain： imx93-blk-ctrl： 擷取 PHY 作為 DSI/CSI 的共用網域 MIPI DSI 和 CSI 網域共用時鐘和重設的控制位元，如果一個網域停用共用資源而另一個網域仍處於作用中狀態，可能會導致不正確的行為。若要解決此問題，請引入共用 MIPI PHY 電源網域來擁有通用資源，並將 DSI 和 CSI 設為其子網域。這可確保共用位元得到妥善管理，並且在仍在使用時不會停用。（CVE-2026-72009）

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

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

  - coresight： platform：延遲連線計數器增量，直到 alloc 成功為止 coresight_add_out_conn（） 在呼叫 devm_krealloc_array（） 之前和 devm_kmalloc（） 之前nr_outconns遞增。如果任一配置失敗，則計數器已經被顛簸，而對應的陣列項目是 NULL 或未初始化的垃圾。coresight_add_in_conn（） 對 nr_inconns 和 devm_krealloc_array（） 有相同的問題。在這兩種情況下，探查都會傳回 -ENOMEM，這會導致 coresight_get_platform_data（） 呼叫 coresight_release_platform_data（） 進行清理。該函式最多可反覆運算 nr_outconns （或 nr_inconns） 個項目，並無條件地解除參照每個指標，命中 NULL 或垃圾項目並發生錯誤，而不是正常失敗。透過將計數器增量移動到所有配置成功之後來修正，以便結構在任何錯誤路徑上始終保持一致。（CVE-2026-72485）

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

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

  - 9p：在無快取模式下跳過 nlink 更新，以修正 WARN_ON v9fs_dec_count（） 在一般檔案上無條件呼叫 drop_nlink（），即使 inode 的 nlink 已經為零。在無快取模式下，用戶端會在每次操作時從伺服器（事實來源）重新擷取 inode 中繼資料，因此當 v9fs_remove（） 傳回時，本機快取的 nlink 可能已經反映了取消連結後的值： 1. 用戶端啟動解除連結，伺服器對其進行處理並將 nlink 設定為 0 2.在取消連結之前，用戶端重新擷取 inode 中繼資料 （nlink=0） 傳回 3。用戶端的 v9fs_remove（） 成功完成 4.用戶端呼叫 v9fs_dec_count（），該 （） 在 nlink=0 上呼叫 drop_nlink（） 此爭用在繁重的取消連結工作負載下很容易觸發，例如 stress-ng 的取消連結壓力源，從而產生以下警告： 警告：fs/inode.c：417 在 drop_nlink+0x4c/0xc8 呼叫追蹤：
    drop_nlink+0x4c/0xc8 v9fs_remove+0x1e0/0x250 [9p] v9fs_vfs_unlink+0x20/0x38 [9p] vfs_unlink+0x13c/0x258 ... 在無快取模式下，伺服器是權威的，而 inode 正在退出，因此在本地調整 nlink 不會購買任何東西。當 CACHE_META 和 CACHE_LOOSE 都未設定時，完全跳過 v9fs_dec_count（），這既避免了警告，又刪除了一類 nlink 爭用（兩個並發解除連結器觀察 nlink > 0，並且都調用 drop_nlink（）），僅 nlink == 0 防護只會縮小而不是關閉。
    (CVE-2026-72170)

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

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

  - mtd：mchp23k256：將 SPI 比對資料用於晶片上限 驅動程式會將晶片容量資訊儲存在 OF 相符資料表和 SPI ID 資料表中。Probe 目前使用 of_device_get_match_data（），因此即使 SPI ID 表選擇了不同的部分，非 OF SPI 模態比對也會回歸到 mchp23k256_caps。使用 spi_get_device_match_data（），以便在缺少 OF 比對資料時使用 SPI id-table driver_data。這會保留現有的預設後援，同時避免僅限 id-table 相符的錯誤 MTD 幾何圖形。
    (CVE-2026-68467)

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

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

  - mm/mm_init：修正 ZONE_DEVICE 的未初始化結構頁面 如果 DAX 記憶體熱插拔到早期區段的未佔用子區段中，section_activate（） 會重複使用未最佳化的開機記憶體。但是，compound_nr_pages（） 仍假設 vmemmap 最佳化正在生效，並且僅初始化減少的結構頁數。因此，剩餘的尾部結構頁面未初始化，這在以後可能會導致意外行為或崩潰。在計算要初始化的結構頁面數目時，將早期區段視為未最佳化，以修正此問題。（CVE-2026-72172）

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

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

  - xprtrdma：修正 ADDR_CHANGE rpcrdma_cm_event_handler（） 上的 ep kref 不平衡，當事件在 RDMA_CM_EVENT_ESTABLISHED 之前到達時，（） 會落入 RDMA_CM_EVENT_ADDR_CHANGE disconnected： 標籤，並在沒有相符的 get 的情況下呼叫 rpcrdma_ep_put（）。然後，kref 在連接拆卸期間下溢，rpcrdma_xprt_disconnect（） 在釋放的 ep 上運行。正常連線生命週期中的參照計數：
    rpcrdma_ep_create（） kref_init ->1 rpcrdma_xprt_connect（） ep_get ->2 （post_recvs 之前） RDMA_CM_EVENT_ESTABLISHED ep_get ->3 RDMA_CM_EVENT_DISCONNECTED ep_put ->2 rpcrdma_xprt_drain（） ep_put ->1 rpcrdma_xprt_disconnect（） 尾ep_put ->0 （ep_destroy） 連接時間 rpcrdma_xprt_connect（） 之前，rpcrdma_post_recvs當有未完成的接收時， 由rpcrdma_xprt_drain平衡。ESTABLISHED 之前的 ADDR_CHANGE 沒有 get 可供消費，因此它的 put 將計數降至 1，然後 drain put 釋放 ep，而 rpcrdma_xprt_disconnect（） 仍然持有指向它的指標。透過 xchg（） 在先前的re_connect_status上分派來修正：對於 prev == 0 （預先建立），喚醒連接服務程式並返回，不放;對於 prev == 1，呼叫 rpcrdma_force_disconnect（） 並返回。case-1 臂依賴後續的 RDMA_CM_EVENT_DISCONNECTED 事件（在仍然連接的cm_id上呼叫 rdma_disconnect（） 時可靠地傳遞）來平衡 ESTABLISHED get;rpcrdma_xprt_drain（） 繼續僅平衡該連接時間 get。任何其他先驗值都表示拆卸已在進行中。
    (CVE-2026-72469)

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

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

  - xen/pvcalls：在索引 rsp[] pvcalls_front_event_handler（） 之前綁定後端回應req_id直接從後端提供的 ring 回應中獲取req_id，並使用它來索引 memcpy（） 和 store 的固定大小 bedata->rsp[] 陣列，無需檢查範圍。惡意或有錯誤的後端可能會設定req_id過去的PVCALLS_NR_RSP_PER_RING，並驅動越界寫入超出 bedata 配置。當線路欄位 rsp->req_id 為 u32 時，req_id也被宣告為 int，因此僅對帶正負號的值進行範圍檢查是不夠的：後端req_id 0xffffffff 變為 -1，通過 >= PVCALLS_NR_RSP_PER_RING 測試並索引 bedata->rsp[-1]。將req_id宣告為 u32，以便單一邊界涵蓋兩端。傳送超出範圍req_id的後端已違反有線通訊協定，因此與其無訊息地刪除回應，不如記錄一次並停止信任後端：set bedata->disabled。然後，事件處理常式會忽略進一步的回應，而等待回應的要求路徑會傳回 -EIO，而不是永遠封鎖。這反映了 xen-netback 使用的致命錯誤處理 （xenvif_fatal_tx_err（））。pvcalls 前端目前信任其後端，因此這不是傳統的 Xen 安全問題，但對於針對惡意後端（機密和分解部署）強化 PV 前端很重要。（CVE-2026-72380）

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

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

  - RDMA/bnxt_re：韌體拆卸後釋放 CQ 切換頁面 只有在韌體拆卸完成後才釋放切換頁面，以便 bnxt_qplib_destroy_cq（） 期間到達的 NQ 中斷不會將切換值寫入已釋放的頁面。在bnxt_qplib_destroy_cq之後移動 free_page（）。（CVE-2026-72499）

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

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

  - netfilter： nft_fib：拒絕 netdev 輸出勾點上的 fib 運算式 netdev 輸出基本鏈中的 fib 運算式解除參照 nft_in（pkt），傳輸路徑上為 NULL，導致評估時出現 NULL 指標解除參照。nft_fib_validate（） 會使用 NF_INET_* 值遮罩勾點，但 netdev 鉤子編號是一個單獨的列舉，可別名它們 （NF_NETDEV_EGRESS == NF_INET_LOCAL_IN），因此出口鏈會通過驗證，然後出錯。新增 nft_fib_netdev_validate（），將每個結果/旗標限制到它讀取的裝置所在的 netdev 鉤子：輸入裝置案例 （OIF、OIFNAME、ADDRTYPE 與 F_IIF） 進入，輸出裝置案例 （ADDRTYPE 與 F_OIF） 輸出，無裝置標誌的 ADDRTYPE 兩者。同時將 nft_fib_validate（） 限制為 NFPROTO_IPV4/IPV6/NET，這樣它的 NF_INET_* 遮罩就不會套用到其他系列的勾點。（CVE-2026-72254）

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

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

  - OpenStack Octavia 透過 18.0.0 不當處理服務品質 （QoS） 原則授權。透過將另一個專案的 QoS 原則與 amphora 建立關聯，經過驗證的使用者可能會阻止刪除該原則。
    所有 Octavia 部署都會受到影響。（CVE-2026-74248）

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

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

  - xprtrdma：修正 bcall rep 洩漏和不受限制的 peek rpcrdma_is_bcall（） 解碼回覆的第一個單字，以判斷框架是否為反向通道呼叫。該解碼路徑中的兩個問題會讓簡短或格式錯誤的回覆洩漏接收緩衝區，並清空接收佇列。首先，推測性窺視 p = xdr_inline_decode（xdr， 0）;/* 後面有五個 p++ 讀取 */ 要求 xdr_inline_decode（） 提供零位元組，這會在不諮詢 xdr->end 的情況下傳回 xdr->p。然後，後續的五個 __be32 讀取最多可通過線負載 20 位元組，進入過時的 regbuf 內容，並將回覆錯誤分類為反向通道呼叫。其次，在後窺視 p = xdr_inline_decode（xdr， 3 * sizeof（*p））;if （unlikely（！p）） 傳回 true;短標頭臂傳回 true，而不呼叫 rpcrdma_bc_receive_call（）。與調用方的合約是，真正的 return 會將 rep 的所有權轉移到反向通道路徑：rpcrdma_reply_handler（） if （rpcrdma_is_bcall（r_xprt， rep）） return;/* 裸返回，跳過 out_post */ ...out_post：
    rpcrdma_post_recvs（r_xprt，製作人員名單 + ...）;因為 rpcrdma_bc_receive_call（） 從未運行過，所以沒有人獲得代表，但rpcrdma_reply_handler仍然在 rpcrdma_rep_put（） 和 rpcrdma_post_recvs（） 之後獲得光回報。代表具有持續 DMA 對應的接收緩衝區，在 rb_all_reps 上孤立，只有在傳輸拆卸時才釋放。此完成不會重新發布任何內容，因此只有在稍後的轉發通道回覆到達out_post並且 rpcrdma_post_recvs（） 分配新的代表進行回填時，才會回收其插槽;如果沒有該流量，接收佇列就會清空，而對等的傳送會繪製 RNR NAK。在零長度窺視之後諮詢 xdr->end 來修正，這樣除非剩餘 20 個位元組的有線負載，否則五個__be32讀取無法執行。需要與 xdr->end 進行位元組精確比較，因為非 4 對齊接收會將資料流的字數四捨五入超過真實承載。還要從短標頭臂傳回 false，以便回覆通過正常的out_norqst清理鏈（rpcrdma_rep_put（） 加上 rpcrdma_post_recvs（））。（CVE-2026-72466）

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

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

  - ksmbd：將開啟器認證用於 FSCTL 突變 SET_SPARSE、SET_ZERO_DATA 和 SET_COMPRESSION 在開啟的 SMB 控制碼上運作，但使用目前的 ksmbd 背景工作者認證呼叫 VFS xattr、fallocate 或 fileattr 協助程式。這些協助程式可以獨立於 SMB 處理存取遮罩，重新驗證 inode 權限、擁有權和 LSM 原則。使用開啟控制碼時在目標檔案中擷取的認證來執行每個作業。將認證處理保留為這些單一檔案 FSCTL 的本機，而不是將工作階段認證套用至完整的 IOCTL 處理常式，其中也包含無控制碼和多控制碼作業。
    (CVE-2026-68457)

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

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

  - afs：修正 inode 的重新初始化，特別是 ->lock_work 似乎在 slab 的 init 函式中初始化一次 afs_vnode：：lock_work 並不足以work_structs。這會導致DEBUG_OBJECTS除錯內容在執行 generic/131 xfstest 時偶爾產生警告： ODEBUG： Activate Not Available （Active State 0） object： 0000000016d8760f object type： work_struct hint： afs_lock_work+0x0/0x220 警告： lib/debugobjects.c：629 at debug_print_object+0x4b/0x90， CPU#3：
    locktest/7695 ... CPU：3 UID：0 PID：7695 通訊：locktest 污染：G S 7.1.0-build3+ #2771 搶佔 ... RIP：
    0010：debug_print_object+0x65/0x90 ... 呼叫追蹤： <TASK> ？ __pfx_afs_lock_work+0x10/0x10 debug_object_activate+0x122/0x170 insert_work+0x25/0x60 __queue_work+0x2e0/0x340 queue_delayed_work_on+0x48/0x70 afs_fl_release_private+0x57/0x70 locks_release_private+0x5c/0xa0 locks_free_lock+0xe/0x20 posix_lock_inode+0x55f/0x5b0 locks_lock_inode_wait+0x81/0x140 ？ file_write_and_wait_range+0x50/0x70 afs_lock+0xcd/0x110 fcntl_setlk+0x10d/0x260 do_fcntl+0x24e/0x5b0
    __do_sys_fcntl+0x6a/0x90 do_syscall_64+0x11e/0x310 entry_SYSCALL_64_after_hwframe+0x71/0x79 在配置 inode 後重新初始化 ->lock_work 來修正此問題。此外，當 inode 被驅逐時，請排清 ->lock_work，以確保它不會仍在執行。（CVE-2026-72375）

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

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

  - drm/radeon：修正 radeon_align_pitch（） 中的整數溢位 radeon_align_pitch（） 與舊的 amdgpu 協助程式具有相同的溢位問題：對齊四捨五入加法和最終的「對齊 * cpp」計算都可能溢位帶正負號的 int。如果包裝，radeon_mode_dumb_create（） 最終可能會傳回無效的音高或建立零大小的啞緩衝區。透過使用 check_add_overflow（） 進行對齊四捨五入，並使用 check_mul_overflow（） 進行最終音高計算來解決此問題，在溢位時傳回 0。也拒絕 radeon_mode_dumb_create（） 中的零間距和大小。使用 sqry 透過基於 AST 的呼叫圖分析找到。（CVE-2026-74417）

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

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

  - IB/mlx5：修正傳輸網域復原並儘早初始化 lb 互斥 mlx5_ib_alloc_transport_domain（） 會配置傳輸網域，然後可能會在 mlx5_ib_enable_lb（） 中失敗。在這種情況下，分配的 TD 會洩漏。透過在 mlx5_ib_enable_lb（） 傳回錯誤時取消配置 TD 來修正此問題。也在 no-loopback-capability success 分支中明確傳回 0，並將 dev->lb.mutex 初始化移至 mlx5_ib_stage_init_init（）。（CVE-2026-74397）

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

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

  - xprtrdma：將 req 回收與RPC完成分離，rl_kref先前透過單一參照計數提供兩個不同的存留期：當 Reply 可以喚醒其RPC工作時，它會進行門控，當 rpcrdma_req 可以返回其可用集區時，它會進行門控。只有在 SGE 需要 DMA 取消映射 （sc_unmap_count > 0） 時，封送處理路徑才採用發送端參照，這使得僅攜帶預先註冊緩衝區的發送成為例外狀況：回覆處理常式將rl_kref從 1 降至 0，並在 HCA 可能仍在從其傳送緩衝區讀取 DMA 時釋放要求。給rl_kref一個更窄的工作。當插槽分配發出要求時，RPC 層會接受一個參考。rpcrdma_prepare_send_sges（） 會在 WR 準備成功之後，無條件地取得 Send-side 參照。xprt_rdma_free_slot（） 和 xprt_rdma_bc_free_rqst（） 刪除RPC層參照;
    rpcrdma_sendctx_unmap（） 會刪除傳送端參照。只有在雙方所有者都簽字後，該請求才會返回其免費池。已移除 rpcrdma_prepare_send_sges（） 中現有的 kref_init（&req->rl_kref） 呼叫。初始化會移至插槽配置路徑 （xprt_rdma_alloc_slot 和 rpcrdma_bc_rqst_get），而釋放回呼會在 req 返回可用集區之前重新布防rl_kref。封送處理路徑中的重新初始化會捨棄項目上已存在的 RPC 層參考。以下有三個不變量： - rpc_rqst所持有的任何rpcrdma_req都有 rl_kref >= 1。xprt_rdma_alloc_slot（）、rpcrdma_bc_rqst_get（） 和 xprt_rdma_alloc_slot（） 中的 backlog-wake 分支在發佈要求之前kref_init rl_kref。如果沒有這個不變量，在插槽分配和封送處理之間中止的RPC任務（例如，在call_connect期間gss_refresh故障或訊號）將驅動 xprt_release（） -> xprt_rdma_free_slot（） -> kref_put 而不是零的參照計數，使refcount_t飽和並擱淺插槽。- 只有在 WR 準備成功之後，才會取得傳送端參照。rpcrdma_prepare_send_sges（） 中的對應失敗會執行 rpcrdma_sendctx_cancel（），該 DMA 會取消對應 sendctx 並清除sc_req而不碰rl_kref。sendctx 環在 rpcrdma_sendctx_put_locked（） 和 rpcrdma_sendctxs_destroy（） 中遍歷具有 sc_req == NULL 的項目，因此一連串的 -EIO 封送處理失敗無法阻止 reqs 關閉rb_send_bufs。- 釋放回呼會重新武裝rl_kref，讓下一個消費者在滿足不變量的情況下進入。回覆現在會直接完成 RPC。
    rpcrdma_reply_handler（） 呼叫 rpcrdma_complete_rqst（） 來取代非 LocalInv 分支上的kref_put。LocalInv 分支已完成從 frwr_unmap_async（） 的RPC，並且不受影響。由於傳送端參照現在可能比 RPC 完成時間更長，因此連線中斷會耗盡 sendctx 項目，而這些項目的無訊號傳送從未有稍後的訊號完成，以遍歷環路。在重設要求緩衝區之前，rpcrdma_sendctxs_destroy（） 遍歷活動範圍並在每個項目上以非 NULL sc_req執行 rpcrdma_sendctx_unmap（），並在 rpcrdma_xprt_disconnect（） 中移動到 rpcrdma_reqs_reset（） 之前，因此當釋放發送端參照時，要求仍處於預重置狀態。排水管會在反通道路徑上造成拆解排序危險。使用新的存留期時，從 rpcrdma_req_release（） 釋放bc_prealloc要求會將其重新新增至bc_pa_list。xprt_rdma_destroy（） 中的斷開連接會在 xprt_destroy_backchannel（） 已經清空bc_pa_list之後運行，因此耗盡的 reqs 會洩漏。xprt_rdma_destroy（） 現在會在中斷連線後第二次執行 xprt_rdma_bc_destroy（xprt， 0） 以回收它們。（CVE-2026-72473）

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

ID	名稱	嚴重性
335592	Linux Distros 未修補弱點：CVE-2026-72124	high
335591	Linux Distros 未修補弱點：CVE-2026-72042	high
335590	Linux Distros 未修補弱點：CVE-2026-72470	high
335589	Linux Distros 未修補弱點：CVE-2026-72023	medium
335588	Linux Distros 未修補弱點：CVE-2026-72200	critical
335587	Linux Distros 未修補弱點：CVE-2026-74386	medium
335586	Linux Distros 未修補弱點：CVE-2026-74318	medium
335585	Linux Distros 未修補弱點：CVE-2026-72157	high
335584	Linux Distros 未修補弱點：CVE-2026-72053	high
335583	Linux Distros 未修補弱點：CVE-2026-72323	critical
335582	Linux Distros 未修補弱點：CVE-2026-74339	medium
335581	Linux Distros 未修補弱點：CVE-2026-74291	medium
335580	Linux Distros 未修補弱點：CVE-2026-72497	high
335579	Linux Distros 未修補弱點：CVE-2026-72202	high
335578	Linux Distros 未修補弱點：CVE-2026-72262	high
335577	Linux Distros 未修補弱點：CVE-2026-72121	high
335576	Linux Distros 未修補弱點：CVE-2026-72464	high
335575	Linux Distros 未修補弱點：CVE-2026-72493	critical
335574	Linux Distros 未修補弱點：CVE-2026-74294	high
335573	Linux Distros 未修補弱點：CVE-2026-74314	high
335572	Linux Distros 未修補弱點：CVE-2026-72199	critical
335571	Linux Distros 未修補弱點：CVE-2026-74310	critical
335570	Linux Distros 未修補弱點：CVE-2026-72397	high
335569	Linux Distros 未修補弱點：CVE-2026-72379	medium
335568	Linux Distros 未修補弱點：CVE-2026-72114	high
335567	Linux Distros 未修補弱點：CVE-2026-72087	medium
335566	Linux Distros 未修補弱點：CVE-2026-72111	high
335565	Linux Distros 未修補弱點：CVE-2026-72329	critical
335564	Linux Distros 未修補弱點：CVE-2026-72113	high
335563	Linux Distros 未修補弱點：CVE-2026-74258	high
335562	Linux Distros 未修補弱點：CVE-2026-72096	medium
335561	Linux Distros 未修補弱點：CVE-2026-72334	high
335560	Linux Distros 未修補弱點：CVE-2026-72035	high
335559	Linux Distros 未修補弱點：CVE-2026-74350	critical
335558	Linux Distros 未修補弱點：CVE-2026-72009	high
335557	Linux Distros 未修補弱點：CVE-2026-72485	high
335556	Linux Distros 未修補弱點：CVE-2026-72170	high
335555	Linux Distros 未修補弱點：CVE-2026-68467	high
335554	Linux Distros 未修補弱點：CVE-2026-72172	high
335553	Linux Distros 未修補弱點：CVE-2026-72469	high
335552	Linux Distros 未修補弱點：CVE-2026-72380	high
335551	Linux Distros 未修補弱點：CVE-2026-72499	high
335550	Linux Distros 未修補弱點：CVE-2026-72254	high
335549	Linux Distros 未修補弱點：CVE-2026-74248	medium
335548	Linux Distros 未修補弱點：CVE-2026-72466	critical
335547	Linux Distros 未修補弱點：CVE-2026-68457	critical
335546	Linux Distros 未修補弱點：CVE-2026-72375	high
335545	Linux Distros 未修補弱點：CVE-2026-74417	high
335544	Linux Distros 未修補弱點：CVE-2026-74397	high
335543	Linux Distros 未修補弱點：CVE-2026-72473	critical

偵測

Nessus 的 Misc. 系列

high

high

high

medium

critical

medium

medium

high

high

critical

medium

medium

high

high

high

high

high

critical

high

high

critical

critical

high

medium

high

medium

high

critical

high

high

medium

high

high

critical

high

high

high

high

high

high

high

high

high

medium

critical

critical

high

high

high

critical