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

  - wifi：rtw88：修正從韌體 RX 描述元讀取超過 DMA 緩衝區的 OOB 讀取 在 rtw_pci_rx_napi（） 中，new_len 計算為 pkt_len （14 位元描述元欄位，最大值 16383） 和 pkt_offset （drv_info_sz + shift，均由韌體控制）。結果可能會超過 RTK_PCI_RX_BUF_SIZE （11478），當 skb_put_data 複製 new_len 個位元組時，造成從預先配置的 DMA 緩衝區越界讀取。USB 傳輸已驗證這一點 （rtw_usb_rx_data_put會針對RTW_USB_MAX_RECVBUF_SZ進行檢查）;PCIe 路徑則沒有。新增檢查，確認new_len不超過 DMA 緩衝區大小。（CVE-2026-74410）

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

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

  - iommu/vt-d：修正探查錯誤路徑中的 RB 樹狀結構損毀 info->node RB 樹狀結構成員會透過 kzalloc 進行零初始化。如果裝置不支援 ATS，則會跳過 device_rbtree_insert（） 呼叫。如果後續探測步驟失敗，錯誤路徑會跳轉至 device_rbtree_remove（），這會將歸零節點誤解為樹根，並損毀裝置 RB 樹狀結構。透過在初始化期間使用 RB_CLEAR_NODE（） 將 RB 節點明確初始化為空並使用 RB_EMPTY_NODE（） 保護刪除來解決此問題。（CVE-2026-74355）

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

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

  - 已解決 Linux 核心中的下列弱點：netfilter: flowtable: Validate iph->ihl in nf_flow_ip4_tunnel_proto() Add sanity check for iph->ihl field in nf_flow_ip4_tunnel_proto() before using it to compute the header size, avoiding out-of-bounds access with malformed IP headers. While at it, use iph->protocol instead of the hardcoded IPPROTO_IPIP constant when setting ctx->tun.proto and reference ctx->tun.hdr_size when updating ctx->offset. (CVE-2026-72417)

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

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

  - KVM：s390：pci：修正 AIF 上的 GISC 參照計數洩漏 啟用失敗 kvm_s390_gisc_register（） 在釘選客體中斷轉送頁面並配置 AISB 位元之前註冊客體 ISC。如果後面的任何設定步驟失敗，函式會解除固定頁面和其他本機狀態，但不會取消註冊 GISC 參照。將遺漏的 kvm_s390_gisc_unregister（） 新增至錯誤展開路徑。（CVE-2026-72290）

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

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

  - net： qrtr：修正 qrtr_endpoint_post（） 中的 32 位整數溢位 qrtr_endpoint_post（） 驗證傳入封包，if （！size || len ！= ALIGN（size， 4） + hdrlen） goto err;其中尺寸來自電線。在 32 位元上，size_t 為 32 位元，而 ALIGN（size， 4） 針對大小 >= 0xfffffffd 換行為 0，因此檢查通過，skb_put_data（skb， data + hdrlen， size） 寫入 hdrlen 大小的 skb 並使核心失敗。64 位元不受影響。這是 ad9d24c9429e2 的 32 位殘差 （net：qrtr：修正 qrtr_endpoint_post 中的 OOB 讀取），僅修正 64 位元大小寫。拒絕任何無法在 ALIGN 之前符合緩衝區的大小。（CVE-2026-72298）

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

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

  - apparmor：使用 peer_path 時修正 unix 通訊端調解中的爭用 保留對 peer_sk 的參照不足以確保存取對等 sk 路徑。存取狀態鎖定之外的路徑允許與 unix_release_sock（） 爭用。透過獲取狀態鎖定並取得對鎖定下路徑的引用來解決此問題。理想情況下，對於連接的通訊端，我們會快取此資訊，這樣我們就不必在這裡鎖定。但現在只是解決比賽問題。（CVE-2026-72462）

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

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

  - 已解決 Linux 核心中的下列弱點：ntfs: make system files immutable to prevent corruption When a system file such as $Bitmap is exposed via show_sys_files and written from userspace, the volume is corrupted and, because the cluster allocator scans $Bitmap through the same inode's page cache, a write to $Bitmap also deadlocks writeback against the folio it already holds locked.
    These files are maintained by the driver itself and have no valid reason to be written through the file interface. Mark base metadata files (mft_no < FILE_first_user) as immutable during inode read so the VFS rejects write, mmap, truncate and unlink with -EPERM. Directories are skipped so the root and $Extend remain usable. Internal metadata updates do not go through the VFS write path and are unaffected.
    (CVE-2026-72186)

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

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

  - fs/ntfs3：將邊界檢查新增至 run_get_highest_vcn（） run_get_highest_vcn（） 會剖析封裝的 NTFS 對應配對緩衝區，而沒有任何長度限制，僅依賴0x00終止符來停止。內嵌屬性包含對應配對的特製 $LogFile UpdateMappingPairs 記錄在沒有終止符的情況下執行，會導致函式讀取過 slab 配置，從而在掛載時觸發 KASAN slab-out-of-bounds 讀取。同級函式 run_unpack（） 在提交 b62567bca474 （ntfs3：將緩衝區邊界檢查新增至 run_unpack（）） 中收到類似的邊界檢查，但遺漏了 run_get_highest_vcn（）。採用 run_buf_size 參數並拒絕任何有效負載將延伸到緩衝區端的執行標頭，以鏡像 run_unpack（） 所使用的模式。fslog.c 中的呼叫端會在對應配對位移之後傳遞剩餘的屬性位元組。KASAN 報告 （在主線 v7.1 合併視窗上 HEAD）： BUG： KASAN： slab-out-of-bounds in run_get_highest_vcn+0x3c0/0x410 透過 task mount/72 在 addr ffff88800e2d5400 讀取大小 1 呼叫追蹤：
    run_get_highest_vcn+0x3c0/0x410 do_action.isra.0+0x3ba8/0x7b50 log_replay+0x9ddd/0x10200 ntfs_loadlog_and_replay+0x4ad/0x610 ntfs_fill_super+0x214a/0x4540 （CVE-2026-72478）

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

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

  - TIPC：需要 TIPCv2 網路連結變動器的網路管理員 TIPCv2 註冊在沒有管理員權限旗標的情況下變更通用網路連結作業。當作業設定GENL_ADMIN_PERM或GENL_UNS_ADMIN_PERM時，一般網路連結只會檢查CAP_NET_ADMIN，因此本機無特權處理程序目前可以透過 TIPC_NL_NET_SET、TIPC_NL_KEY_SET、TIPC_NL_KEY_FLUSH 和承載啟用/停用等命令來變更 TIPC 狀態。
    舊版 TIPC netlink API 已檢查 netlink_net_capable （...， CAP_NET_ADMIN） 是否有管理命令。為 TIPCv2 突變器提供等效的通用網路連結閘道。使用 GENL_UNS_ADMIN_PERM，它對應至相同的命名空間感知CAP_NET_ADMIN檢查 netlink_net_capable（） 的執行情況，以便行為與舊路徑相符，並繼續為非初始使用者命名空間 （容器） 中的CAP_NET_ADMIN持有者工作。以 uid/gid 65534 執行的 QEMU/KASAN 重現，具有零有效功能，先前成功變更網路識別碼和節點身分識別、設定和排清金鑰資料，以及啟用/停用 UDP 承載程式。套用此修補程式後，相同的作業會以 -EPERM 失敗。
    (CVE-2026-74283)

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

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

  - netfilter： ipset：修正 kfree_rcu（） 和 rcu_assign_pointer（） 的順序 Sashiko 指出，在處理註解副檔名時，kfree_rcu（） 是在 rcu_assign_pointer（） 之前呼叫的。修正順序，以便先呼叫 rcu_assign_pointer（）。（CVE-2026-72435）

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

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

  - batman-adv： bla：在 skb realloc 後重新取得 gw 位址 batadv_bla_is_backbone_gw（） 呼叫的 pskb_may_pull（） 可以重新配置 skb 後面的緩衝區。需要重新指派指向舊緩衝區的變數，以避免釋放後使用。（CVE-2026-72233）

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

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

  - landlock：修正 SIGIO 路徑上的LANDLOCK_SCOPE_SIGNAL繞過LANDLOCK_SCOPE_SIGNAL必須防止沙箱處理程序向其 Landlock 網域之外的處理程序發出訊號。它可以透過非同步 SIGIO 遞送路徑繞過。擁有任何檔案或通訊端的沙箱處理程序可以使用 fcntl（fd， F_SETOWN， -pgid）、fcntl（fd， F_SETSIG， SIGKILL） 和 O_ASYNC 來武裝它，以便 I/O 事件使核心將所選訊號傳遞給整個處理程序群組。作為其流程群組任務清單的負責人（fork（） 之後的預設位置），該群組還可以保存啟動它的非沙箱進程，例如主管或安全監控者。因此，沙箱可以終止或發出信號，LANDLOCK_SCOPE_SIGNAL旨在防止它。範圍是在 hook_file_send_sigiotask（） 中針對F_SETOWN時記錄的 Landlock 網域強制執行，而不是針對寄件者的即時網域。
    control_current_fowner（） 會決定是否要記錄該網域，並在 fowner 目標位於呼叫端的執行緒群組中時跳過記錄，這僅對單一任務目標 （PIDTYPE_PID、PIDTYPE_TGID） 安全。對於處理程序群組 （PIDTYPE_PGID） pid_task（） 僅傳回一個成員;每當該成員共享呼叫者的線程組時，就會跳過錄音，然後 hook_file_send_sigiotask（） 讓信號在未選中的情況下扇出到整個組。記錄每個非單一處理程序目標的網域，以便在傳送時針對每個群組成員強制執行範圍。該記錄本身是必要的，但還不夠：核心透過其成員的執行緒群組領導者向進程群組發出訊號，並且註冊者自己的進程的領導者可以攜帶與武裝所有者的同級執行緒不同的 Landlock 網域。然後，domain_is_scoped（） 會拒絕該領導者，即使提交 18eb75f3af40 （landlock：始終允許同一進程的執行緒之間的訊號） 需要允許相同進程傳遞。
    hook_task_kill（） 透過即時評估每個收件者的 same_thread_group（） 來避免這種情況;相反，SIGIO 路徑會將整個決策委派給單一註冊時間檢查，而處理程序群組扇出無法遵循該檢查。因此，也要將註冊者的執行緒群組記錄在其網域旁邊，並在交付時豁免它：
    每當收件者屬於註冊人自己的進程時，hook_file_send_sigiotask（） 就允許訊號，以還原相同進程保證，同時封鎖網域外群組成員。直接 kill（） 路徑 （hook_task_kill） 已評估即時網域，且不受影響。[mic：更早檢查pid_type並改進註解，修正提交訊息，修正註解格式]（CVE-2026-72183）

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

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

  - net： ip_vti：需要裝置 netns 中的 CAP_NET_ADMIN 才能讓 changelink vti_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（） 上閘道 vti_changelink（）。（CVE-2026-72054）

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

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

  - crypto：marvell/octeontx - 修正使用錯誤迴圈索引的 DMA 清理 sg_cleanup 路徑在取消映射 DMA 緩衝區時使用 list[i] 而不是 list[j]，洩露成功映射的項目並重複取消映射失敗的項目。（CVE-2026-74280）

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

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

  - afs： 移除符號連結及裝載點的AS_RELEASE_ALWAYS設定 一般 AFS 檔案會正確使用已將 release_folio 設為 netfs_release_folio 的afs_file_aops，因此當啟用 fscache 時 （透過 afs_vnode_set_cache（） 設定） 時，AS_RELEASE_ALWAYS對它們有效。AFS 中的符號鏈結及裝載點使用 afs_dir_aops，不提供release_folio回呼。然而，afs_apply_status（） 會無條件地呼叫 mapping_set_release_always（） 來處理這些。在這種情況下，當記憶體管理程式碼嘗試釋放對開本時，filemap_release_folio（） 會檢查 folio_needs_release（），由於設定了AS_RELEASE_ALWAYS而傳回 true。由於沒有release_folio回呼，因此它會落入 try_to_free_buffers（），而 （） 目前預期 buffer_heads 不是 null。對於沒有buffer_heads的符號連結和掛載點，這會導致指標解除參照。[dh：新增了更多遺漏的位]（CVE-2026-72377）

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

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

  - batman-adv： mcast：避免 num_dests 標頭的 OOB 讀取 在存取結構batadv_tvlv_mcast_tracker的num_dests之前，會嘗試檢查網路標頭中實際上是否有足夠的空間。但是，不是使用 offsetofend（） 來檢查必須可存取的整個大小 （2），而是呼叫 offsetof（） of。後者一律傳回 0。與網路標頭長度的比較一律會傳回有足夠的資料可用，即使只有 1 或 0 個位元組可供存取。不要使用 offsetofend（），而是對整個標頭使用更常見的檢查。
    (CVE-2026-72227)

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

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

  - 已解決 Linux 核心中的下列弱點：rxrpc: Don't move a peeked OOB message onto the pending queue rxrpc_recvmsg_oob() takes a received oob message off recvmsg_oobq and, if a response is needed, moves it onto the pending_oobq tree. However, only the unlink from recvmsg_oobq is guarded by MSG_PEEK; the move onto pending_oobq always runs. As a result, reading a challenge with MSG_PEEK leaves the skb on recvmsg_oobq while also adding it to pending_oobq. Since struct sk_buff's rbnode shares storage with its next and prev pointers, rb_insert_color() overwrites the list linkage, and the skb, which holds a single reference, becomes reachable from both queues at once. When the socket is closed both queues are drained in turn. While draining recvmsg_oobq, __skb_unlink() follows the next and prev pointers that rbnode has overwritten and writes to a bad address. Also, as the skb holds a single reference but is freed from each queue, both the skb and the connection reference it holds are released twice. This leads to memory corruption and to a use-after-free caused by the connection refcount underflow. MSG_PEEK does not consume the message from the queue, so only unlink it from recvmsg_oobq and then move it onto pending_oobq or free it when the message is actually consumed. (CVE-2026-74434)

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

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

  - net/mlx5： HWS，修正調整大小目標設定失敗時的匹配器洩漏 hws_bwc_matcher_move（） 會在將替代匹配器設定為調整大小目標之前，先配置一個替換匹配器。如果 mlx5hws_matcher_resize_set_target（） 失敗，則替換匹配器不會附加到任何地方並被洩露。在從 resize-target 失敗路徑返回之前，先破壞替換匹配器來修正洩漏。該錯誤首先是由我們在分析 v6.13-rc1 時針對核心記憶體管理錯誤開發的實驗性分析工具標記的。該工具仍在開發中，尚未公開。手動檢查確認該錯誤在 v7.1.1 中仍然存在。x86_64 allyesconfig 組建沒有顯示新的警告。由於我們沒有支援 mlx5 HWS 的裝置可供測試，因此無法執行執行階段測試。（CVE-2026-72032）

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

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

  - 已解決 Linux 核心中的下列弱點：bpf: Reject negative const offsets for buffer pointers The verifier rejects variable offsets for PTR_TO_TP_BUFFER and PTR_TO_BUF accesses, but it currently accepts a constant negative offset produced by pointer arithmetic. Commit 022ac0750883 (bpf:
    use reg->var_off instead of reg->off for pointers) moved constant pointer offsets from reg->off to reg->var_off. However, __check_buffer_access() continued to check only the instruction offset. An access with reg->var_off equal to -8 and an instruction offset of zero therefore passes verification. For writable raw tracepoints, the access end is also calculated from the unsigned reg->var_off.value. An eight-byte access starting at -8 wraps the calculated end to zero, allowing the program to load and attach without increasing max_tp_access. After ensuring that reg->var_off is constant, calculate the effective access start using signed arithmetic and reject it when it is negative. Use the validated start to calculate the access end for both PTR_TO_TP_BUFFER and PTR_TO_BUF. (CVE-2026-68462)

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

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

  - wifi：rtw89：修正 AER 處理常式中錯誤的pci_get_drvdata類型 rtw89 在探測時透過 pci_set_drvdata（） 儲存ieee80211_hw指標，但 io_error_detected（） 和 io_resume（） 會將其擷取為net_device指標。這會導致 netif_device_detach/attach 在ieee80211_hw結構上運行，以錯誤的位移讀取和寫入。相鄰的 io_slot_reset（） 已經正確執行了此操作。請改用 ieee80211_stop_queues/wake_queues，與驅動程式中的所有其他佇列停止/啟動路徑一致。在修正之前和之後從測試模組呼叫處理常式，在RTL8852CE上進行測試。
    (CVE-2026-74413)

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

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

  - MTD： SLRAM：從裝置清單中移除失敗的項目 register_device（） 連結新的slram_mtdlist項目，然後再配置項目所需的所有狀態。如果稍後的分配、memremap（） 或 mtd_device_register（） 失敗，則部分初始化的項目仍保留在全域清單中。然後，稍後的清理可以從該失敗項目中取消參照或釋放無效狀態。在連結項目之後，展開部分初始化的項目，並清除每個失敗路徑上的清單尾部。（CVE-2026-72171）

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

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

  - fbdev： tdfxfb：修正 tdfxfb_probe（） 中潛在的記憶體洩漏 在 tdfxfb_probe（） 中，定義 CONFIG_FB_3DFX_I2C 時使用 fb_videomode_to_modelist（） 配置給 modelist 的記憶體不會在後續錯誤路徑中釋放。透過呼叫 fb_destroy_modelist（） 來修正此問題。（CVE-2026-72268）

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

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

  - RDMA/srpt：修正即時資料長度檢查中的整數溢位 imm_buf->len 是從網路接收的使用者控制uint32_t。將其新增至 imm_data_offset 而不進行溢位檢查，惡意發起者可以傳送 len=0xFFFFFFFF，導致req_size換行到一個小值，繞過邊界檢查，然後傳遞 ~4GB 長度給 sg_init_one（）。在比較之前使用 check_add_overflow（） 來偵測換行。（CVE-2026-74394）

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

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

  - mtd：rawnand：PL353：修正探查資源分配 在 probe（） 期間，會使用父裝置而不是目前裝置呼叫 devm_ioremap（）。因此，當模組卸載時，暫存器區域不會釋放。以 devm_ioremap（） 中的 pl35x 裝置為目標，而不是其父裝置。（CVE-2026-72167）

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

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

  - sunrpc：非同步TLS交握回呼 svc_tcp_handshake（） 的 pin svc_xprt 將原始svc_xprt指標儲存在 tls_handshake_args.ta_data 中，並透過 tls_server_hello_x509（） 提交要求。
    交握核心只需要 sock_hold（req->hr_sk）;沒有任何內容引用 svc_tcp_handshake_done（） 透過 container_of（） 到達的內嵌結構svc_sock。兩個勢均力敵的爭用會讓機中回呼透過釋放的svc_sock寫入。svc_sock_free（） 呼叫 tls_handshake_cancel（） 並捨棄其傳回值：false 傳回表示 handshake_complete（） 已經設定HANDSHAKE_F_REQ_COMPLETED但 hp_done（） 可能尚未完成，但 svc_sock_free（） 繼續執行 kfree（svsk）。svc_tcp_handshake（） 本身內部的取消失敗者 fall-through 會產生相同的視窗：當 wait_for_completion_interruptible_timeout（） 傳回 <= 0（逾時或訊號）並且 tls_handshake_cancel（） 傳回 false 時，函數不會排空，傳回，並且 svc_handle_xprt（） 呼叫 svc_xprt_received（），這會清除XPT_BUSY並可以刪除最後一個引用。然後，當 svc_tcp_handshake_done（） 仍在更新xpt_flags並遍歷 svsk->sk_handshake_done 時，並行關閉會執行 svc_sock_free（）。損毀會以 set_bit/clear_bit RMW 進入釋放的 xpt_flags slab 插槽，以及 complete_all（） 遍歷並寫入嵌入在 sk_handshake_done 中的釋放wait_queue_head_t清單 -- 一個 slab-corruption 原語，而不是良性的讀取。每當連線關閉與 tlshd downcall 傳遞時段重疊時，在任何啟用 TLS 的 NFS 伺服器上都可以連線路徑;可中斷等待意味著訊號傳遞就足夠了，而不僅僅是SVC_HANDSHAKE_TO到期。在 tls_server_hello_x509（） 之前立即取 svc_xprt_get（xprt），以便進行中回呼擁有自己的參照。在保證不觸發回呼的兩個邊緣（tls_server_hello_x509（） 提交失敗和 tls_handshake_cancel（） 成功）以及 complete_all（） 之後的 svc_tcp_handshake_done（） 尾部）釋放它。[cel：重寫提交訊息以描述實際變更]（CVE-2026-72222）

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

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

  - ksmbd：修正 same_client_has_lease（） 中的釋放後使用 same_client_has_lease（） 在刪除 ci->m_lock 而不取得參照後，從 ci->m_op_list 傳回 opinfo 指標。然後，smb_grant_oplock（） 會在 copy_lease（） 中和檢查breaking_cnt時取消參照該指標。並行關閉可以從 ci->m_op_list 移除舊的租用，並在呼叫端使用傳回的指標之前卸除最後一個參考，導致釋放後使用。當 same_client_has_lease（） 選取現有的租用時，取得參照，在掃描時刪除任何先前的相符專案，並在複製租用狀態後釋放 smb_grant_oplock（） 中傳回的參照。（CVE-2026-72492）

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

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

  - platform/x86： ISST： 將 SST-PP 控制還原至所有網域 SST-PP 控制偏移只會在恢復之後還原至電源網域 0。暫停期間，會讀取並儲存所有電源網域的控制值。使用 pd_info->sst_base 而不是 power_domain_info->sst_base，後者僅指向電源網域 0 基底位址。（CVE-2026-72143）

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

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

  - wifi：ath12k：修正vdev_create錯誤路徑中不一致的 arvif 狀態 ath12k_mac_vdev_create（） 有三個錯誤路徑問題，導致 arvif 處於不一致的狀態： 1. 當 ath12k_wmi_vdev_create（） 失敗時，函數會直接傳回，而不清除 arvif->ar，這是在 WMI 呼叫之前就已經設定的。
    後續程式碼檢查 arvif->ar 以判斷 vdev 就緒程度，仍會看到非 NULL 值，即使韌體中沒有 vdev。2. 當 err_peer_del 中的 ath12k_wmi_send_peer_delete_cmd（） 失敗時，程式碼會跳到 err：跳過 DP 對等清理和 vdev 回滾，保留 num_created_vdevs、vdev 映射和 arvif 清單成員資格。3、當ath12k_wait_for_peer_delete_done（）失敗時，程式碼跳轉到err_vdev_del：
    略過 DP 對等清除。透過將 ath12k_wmi_vdev_create（） 失敗變更為 goto err 而不是直接返回、透過 err_dp_peer_del 路由err_peer_del故障路徑來修正：以進行適當的 DP 對等體和 vdev 復原，並在 err： 處合併 arvif 狀態清除。測試對象： WCN7850 hw2.0 PCI WLAN。HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 （CVE-2026-74367）

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

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

  - kho：確保暫存大小始終與CMA_MIN_ALIGNMENT_BYTES對齊 使用 scratch_scale 時，暫存大小會四捨五入為 CMA_MIN_ALIGNMENT_BYTES，因為它們將作為 MIGRATE_CMA 發布。透過命令列使用固定暫存大小時，不會執行此動作。這可能會導致使用者指定未對齊的大小，進而核心釋放僅部分暫存的頁面區塊。對 scratch_size_update（） 中的兩種情況進行四捨五入。（CVE-2026-72169）

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

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

  - 已解決 Linux 核心中的下列弱點：ntfs: avoid stale runlist element dereference in MFT writeback ntfs_write_mft_block() maps each $MFT record through the $MFT data runlist.
    For sub-folio clusters it looks up a struct runlist_element under ni->runlist.lock, drops the lock, and later uses rl->length and rl->vcn when choosing folio_sz. That pointer is only borrowed from ni->runlist.rl. Concurrent $MFT allocation extension can merge a replacement runlist under the same lock, and ntfs_rl_realloc() can free the old backing array. If that happens between the lookup and the later folio_sz decision, writeback can dereference freed runlist storage. The buggy scenario involves two paths, with each column showing the order within that path: MFT writeback path: $MFT allocation extension: 1.
    Look up rl under 1. Extend the $MFT data allocation. ni->runlist.lock. 2. Publish a replacement runlist.
    2. Drop ni->runlist.lock. 3. Free the old runlist array. 3. Read rl->length and rl->vcn to choose folio_sz. Compute the remaining run length while ni->runlist.lock is still held, and use that scalar after unlock. This preserves the existing folio sizing decision without carrying a borrowed runlist_element across the lock boundary. Validation reproduced this kernel report: BUG: KASAN: slab-use-after-free in ntfs_mft_writepages+0x1c8d/0x1fb0 Call Trace: <TASK> dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 ? ntfs_mft_writepages+0x1c8d/0x1fb0 ? srso_alias_return_thunk+0x5/0xfbef5 ? __virt_addr_valid+0x20d/0x410 ? ntfs_mft_writepages+0x1c8d/0x1fb0 kasan_report+0xe0/0x110 ? ntfs_mft_writepages+0x1c8d/0x1fb0 ntfs_mft_writepages+0x1c8d/0x1fb0 ? __pfx_ntfs_mft_writepages+0x10/0x10 ?
    __pfx___mutex_unlock_slowpath+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? iput+0x92/0xa80 do_writepages+0x219/0x530 ? __pfx_do_writepages+0x10/0x10 __writeback_single_inode+0x117/0xf50 ? do_raw_spin_lock+0x130/0x270 ? __pfx_do_raw_spin_lock+0x10/0x10 ? __pfx___writeback_single_inode+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 writeback_sb_inodes+0x65b/0x1810 ? srso_alias_return_thunk+0x5/0xfbef5 ? lock_acquire+0x2b8/0x2f0 ? __pfx_writeback_sb_inodes+0x10/0x10 ? lock_release+0x1e0/0x280 ? _raw_spin_unlock+0x23/0x40 ? move_expired_inodes+0x2b8/0x850
    __writeback_inodes_wb+0xf4/0x270 ? __pfx___writeback_inodes_wb+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? queue_io+0x2e4/0x410 wb_writeback+0x666/0x880 ? srso_alias_return_thunk+0x5/0xfbef5 ? __pfx_wb_writeback+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 ? get_nr_dirty_inodes+0x1c/0x170 wb_workfn+0x75e/0xbb0 ? srso_alias_return_thunk+0x5/0xfbef5 ? _raw_spin_unlock_irqrestore+0x27/0x60 ? __pfx_wb_workfn+0x10/0x10 ?
    __pfx_debug_object_deactivate+0x10/0x10 ? lock_acquire+0x2b8/0x2f0 ? srso_alias_return_thunk+0x5/0xfbef5 ? lock_release+0x1e0/0x280 process_one_work+0x8d0/0x1870 ? __pfx_process_one_work+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 worker_thread+0x575/0xf80 ? __pfx_worker_thread+0x10/0x10 kthread+0x2e7/0x3c0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x576/0x810 ? __pfx_ret_from_fork+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? __switch_to+0x57e/0xe10 ? __switch_to_asm+0x33/0x70 ?
    __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> Allocated by task 970:
    kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0
    __kvmalloc_node_noprof+0x353/0x920 ntfs_rl_realloc+0x3c/0x80 ntfs_runlists_merge+0x1212/0x3010 ntfs_mft_data_extend_allocation_nolock+0x3e0/0x1f40 ntfs_mft_record_alloc+0x1ab4/0x4f10
    __ntfs_create+0x680/0x2e50 ntfs_create+0x1e6/0x3a0 path_openat+0x2b55/0x3c10 do_file_open+0x1f4/0x460 do_sys_openat2+0xde/0x170 __x64_sys_openat+0x122/0x1e0 do_syscall_64+0x115/0x6a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 1294: kasan_save_ ---truncated--- (CVE-2026-72354)

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

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

  - 已解決 Linux 核心中的下列弱點：netfilter: flowtable: fix and simplify IP6IP6 tunnel handling Fix nf_flow_ip6_tunnel_proto() to use pskb_may_pull() instead of skb_header_pointer() to ensure the outer IPv6 header is in the skb headroom, which is required for subsequent packet processing. Move ctx->offset update inside the IPPROTO_IPV6 conditional block since it should only be adjusted when an IP6IP6 tunnel is actually detected. Simplify the rx path by removing ipv6_skip_exthdr() and checking ip6h->nexthdr directly, as the flowtable fast path only handles simple IP6IP6 encapsulation without extension headers. Drop the tunnel encapsulation limit destination option support from the tx path to match, since the rx path no longer handles extension headers. Remove the encap_limit parameter from nf_flow_offload_ipv6_forward(), nf_flow_tunnel_ip6ip6_push() and nf_flow_tunnel_v6_push(), along with the ipv6_tel_txoption struct and related headroom/MTU adjustments.
    (CVE-2026-72442)

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

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

  - fbdev： tridentfb：修正 trident_pci_probe（） 中潛在的記憶體洩漏 在 trident_pci_probe（） 中，使用 fb_videomode_to_modelist（） 配置給 modelist 的記憶體不會在後續錯誤路徑中釋放。透過呼叫 fb_destroy_modelist（） 來修正此問題。（CVE-2026-72264）

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

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

  - power： supply： charger-manager：修正 is_full_charged（） 中的參照計數洩漏 在 is_full_charged（） 中，呼叫 power_supply_get_by_name（） 以取得對 fuel_gauge 電源供應器的參照。如果電壓檢查 （uV >= desc->fullbatt_uV） 成功，則函數直接返回 true，而不釋放參考，從而洩漏參考計數。透過設定旗標並跳轉到 power_supply_put（） 正確刪除引用的 out 標籤來解決此問題。（CVE-2026-72182）

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

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

  - 已解決 Linux 核心中的下列弱點：drm/xe/pt: prevent invalid cursor access for purged BOs During a page table walk for binding, xe_pt_stage_bind() explicitly skips initializing the xe_res_cursor for purged BOs, treating them similarly to NULL VMAs by only setting the cursor size. However, xe_pt_hugepte_possible() and xe_pt_scan_64K() did not check if the BO was purged before attempting to walk the cursor using xe_res_dma() and xe_res_next(). Because the cursor was left uninitialized for purged BOs, this falls through and triggers warnings like: WARNING:
    drivers/gpu/drm/xe/xe_res_cursor.h:274 at xe_res_next Fix this by explicitly checking if the BO is purged in both xe_pt_hugepte_possible() and xe_pt_scan_64K(), returning early just as we do for NULL VMAs, avoiding the invalid cursor accesses entirely. As a precaution, also zero-initialize the cursor in xe_pt_stage_bind() to ensure we don't pass garbage data into the page table walkers if we ever hit a similar edge case in the future. (cherry picked from commit 4c7b9c6ece32440e5a435a92076d049450cd2d2e) (CVE-2026-72358)

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

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

  - ipvs：修正更多具有錯誤 ipv6 傳輸偏移的位置 Sashiko 報告更多不正確的 IPv6 傳輸偏移。TCP 的應用程式程式碼假設 IPv4 網路標頭，即使在提供 ipvsh 引數之後也是如此。
    這可能會導致 IPv6 上的應用程式出現問題。至於核心樹 （FTP） 中唯一的官方應用程序，這個問題是無害的，因為我們使用 Netfilter 來破壞 FTP 端口，並且我們不調整 TCP 序列號。此外，在 ip_vs_out_icmp_v6（） 中提供 ICMPV6 標頭的正確位移，以便在 IPv6 封包具有延伸標頭時進行正確的總和檢查碼檢查。（CVE-2026-68477）

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

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

  - ASoC： SOF： ipc3-control： 驗證 snd_sof_update_control 中的大小 在 snd_sof_update_control（） 中，會針對 local_cdata->data->size 檢查韌體提供的 cdata->num_elems，但絕不針對實際配置大小進行檢查。如果先前將 local_cdata->data->size 設定為不一致的值，則 memcpy 可能會寫入已配置的緩衝區。在複製之前，新增邊界檢查以確保num_elems符合ipc_control_data配置中的可用空間。（CVE-2026-72261）

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

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

  - Bluetooth： MGMT：修正 adv 監視器新增失敗清除 hci_add_adv_monitor（） 會在啟用 MSFT 設定步驟之前在 hdev->adv_monitors_idr 中發佈新adv_monitor。然後，MSFT 卸載新增路徑可能會在本機在控制器新增命令完成之前失敗，或在 MSFT 新增回呼中失敗。在目前排入佇列的管理新增流程中，hci_cmd_sync_work（） 在傳回 msft_add_monitor_pattern（） 之後，仍會使用原始擱置中的命令叫用 mgmt_add_adv_patterns_monitor_complete（）。有錯誤的案例涉及兩條路徑，每欄顯示該路徑內的順序：MSFT 新增處理管理完成 1。插入顯示器和手柄 1.收到同步錯誤 2.發送 MSFT add 命令 2。呼叫 add-monitor 完成 3.回呼看到錯誤的回應 3.載入 cmd->user_data 4.回調釋放監視器 4.讀取 monitor->handle 本機 MSFT 設定失敗具有相同擁有權錯誤的另一半：它們會在插入 IDR 後傳回錯誤，但沒有後續程式碼會從 IDR 中移除失敗的監視器。保留擱置管理命令的所有權，直到其完成為止。針對一般管理新增，MSFT 新增回呼現在會記錄成功的控制器狀態，並將錯誤傳回給呼叫端。複製回應控制碼之後，管理完成會在不成功時釋放監視器，而繼續/重新註冊回呼錯誤清除仍保留在 MSFT 回呼中。
    成功路徑會保留現有的簿記。驗證重現了此核心報告： 錯誤：KASAN：
    slab-use-after-free in mgmt_add_adv_patterns_monitor_complete+0xfb/0x260 [bluetooth] 通話追蹤： <TASK> dump_stack_lvl+0x66/0xa0 print_report+0xce/0x5f0 ？ mgmt_add_adv_patterns_monitor_complete+0xfb/0x260 [藍牙] ？ srso_alias_return_thunk+0x5/0xfbef5 ？ __virt_addr_valid+0x19f/0x330 ？ mgmt_add_adv_patterns_monitor_complete+0xfb/0x260 [藍牙] kasan_report+0xe0/0x110 ？ mgmt_add_adv_patterns_monitor_complete+0xfb/0x260 [藍牙] mgmt_add_adv_patterns_monitor_COMPLETE+0xfb/0x260 [藍牙] ？srso_alias_return_thunk+0x5/0xfbef5 ？0xffffffffc00d00da ？__pfx_mgmt_add_adv_patterns_monitor_complete+0x10/0x10 [藍牙] ？
    __pfx_mgmt_add_adv_patterns_monitor_complete+0x10/0x10 [藍牙] ？hci_cmd_sync_work+0x1ab/0x210 [藍牙] hci_cmd_sync_work+0x1c0/0x210 [藍牙] ？
    __pfx_mgmt_add_adv_patterns_monitor_complete+0x10/0x10 [藍牙] process_one_work+0x4fd/0xbc0 ？
    __pfx_process_one_work+0x10/0x10 ？srso_alias_return_thunk+0x5/0xfbef5 ？srso_alias_return_thunk+0x5/0xfbef5 ？__list_add_valid_or_report+0x37/0xf0 ？
    __pfx_hci_cmd_sync_work+0x10/0x10 [藍牙] ？srso_alias_return_thunk+0x5/0xfbef5 worker_thread+0x2d8/0x570 ？__pfx_worker_thread+0x10/0x10 kthread+0x1ad/0x1f0 ？__pfx_kthread+0x10/0x10 ret_from_fork+0x3c9/0x540 ？__pfx_ret_from_fork+0x10/0x10 ？srso_alias_return_thunk+0x5/0xfbef5 ？
    __switch_to+0x2e9/0x730？__pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> 由 CPU 3 上的任務 471 在 285.205389 秒分配：kasan_save_stack+0x33/0x60 kasan_save_track+0x17/0x60
    __kasan_kmalloc+0xaa/0xb0 add_adv_patterns_monitor_rssi+0xd5/0x230 [藍牙] hci_sock_sendmsg+0x96b/0xf80 [藍牙] __sys_sendto+0x2bc/0x2d0 __x64_sys_sendto+0x76/0x90 do_syscall_64+0x115/0x6a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f 在 285.217112s 處被 CPU 2 上的任務 454 釋放：kasan_save_stack+0x33/0x60 kasan_save_track+0x17/0x60 kasan_save_free_info+0x3b/0x60
    __kasan_slab_free+0x5f/0x80 kfree+0x313/0x590 msft_add_monitor_sync+0x54a/0x570 [藍牙] hci_add_adv_monitor+0x133/0x180 [藍牙] hci_cmd_sync_work+0x187/0x210 [藍牙] 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-72335）

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

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

  - fbdev： i740fb：修正 i740fb_probe（） 中潛在的記憶體洩漏 在 i740fb_probe（） 中，在 fb_videomode_to_modelist（） 中為 modelist 配置的記憶體不會在錯誤路徑中釋放。透過呼叫 fb_destroy_modelist（） 來修正此問題。（CVE-2026-72271）

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

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

  - ASoC： fsl： fsl_audmix：驗證寫入的列舉值 fsl_audmix_put_mix_clk_src（） 及 fsl_audmix_put_out_src（） 以 snd_soc_enum_item_to_val（） 轉換使用者提供的列舉項目，然後再檢查項目是否在列舉的項目計數內。通用 snd_soc_put_enum_double（） 協助程式執行該驗證，但這些回呼首先使用轉換後的值：時鐘源路徑使用 BIT（） 對其進行測試，輸出源路徑用它索引 prms 轉換表。在轉換超出範圍的列舉項目之前，先拒絕它們。（CVE-2026-74293）

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

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

  - lockd：在快取的 nlm_do_fopen（） 失敗時插入 nlm_file refcount 洩漏 nlm_lookup_file（） 中的快取檔案路徑無條件地到達 found： 標籤，即使 nlm_do_fopen（） 失敗也是如此。在那個標籤上
    *result 和 file->f_count 會在傳回錯誤之前更新。包裝函式 nlm3svc_lookup_file（） 和 nlm4svc_lookup_file（） 然後退出其開關，而不將 *result 複製回其調用方，因此 proc 處理常式的本機 nlm_file 指標保持為 NULL，清理路徑會跳過 nlm_release_file（） 。f_count增量永遠不會釋放，並且 nlm_traverse_files（） 無法再收穫該文件，因為它的參照計數永遠不會在請求之間返回為零。使快取路徑短路，以便在雜湊nlm_file上失敗nlm_do_fopen時不觸及 *result 或 f_count。（CVE-2026-72218）

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

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

  - Glances 是一款開放原始碼系統跨平台監控工具。在之前 4.5.6，glances/actions.py 中的 GlancesActions.run（） 會 --disable-config-exec 忽略警示動作命令，並在啟用殼層運算子的情況下叫用 secure_popen（），從而允許在觸發警示時執行已設定的重新導向、命令鏈結或管道。此問題已在 4.5.6中修正。（CVE-2026-68519）

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

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

  - octeontx2-af：正確驗證 NIX 最大 LF 數 NIX 最大 LF 數可透過 devlink 命令設定，但可以在將任何 LF 指派給 PF/VF 之前完成。用於檢查是否已指派任何 LF 的條件不正確。此修補程式修正了這種情況。（CVE-2026-72410）

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

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

  - md/raid10：在重複使用 r10bio 進行 discard 時重設 read_slot。put_all_bios() 一律會釋放 devs[i].bio，但僅在 r10_bio->read_slot < 0 時才釋放 devs[i].repl_bio。如果 discard 重複使用了先前用於讀取的 r10bio，read_slot 可能仍為非負值，discard 清理過程可能會跳過對 repl_bio 的 bio_put()。
    在為 discard 準備 r10bio 時將 read_slot 重設為 -1，以便一律正確釋放替換 bio。(CVE-2026-74376)

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

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

  - xfrm：在比賽期間驗證選擇器系列和 prefixlen syzbot 報告了 xfrm_selector_match（） 中的移界AF_UNSPEC因為具有較大 prefixlen （例如 128） 的選擇器與 IPv4 流程 （當設定了 XFRM_STATE_AF_UNSPEC 時） 相符。透過以下方式解決此問題： - 拒絕xfrm_selector_match中不相符的系列。- 如果 prefixlen > 32，則在 addr4_match 中傳回 false。- 如果 prefixlen > 128，則在 addr_match 中傳回 false （防止溢位）。（CVE-2026-72450）

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

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

  - virtio： rtc：在還原之前拆除舊的 virtqueue virtio_device_restore（） 會重設裝置並還原協商的功能，然後再呼叫 ->restore（）。viortc_freeze（） 故意保留現有的 virtqueues，以便警報佇列仍然可以喚醒系統，但 viortc_restore（） 會立即呼叫 viortc_init_vqs（），而無需先刪除這些舊佇列。如果 virtqueue 重新初始化在 virtio-pci 上失敗，則傳輸錯誤路徑可以針對新配置的 vp_dev->vqs 陣列執行 vp_del_vqs（），而 vdev->vqs 仍包含舊的 virtqueues。然後，vp_del_vqs（） 透過新陣列查詢佇列狀態，並可以在 vp_del_vq（） 中取消參照 NULL 資訊指標，從而在還原期間使客體核心崩潰。在非錯誤重新初始化期間，當其中一個 vp_find_vqs_msix（） 嘗試在稍後的嘗試成功之前失敗時，也會發生這種情況。在重建過時的 virtqueues 之前，先將其刪除。如果在 virtio_device_ready（） 之前還原失敗，請重複使用移除路徑來停止裝置。
    裝置準備就緒後，直接傳回錯誤，而不是再次刪除 virtqueue。
    (CVE-2026-74311)

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

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

  - net： mvneta：還原時重新啟用 percpu 中斷 在 Marvell MPIC 平台 （Armada 370/XP/38x） 上，mvneta 針對 NAPI 使用 percpu IRQ 停用/啟用配置：ISR （mvneta_percpu_isr） 呼叫 disable_percpu_irq（） 以遮罩 MPIC 每個 CPU 中斷，並排程 NAPI 輪詢，該輪詢會在完成時呼叫 enable_percpu_irq（） 以解除遮罩。如果在 NAPI 輪詢擱置期間 （在 ISR 中的 disable_percpu_irq 和輪詢完成的enable_percpu_irq之間） 發生暫停，則永遠不會重新啟用中斷： 1. mvneta_percpu_isr：
    disable_percpu_irq（） + napi_schedule（） => MPIC 遮罩，清除 cpumask 位percpu_enabled 2.NAPI 輪詢在暫停繼續之前不會完成 （PREEMPT_RT這很有可能，因為 softirq 在 ksoftirqd 中執行，該 ksoftirqd 會被凍結;在非 RT 上，當 softirq 處理延遲到 ksoftirqd 時，可能會發生這種情況） 3.
    mvneta_stop_dev => napi_disable（）：取消擱置的輪詢，而不執行完成路徑 4。
    suspend_device_irqs => IRQCHIP_MASK_ON_SUSPEND：遮罩 MPIC （已遮罩，但記錄IRQS_SUSPENDED） 5.
    恢復：mpic_resume檢查 irq_percpu_is_enabled（） => false（在步驟 1 中清除位元）=>跳過取消遮罩 6。
    mvneta_start_dev僅還原裝置層級INTR_NEW_MASK，不會觸及 MPIC 每個 CPU 遮罩 結果：
    MPIC per-CPU 中斷會永久保持遮罩狀態。NIC 會產生中斷 （INTR_NEW_CAUSE ！= 0），但 CPU 從未收到中斷，導致網路連線完全中斷。藉由在還原路徑中呼叫 on_each_cpu（mvneta_percpu_enable） 來修正，以無條件地解除遮罩 MPIC 每個 CPU 中斷，而不論預先暫停狀態為何。（CVE-2026-72409）

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

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

  - bpf： 拒絕在 map-in-map 中將獨佔映射作為內部映射 獨佔映射（使用 excl_prog_hash 建立）通過哈希綁定到單個程序：check_map_prog_compatibility（） 拒絕載入任何摘要不符合 map->excl_prog_sha 的程序。該檢查僅針對程式直接參照的對應（即其used_maps）執行。在運行時通過映射的映射到達的映射永遠不會used_maps，並且 bpf_map_meta_equal（） 不考慮excl_prog_sha，因此可以將獨佔映射插入到非獨佔的外部映射中，然後由不相關的程序查找和變異，繞過獨佔性保證。對於已簽名的載入器，這會破壞已簽名載入器中新增的中繼資料對應排他性檢查：快取的 map->sha[] 會針對已簽名的雜湊進行驗證，而敵對主機上的另一個程式會透過外部對應重寫凍結對應的內容。（CVE-2026-74364）

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

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

  - ASoC： SOF： ipc3-control： 在control_update大小計算中使用溢位檢查 在 sof_ipc3_control_update（） 中，expected_size計算在算術中使用韌體提供的 cdata->num_elems，這在 32 位元平台上可能會溢位，並包裝成一個小值。這樣一來，cdata->rhdr.hdr.size 比較會以不相符的大小通過，進而導致snd_sof_update_control中的越界存取。使用 check_mul_overflow（） 和 check_add_overflow（） 來偵測和拒絕溢位的大小計算。
    (CVE-2026-72302)

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

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

  - gpib：修正 command_ioctl（） 提交 d1857f8296dc 中descriptor_busy的雙重遞減 （GPIB：修正 IO ioctl 處理常式中的釋放後使用） 引入了一個descriptor_busy參照計數器，用於在 IO ioctl 作業中釘選結構gpib_descriptor。在 command_ioctl（） 中，迴圈內的錯誤路徑遞減descriptor_busy並中斷，但執行隨後會下降到迴圈後的無條件遞減，使計數器下溢至 -1。這會重新啟用原始修正所要防止的釋放後使用：並發 close_dev_ioctl（） 會在主動使用的描述元上看到 descriptor_busy == 0 並釋放它。從錯誤路徑中移除早期遞減。循環後遞減已經處理了所有退出路徑，符合 read_ioctl（） 和 write_ioctl（） 中使用的正確模式。（CVE-2026-72482）

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

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

  - 快取檔案：修正錯誤路徑中的雙重解鎖nomem_d_alloc 當 start_creating（） 失敗並傳回 -ENOMEM 時，它已經釋放了 __start_dirop（） 中的父目錄鎖定： static struct dentry
    *__start_dirop（...）{ ...inode_lock_nested（導演，I_MUTEX_PARENT）;dentry = lookup_one_qstr_excl（名稱、父項、lookup_flags）;if （IS_ERR（dentry）） inode_unlock（dir）;<-- 錯誤時釋放鎖定 return dentry;} 然而，cachefiles_get_directory（） 中的nomem_d_alloc錯誤路徑會無條件地再次呼叫 inode_unlock（d_inode（dir）），造成雙重解鎖，破壞 rwsem 狀態。這是提交 7ab96df840e60 的遺留物，該提交用 start_creating（） 取代了手動鎖定，但未能更新nomem_d_alloc路徑（同時正確更新mkdir_error和lookup_error路徑）。
    (CVE-2026-72368)

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

