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

  - bpf：保護 conntrack opts 錯誤寫入 conntrack 查詢和分配 kfuncs 採用 opts 指標和 opts__sz 引數。驗證程式只會檢查 opts__sz 所描述的記憶體範圍，但每當內部查閱或配置協助程式傳回錯誤時，包裝函式都會無條件地寫入 opts->error。對於小於 opts->error 結尾的無效大小，該寫入可能會超出驗證程式檢查的範圍。繼續為無效引數傳回 NULL，但僅在提供的大小包含欄位時，才透過 opts->error 報告錯誤。這會保留支援的 12 位元組和 16 位元組版面配置的錯誤報告，以及仍包含 opts->error 的其他無效大小。（CVE-2026-72423）

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

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

  - mmc： vub300：修正探查失敗時的釋放後使用 vub300 驅動程式使用 vub300->kref 來管理其控制器狀態，當最後一個參照被丟棄時，vub300_delete（） 會釋放 mmc 主機。不過，非活動計時器布防之後的探查錯誤路徑仍會繞過該存留期規則，如果 mmc_add_host（） 失敗，則會直接落入 mmc_free_host（）。爭用視窗介於布防閒置計時器和到達探查錯誤之間 mmc_add_host（） 失敗後展開：探查執行緒計時器/工作佇列 ------------ --------------- kref_init（&vub300->kref） ref = 1 kref_get（&vub300->kref） ref = 2，計時器 ref add_timer（inactivity_timer） 在一秒鐘後觸發 | |比賽窗口 |<----------------------------------------------------> |mmc_add_host（mmc） 閒置計時器觸發 vub300_queue_dead_work（） kref_get（） ref = 3 queue_work（deadwork） mmc_add_host（） 失敗 timer_delete_sync（） mmc_free_host（mmc） 釋放 vub300 死效執行 use-after-free 閒置逾時為一秒鐘，因此這需要 mmc_add_host（） 失敗並需要超過一秒鐘才能執行此操作。這在實踐中不太可能發生，但錯誤路徑仍然是錯誤的。timer_delete_sync（） 只等待計時器回呼本身。它不會排清回呼可能已排入佇列的無效工作。因此，佇列的無效工作仍可保留 kref，而探查錯誤路徑會直接釋放支援 mmc 主機，包括 vub300 儲存體。使用與中斷連線相同的存留期機制來修正此問題。清除 vub300->interface，以便計時器回呼和任何排入佇列的死工作提前返回並丟棄其參照，然後丟棄初始探查參照並返回，而不會落入err_free_host。（CVE-2026-72073）

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

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

  - vxlan：修正 vxlan_gro_prepare_receive（） 中潛在的 null-ptr-deref。當 vxlan_gro_prepare_receive（） 執行時，udp_tunnel_sock_release（） 可能會將 sk->sk_user_data 設為 NULL。讓我們檢查一下 skb_gro_remcsum_init（） 之後的 rcu_dereference_sk_user_data（） 是否為 NULL。（CVE-2026-74406）

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

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

  - cifs：驗證 DFS 轉介字串位移 parse_dfs_referrals（） 會驗證回應標頭和轉介陣列是否適合收到的緩衝區，但每個轉介也包含伺服器所提供的字串位移。這些位移可用來計算 DfsPath 和 NetworkAddress 字串指標，而不檢查它們是否仍指向回應緩衝區內。因此，格式不正確的轉介可能會使計算的指標超過緩衝區的結尾。然後將產生的負max_len傳遞給 cifs_strndup_from_utf16（），非 Unicode 路徑將其作為size_t轉發給 kstrndup（），從而允許 strnlen（） 越界讀取。在衍生字串指標之前，先驗證每個字串位移。
    (CVE-2026-72318)

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

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

  - net/mlx5e：修正 HV VHCA 統計代理程式註冊爭用 mlx5e_hv_vhca_stats_create（） 透過 mlx5_hv_vhca_agent_create（） 註冊統計代理程式。協助程式會在 agents_lock 下的 hv_vhca->agents[type] 中發佈代理程式，並立即在 HV VHCA 工作佇列上排程非同步控制失效，然後再返回 mlx5e。非同步無效會叫用控制代理程式的無效回呼，該回呼會讀取虛擬化管理程式控制區塊，並將命令轉送至 mlx5e_hv_vhca_stats_control（）。該回呼可以： - 呼叫 cancel_delayed_work_sync（&priv->stats_agent.work），或 - 呼叫 queue_delayed_work（priv->wq， &sagent->work， sagent->delay）。然而，delayed_work 和 priv->stats_agent.agent 只有在 mlx5_hv_vhca_agent_create（） 返回 mlx5e 後才初始化：agent = mlx5_hv_vhca_agent_create（...）;/* 發佈 + 無效 */ ...priv->stats_agent.agent = 代理程式;/* 太晚了 */ INIT_DELAYED_WORK（&priv->stats_agent.work， ...）;/* 太晚 */ 如果非同步控制路徑在上述兩個指派之前執行，它可以： - 在 timer.function 為 NULL 的未初始化delayed_work上運作。queue_delayed_work（） 無條件調用 add_timer（），因此當計時器到期時，計時器 softirq 會叫用 NULL 函式指標。- 稍後透過 INIT_DELAYED_WORK（） 重新初始化計時器，而計時器已排入計時器輪中的佇列，從而損毀 hlist （當前一個儲存區節點仍指向此項目時，entry.pprev 已清除）。- 當背景工作最終執行時，mlx5e_hv_vhca_stats_work（） 會讀取 sagent->agent （NULL） 並在 mlx5_hv_vhca_agent_write（） 內取消參照它。透過以下方式解決此問題： - 在叫用 mlx5_hv_vhca_agent_create（） 之前初始化 priv->stats_agent.work，以便在控制回呼觀察到工作時始終處於有效狀態。
    - 將結構mlx5_hv_vhca_agent **ctx_update out 參數新增至 mlx5_hv_vhca_agent_create（）。協助程式會先將代理程式指標寫入 *ctx_update，然後再發佈至 hv_vhca->agents[] 並觸發agents_update流程，因此隨後從該流程叫用的任何回呼都已經看到有效的 priv->stats_agent.agent。這可避免控制回呼參與代理程式初始化。
    在此情況下，請使用 READ_ONCE（）/WRITE_ONCE（） 存取 priv->stats_agent.agent，以便與背景工作進行跨 CPU 存取，並清除 agent_create（） 故障路徑上的 priv->stats_agent.buf。（CVE-2026-72342）

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

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

  - net/9p：修正 p9_client_rpc 中對致命訊號的無限迴圈 當以類型 P9_TFLUSH 呼叫 p9_client_rpc（） 並且傳輸沒有對等體時 （例如，由沒有 9p 伺服器的管道支援的 fd 傳輸），致命訊號會導致無限迴圈： 再次： err = io_wait_event_killable（req->wq， ...） /* SIGKILL 喚醒任務， 返回 -ERESTARTSYS */ if （err == -ERESTARTSYS &&; c->status == Connected &&; type == P9_TFLUSH） {sigpending = 1; clear_thread_flag（TIF_SIGPENDING）; 再次轉去; } clear_thread_flag（） 在跳回 io_wait_event_killable（） 之前清除TIF_SIGPENDING。signal_pending_state（） 檢查TIF_SIGPENDING，發現它為零，然後任務再次進入睡眠狀態。此任務只能在呼叫 signal_wake_up（） 並再次設定TIF_SIGPENDING的下一個訊號傳遞時喚醒。當這種情況發生時，循環會重複，清除TIF_SIGPENDING，然後無限期地再次休眠。這實際上是由 coredump_wait（） 觸發的：當多執行緒進程中的執行緒造成核心轉儲時（例如，透過 Syscall User Dispatch 中的 SIGSYS），coredump_wait（） 將 SIGKILL 傳送到所有其他執行緒並等待它們呼叫 mm_release（）。如果其中一個執行緒在沒有對等體的 fd 傳輸的 p9_client_rpc（） 中被阻塞，它就會進入P9_TFLUSH迴圈並且永遠不會呼叫 mm_release（），因此 coredump_wait（） 永遠停止： 資訊：任務 syz.0。18:676 被封鎖超過 143 秒。未受污染 6.12.77+ #1 task：syz.0.18 state：D stack：27600 pid：676 tgid：673 ppid：630 flags：0x00000004 呼叫追蹤： <TASK> context_switch kernel/sched/core.c：5344 [inline]
    __schedule+0xcb4/0x5d50 kernel/sched/core.c：6724 __schedule_loop kernel/sched/core.c：6801 [inline] schedule+0xe5/0x350 kernel/sched/core.c：6816 schedule_timeout+0x253/0x290 kernel/time/timer.c：2593 do_wait_for_common kernel/sched/completion.c：95 [inline] __wait_for_common+0x409/0x600 kernel/sched/completion.c：116 wait_for_common kernel/sched/completion.c：127 [inline] wait_for_completion_state+0x1d/0x40 kernel/sched/completion.c：264 coredump_wait fs/coredump.c：448 [inline] do_coredump+0x854/0x4350 fs/coredump.c：629 get_signal+0x1425/0x2730 kernel/signal.c：2903 arch_do_signal_or_restart+0x81/0x880 arch/x86/kernel/signal.c：337 exit_to_user_mode_loop kernel/entry/common.c：111 [inline] exit_to_user_mode_prepare include/linux/entry-common.h：328 [inline]
    __syscall_exit_to_user_mode_work kernel/entry/common.c：207 [內嵌] syscall_exit_to_user_mode+0xf9/0x160 kernel/entry/common.c：218 do_syscall_64+0x102/0x220 arch/x86/entry/common.c：84 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK> 修正：在清除 P9_TFLUSH 重試迴圈中的TIF_SIGPENDING之前檢查 fatal_signal_pending（）。此時 TIF_SIGPENDING 仍處於設定狀態，因此 fatal_signal_pending（） 可以正常運作。如果重大訊號擱置中，請跳至 recalc_sigpending 以還原TIF_SIGPENDING並將 -ERESTARTSYS 傳回給呼叫端。同樣的缺陷也存在於回到 的 5.4穩定核心中。在這些核心上，無限迴圈會更早地被父進程的第二個 SIGKILL 中斷（例如，kill_and_wait（） 在逾時後重試），導致殭屍進程和關機延遲，而不是永久的 D 狀態掛起，但潛在的缺陷是相同的。由 Linux 驗證中心 （linuxtesting.org） 與 Syzkaller 一起找到。（CVE-2026-72166）

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

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

  - sunrpc：修正未初始化的xprt_create_args結構 xprt_create_args結構是在堆疊上分配的，無需在 rpc_sysfs_xprt_switch_add_xprt_store（） 中初始化。雖然某些欄位是手動填入的，但 srcaddr、bc_xps 和 flags 等關鍵欄位包含未初始化的堆疊垃圾。這可能導致： 1. xs_setup_xprt（） 解除參照垃圾 srcaddr 時發生核心錯誤 2.如果 srcaddr 指向敏感堆疊資料，則資訊洩露 3.如果旗標設定了隨機位，則無法預測的行為 修正是將結構初始化為零，以確保所有未使用的欄位都是 NULL/0，防止傳輸設定程式碼對垃圾資料採取行動。（CVE-2026-72150）

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

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

  - 已解決 Linux 核心中的下列弱點：ntfs: add bounds check before accessing EA entries in ntfs_ea_lookup and ntfs_listxattr, this verifies that there is enough space in the EA entry before accessing the next_entry_offset field of the EA entry. (CVE-2026-72208)

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

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

  - md/raid1：修正寫入失敗時的 writes_pending 和屏障參照洩漏 raid1_make_request（） 在呼叫 raid1_write_request（） 之前使用 md_write_start（） 取得writes_pending參照。raid1_write_request（） 中的幾個失敗路徑完成 bio 並返回，而沒有到達正常的寫入完成路徑，導致對應的 md_write_end（） 被跳過。使 raid1_write_request（） 傳回一個狀態，指示寫入要求是否已成功排入佇列。這允許 raid1_make_request（） 在 raid1_write_request（） 失敗時呼叫 md_write_end（）。此外，如果 wait_blocked_rdev（） 在 wait_barrier（） 成功後失敗，則不會釋放相關聯的屏障參照。在從該路徑返回之前呼叫 allow_barrier（），以保持障礙會計的平衡。（CVE-2026-72440）

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

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

  - Bluetooth： 6lowpan：保持 L2CAP conn 跨 debugfs 控制 get_l2cap_conn（） 在 hdev 保護下查找 LE hci_conn，但在讀取 hcon->l2cap_data 之前以及 lowpan_control_write（） 稍後取消參照 conn->hcon之前刪除該保護。中斷連線或裝置關閉可能會中斷該視窗中的相同 L2CAP 連線。有錯誤的案例涉及兩條路徑，每欄顯示該路徑內的順序： 6LoWPAN 控制寫入： HCI 中斷連線/裝置關閉： 1. get_l2cap_conn（） 找到 hcon 1。
    hci_disconn_cfm（） dispatch 和 hcon->l2cap_data。L2CAP 中斷連線回呼。2. get_l2cap_conn（） 丟棄 hdev 2。l2cap_conn_del（） 清除保護並傳回 conn。hcon->l2cap_data，並捨棄 L2CAP 連線參照。3. lowpan_control_write（） 讀作 3.hci_conn_del（） 移除並捨棄 conn->hcon。HCI 連線。當 hdev 仍處於鎖定狀態時，參照使用 l2cap_conn_hold_unless_zero（） 的 L2CAP 連線，並在 debugfs 命令最後一次使用 conn 後刪除該參照。這會鏡像現有的 L2CAP ACL 接收端遞交，並在離開 hdev 保護後保持連線可取消參照。匯出現有的協助程式，讓bluetooth_6lowpan模組可以使用相同的存留期基本模式。驗證重現了此核心報告： 錯誤：KASAN：lowpan_control_write+0x374/0x520 中的 slab-use-after-free 有錯誤的位址屬於 ffff888111b9d000 的物件，該物件屬於大小為 1024 的快取 kmalloc-1k 有錯誤的位址位於釋放的 1024 位元組區域內的 0 位元組 [ffff888111b9d000， ffff888111b9d400） 大小 8 的讀取 呼叫追蹤：dump_stack_lvl+0x66/0xa0 print_report+0xce/0x5f0 lowpan_control_write+0x374/0x520 （net/bluetooth/6lowpan.c：1131）srso_alias_return_thunk+0x5/0xfbef5 __virt_addr_valid+0x19f/0x330 kasan_report+0xe0/0x110
    __debugfs_file_get+0xf7/0x400 full_proxy_write+0x9e/0xd0 vfs_write+0x1b0/0x810 ksys_write+0xd2/0x170 dnotify_flush+0x32/0x220 do_syscall_64+0x115/0x6a0 （arch/x86/entry/syscall_64.c：87） entry_SYSCALL_64_after_hwframe+0x77/0x7f 依任務堆疊分配：kasan_save_stack+0x33/0x60 kasan_save_track+0x17/0x60 __kasan_kmalloc+0xaa/0xb0 l2cap_conn_add+0x45/0x520 l2cap_chan_connect+0xac6/0xd90 l2cap_sock_connect+0x216/0x350 __sys_連線+0x101/0x130
    __x64_sys_connect+0x40/0x50 do_syscall_64+0x115/0x6a0 （arch/x86/entry/syscall_64.c：87） entry_SYSCALL_64_after_hwframe+0x77/0x7f 依任務堆疊釋放：kasan_save_stack+0x33/0x60 kasan_save_track+0x17/0x60 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x5f/0x80 kfree+0x313/0x590 hci_conn_hash_flush+0xc0/0x140 hci_dev_close_sync+0x41a/0xb00 hci_dev_close+0x12f/0x160 hci_sock_ioctl+0x157/0x570 sock_do_ioctl+0xf7/0x210 sock_ioctl+0x32f/0x490 __x64_sys_ioctl+0xc7/0x110 do_syscall_64+0x115/0x6a0 （arch/x86/entry/syscall_64.c：87） entry_SYSCALL_64_after_hwframe+0x77/0x7f kasan_record_aux_stack+0xa7/0xc0 insert_work+0x32/0x100 __queue_work+0x262/0xa60 queue_work_on+0xad/0xb0 l2cap_connect_cfm+0x4ef/0x670 hci_le_remote_feat_complete_evt+0x247/0x430 hci_event_packet+0x360/0x6f0 hci_rx_work+0x2ae/0x7a0 process_one_work+0x4fd/0xbc0 worker_thread+0x2d8/0x570 kthread+0x1ad/0x1f0 ret_from_fork+0x3c9/0x540 ret_from_fork_asm+0x1a/0x30 （CVE-2026-72336）

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

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

  - bpf：修正 lru 鎖定上的 NMI/追蹤點重新進入鎖死 NMI 和追蹤點 BPF 程式可以重新進入 bpf_lru_pop_free（）/push_free（） 已在相同 CPU 上保留的每個 CPU 或全域 LRU 鎖定，即 AA 鎖死。Lockdep 報告 &l->lock 上不一致的 {INITIAL USE} -> {IN-NMI} （syzbot c69a0a2c816716f1e0d5），並且在 &loc_l->lock 上檢測到可能的遞迴鎖定 （syzbot 18b26edb69b2e19f3b33）。先前基於 trylock 和 rqspinlock 的修正（請參閱連結）因可靠性受到影響而被刪除。此修補程式會將每個 LRU 鎖定站點轉換為 rqspinlock_t，並為某些故障視窗新增復原路徑，以避免節點洩漏。失敗復原： - *_pop_free 頂層：傳回 NULL;
    prealloc_lru_pop（） 已經將其視為無自由元素 （-ENOMEM）。- 跨 CPU 竊取：跳過受害者鎖定的loc_l，嘗試下一個 CPU。- 竊取後本機鎖定失敗：將被盜節點發佈到無鎖定的 per-CPU free_llist;該 CPU 上的下一個彈出物會拾取它。- push_free失敗：標示節點 pending_free=1。
    __local_list_flush（）、__local_list_pop_pending（） 會從pending_list回收節點。
    __bpf_lru_list_shrink_inactive（） 會從非作用中清單中回收節點。作用中清單中的節點會由 __bpf_lru_list_shrink（） 回收，或在 __bpf_lru_list_rotate_active（） 將其降級為非作用中之後回收。
    (CVE-2026-74337)

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

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

  - net： watchdog：修正參照計數追蹤爭用 Blamed commit 將監控程式程式碼中未追蹤的 dev_hold（）/dev_put（） 呼叫轉換為使用追蹤的 dev_hold_track（）/dev_put_track（） （後來重新命名/介面為 netdev_hold（） 和 netdev_put（））。透過引入 dev->watchdog_dev_tracker 來儲存參照追蹤資訊而不新增 netdev_watchdog_up（） 和 dev_watchdog（） 之間的同步，它啟用了可以同時覆蓋或釋放此指標的爭用條件，從而導致清單損毀崩潰 syzbot 報告：list_del損毀，ffff888114a18c00->next 是 lib/list_debug.c：52 處的 NULL 核心錯誤！哎呀：無效的操作碼：0000 [#1] SMP KASAN PTI CPU：1 UID：0 PID：91 通訊：kworker/u8：5 未受污染的 syzkaller #0 PREEMPT（lazy） 硬體名稱：
    Google Google Compute Engine/Google Compute Engine、BIOS Google 2026 年 5 月 9 日 工作佇列：events_unbound linkwatch_event RIP：0010：__list_del_entry_valid_or_report.cold+0x22/0x2a lib/list_debug.c：52 呼叫追蹤：
    <TASK> __list_del_entry_valid include/linux/list.h：132 [內聯] __list_del_entry include/linux/list.h：246 [內聯] list_move_tail include/linux/list.h：341 [內聯] ref_tracker_free+0x1a7/0x6c0 lib/ref_tracker.c：329 netdev_tracker_free include/linux/netdevice.h：4491 [內聯] netdev_put include/linux/netdevice.h：4508 [內聯] netdev_put include/linux/netdevice.h：4504 [內聯] netdev_watchdog_down net/sched/sch_generic.c：600 [內聯] dev_deactivate_many+0x28c/0xfe0 net/sched/sch_generic.c：1363 dev_deactivate+0x109/0x1d0 net/sched/sch_generic.c：1397 linkwatch_do_dev net/core/link_watch.c：184 [內嵌] linkwatch_do_dev+0xd3/0x120 net/core/link_watch.c：166
    __linkwatch_run_queue+0x3a5/0x810 net/core/link_watch.c：240 linkwatch_event+0x8f/0xc0 net/core/link_watch.c：314 process_one_work+0xa0e/0x1980 kernel/workqueue.c：3314 process_scheduled_works kernel/workqueue.c：3397 [內嵌] worker_thread+0x5ef/0xe50 kernel/workqueue.c：3478 kthread+0x370/0x450 kernel/kthread.c：436 ret_from_fork+0x69a/0xc80 arch/x86/kernel/process.c：158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S：245 此修補程式有三個協調的部分： 1） 新增 dev->watchdog_lock 和 dev->watchdog_ref_held 來序列化看門狗操作。2） 從 netif_carrier_on（） 中刪除 netdev_watchdog_up（） 呼叫：這確保了 netdev_watchdog_up（） 僅從 process/BH 上下文調用（透過 linkwatch 工作佇列 dev_activate（）），允許我們使用 spin_lock_bh（） 進行同步。3） 同步看門狗和看門狗計時器：用 tx_global_lock 和 watchdog_lock 保護 netdev_watchdog_up（）。僅在 netdev_watchdog_up（） 中配置新的追蹤器 （如果尚未存在）。在 dev_watchdog（） 中，如果計時器是由 dev_watchdog（） 本身或同時由 netdev_watchdog_up（） 重新排程的，請確保我們不會釋放追蹤器。（CVE-2026-74264）

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

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

  - netfilter： nf_conntrack_sip：在存取 skb_dst（） 之前先驗證它 TC Ingress 和 OpenVswitch 不保證路由資訊可用。這些子系統使用 conntrack 協助程式基礎架構，如果 sip_external_media 設定為 1 （預設情況下停用為模組參數），則 SIP 協助程式依賴 skb_dst（） 的存在。這有效地停用了這些子系統的sip_external_media切換開關，而不會導致當機。（CVE-2026-72253）

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

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

  - mm/hugetlb：修正 hugetlb cgroup rsvd 充值/未充值不相符 在 alloc_hugetlb_folio（） 中，單一h_cg指標用於 rsvd 和非 rsvd hugetlb cgroup 充值。設定map_chg時，hugetlb_cgroup_charge_cgroup_rsvd（） 會將收費的 cgroup 儲存在 h_cg 中，但緊接的 hugetlb_cgroup_charge_cgroup（） 會以非 RSVD cgroup 指標覆寫h_cg。因此，hugetlb_cgroup_commit_charge_rsvd（） 會將錯誤 （非 RSVD） 的 cgroup 指標儲存到對開本的 rsvd 插槽中。
    稍後釋放對開本時，free_huge_folio（） 會無條件地呼叫 hugetlb_cgroup_uncharge_folio（） 和 hugetlb_cgroup_uncharge_folio_rsvd（）。rsvd 取消收費會從作品集讀回錯誤的 cgroup，並遞減從未為該 cgroup 收費的計數器，從而造成page_counter的反向溢位： page_counter underflow： -512 nr_pages=512 警告：mm/page_counter.c：61 在 page_counter_cancel 透過引入專門用於 rsvd 費用路徑的單獨 h_cg_rsvd 指標來解決此問題。 透過 RSVD 和非 RSVD 費用的充電、認可和錯誤取消充電路徑完全獨立。（CVE-2026-72213）

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

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

  - configfs_lookup（）：不要讓 ->s_dentry 在失敗時懸而未決 通常，當 ->s_dentry 指向的 dentry 變為負數時（實際上是在驅逐時）被清除。然而，只有當 dentry 首先變得積極時，這種情況才會發生;在 inode 配置失敗的情況下，dentry 永遠不會變成正數，因此
    ->d_iput（） 完全不調用。我們手動完成通常由 configfs_d_iput（） 完成的部分操作（刪除對 configfs_dirent 的引用），但我們不會清除那裡的 ->s_dentry。儘管它很草率，但在 configfs_create_{dir，link}（） 的情況下並不重要 - configfs_dirent刪除對它的唯一引用是無法倖存的。然而，對於 configfs_lookup（） 來說，它*確實*倖存下來，有一個懸空的指針指向即將被釋放的 dentry 坐在它的 ->s_dentry。該目錄中的後續 getdents（2） 最終將取消引用該指標以選擇 inode 編號。釋放後使用... 這是最低限度的修復;正確的方法是只有在我們知道我們有一個 inode 之後才在 dentry 和 configfs_dirent 之間設置鏈接，但這需要更多的手術，而且這個錯誤自 2006 年以來就一直存在，所以......
    (CVE-2026-74359)

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

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

  - ntfs：拒絕僅限常駐屬性的非常駐記錄 共用查閱時間屬性驗證程式會拒絕非常駐$FILE_NAME$VOLUME_NAME和記錄，因為它們的格式需要常駐值，且呼叫端會將傳回的記錄當作常駐屬性來處理。其他僅限常駐的屬性類型仍會通過一般非常駐對應檢查。這留下了真正的居民/非居民工會混淆路徑。inode 載入會查詢 $STANDARD_INFORMATION ，然後讀取data.resident.value_offset而不檢查 a->non_resident。 ntfs_inode_sync_standard_information（） 在更新標準資訊值時會執行相同的動作。 ntfs_write_volume_flags（） 也會直接查詢 $VOLUME_INFORMATION 並讀取data.resident.value_offset。 $INDEX_ROOT dir.c 和 index.c 中的呼叫端在耗用常駐索引根值之前，會依賴相同的查詢合約。拒絕共用驗證器中所有僅限居民屬性類型的非居民記錄。保留現有$FILE_NAME的 和 $VOLUME_NAME 行為，但透過協助程式將其分解，並將其延伸至 $STANDARD_INFORMATION、 $OBJECT_ID、 $VOLUME_INFORMATION$INDEX_ROOT和 $EA_INFORMATION。對於$OBJECT_ID$EA_INFORMATION，這是僅限居民格式的合約強化;此修補程式僅拒絕非居民形式，不會為這些類型新增新的居民值驗證。（CVE-2026-72198）

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

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

  - dm-verity：修正 FEC 計算中的緩衝區溢位：dm-verity-fec 中存在緩衝區溢位：if （neras &&
    *neras <= v->fec->roots） fio->erasures[（*neras）++] = i;這允許 *neras 達到根 + 1（後增量將其推過根）。然後將此值作為no_eras傳遞給 decode_rs8（）。在 RS 解碼器 （lib/reed_solomon/decode_rs.c：113-121） 內，擦除定位器多項式迴圈寫入 lambda[j]，其中 j 可以到達 nroots + 1，超過lambda[]末尾一個元素（大小為nroots + 1，有效索引為0..nroots）。越界寫入落在 syn[0] 上，損毀了綜合症緩衝區。（CVE-2026-72098）

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

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

  - tpm： tpm_tis_spi：在 wait_for_tmp_stat（） 中使用 wait_woken（） wait_event_interruptible_timeout（） 會在將目前任務狀態設定為 TASK_INTERRUPTIBLE 後評估其狀況。使用CONFIG_DEBUG_ATOMIC_SLEEP當使用 IRQ 等待路徑時，這會觸發警告： tpm_tis_status（） tpm_tis_spi_read_bytes（） tpm_tis_spi_transfer_full（） spi_bus_lock（） mutex_lock（） 採取以下措施解決此問題： 1. 僅在任務執行時呼叫 wait_tpm_stat_cond（）。2. 使用 wait_woken（） 等待變更。
    (CVE-2026-72152)

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

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

  - can： bcm：追蹤單一來源介面的 ANYDEV 逾時/節流操作 當相符的畫面從數個介面到達時，具有作用中 RX 逾時和/或節流計時器的 ANYDEV rx 操作 （ifindex == 0） 沒有定義的語義： bcm_rx_handler（） 可以針對不同 CPU 上的相同操作同時執行，對 bcm_rx_timeout_handler（） 進行 hrtimer_cancel（）/ bcm_rx_starttimer（） 競用，並導致虛假的 RX_TIMEOUT 通知和last_frames損毀。相同的並發性會讓來自不同介面的節流多工畫面破壞操作共用的單一 rx_ifindex/rx_stamp 欄位。新增op->if_detected以追蹤在設定逾時/節流計時器時傳送相符幀的第一個介面，並拒絕來自該操作的任何其他介面的幀。在 hrtimer_cancel（） 接觸 op->timer 之前，在 bcm_rx_handler（） 中決定聲明，因此被拒絕的幀永遠不會干擾聲明介面的監控程式。RTR 模式操作會透過 RX_RTR_FRAME 排除，與 kt_ival1/kt_ival2 無關，因為這些操作可能會短暫地保留先前非 RTR 組態中的過時值。當 SETTIMER 重新設定計時器值時，宣告會在 NETDEV_UNREGISTER 的 bcm_notify（） 和 bcm_rx_setup（） 中釋放。（重新）聲明只能在 NETREG_REGISTERED dev->reg_state 中的 CAN 設備上進行，以涵蓋 bcm_notify（） 中的版本，其中 reg_state 在 synchronize_net（） 之前變為NETREG_UNREGISTERING。（CVE-2026-72115）

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

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

  - selinux：避免 selinux_sctp_bind_connect（） 中的sk_socket取消參照 selinux_sctp_bind_connect（） 解除參照 sk->sk_socket 以將結構通訊端 * 傳遞給 selinux_socket_bind（） 和 selinux_socket_connect_helper（）。但是，從 ASCONF softirq 路徑 （sctp_process_asconf） 叫用勾點時，沒有檔案參照保證 sk->sk_socket 為非 NULL。setsockopt 呼叫端 （bindx、connectx、set_primary、sendmsg connect） 會保留檔案參照，不會受到影響。selinux_socket_bind（） 和 selinux_socket_connect_helper（） 都會立即解析 sock->sk，絕不將結構通訊端 * 用於其他任何操作。將內部邏輯重構為直接採用結構襪子 * 的協助程式，這樣 selinux_sctp_bind_connect（） 就永遠不需要接觸 sk->sk_socket。
    (CVE-2026-72242)

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

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

  - nvdimm/btt：處理 BTT 通道取得中的先佔 BTT 通道會在 BTT I/O 期間序列化對每個通道中繼資料和工作區狀態的存取。btt-check 單元測試會報告 BTT 寫入期間的資料不相符，這是因為通道擷取中的爭用，可能導致無訊息資料損毀。現有的通道模型會使用微調鎖定以及每個 CPU 遞迴計數。在 BTT 通道成為搶佔式後，該遞迴模型不再有效：另一個任務可以在相同的 CPU 上運行、觀察非零遞歸計數、繞過鎖定並同時使用相同的通道。BTT 通道也在 arena_write_bytes（） 呼叫中保持。該路徑會到達 nsio_rw_bytes（），而 （） 會以 nvdimm_flush（） 排清寫入。某些提供者排清回呼可能會休眠，使微調鎖定成為通道存留期的錯誤基本類型。將基於微調鎖的遞迴模型替換為動態分配的每車道互斥陣列，並無條件地採用車道鎖定。新增 might_sleep（） 以捕獲任何未來的原子上下文呼叫者。使用 ndctl 單元測試 btt-check.sh 找到。
    (CVE-2026-74365)

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

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

  - nfs：使用 nfsi->rwsem 保護檔案鎖定清單的周遊凌風發現了一個錯誤，並提出了兩種解決方案，但似乎都存在問題。通常，我們無法在迭代檔案鎖定清單時釋放flc_lock，以避免檔案鎖定出現釋放後使用（UAF）問題。但是，像 nfs_delegation_claim_locks 和 nfs4_reclaim_locks 這樣的函數無法遵守此規則，因為recover_lock或nfs4_lock_delegation_recall可能需要很長時間。為了解決此問題，NFS 會切換為使用 nfsi->rwsem 來提供相同的保護，而 nfs_reclaim_locks 會遵循此方法。雖然nfs_delegation_claim_locks改用so_delegreturn_mutex，但這還不夠，因為單一 inode 可以有多個 nfs4_state 執行個體。因此，在此情況下，修正方法是也使用 nfsi->rwsem。此外，在提交 c69899a17ca4 （NFSv4：VFS 位元組範圍鎖定的更新必須是不可部分完成且 stateid 更新） 之後，函式 nfs4_locku_done 和 nfs4_lock_done 也會違反此規則，因為它們呼叫 locks_lock_inode_wait 而不保留 nfsi->rwsem。僅新增此保護可能會導致許多鎖死，因此改為將對 locks_lock_inode_wait 的呼叫移至_nfs4_proc_setlk。關於提交 c69899a17ca4 修正的錯誤 （NFSv4：VFS 位元組範圍鎖定的更新必須與 stateid 更新是不可部分完成的），它已在提交 0460253913e5 （NFSv4：nfs4_do_open（） 錯誤地觸發狀態恢復）後得到解決，因為在呼叫 nfs4_do_reclaim 之前，所有插槽都會被耗盡，這會阻止沿此路徑並發 stateid 更改。此外，nfs_delegation_claim_locks也不會造成此並行，因為何時
    _nfs4_proc_setlk是用NFS_DELEGATED_STATE調用的，沒有傳送任何RPC，所以不會調用nfs4_lock_done。
    因此，從 nfs_delegation_claim_locks nfs4_lock_delegation_recall是第一次設定 stateid。（CVE-2026-72472）

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

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

  - smb： client：修正 DIO 提交後卸載時的忙碌 dentry 警告 c68337442f03 （cifs：修正卸載後使用的忙碌 dentry） 修正了 cifs 中檔案延遲關閉導致 umount 中未釋放 dentry 參照計數的問題，方法是在 cifs_kill_sb（） 中排清 deferredclose_wq 來解決此問題。然而，cifs DIO 路徑也遇到同樣的 busy-dentry 問題，這是由延遲的 dentry 參照計數釋放所造成：[dio] [cifsd] [close + umount] netfs_unbuffered_write_iter_locked ...cifs_demultiplex_thread netfs_unbuffered_write cifs_issue_write netfs_wait_for_in_progress_stream [1] ...
    netfs_write_subrequest_terminated netfs_subreq_clear_in_progress netfs_wake_collector // 喚醒 [1] netfs_put_subrequest netfs_put_request queue_work（system_dfl_wq， xxx） [2] // dio 寫入 return cifs_close
    _cifsFileInfo_put // cfile->count 2->1 --cfile->count [3] // 卸載cifs_kill_sb kill_anon_super // 觸發警告！ shrink_dcache_for_umount [4] [system_dfl_wq] [5] netfs_free_request ...
    _cifsFileInfo_put // cfile->count 1->0 --cfile->count queue_work（fileinfo_put_wq， xxx） [fileinfo_put_wq] [6] cifsFileInfo_put_work cifsFileInfo_put_final dput 如果在 [5] 之前觸發卸載路徑，則會產生警告： 錯誤：dentry 00000000eab1f070{i=9a917b66ae404fec，n=test} 仍在使用 （1） [卸載 cifs cifs] cifs_evict_inode（） 中現有的 per-inode ictx->io_count 等待無濟於事： 它位於 inode 驅逐路徑中，該路徑在 shrink_dcache_for_umount（） 已經警告繁忙的牙位之後運行。透過新增每個超級區塊的 outstanding-rreq 計數器來修正此問題，該計數器在 cifs_init_request（） 中遞增，在 cifs_free_request（） 中遞減。在 cifs_kill_sb（） 中，在 kill_anon_super（） 之前，等待此計數器達到 0 - 這保證此 sb 的所有cleanup_work都已運行，因此所有相關的 cfile put 都在 fileinfo_put_wq 或 serverclose_wq 上排隊。然後清空工作佇列，以便捨棄 dentry 參照。這是有針對性的等待，而不是全系統system_dfl_wq的排清。
    (CVE-2026-72315)

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

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

  - xfrm：修正 xfrm 非同步恢復 xfrm 非同步恢復中的 dev 釋放後使用，保留 skb->dev refcnt，直到transport_finish之後。不過，xfrm_rcv_cb可以修改 skb->dev 以通道開發，而不採用裝置參照 （例如 vti_rcv_cb）。後續的非同步還原會遞減通道裝置的參照計數，進而導致通道開發的 UAF 和原始開發的 refcnt 洩漏，如下所示：
    unregister_netdevice：等待 vti1 變為免費。使用計數 = -2 隱藏原始 skb->dev 以修正 refcnt 不平衡。xfrm_rcv_cb 設定的新 skb->dev 可以與設備拆解競爭。將 rcu 保護擴展到xfrm_rcv_cb和transport_finish以防止爭用。（CVE-2026-72463）

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

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

  - vhost：修正非空環的vhost_get_avail_idx vhost_get_avail_idx應該報告它是否更新了 vq->avail_idx。相反地，它會傳回是否已使用所有項目，這通常是相同的。但並非總是如此 - 在 drivers/vhost/net.c 中，當啟用可合併的緩衝區時，驅動程式會檢查合併的項目是否足夠大以儲存傳入的封包。如果沒有，驅動程式會重新啟用通知，且可用的項目仍在通道中。來自vhost_get_avail_idx的錯誤傳回值會透過vhost_enable_notify傳播，並在客體未取得進展時導致主機即時鎖定，因為虛擬主機會立即停用通知，並使用可用的項目重試。這可以追溯到提交 d3bb267bbdcb （vhost：vhost_enable_notify（） 中的快取可用性索引），該提交更改了 vhost_enable_notify（） 以將新讀取的可用性索引與 vq->last_avail_idx 而不是先前快取的 vq->avail_idx 進行比較。提交 7ad472397667 （vhost：將 smp_rmb（） 移至 vhost_get_avail_idx（）），然後在重構 vhost_enable_notify（） 以呼叫統一的 vhost_get_avail_idx（） 時進行相同的比較。顯而易見的解決方法是讓vhost_get_avail_idx按照評論所說的去做，並報告是否添加了新條目。（CVE-2026-74356）

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

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

  - tcp：在強制關閉子通訊端之前清除 sock_ops cb 旗標 子通訊端透過 sk_clone_lock（） 繼承接聽程式的bpf_sock_ops_cb_flags。如果其設定在 tcp_v4_syn_recv_sock（） / tcp_v6_syn_recv_sock（） 中失敗，則透過 put_and_exit 釋放子項，其中 inet_csk_prepare_forced_close（） 會刪除通訊端鎖定，而 tcp_done（） 會在沒有它的情況下執行。如果BPF_SOCK_OPS_STATE_CB_FLAG是繼承的，則 tcp_done（） -> tcp_set_state（） 呼叫 tcp_call_bpf（），它需要鎖定並觸發 sock_owned_by_me（）：
    警告：include/net/sock.h：1799 at tcp_set_state+0x433/0x550 RIP：0010：tcp_set_state+0x433/0x550 include/net/sock.h：1799 呼叫追蹤： <IRQ> tcp_done+0xba/0x250 net/ipv4/tcp.c：5095 tcp_v4_syn_recv_sock+0x850/0xa50 net/ipv4/tcp_ipv4.c：1787 tcp_check_req+0xf30/0x1360 net/ipv4/tcp_minisocks.c：926 tcp_v4_rcv+0x1047/0x1b50 net/ipv4/tcp_ipv4.c：2164 </IRQ> 子在建立之前就被釋放了， 因此，它不應該執行sock_ops回呼。清除其在 inet_csk_prepare_for_destroy_sock（） 中的 cb 旗標，這是 IPv4、IPv6 和 chtls 強制關閉路徑以及 MPTCP ->syn_recv_sock（） 故障路徑 （dispose_child） 的公共點，它也會到達從未建立的子項上的 tcp_done（）。（CVE-2026-74268）

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

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

  - bpf，fork：在存取它的救助之前擦除 ->bpf_storage 目前，copy_process（） 可以在 p->bpf_storage 初始化之前救助到 free_task（），使用以下調用圖（此處顯示 ！CONFIG_MEMCG 情況）：copy_process dup_task_struct arch_dup_task_struct [複製整個task_struct，包括 ->bpf_storage 成員] [RLIMIT_NPROC檢查失敗] delayed_free_task free_task bpf_task_storage_free rcu_dereference（task->bpf_storage） bpf_local_storage_destroy 在這種情況下，bpf_local_storage_destroy（） 操作的新生任務的 ->bpf_storage 成員是父項 ->bpf_storage 指標的純副本，而不是真正的初始化指標。這會導致不良（核心懸置、UAF）。
    只要呼叫 fork（） 的處理程序已插入到工作儲存對應中，就可以實現此目標。
    (CVE-2026-72110)

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

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

  - ESPINTCP：使用 sk_msg_free_partial 修復部分發送 sk_msg_free_partial（），確保 SKMSG 在每次迭代時的一致性，而無需手動處理未收費和偏移。這簡化了程式碼，並修正了當我們不傳送完整內容時 skmsg 帳戶中的一些錯誤。（CVE-2026-72041）

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

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

  - net： mana：驗證 NIC 報告的封包長度 驗證 RX CQE 中報告的封包長度，再將其傳遞至 skb 處理。CQE 是由 NIC 裝置提供，不應盲目信任。（CVE-2026-72065）

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

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

  - 已解決 Linux 核心中的下列弱點：ntfs: validate index entries on reading Validate index entries immediately after reading an index root or index block from disk. This eliminates repeated checks in lookup and readdir, and reduce the risk of missing checks in those paths.
    (CVE-2026-72201)

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

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

  - selinux：檢查 TCP 快速開啟的連線相關權限 與 Landlock 類似，引入 TCP 快速開啟支援時，SELinux 並未更新，以確保在使用 TCP 快速開啟時檢查連線相關權限。更新其 socket_sendmsg（） 鉤子，以便在傳遞 MSG_FASTOPEN 時呼叫 selinux_socket_connect（）。
    (CVE-2026-72243)

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

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

  - PCI：存取前檢查 ROM 標頭和資料結構 addr 在x86_64電腦上執行 stress-ng 時，我們遇到當機： 錯誤：無法處理位址的頁面錯誤：ffa0000007f40000 RIP：
    0010：pci_get_rom_size+0x52/0x220 呼叫追蹤： <TASK> pci_map_rom+0x80/0x130 pci_read_rom+0x4b/0xe0 kernfs_file_read_iter+0x96/0x180 vfs_read+0x1b1/0x300 我們的分析表明，ROM 空間的起始位址為 0xffa0000007f30000，大小為 0x10000。由於 ROM 空間中斷，在呼叫 readl（pds） 之前，pds 的值是 0xffa0000007f3ffff，它已經指向 ROM 空間端，呼叫 readl（） 將讀取 4 個位元組，因此會導致越界存取並觸發當機。透過新增影像標頭和資料結構檢查來修正此問題。我們還在 arm64 機器上發現了另一個崩潰：無法處理虛擬位址 ffff8000dd1393ff 的核心分頁請求 Mem 中止資訊：ESR = 0x0000000096000021 EC = 0x25：DABT（當前 EL），IL = 32 位元 SET = 0，FnV = 0 EA = 0，S1PTW = 0 FSC = 0x21：對齊錯誤 呼叫追蹤與 x86_64 相同，但當機原因是資料結構 addr 未與 4 對齊， 和 arm64 機器報告對準錯誤。透過新增坐標系檢查來修正此問題。[bhelgaas：
    縮短函式名稱，換行註解] （CVE-2026-72487）

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

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

  - scsi： xen： scsiback： 釋放 TMR 提交失敗路徑上的命令標籤 scsiback_device_action（） 取得 scsiback_get_pend_req（） 中的命令標籤，並使用 target_submit_tmr（） 提交任務管理要求。
    當 target_submit_tmr（） 失敗時，它傳回 < 0，scsiback 跳轉到 err： 標籤，該標籤發送回應但不釋放任何內容，從而洩露標籤。影響：每當 target_submit_tmr（） 失敗時，pvSCSI 客體可能會發出 VSCSIIF_ACT_SCSI_ABORT 或 RESET 要求，藉此洩漏 LUN 工作階段的命令標籤，從而停止 LUN。
    此處不能使用 transport_generic_free_cmd（）。當 target_submit_tmr（） 傳回錯誤時，它已經執行了 __target_init_cmd（） （所以 se_cmd->cmd_kref 是 1，而不是零），並且在其 target_get_sess_cmd（） 錯誤路徑上，它已經透過 core_tmr_release_req（） 釋放了 se_cmd->se_tmr_req，同時保留SCF_SCSI_TMR_CDB設定和指標懸空。讓命令 release 執行 target_free_cmd_mem（） 將雙重釋放se_tmr_req。在此路徑上也使用相同的協助程式，它只會傳回標籤。（CVE-2026-72086）

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

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

  - RDMA/nldev：修正存取 mr->pd 時的鎖定Sashiko 指出，由於rereg_mr，PD 實際上是可變的，並且 nldev 中的所有接觸都是活潑的。使用 mr->device 而不是 mr->pd->device。取得 PD 重新追蹤 ID 會比較棘手。為避免打擾所有快樂路徑，請新增一個類似於 flush_workqueue（） 或 synchronize_irq（） 的 rdma_restrack_sync（） 操作：返回後，所有舊的 nldev 對 mr 的接觸都消失了，所有內容都會看到新的 PD。這樣可以安全地伸入 PD 指標。
    (CVE-2026-74334)

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

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

  - dlm：修正以 send_queue 順序新增訊息控點 在觸發大量要求並觸發網路上大量 DLM 訊息的基準測試案例中，可能是 mh->seq 未按照最舊的 seq 編號排序。dlm_receive_ack需要此排序，因為之前 （mh->seq， seq） 將停止檢查節點>send_queue尾部排序的舊序號。關於 before（mh->seq， seq） 沒有正確排序的副作用是引用問題和釋放後使用。
    我只能在實驗性 DLM 分支和使用 io_uring 的使用者空間 DLM 基準測試中重現此問題。更改此選項後，我不再遇到任何發送緩衝區問題的引用計數。（CVE-2026-74401）

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

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

  - i2c：imx：修正 SMBus 上鎖定的匯流排 區塊讀取為 0 （不可部分完成） SMBus 3.1 6.5.7 允許區塊讀取位元組計數為 0，但不可部分完成 （輪詢） 路徑將其拒絕為 -EPROTO。更糟糕的是，它會在沒有 NACK+STOP 的情況下返回：下一個接收週期已經開始，因此目標繼續保持 SDA，並且總線保持卡住，直到此 i2c 控制器重新啟動電源。讀取 I2DR 以取得計數同樣會武裝計數> I2C_SMBUS_BLOCK_MAX路徑上的下一個位元組，該位元組也會直接傳回 -EPROTO 並保留匯流排。同時處理兩者：NACK 進行中的虛擬位元組 （TXAK） 並擴充 msgs->len，以便現有的最後一個位元組處理發出 STOP;虛擬位元組會遭到捨棄。計數為 0 是有效的空區塊讀取;高於 I2C_SMBUS_BLOCK_MAX 的計數仍會報告為 -EPROTO，但僅在匯流排釋放之後。中斷驅動路徑在稍後的提交中具有相同的缺陷，並且是單獨修復的，因為它帶有不同的修復：標籤和穩定範圍。（CVE-2026-72142）

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

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

  - RDMA/siw：修正端點/通訊端關聯處理 透過 siw_socket_disassoc（） 取消通訊端與端點的關聯，可能會釋放該端點上的最後一個參照並將其釋放。因此，請勿在呼叫該函式之後清除端點通訊端指標，而是在內部清除。此修正了一個： 錯誤：KASAN：siw_cm_work_handler （drivers/infiniband/sw/siw/siw_cm.c：1053 drivers/infiniband/sw/siw/siw_cm.c：1075） 中的 slab-use-after-free （drivers/infiniband/sw/siw/.c：1075） 在建立連線期間處理格式錯誤的 MPA 要求之後，導致新端點關閉。（CVE-2026-74345）

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

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

  - ALSA： seq：在調整大小期間避免過時的 FIFO 儲存格 snd_seq_fifo_resize（） 在等待 FIFO 使用者之前仍需要發佈替換集區。阻塞 snd_seq_read（） 在休眠時保留 f->use_lock，因此並行發送者必須能夠排入新集區並喚醒該讀取器，而不是針對關閉的舊集區失敗。但是，snd_seq_fifo_event_in（） 會在事件採用 f->lock 之前複製事件，並且 snd_seq_read（） 可以出列儲存格，然後在 copy_to_user（） 或 snd_seq_expand_var_event（） 失敗時呼叫 snd_seq_fifo_cell_putback（）。如果調整大小會交換 f->pool 並在兩者之間分離 oldhead，則任一路徑都可以在快照之後重新連結舊集區儲存格。該過時的儲存格位於已排空的 oldhead 清單之外，使 oldpool->counter 保持升高，並且可以讓 snd_seq_pool_delete（） 等待淘汰的集區排空。在 snd_seq_fifo_resize（） 中保留現有的等待前交換排序，但在任何 FIFO 重新連結之前拒絕過時的儲存格。在 f->lock 下重新驗證事件輸入單元格，並針對已發佈的替換集區重試它們，並釋放過時的回放單元格，而不是將它們連結回 FIFO。有錯誤的案例涉及兩條路徑，每欄顯示該路徑內的順序：調整路徑大小：
    重新連結路徑： 1. 分配 newpool。1. 以 f->use_lock。2. 將 f->pool 換成 newpool 和 2.複製或出列舊集區分離 oldhead。Oldpool 關閉前的儲存格。3. 標記舊池關閉和 3.等待 FIFO 使用者後，到達稍後的重新連結點。調整已發佈的 newpool 大小。4. 釋放 oldhead 並刪除 4.
    在 oldpool 之後重新連結 old-pool 儲存單元。調整分離的 oldhead 大小。5. 放下 f->use_lock。轉發程式報告在預期集區拆卸路徑中封鎖的調整大小 ioctl： signal： resize iteration=98 target_pool=4 超過 250ms （elapsed=251ms） 診斷：resize_tid=651 wchan=snd_seq_pool_done 診斷：resize_tid=651 stack= snd_seq_pool_done+0x5b/0x140 snd_seq_pool_delete+0x7a/0x90 snd_seq_fifo_resize+0x193/0x1e0 snd_seq_ioctl_set_client_pool+0x214/0x260 snd_seq_ioctl+0x119/0x540
    __x64_sys_ioctl+0xd1/0x120 do_syscall_64+0xbb/0x2f0 entry_SYSCALL_64_after_hwframe+0x77/0x7f 具有較大集區的第二次執行命中相同的目標路徑： signal： resize iteration=32 target_pool=64 超過 250ms （elapsed=251ms） 診斷：resize_tid=663 wchan=snd_seq_pool_done 診斷：resize_tid=663 stack= snd_seq_pool_done+0x5b/0x140 snd_seq_pool_delete+0x7a/0x90 snd_seq_fifo_resize+0x193/0x1e0 snd_seq_ioctl_set_client_pool+0x214/0x260 snd_seq_ioctl+0x119/0x540 __x64_sys_ioctl+0xd1/0x120 do_syscall_64+0xbb/0x2f0 entry_SYSCALL_64_after_hwframe+0x77/0x7f （CVE-2026-74261）

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

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

  - RDMA/bnxt_re：將 dpi 變數初始化為零 dpi 只會針對 BNXT_RE_ALLOC_WC_PAGE 初始化，但會針對所有情況複製。因此，將 dpi 初始化為 0。（CVE-2026-72501）

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

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

  - bpf：在載入時拒絕可休眠的BPF_LSM_CGROUP程式cgroup 填充程序在 rcu_read_lock_dont_migrate（） 下運行，因此我們不應該在那裡附加任何可休眠的 BPF 程式。新增對驗證程式的支援，以明確拒絕嘗試載入以 LSM cgroup 附件為目的地的可休眠 BPF 程式。
    如果沒有這個，我們會在調用 bpf_get_dentry_xattr（） 時從標記為BPF_F_SLEEPABLE附加到 file_open 的 BPF_LSM_CGROUP 程式中得到以下 splat： 錯誤：從 kernel/locking/rwsem.c：1567 的無效上下文呼叫休眠函數 in_atomic（）： 0， irqs_disabled（）： 0， non_block： 0， pid： 34317， name： load preempt_count： 0， 預期：0 RCU 巢狀深度：2，預期：0 呼叫追蹤：down_read+0x76/0x480 ext4_xattr_get+0x11f/0x700 __vfs_getxattr+0xf0/0x150 bpf_get_dentry_xattr+0xbb/0xf0 bpf_prog_e76a298dac9218c6_test_open+0x6a/0x85 __cgroup_bpf_run_lsm_current+0x326/0x840 bpf_trampoline_6442534646+0x62/0x14d security_file_open+0x34/0x60 do_dentry_open+0x340/0x1260 vfs_open+0x7a/0x440 path_openat+0x1bac/0x30a0 libbpf 為每個 libbpf 提供 .s 命名區段變體可休眠程式類型 （lsm_cgroup除外），反映 per-cgroup LSM 程式僅在不可休眠內容中執行。上述 splat 是透過直接使用 bpf（2） 繞過 libbpf 而獲得的。
    (CVE-2026-74338)

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

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

  - netfs：修正遍歷子要求清單時的屏障 修正重試遍歷子要求清單時使用的屏障，因為可能會看到應用程式執行緒剛剛新增的子要求。（CVE-2026-72355）

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

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

  - 已解決 Linux 核心中的下列弱點：ntfs: centalize $INDEX_ROOT header validation Add a dedicated helper to perform stricter validation of $INDEX_ROOT and use it for both directory inodes and named index inodes. This keeps the root size and header geometry checks consistent across both read paths. (CVE-2026-72204)

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

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

  - net/sched： sch_teql：引入 slaves_lock 以避免爭用情形和 UAF teql master->slaves 單鏈錶不受多次寫入保護。它可以從 teql_master_xmit（）、teql_dequeue（）、teql_init（） 和 teql_destroy（） 同時進行修改，而無需持有任何清單鎖定或 RCU 保護。zdi-disclosures@trendmicro.com 已證明 qdisc 會在 RCU 寬限期後釋放，但在另一個 CPU 上執行的 teql_master_xmit（） 仍可將過時指標保留到清單中，從而導致 slab-use-after-free： 錯誤： KASAN：teql_master_xmit+0xf0f/0x16b0 中的 slab-use-after-free 由任務 poc/332 在 addr ffff888013fb0440 讀取大小 8 釋放的 512 位元組區域 [ffff888013fb0400， ffff888013fb0600） （kmalloc-512） 修復？新增每個主slaves_lock同步鎖，以序列化主>從的所有突變以及 teql_destroy（） 和 teql_qdisc_init（） 中的 NEXT_SLAVE（） 連結。
    teql_master_xmit（） 也對這些更新採取相同的slaves_lock。用__rcu註解主>從和每個從屬的 ->next 指標，並在任何接觸到它們的地方使用適當的 RCU 存取子：
    寫入器端的 rcu_assign_pointer（） （在 slaves_lock 下），寫入器端負載的 rcu_dereference_protected（） （也在 slaves_lock 下），teql_master_xmit（） 中的負載的 rcu_dereference_bh（） 和 teql_master_open（）/teql_master_mtu（） 中的負載的 rtnl_dereference（），這些負載在 RTNL 下運行。將其與 teql_master_xmit（） 中清單遍歷周圍的 rcu_read_lock_bh（）/rcu_read_unlock_bh（） 配對，以便讀者要么觀察到完全鍊錶，要么被推遲到正在進行的突變完成。teql_master_xmit（） 中的兩個提前返回路徑已更新，以在返回之前釋放 RCU-bh 讀取端關鍵區段，因為保留它將永久停用該 CPU 上的 BH。（CVE-2026-72390）

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

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

  - GPIO： mvebu：Unbind 上的釋放通用晶片 irq_alloc_domain_generic_chips（） 會配置必須透過 irq_domain_remove_generic_chips（） 釋放的通用晶片資料。devres 動作 mvebu_gpio_remove_irq_domain（） 僅調用 irq_domain_remove（），它僅在設定了 IRQ_DOMAIN_FLAG_DESTROY_GC 時釋放通用晶片。
    請改為在 irq_domain_remove（） 之前明確呼叫 irq_domain_remove_generic_chips（）。（CVE-2026-72324）

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

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 的判定取決於廠商所報告的套件是否存在。

ID	名稱	嚴重性
335636	Linux Distros 未修補弱點：CVE-2026-72423	high
335635	Linux Distros 未修補弱點：CVE-2026-72073	high
335634	Linux Distros 未修補弱點：CVE-2026-74406	critical
335633	Linux Distros 未修補弱點：CVE-2026-72318	critical
335632	Linux Distros 未修補弱點：CVE-2026-72342	high
335631	Linux Distros 未修補弱點：CVE-2026-72166	medium
335630	Linux Distros 未修補弱點：CVE-2026-72150	high
335629	Linux Distros 未修補弱點：CVE-2026-72208	critical
335628	Linux Distros 未修補弱點：CVE-2026-72440	high
335627	Linux Distros 未修補弱點：CVE-2026-72336	high
335626	Linux Distros 未修補弱點：CVE-2026-74337	medium
335625	Linux Distros 未修補弱點：CVE-2026-74264	high
335624	Linux Distros 未修補弱點：CVE-2026-72253	high
335623	Linux Distros 未修補弱點：CVE-2026-72213	high
335622	Linux Distros 未修補弱點：CVE-2026-74359	high
335621	Linux Distros 未修補弱點：CVE-2026-72198	high
335620	Linux Distros 未修補弱點：CVE-2026-72098	critical
335619	Linux Distros 未修補弱點：CVE-2026-72152	high
335618	Linux Distros 未修補弱點：CVE-2026-72115	high
335617	Linux Distros 未修補弱點：CVE-2026-72242	high
335616	Linux Distros 未修補弱點：CVE-2026-74365	high
335615	Linux Distros 未修補弱點：CVE-2026-72472	critical
335614	Linux Distros 未修補弱點：CVE-2026-72315	high
335613	Linux Distros 未修補弱點：CVE-2026-72463	critical
335612	Linux Distros 未修補弱點：CVE-2026-74356	high
335611	Linux Distros 未修補弱點：CVE-2026-74268	critical
335610	Linux Distros 未修補弱點：CVE-2026-72110	high
335609	Linux Distros 未修補弱點：CVE-2026-72041	critical
335608	Linux Distros 未修補弱點：CVE-2026-72065	critical
335607	Linux Distros 未修補弱點：CVE-2026-72201	critical
335606	Linux Distros 未修補弱點：CVE-2026-72243	high
335605	Linux Distros 未修補弱點：CVE-2026-72487	high
335604	Linux Distros 未修補弱點：CVE-2026-72086	high
335603	Linux Distros 未修補弱點：CVE-2026-74334	high
335602	Linux Distros 未修補弱點：CVE-2026-74401	critical
335601	Linux Distros 未修補弱點：CVE-2026-72142	medium
335600	Linux Distros 未修補弱點：CVE-2026-74345	critical
335599	Linux Distros 未修補弱點：CVE-2026-74261	low
335598	Linux Distros 未修補弱點：CVE-2026-72501	medium
335597	Linux Distros 未修補弱點：CVE-2026-74338	high
335596	Linux Distros 未修補弱點：CVE-2026-72355	critical
335595	Linux Distros 未修補弱點：CVE-2026-72204	high
335594	Linux Distros 未修補弱點：CVE-2026-72390	high
335593	Linux Distros 未修補弱點：CVE-2026-72324	medium
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

偵測

Nessus 的 Misc. 系列

high

high

critical

critical

high

medium

high

critical

high

high

medium

high

high

high

high

high

critical

high

high

high

high

critical

high

critical

high

critical

high

critical

critical

critical

high

high

high

high

critical

medium

critical

low

medium

high

critical

high

high

medium

high

high

high

medium

critical

medium