ID	名稱	嚴重性
337572	Linux Distros 未修補弱點：CVE-2026-74410	high
337571	Linux Distros 未修補弱點：CVE-2026-74355	high
337570	Linux Distros 未修補弱點：CVE-2026-72417	critical
337569	Linux Distros 未修補弱點：CVE-2026-72290	high
337568	Linux Distros 未修補弱點：CVE-2026-72298	high
337567	Linux Distros 未修補弱點：CVE-2026-72462	high
337566	Linux Distros 未修補弱點：CVE-2026-72186	critical
337565	Linux Distros 未修補弱點：CVE-2026-72478	high
337564	Linux Distros 未修補弱點：CVE-2026-74283	high
337563	Linux Distros 未修補弱點：CVE-2026-72435	high
337562	Linux Distros 未修補弱點：CVE-2026-72233	high
337561	Linux Distros 未修補弱點：CVE-2026-72183	high
337560	Linux Distros 未修補弱點：CVE-2026-72054	high
337559	Linux Distros 未修補弱點：CVE-2026-74280	critical
337558	Linux Distros 未修補弱點：CVE-2026-72377	high
337557	Linux Distros 未修補弱點：CVE-2026-72227	high
337556	Linux Distros 未修補弱點：CVE-2026-74434	critical
337555	Linux Distros 未修補弱點：CVE-2026-72032	medium
337554	Linux Distros 未修補弱點：CVE-2026-68462	high
337553	Linux Distros 未修補弱點：CVE-2026-74413	high
337552	Linux Distros 未修補弱點：CVE-2026-72171	high
337550	Linux Distros 未修補弱點：CVE-2026-72268	medium
337549	Linux Distros 未修補弱點：CVE-2026-74394	critical
337548	Linux Distros 未修補弱點：CVE-2026-72167	medium
337547	Linux Distros 未修補弱點：CVE-2026-72222	critical
337546	Linux Distros 未修補弱點：CVE-2026-72492	high
337545	Linux Distros 未修補弱點：CVE-2026-72143	high
337544	Linux Distros 未修補弱點：CVE-2026-74367	high
337543	Linux Distros 未修補弱點：CVE-2026-72169	medium
337542	Linux Distros 未修補弱點：CVE-2026-72354	high
337541	Linux Distros 未修補弱點：CVE-2026-72442	critical
337540	Linux Distros 未修補弱點：CVE-2026-72264	medium
337539	Linux Distros 未修補弱點：CVE-2026-72182	high
337538	Linux Distros 未修補弱點：CVE-2026-72358	high
337537	Linux Distros 未修補弱點：CVE-2026-68477	critical
337536	Linux Distros 未修補弱點：CVE-2026-72261	high
337535	Linux Distros 未修補弱點：CVE-2026-72335	high
337534	Linux Distros 未修補弱點：CVE-2026-72271	medium
337533	Linux Distros 未修補弱點：CVE-2026-74293	high
337532	Linux Distros 未修補弱點：CVE-2026-72218	medium
337531	Linux Distros 未修補弱點：CVE-2026-68519	high
337530	Linux Distros 未修補弱點：CVE-2026-72410	high
337529	Linux Distros 未修補弱點：CVE-2026-74376	critical
337528	Linux Distros 未修補弱點：CVE-2026-72450	high
337527	Linux Distros 未修補弱點：CVE-2026-74311	high
337526	Linux Distros 未修補弱點：CVE-2026-72409	high
337525	Linux Distros 未修補弱點：CVE-2026-74364	high
337524	Linux Distros 未修補弱點：CVE-2026-72302	high
337523	Linux Distros 未修補弱點：CVE-2026-72482	high
337522	Linux Distros 未修補弱點：CVE-2026-72368	high

偵測

Nessus 的 Misc. 系列

high

high

critical

high

high

high

critical

high

high

high

high

high

high

critical

high

high

critical

medium

high

high

high

medium

critical

medium

critical

high

high

high

medium

high

critical

medium

high

high

critical

high

high

medium

high

medium

high

high

critical

high

high

high

high

high

high

high